From owner-linux-xfs@oss.sgi.com Wed Oct 1 01:48:22 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 01 Oct 2003 01:49:02 -0700 (PDT) Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h918mLFx008867 for ; Wed, 1 Oct 2003 01:48:22 -0700 Received: from mail-veri.imag.fr (pave.imag.fr [129.88.43.12]) by imag.imag.fr (8.12.10/8.12.10) with ESMTP id h918mJsJ026699 for ; Wed, 1 Oct 2003 10:48:19 +0200 (CEST) Received: from astazou.imag.fr ([129.88.43.102] helo=astazou.imag.fr.imag.fr ident=kowalski) by mail-veri.imag.fr with esmtp (Exim 3.35 #1 (Debian)) id 1A4ceh-0002oi-00 for ; Wed, 01 Oct 2003 10:48:19 +0200 To: linux-xfs@oss.sgi.com Subject: data corruption after hard halt From: Nicolas Kowalski Date: Wed, 01 Oct 2003 10:48:18 +0200 Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Common Lisp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IMAG-MailScanner: Found to be clean X-IMAG-MailScanner-Information: Please contact the ISP for more information X-archive-position: 589 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Nicolas.Kowalski@imag.fr Precedence: bulk X-list: linux-xfs Hello. Yesterday we faced a massive power outage. On our master file server (NFS, Samba, Netatalk) running linux-2.4.21-xfs, some files that were modified a few seconds before the outage on the NFS clients have been truncated to zero sizes on the server. These were not *new* files, but files existing long before this failure. Perhaps this is related to the way the software (Emacs in particular) write files when modifying them, but I am not sure about this. What can I do to prevent this ? Many thanks in advance. PS: by now, this server is running "SGI-XFS CVS-2003-09-24_05:00_UTC", kernel that was installed a few days before this power outage. -- Nicolas From owner-linux-xfs@oss.sgi.com Wed Oct 1 01:54:13 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 01 Oct 2003 01:54:45 -0700 (PDT) Received: from smtp.austarmetro.com.au (root@smtp.austarmetro.com.au [203.166.224.2]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h918sBFx010048 for ; Wed, 1 Oct 2003 01:54:12 -0700 Received: from dialup-54.10.220.203.acc08-dryb-mel.comindico.com.au (dialup-54.10.220.203.acc08-dryb-mel.comindico.com.au [203.220.10.54]) by smtp.austarmetro.com.au (8.12.6/pre1.0-MySQL/8.12.6) with ESMTP id h918s8pe032203 for ; Wed, 1 Oct 2003 18:54:09 +1000 From: MichaelM To: Subject: Binary null problem. Date: Wed, 1 Oct 2003 18:54:10 +0000 User-Agent: KMail/1.5.2 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200310011854.10422.lordvader@austarmetro.com.au> X-Virus-Scanned: by amavisd-new X-archive-position: 590 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lordvader@austarmetro.com.au Precedence: bulk X-list: linux-xfs I do a bit of OpenGL development on my system for my uni assignments. Of course, it does mean that my system will crash every now and then. The thing is, on two seperate occasions I've lost all my work when my code was replace with binary NULLs. Is there a workaround to this such that it doesn't happen again? The FAQ mentions that the kernel writes out to disk every 30 seconds. Perhaps reducing this time may help? I'm using kernel 2.4.22-xfs (pulled from the CVS tree). Any help would be much appreciated. From owner-linux-xfs@oss.sgi.com Wed Oct 1 02:01:18 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 01 Oct 2003 02:01:55 -0700 (PDT) Received: from hermes.acsalaska.net (hermes.acsalaska.net [209.112.155.38]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9191HFx011383 for ; Wed, 1 Oct 2003 02:01:18 -0700 Received: from erbenson.alaska.net (60-pm5.nwc.alaska.net [209.112.139.60]) by hermes.acsalaska.net (8.12.10/8.12.10) with ESMTP id h9191EbL085536 for ; Wed, 1 Oct 2003 01:01:15 -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 4455739E7 for ; Wed, 1 Oct 2003 01:01:12 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id A12E340FF35; Wed, 1 Oct 2003 01:01:13 -0800 (AKDT) Date: Wed, 1 Oct 2003 01:01:13 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: Binary null problem. Message-ID: <20031001090113.GJ1074@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <200310011854.10422.lordvader@austarmetro.com.au> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="F4+N/OgRSdC8YnqX" Content-Disposition: inline In-Reply-To: <200310011854.10422.lordvader@austarmetro.com.au> User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-ACS-Spam-Status: no X-ACS-Scanned-By: MD 2.37; SA 2.55; spamdefang 1.58 X-archive-position: 591 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: erbenson@alaska.net Precedence: bulk X-list: linux-xfs --F4+N/OgRSdC8YnqX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 01, 2003 at 06:54:10PM +0000, MichaelM wrote: > I do a bit of OpenGL development on my system for my uni assignments. Of= =20 > course, it does mean that my system will crash every now and then. > The thing is, on two seperate occasions I've lost all my work when my code > was replace with binary NULLs. > Is there a workaround to this such that it doesn't happen again? The FAQ= =20 > mentions that the kernel writes out to disk every 30 seconds. Perhaps=20 > reducing this time may help? >=20 > I'm using kernel 2.4.22-xfs (pulled from the CVS tree). >=20 > Any help would be much appreciated. chattr -R +S important_srcdir this is equivilent to mount -o sync, but confined to a specific directory so you don't lose speed performance across the entire filesystem. you need current CVS for this to work. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --F4+N/OgRSdC8YnqX 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 iEYEARECAAYFAj96l9kACgkQJKx7GixEevzZDACbBCcDusM8sw/mayumac0l+AWz dekAn0mqxGEW+K/QtaxPLbs3iokwV93L =JC87 -----END PGP SIGNATURE----- --F4+N/OgRSdC8YnqX-- From owner-linux-xfs@oss.sgi.com Wed Oct 1 07:28:58 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 01 Oct 2003 07:29:37 -0700 (PDT) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h91ESvFx006283 for ; Wed, 1 Oct 2003 07:28:58 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h91EkEHc009764 for ; Wed, 1 Oct 2003 09:46:15 -0500 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h91ESqcc11819072 for ; Wed, 1 Oct 2003 09:28:52 -0500 (CDT) Received: from sgi.com (penguin.americas.sgi.com [128.162.240.135]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h91ESqRn304793205 for ; Wed, 1 Oct 2003 09:28:52 -0500 (CDT) Received: from penguin.americas.sgi.com (localhost.localdomain [127.0.0.1]) by sgi.com (8.12.8/8.12.8) with ESMTP id h91EC4Gf007633 for ; Wed, 1 Oct 2003 09:12:04 -0500 Received: (from lord@localhost) by penguin.americas.sgi.com (8.12.8/8.12.8/Submit) id h91EC4cP007631 for linux-xfs@oss.sgi.com; Wed, 1 Oct 2003 09:12:04 -0500 Date: Wed, 1 Oct 2003 09:12:04 -0500 From: Steve Lord Message-Id: <200310011412.h91EC4cP007631@penguin.americas.sgi.com> Subject: TAKE 901712 - performance tweak for unwritten extents To: linux-xfs@oss.sgi.com X-archive-position: 593 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@penguin.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 503 Lines: 19 move unwritten extent conversion for O_DIRECT into the write thread and out of the I/O completion threads. This scales better. Date: Wed Oct 1 07:27:53 PDT 2003 Workarea: penguin.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:159288a linux/fs/xfs/linux/xfs_aops.c - 1.51 - do not setup an I/O completion handler for O_DIRECT writes to unwritten extents, do the conversion in place. From owner-linux-xfs@oss.sgi.com Wed Oct 1 08:12:06 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 01 Oct 2003 08:12:52 -0700 (PDT) Received: from office.lsg.internal (wsip-68-14-236-254.ph.ph.cox.net [68.14.236.254]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h91FC5Fx009788 for ; Wed, 1 Oct 2003 08:12:06 -0700 Received: from [127.0.0.1] (helo=localhost) by office.lsg.internal with esmtp (Exim 4.23) id 1A4idz-0006dl-Vo for linux-xfs@oss.sgi.com; Wed, 01 Oct 2003 08:12:00 -0700 Received: from office.lsg.internal ([127.0.0.1]) by localhost (office.lsg.internal [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25102-10 for ; Wed, 1 Oct 2003 08:11:58 -0700 (MST) Received: from jeeves.kpf.internal ([192.168.170.1]) by office.lsg.internal with esmtp (Exim 4.23) id 1A4idy-0006da-CG for linux-xfs@oss.sgi.com; Wed, 01 Oct 2003 08:11:58 -0700 Received: from [192.168.172.107] (helo=backtobasicsmgmt.com) by jeeves.kpf.internal with esmtp (Exim 4.05) id 1A4ibf-00036w-00 for linux-xfs@oss.sgi.com; Wed, 01 Oct 2003 08:09:35 -0700 Message-ID: <3F7AEE2B.1050100@backtobasicsmgmt.com> Date: Wed, 01 Oct 2003 08:09:31 -0700 From: "Kevin P. Fleming" Organization: Back to Basics Network Management User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: xfsprogs build requires libtool to be installed, but should not Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at labsysgrp.com X-archive-position: 594 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kpfleming@backtobasicsmgmt.com Precedence: bulk X-list: linux-xfs Content-Length: 531 Lines: 10 The xfsprogs package uses libtool for building its objects; no problem there. However, it requires that libtool be installed on the host system during the configure process, but this should not be necessary. The proper way to integrate libtool into a source package includes a copy of the final libtool script itself (not the whole libtool distribution) _into_ the source package, so that the package can be built without the host system needing to have libtool installed. Can someone look into improving this situation? From owner-linux-xfs@oss.sgi.com Wed Oct 1 08:39:39 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 01 Oct 2003 08:40:14 -0700 (PDT) Received: from mail.tamiweb.com (mail.tamiweb.com [194.12.244.146]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h91FdYFx018217 for ; Wed, 1 Oct 2003 08:39:37 -0700 Received: (qmail 16310 invoked by uid 89); 1 Oct 2003 15:43:35 -0000 Received: from unknown (HELO laptop.minfin.bg) (larry@tamiweb.com@217.18.248.91) by 0 with SMTP; 1 Oct 2003 15:43:35 -0000 Subject: cvs missing files From: Kostadin Karaivanov Reply-To: larry@tamiweb.com To: linux-xfs@oss.sgi.com Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-RvmvjoEfa8OzoaCvkBBY" Organization: tamiweb Message-Id: <1065022838.16695.6.camel@laptop.minfin.bg> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Wed, 01 Oct 2003 18:40:39 +0300 X-archive-position: 595 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: larry@tamiweb.com Precedence: bulk X-list: linux-xfs Content-Length: 721 Lines: 28 --=-RvmvjoEfa8OzoaCvkBBY Content-Type: text/plain Content-Transfer-Encoding: quoted-printable linux-2.4-xfs/linux/fs/xfs/ is missing from cvs. This is at least since 16:00 EEST oct. the 1st. The directory is not present in webcvs (http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/linux/fs/) too.=20=20= =20 10x for the great work team. wwell Larry --=-RvmvjoEfa8OzoaCvkBBY Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQA/evV1inq4IVRzHg8RAnQlAJ9rThfIl/I+IDLalPRMXN5EpR2kcwCg2JoK Aeld2/xKe2xJ9ne7gfCSlg0= =RjJ4 -----END PGP SIGNATURE----- --=-RvmvjoEfa8OzoaCvkBBY-- From owner-linux-xfs@oss.sgi.com Wed Oct 1 09:29:56 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 01 Oct 2003 09:30:44 -0700 (PDT) Received: from exchange.dct.be (212-123-1-4.iFiber.telenet-ops.be [212.123.1.4]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h91GTsFx024321 for ; Wed, 1 Oct 2003 09:29:55 -0700 Received: from Jan-DEV.dct.be ([192.168.5.151]) by exchange.dct.be with Microsoft SMTPSVC(5.0.2195.6713); Wed, 1 Oct 2003 11:40:57 +0200 Subject: 20 milion 64k files - SLOW !!! From: Jan De Landtsheer To: linux-xfs@oss.sgi.com Content-Type: text/plain Message-Id: <1065001066.29584.84.camel@Jan-DEV.dct.be> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Wed, 01 Oct 2003 11:37:58 +0200 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Oct 2003 09:40:57.0155 (UTC) FILETIME=[1D6CC130:01C38800] X-archive-position: 596 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jan@dct-mail.com Precedence: bulk X-list: linux-xfs Content-Length: 1075 Lines: 29 Fast in the beginning, but slowing graduately down till not usable any more. I'll try to explain... We have an app that receives 64k measurement data from a bunch of probes. This data will be sent over the Gigabit network to a central TB server on wich I want to use XFS for it's stability. Problem is that once more than 1.000.000 files are written, things gradually slow down, till the way we want to store and retrieve files does not serve any more as a solution. I've writte a little script to test this files creation process as it would be on a live system (python script) and the more files , the slower tings get, till I can only get at about 10 files of 64K/sec, which is way to slow to consider it as a solution. Question is if a filesystem can be used as an alternative for databases, but still... I just want to store files, so I don't think a DB would be a solution, as I also need to retrieve the data as quickly. If Someone wants the script to test and confirm my findings, and eventually help me find a solution, I would be most gratefull. Thanks Jan From owner-linux-xfs@oss.sgi.com Wed Oct 1 09:48:21 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 01 Oct 2003 09:48:55 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h91GmKFx026826 for ; Wed, 1 Oct 2003 09:48:21 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h91GmFq0016237 for ; Wed, 1 Oct 2003 09:48:15 -0700 Received: from tulip-e236.americas.sgi.com (tulip-e236.americas.sgi.com [128.162.236.208]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h91GmEcc11877247; Wed, 1 Oct 2003 11:48:14 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by tulip-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h91GmESn30632689; Wed, 1 Oct 2003 11:48:14 -0500 (CDT) Received: from jen.americas.sgi.com (localhost.localdomain [127.0.0.1]) by jen.americas.sgi.com (8.12.8/8.12.8) with ESMTP id h91GmDKZ032242; Wed, 1 Oct 2003 11:48:13 -0500 Received: (from lord@localhost) by jen.americas.sgi.com (8.12.8/8.12.8/Submit) id h91GmCmE032240; Wed, 1 Oct 2003 11:48:12 -0500 X-Authentication-Warning: jen.americas.sgi.com: lord set sender to lord@sgi.com using -f Subject: Re: 20 milion 64k files - SLOW !!! From: Steve Lord To: Jan De Landtsheer Cc: linux-xfs@oss.sgi.com In-Reply-To: <1065001066.29584.84.camel@Jan-DEV.dct.be> References: <1065001066.29584.84.camel@Jan-DEV.dct.be> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1065026892.26609.115.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 01 Oct 2003 11:48:12 -0500 X-archive-position: 597 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1458 Lines: 39 On Wed, 2003-10-01 at 04:37, Jan De Landtsheer wrote: > Fast in the beginning, but slowing graduately down till not usable any > more. > > I'll try to explain... > We have an app that receives 64k measurement data from a bunch of > probes. > This data will be sent over the Gigabit network to a central TB server > on wich I want to use XFS for it's stability. > > Problem is that once more than 1.000.000 files are written, things > gradually slow down, till the way we want to store and retrieve files > does not serve any more as a solution. > > I've writte a little script to test this files creation process as it > would be on a live system (python script) and the more files , the > slower tings get, till I can only get at about 10 files of 64K/sec, > which is way to slow to consider it as a solution. > > Question is if a filesystem can be used as an alternative for databases, > but still... I just want to store files, so I don't think a DB would be > a solution, as I also need to retrieve the data as quickly. > > If Someone wants the script to test and confirm my findings, and > eventually help me find a solution, I would be most gratefull. Simple question, one directory, or many? any hashing scheme where you put 1 million files in 1 dir is going to slow down as you extend 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 1 13:31:31 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 01 Oct 2003 13:32:06 -0700 (PDT) Received: from saytrin ([62.217.245.194]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h91KVJFx011476 for ; Wed, 1 Oct 2003 13:31:20 -0700 Received: by saytrin (Postfix, from userid 4004) id E10081158; Wed, 1 Oct 2003 23:00:39 +0300 (EEST) Date: Wed, 1 Oct 2003 23:00:39 +0300 From: Iustin Pop To: Nicolas Kowalski Cc: linux-xfs@oss.sgi.com Subject: Re: data corruption after hard halt Message-ID: <20031001200039.GB6236@saytrin.hq.k1024.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Linux: This message was written on Linux X-Header: /usr/include gives great headers User-Agent: Mutt/1.5.4i X-archive-position: 598 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: iusty@k1024.org Precedence: bulk X-list: linux-xfs Content-Length: 816 Lines: 21 > some files that were > modified a few seconds before the outage on the NFS clients have been ^^^^^^^^^^^^^^^^^^^^ As far as I know, you can't protect yourself from this - at least not with XFS. It journals meta-data, not data. Maybe ext3's data journalling can help you, though. > truncated to zero sizes on the server. > > These were not *new* files, but files existing long before this > failure. Perhaps this is related to the way the software (Emacs in > particular) write files when modifying them, but I am not sure about > this. > > What can I do to prevent this ? Except for doing sync (or fsync, from programs), I don't know another software solution. A hardware one is an UPS, coupled to the server, which signals the server to shutdown BEFORE losing power (battery). Regards, Iustin Pop From owner-linux-xfs@oss.sgi.com Wed Oct 1 13:54:15 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 01 Oct 2003 13:54:48 -0700 (PDT) Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h91KsDFx012615 for ; Wed, 1 Oct 2003 13:54:14 -0700 Received: from mail-veri.imag.fr (pave.imag.fr [129.88.43.12]) by imag.imag.fr (8.12.10/8.12.10) with ESMTP id h91KsApK014226 for ; Wed, 1 Oct 2003 22:54:10 +0200 (CEST) Received: from astazou.imag.fr ([129.88.43.102] helo=astazou.imag.fr.imag.fr ident=kowalski) by mail-veri.imag.fr with esmtp (Exim 3.35 #1 (Debian)) id 1A4nz8-0005gL-00 for ; Wed, 01 Oct 2003 22:54:10 +0200 To: linux-xfs@oss.sgi.com Subject: Re: data corruption after hard halt References: <20031001200039.GB6236@saytrin.hq.k1024.org> From: Nicolas Kowalski Date: Wed, 01 Oct 2003 22:54:09 +0200 In-Reply-To: <20031001200039.GB6236@saytrin.hq.k1024.org> (Iustin Pop's message of "Wed, 1 Oct 2003 23:00:39 +0300") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Common Lisp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IMAG-MailScanner: Found to be clean X-IMAG-MailScanner-Information: Please contact the ISP for more information X-archive-position: 599 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Nicolas.Kowalski@imag.fr Precedence: bulk X-list: linux-xfs Content-Length: 1094 Lines: 32 Iustin Pop writes: >> some files that were >> modified a few seconds before the outage on the NFS clients have been > ^^^^^^^^^^^^^^^^^^^^ > As far as I know, you can't protect yourself from this - at least not > with XFS. It journals meta-data, not data. Maybe ext3's data journalling > can help you, though. This is exactly what I was thinking about. Hm. In normal state , XFS is the best filesystem I know (speed, reliability). In the case of hardware/power failures , this is another story; however, these are very very rare events, perhaps one or two max per year, and they do not cause so much damage. So, XFS is still the best choice for us, I hope. By the way, backups are always goods...This saved a lot of my users work. >> What can I do to prevent this ? > Except for doing sync (or fsync, from programs), I don't know another > software solution. A hardware one is an UPS, coupled to the server, > which signals the server to shutdown BEFORE losing power (battery). Actually, this is our UPS which failed... Thanks for your reply. -- Nicolas From owner-linux-xfs@oss.sgi.com Wed Oct 1 14:06:10 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 01 Oct 2003 14:06:51 -0700 (PDT) Received: from saytrin ([62.217.245.194]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h91L5tFx016027 for ; Wed, 1 Oct 2003 14:06:03 -0700 Received: by saytrin (Postfix, from userid 4004) id 14FC724FE; Thu, 2 Oct 2003 00:07:04 +0300 (EEST) Date: Thu, 2 Oct 2003 00:07:04 +0300 From: Iustin Pop To: Nicolas Kowalski Cc: linux-xfs@oss.sgi.com Subject: Re: data corruption after hard halt Message-ID: <20031001210704.GD6236@saytrin.hq.k1024.org> References: <20031001200039.GB6236@saytrin.hq.k1024.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Linux: This message was written on Linux X-Header: /usr/include gives great headers User-Agent: Mutt/1.5.4i X-archive-position: 600 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: iusty@k1024.org Precedence: bulk X-list: linux-xfs Content-Length: 906 Lines: 20 On Wed, Oct 01, 2003 at 10:54:09PM +0200, Nicolas Kowalski wrote: > This is exactly what I was thinking about. Hm. In normal state , XFS > is the best filesystem I know (speed, reliability). In the case of > hardware/power failures , this is another story; however, these are > very very rare events, perhaps one or two max per year, and they do > not cause so much damage. So, XFS is still the best choice for us, I > hope. Maybe using chattr +S on important files, as said on the list elsewhere (but code is not yet in release version) And related to hardware failures, I got very good (until now) experiences from XFS once when the RAID controller went bad on me while adding a logical drive; but XFS just had just shutdown that filesystem and everything was OK, no problems. > Actually, this is our UPS which failed... Well, that is certainly a sad moment... Sorry for the CAPS then :) Iustin Pop From owner-linux-xfs@oss.sgi.com Wed Oct 1 14:09:32 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 01 Oct 2003 14:10:05 -0700 (PDT) Received: from shell.wgops.com (postfix@shell.wgops.com [66.92.192.108]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h91L9VFx016450 for ; Wed, 1 Oct 2003 14:09:32 -0700 Received: from [10.1.2.77] (jobe.wgops.com [10.1.2.77]) by shell.wgops.com (Postfix) with ESMTP id 9F0CA2537B for ; Wed, 1 Oct 2003 15:09:02 -0600 (MDT) Date: Wed, 01 Oct 2003 15:08:29 -0600 From: Michael Loftis To: linux-xfs@oss.sgi.com Subject: XFS internel errors (oops?) Message-ID: <126430627.1065020909@[10.1.2.77]> X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-MailScanner-Information: Please contact support@wgops.com X-MailScanner: WGOPS clean X-archive-position: 601 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mloftis@wgops.com Precedence: bulk X-list: linux-xfs Content-Length: 5621 Lines: 132 OK at about 3AM this morning under heavy-ish load one of the remaining NFS fileservers with XFS quipped the below... It's still..running....I don't know if that's a good thing or not. We're looking at about 160GB of storage, and this sysem is extremely downtime sensitive, I can't just take the thing offline... 0x0: 58 46 53 42 00 00 10 00 00 00 00 00 02 14 ac 20 Filesystem "dac960(48,3)": XFS internal error xfs_itobp at line 382 of file xfs_inode.c. Caller 0xf889b40b f6f8fc94 f889a164 f88de7ea 00000001 f773c400 f88de7d2 0000017e f889b40b f889b40b 00000000 00000000 00a80200 cf7d4140 f7bb8524 cf7d4140 e07920a0 00000001 00000000 00000001 cf7d4140 f88eea90 00000000 00000000 00000010 Call Trace: [] xfs_itobp+0x1a4/0x1f0 [xfs] [] .rodata.str1.1+0x5ea/0x190c [xfs] [] .rodata.str1.1+0x5d2/0x190c [xfs] [] xfs_iread+0x5b/0x1c0 [xfs] [] xfs_iread+0x5b/0x1c0 [xfs] [] pbhash+0xc30/0x1000 [xfs] [] xfs_trans_brelse+0x4d/0xf0 [xfs] [] xfs_iread+0x5b/0x1c0 [xfs] [] xfs_iget_core+0x14a/0x480 [xfs] [] xfs_iget+0x7d/0x150 [xfs] [] xfs_vget+0x4b/0xba [xfs] [] vfs_vget+0x21/0x30 [xfs] [] linvfs_fh_to_dentry+0x6e/0x100 [xfs] [] nfsd_get_dentry+0x28/0xb0 [nfsd] [] find_fh_dentry+0x14d/0x360 [nfsd] [] fh_verify+0x271/0x470 [nfsd] [] svc_sock_enqueue+0x184/0x200 [sunrpc] [] nfsd_access+0x1c/0xe0 [nfsd] [] nfsd3_proc_access+0xb7/0xd0 [nfsd] [] nfsd_procedures3+0x90/0x360 [nfsd] [] nfsd_procedures3+0x90/0x360 [nfsd] [] nfsd_dispatch+0xb7/0x17b [nfsd] [] svc_process_Rsmp_cec9731f+0x347/0x518 [sunrpc] [] nfsd_version3+0x0/0x10 [nfsd] [] nfsd_program+0x0/0x28 [nfsd] [] nfsd+0x20c/0x360 [nfsd] [] nfsd+0x0/0x360 [nfsd] [] arch_kernel_thread+0x26/0x30 [kernel] [] nfsd+0x0/0x360 [nfsd] 0x0: 58 46 53 42 00 00 10 00 00 00 00 00 02 14 ac 20 Filesystem "dac960(48,3)": XFS internal error xfs_itobp at line 382 of file xfs_inode.c. Caller 0xf889b40b f6f8fc94 f889a164 f88de7ea 00000001 f773c400 f88de7d2 0000017e f889b40b f889b40b 00000000 00000000 00000004 cf7d4140 d6fbd320 00000000 c03c6ae0 00000001 00000080 ddae5ea4 ddae5e90 00000000 00000000 00000000 00000010 Call Trace: [] xfs_itobp+0x1a4/0x1f0 [xfs] [] .rodata.str1.1+0x5ea/0x190c [xfs] [] .rodata.str1.1+0x5d2/0x190c [xfs] [] xfs_iread+0x5b/0x1c0 [xfs] [] xfs_iread+0x5b/0x1c0 [xfs] [] output_maybe_reroute+0x0/0x10 [kernel] [] xfs_iread+0x5b/0x1c0 [xfs] [] output_maybe_reroute+0xb/0x10 [kernel] [] xfs_iget_core+0x14a/0x480 [xfs] [] xfs_iget+0x7d/0x150 [xfs] [] xfs_vget+0x4b/0xba [xfs] [] vfs_vget+0x21/0x30 [xfs] [] linvfs_fh_to_dentry+0x6e/0x100 [xfs] [] nfsd_get_dentry+0x28/0xb0 [nfsd] [] find_fh_dentry+0x14d/0x360 [nfsd] [] inet_sendmsg+0x35/0x40 [kernel] [] fh_verify+0x271/0x470 [nfsd] [] nfsd_access+0x1c/0xe0 [nfsd] [] nfsd3_proc_access+0xb7/0xd0 [nfsd] [] nfsd_procedures3+0x90/0x360 [nfsd] [] nfsd_procedures3+0x90/0x360 [nfsd] [] nfsd_dispatch+0xb7/0x17b [nfsd] [] svc_process_Rsmp_cec9731f+0x347/0x518 [sunrpc] [] nfsd_version3+0x0/0x10 [nfsd] [] nfsd_program+0x0/0x28 [nfsd] [] nfsd+0x20c/0x360 [nfsd] [] nfsd+0x0/0x360 [nfsd] [] arch_kernel_thread+0x26/0x30 [kernel] [] nfsd+0x0/0x360 [nfsd] 0x0: 58 46 53 42 00 00 10 00 00 00 00 00 02 14 ac 20 Filesystem "dac960(48,3)": XFS internal error xfs_itobp at line 382 of file xfs_inode.c. Caller 0xf889b40b f6f8dc94 f889a164 f88de7ea 00000001 f773c400 f88de7d2 0000017e f889b40b f889b40b 00000000 00000000 00a80200 f0858900 f7bb8524 c0359dac c0359cec c0359cdc 00000001 c01db013 c0359cec f6f8dcf0 00000000 00000000 00000010 Call Trace: [] xfs_itobp+0x1a4/0x1f0 [xfs] [] .rodata.str1.1+0x5ea/0x190c [xfs] [] .rodata.str1.1+0x5d2/0x190c [xfs] [] xfs_iread+0x5b/0x1c0 [xfs] [] xfs_iread+0x5b/0x1c0 [xfs] [] net_rx_action+0xb3/0x170 [kernel] [] xfs_iread+0x5b/0x1c0 [xfs] [] xfs_iget_core+0x14a/0x480 [xfs] [] xfs_iget+0x7d/0x150 [xfs] [] xfs_vget+0x4b/0xba [xfs] [] vfs_vget+0x21/0x30 [xfs] [] linvfs_fh_to_dentry+0x6e/0x100 [xfs] [] nfsd_get_dentry+0x28/0xb0 [nfsd] [] find_fh_dentry+0x14d/0x360 [nfsd] [] fh_verify+0x271/0x470 [nfsd] [] svc_sock_enqueue+0x184/0x200 [sunrpc] [] nfsd_access+0x1c/0xe0 [nfsd] [] nfsd3_proc_access+0xb7/0xd0 [nfsd] [] nfsd_procedures3+0x90/0x360 [nfsd] [] nfsd_procedures3+0x90/0x360 [nfsd] [] nfsd_dispatch+0xb7/0x17b [nfsd] [] svc_process_Rsmp_cec9731f+0x347/0x518 [sunrpc] [] nfsd_version3+0x0/0x10 [nfsd] [] nfsd_program+0x0/0x28 [nfsd] [] nfsd+0x20c/0x360 [nfsd] [] nfsd+0x0/0x360 [nfsd] [] arch_kernel_thread+0x26/0x30 [kernel] [] nfsd+0x0/0x360 [nfsd] -- Undocumented Features quote of the moment... "It's not the one bullet with your name on it that you have to worry about; it's the twenty thousand-odd rounds labeled `occupant.'" --Murphy's Laws of Combat From owner-linux-xfs@oss.sgi.com Wed Oct 1 14:30:26 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 01 Oct 2003 14:31:01 -0700 (PDT) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h91LUQFx017017 for ; Wed, 1 Oct 2003 14:30:26 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h91JXqOO025785 for ; Wed, 1 Oct 2003 12:33:52 -0700 Received: from tulip-e236.americas.sgi.com (tulip-e236.americas.sgi.com [128.162.236.208]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h91LUKcc11907790; Wed, 1 Oct 2003 16:30:20 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by tulip-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h91LUKSn30613312; Wed, 1 Oct 2003 16:30:20 -0500 (CDT) Received: from jen.americas.sgi.com (localhost.localdomain [127.0.0.1]) by jen.americas.sgi.com (8.12.8/8.12.8) with ESMTP id h91LUJKZ002372; Wed, 1 Oct 2003 16:30:19 -0500 Received: (from lord@localhost) by jen.americas.sgi.com (8.12.8/8.12.8/Submit) id h91LUJCH002370; Wed, 1 Oct 2003 16:30:19 -0500 X-Authentication-Warning: jen.americas.sgi.com: lord set sender to lord@sgi.com using -f Subject: Re: XFS internel errors (oops?) From: Steve Lord To: Michael Loftis Cc: linux-xfs@oss.sgi.com In-Reply-To: <126430627.1065020909@[10.1.2.77]> References: <126430627.1065020909@[10.1.2.77]> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1065043818.26615.376.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 01 Oct 2003 16:30:18 -0500 X-archive-position: 602 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 6289 Lines: 146 On Wed, 2003-10-01 at 16:08, Michael Loftis wrote: > OK at about 3AM this morning under heavy-ish load one of the remaining NFS > fileservers with XFS quipped the below... > > It's still..running....I don't know if that's a good thing or not. > We're looking at about 160GB of storage, and this sysem is extremely > downtime sensitive, I can't just take the thing offline... This is a stale/bad nfs file handle, some debugging info added to xfs was a but gratuitous in this case and has been turned off unless you crack up some debug options. Should not have caused any harm. Steve > > 0x0: 58 46 53 42 00 00 10 00 00 00 00 00 02 14 ac 20 > Filesystem "dac960(48,3)": XFS internal error xfs_itobp at line 382 of file > xfs_inode.c. Caller 0xf889b40b > f6f8fc94 f889a164 f88de7ea 00000001 f773c400 f88de7d2 0000017e f889b40b > f889b40b 00000000 00000000 00a80200 cf7d4140 f7bb8524 cf7d4140 > e07920a0 > 00000001 00000000 00000001 cf7d4140 f88eea90 00000000 00000000 > 00000010 > Call Trace: > [] xfs_itobp+0x1a4/0x1f0 [xfs] > [] .rodata.str1.1+0x5ea/0x190c [xfs] > [] .rodata.str1.1+0x5d2/0x190c [xfs] > [] xfs_iread+0x5b/0x1c0 [xfs] > [] xfs_iread+0x5b/0x1c0 [xfs] > [] pbhash+0xc30/0x1000 [xfs] > [] xfs_trans_brelse+0x4d/0xf0 [xfs] > [] xfs_iread+0x5b/0x1c0 [xfs] > [] xfs_iget_core+0x14a/0x480 [xfs] > [] xfs_iget+0x7d/0x150 [xfs] > [] xfs_vget+0x4b/0xba [xfs] > [] vfs_vget+0x21/0x30 [xfs] > [] linvfs_fh_to_dentry+0x6e/0x100 [xfs] > [] nfsd_get_dentry+0x28/0xb0 [nfsd] > [] find_fh_dentry+0x14d/0x360 [nfsd] > [] fh_verify+0x271/0x470 [nfsd] > [] svc_sock_enqueue+0x184/0x200 [sunrpc] > [] nfsd_access+0x1c/0xe0 [nfsd] > [] nfsd3_proc_access+0xb7/0xd0 [nfsd] > [] nfsd_procedures3+0x90/0x360 [nfsd] > [] nfsd_procedures3+0x90/0x360 [nfsd] > [] nfsd_dispatch+0xb7/0x17b [nfsd] > [] svc_process_Rsmp_cec9731f+0x347/0x518 [sunrpc] > [] nfsd_version3+0x0/0x10 [nfsd] > [] nfsd_program+0x0/0x28 [nfsd] > [] nfsd+0x20c/0x360 [nfsd] > [] nfsd+0x0/0x360 [nfsd] > [] arch_kernel_thread+0x26/0x30 [kernel] > [] nfsd+0x0/0x360 [nfsd] > > 0x0: 58 46 53 42 00 00 10 00 00 00 00 00 02 14 ac 20 > Filesystem "dac960(48,3)": XFS internal error xfs_itobp at line 382 of file > xfs_inode.c. Caller 0xf889b40b > f6f8fc94 f889a164 f88de7ea 00000001 f773c400 f88de7d2 0000017e f889b40b > f889b40b 00000000 00000000 00000004 cf7d4140 d6fbd320 00000000 > c03c6ae0 > 00000001 00000080 ddae5ea4 ddae5e90 00000000 00000000 00000000 > 00000010 > Call Trace: > [] xfs_itobp+0x1a4/0x1f0 [xfs] > [] .rodata.str1.1+0x5ea/0x190c [xfs] > [] .rodata.str1.1+0x5d2/0x190c [xfs] > [] xfs_iread+0x5b/0x1c0 [xfs] > [] xfs_iread+0x5b/0x1c0 [xfs] > [] output_maybe_reroute+0x0/0x10 [kernel] > [] xfs_iread+0x5b/0x1c0 [xfs] > [] output_maybe_reroute+0xb/0x10 [kernel] > [] xfs_iget_core+0x14a/0x480 [xfs] > [] xfs_iget+0x7d/0x150 [xfs] > [] xfs_vget+0x4b/0xba [xfs] > [] vfs_vget+0x21/0x30 [xfs] > [] linvfs_fh_to_dentry+0x6e/0x100 [xfs] > [] nfsd_get_dentry+0x28/0xb0 [nfsd] > [] find_fh_dentry+0x14d/0x360 [nfsd] > [] inet_sendmsg+0x35/0x40 [kernel] > [] fh_verify+0x271/0x470 [nfsd] > [] nfsd_access+0x1c/0xe0 [nfsd] > [] nfsd3_proc_access+0xb7/0xd0 [nfsd] > [] nfsd_procedures3+0x90/0x360 [nfsd] > [] nfsd_procedures3+0x90/0x360 [nfsd] > [] nfsd_dispatch+0xb7/0x17b [nfsd] > [] svc_process_Rsmp_cec9731f+0x347/0x518 [sunrpc] > [] nfsd_version3+0x0/0x10 [nfsd] > [] nfsd_program+0x0/0x28 [nfsd] > [] nfsd+0x20c/0x360 [nfsd] > [] nfsd+0x0/0x360 [nfsd] > [] arch_kernel_thread+0x26/0x30 [kernel] > [] nfsd+0x0/0x360 [nfsd] > > 0x0: 58 46 53 42 00 00 10 00 00 00 00 00 02 14 ac 20 > Filesystem "dac960(48,3)": XFS internal error xfs_itobp at line 382 of file > xfs_inode.c. Caller 0xf889b40b > f6f8dc94 f889a164 f88de7ea 00000001 f773c400 f88de7d2 0000017e f889b40b > f889b40b 00000000 00000000 00a80200 f0858900 f7bb8524 c0359dac > c0359cec > c0359cdc 00000001 c01db013 c0359cec f6f8dcf0 00000000 00000000 > 00000010 > Call Trace: > [] xfs_itobp+0x1a4/0x1f0 [xfs] > [] .rodata.str1.1+0x5ea/0x190c [xfs] > [] .rodata.str1.1+0x5d2/0x190c [xfs] > [] xfs_iread+0x5b/0x1c0 [xfs] > [] xfs_iread+0x5b/0x1c0 [xfs] > [] net_rx_action+0xb3/0x170 [kernel] > [] xfs_iread+0x5b/0x1c0 [xfs] > [] xfs_iget_core+0x14a/0x480 [xfs] > [] xfs_iget+0x7d/0x150 [xfs] > [] xfs_vget+0x4b/0xba [xfs] > [] vfs_vget+0x21/0x30 [xfs] > [] linvfs_fh_to_dentry+0x6e/0x100 [xfs] > [] nfsd_get_dentry+0x28/0xb0 [nfsd] > [] find_fh_dentry+0x14d/0x360 [nfsd] > [] fh_verify+0x271/0x470 [nfsd] > [] svc_sock_enqueue+0x184/0x200 [sunrpc] > [] nfsd_access+0x1c/0xe0 [nfsd] > [] nfsd3_proc_access+0xb7/0xd0 [nfsd] > [] nfsd_procedures3+0x90/0x360 [nfsd] > [] nfsd_procedures3+0x90/0x360 [nfsd] > [] nfsd_dispatch+0xb7/0x17b [nfsd] > [] svc_process_Rsmp_cec9731f+0x347/0x518 [sunrpc] > [] nfsd_version3+0x0/0x10 [nfsd] > [] nfsd_program+0x0/0x28 [nfsd] > [] nfsd+0x20c/0x360 [nfsd] > [] nfsd+0x0/0x360 [nfsd] > [] arch_kernel_thread+0x26/0x30 [kernel] > [] nfsd+0x0/0x360 [nfsd] > > > > -- > Undocumented Features quote of the moment... > "It's not the one bullet with your name on it that you > have to worry about; it's the twenty thousand-odd rounds > labeled `occupant.'" > --Murphy's Laws of Combat -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Wed Oct 1 14:37:05 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 01 Oct 2003 14:37:37 -0700 (PDT) Received: from shell.wgops.com (postfix@shell.wgops.com [66.92.192.108]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h91Lb4Fx017441 for ; Wed, 1 Oct 2003 14:37:05 -0700 Received: from [10.1.2.77] (jobe.wgops.com [10.1.2.77]) by shell.wgops.com (Postfix) with ESMTP id B94FF25389 for ; Wed, 1 Oct 2003 15:36:54 -0600 (MDT) Date: Wed, 01 Oct 2003 15:36:22 -0600 From: Michael Loftis Cc: linux-xfs@oss.sgi.com Subject: Re: XFS internel errors (oops?) Message-ID: <128102762.1065022582@[10.1.2.77]> In-Reply-To: <1065043818.26615.376.camel@jen.americas.sgi.com> References: <126430627.1065020909@[10.1.2.77]> <1065043818.26615.376.camel@jen.americas.sgi.com> X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-MailScanner-Information: Please contact support@wgops.com X-MailScanner: WGOPS clean X-archive-position: 603 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mloftis@wgops.com Precedence: bulk X-list: linux-xfs Content-Length: 1322 Lines: 36 Thanks, I appreciate the response...I have had this trace (or similar ones) happen before, but they seemed to have stopped after we xfs_repair-ed during one long planned downtime (actually went longer, lots of smallish files, webserver store)... I'm due for another round of kernel upgrades in a couple months for that box and other sensitive ones, I'll be sure and catch the latest XFS patches again when I do. --On Wednesday, October 01, 2003 4:30 PM -0500 Steve Lord wrote: > On Wed, 2003-10-01 at 16:08, Michael Loftis wrote: >> OK at about 3AM this morning under heavy-ish load one of the remaining >> NFS fileservers with XFS quipped the below... >> >> It's still..running....I don't know if that's a good thing or not. >> We're looking at about 160GB of storage, and this sysem is extremely >> downtime sensitive, I can't just take the thing offline... > > > This is a stale/bad nfs file handle, some debugging info added to > xfs was a but gratuitous in this case and has been turned off > unless you crack up some debug options. Should not have caused > any harm. > > Steve > -- Undocumented Features quote of the moment... "It's not the one bullet with your name on it that you have to worry about; it's the twenty thousand-odd rounds labeled `occupant.'" --Murphy's Laws of Combat From owner-linux-xfs@oss.sgi.com Wed Oct 1 20:27:42 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 01 Oct 2003 20:28:22 -0700 (PDT) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h923Rg25031720 for ; Wed, 1 Oct 2003 20:27:42 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id h921V6OO021175 for ; Wed, 1 Oct 2003 18:31:08 -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 NAA07988; Thu, 2 Oct 2003 13:27:30 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h923RTYN160233; Thu, 2 Oct 2003 13:27:29 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id h923P1qK001024; Thu, 2 Oct 2003 13:25:01 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id h923OwFr001022; Thu, 2 Oct 2003 13:24:58 +1000 Date: Thu, 2 Oct 2003 13:24:58 +1000 From: Nathan Scott To: "Kevin P. Fleming" Cc: linux-xfs@oss.sgi.com Subject: Re: xfsprogs build requires libtool to be installed, but should not Message-ID: <20031002032458.GA719@frodo> References: <3F7AEE2B.1050100@backtobasicsmgmt.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F7AEE2B.1050100@backtobasicsmgmt.com> User-Agent: Mutt/1.5.3i X-archive-position: 604 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1048 Lines: 27 On Wed, Oct 01, 2003 at 08:09:31AM -0700, Kevin P. Fleming wrote: > The xfsprogs package uses libtool for building its objects; no problem > there. However, it requires that libtool be installed on the host > system during the configure process, but this should not be necessary. > The proper way to integrate libtool into a source package includes a ^^^^^^ Why? libtool is a very hairy 5000+ line shell script ... since all distributions include it in a nice self-contained package, I don't understand why every package should also include an arbitary version of it as well. > copy of the final libtool script itself (not the whole libtool > distribution) _into_ the source package, so that the package can be > built without the host system needing to have libtool installed. Numerous other build tools must be installed to build XFS userspace, requiring libtool be installed as well doesn't seem like a big deal. > Can someone look into improving this situation? I see no compelling reason to change it. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Oct 1 22:10:44 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 01 Oct 2003 22:11:17 -0700 (PDT) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h925Ai25001997 for ; Wed, 1 Oct 2003 22:10:44 -0700 Received: from bruce.melbourne.sgi.com (bruce.melbourne.sgi.com [134.14.54.176]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h923EAOO027940 for ; Wed, 1 Oct 2003 20:14:11 -0700 Received: from bruce.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by bruce.melbourne.sgi.com (8.12.8/8.12.8) with ESMTP id h924upkn012869 for ; Thu, 2 Oct 2003 14:56:51 +1000 Received: (from nathans@localhost) by bruce.melbourne.sgi.com (8.12.8/8.12.8/Submit) id h924uo48012868 for linux-xfs@oss.sgi.com; Thu, 2 Oct 2003 14:56:50 +1000 Date: Thu, 2 Oct 2003 14:56:50 +1000 From: Nathan Scott Message-Id: <200310020456.h924uo48012868@bruce.melbourne.sgi.com> Subject: TAKE - xfstests X-archive-position: 605 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@bruce.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 377 Lines: 14 Fix dump tests which compare before/after dumps using ls - directory size is not constant in the presense of both large and small inums. Date: Wed Oct 1 22:09:02 PDT 2003 Workarea: bruce.melbourne.sgi.com:/build2/devel26 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: xfs-cmds:slinx:159337a cmd/xfstests/common.dump - 1.44 From owner-linux-xfs@oss.sgi.com Thu Oct 2 04:35:10 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 02 Oct 2003 04:35:50 -0700 (PDT) Received: from postfix4-2.free.fr (postfix4-2.free.fr [213.228.0.176]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h92BZ925006315 for ; Thu, 2 Oct 2003 04:35:10 -0700 Received: from monaco.net (unknown [81.56.190.19]) by postfix4-2.free.fr (Postfix) with ESMTP id D5DE5C995 for ; Thu, 2 Oct 2003 13:35:07 +0200 (CEST) Message-ID: <3F7C0D52.6070403@monaco.net> Date: Thu, 02 Oct 2003 13:34:42 +0200 From: deny User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: fr-fr, fr MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: could not open default font fixed Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 607 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: deny@monaco.net Precedence: bulk X-list: linux-xfs Content-Length: 488 Lines: 31 hi i ve this message on my mandrake 9.0 when i am booting what i do before ? i stop abruptely after a froze when try to ending mandrake i try to stop my xfs server i do init 3 and try to launch xfs but i dont know the exact command (xfs start or stop dont work i ve the message : usage xfs -config config-file -port etc..... i try to update the system but i am blocked just after reconfiguring the rpm base (from the cd rom install n 1 ) i don't know what else to do thanks From owner-linux-xfs@oss.sgi.com Thu Oct 2 05:07:26 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 02 Oct 2003 05:07:46 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10) with ESMTP id h92C7Q25009620 for ; Thu, 2 Oct 2003 05:07:26 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id h92C7QMK009619 for linux-xfs@oss.sgi.com; Thu, 2 Oct 2003 05:07:26 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10) with ESMTP id h92C7N2B009588 for ; Thu, 2 Oct 2003 05:07:24 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id h92C09cs009441; Thu, 2 Oct 2003 05:00:09 -0700 Date: Thu, 2 Oct 2003 05:00:09 -0700 Message-Id: <200310021200.h92C09cs009441@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 267] pwrite64 failed on 1.2 TB evms volume X-Bugzilla-Reason: AssignedTo X-archive-position: 608 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 380 Lines: 17 http://oss.sgi.com/bugzilla/show_bug.cgi?id=267 dg@ethx.de changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEW ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Oct 2 05:07:27 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 02 Oct 2003 05:07:46 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10) with ESMTP id h92C7Q25009621 for ; Thu, 2 Oct 2003 05:07:26 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id h92C7Qxq009618 for linux-xfs@oss.sgi.com; Thu, 2 Oct 2003 05:07:26 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10) with ESMTP id h92C7N2D009588 for ; Thu, 2 Oct 2003 05:07:24 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id h92C1jSI009473; Thu, 2 Oct 2003 05:01:45 -0700 Date: Thu, 2 Oct 2003 05:01:45 -0700 Message-Id: <200310021201.h92C1jSI009473@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 267] pwrite64 failed on 1.2 TB evms volume X-Bugzilla-Reason: AssignedTo X-archive-position: 608 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 387 Lines: 17 http://oss.sgi.com/bugzilla/show_bug.cgi?id=267 dg@ethx.de changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dg@ethx.de ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Oct 2 05:13:10 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 02 Oct 2003 05:13:44 -0700 (PDT) Received: from mobi.unsec.nl (guest.cmbi.kun.nl [131.174.88.68]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h92CD925010467 for ; Thu, 2 Oct 2003 05:13:10 -0700 Received: from mobi.unsec.nl (localhost.localdomain [127.0.0.1]) by mobi.unsec.nl (8.12.8/8.12.8) with ESMTP id h92CAxff004491; Thu, 2 Oct 2003 14:12:19 +0200 Received: from localhost (rudi@localhost) by mobi.unsec.nl (8.12.8/8.12.8/Submit) with ESMTP id h92CAxRC004488; Thu, 2 Oct 2003 14:10:59 +0200 X-Authentication-Warning: mobi.unsec.nl: rudi owned process doing -bs Date: Thu, 2 Oct 2003 14:10:59 +0200 (CEST) From: Rudi Engelbertink X-X-Sender: rudi@mobi.unsec.nl To: deny cc: linux-xfs@oss.sgi.com Subject: Re: could not open default font fixed In-Reply-To: <3F7C0D52.6070403@monaco.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be mclean X-archive-position: 609 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: rudi@snow.nl Precedence: bulk X-list: linux-xfs Content-Length: 1392 Lines: 59 On Thu, 2 Oct 2003, deny wrote: I know this is a bit confusing but this has nothing to do with the XFS filesystem. You have a problem with the X font server. and stopping or starting the fontserver is done by /etc/init.d/xfs [start || stop] RGDS Rudi. > Date: Thu, 02 Oct 2003 13:34:42 +0200 > From: deny > To: linux-xfs@oss.sgi.com > Subject: could not open default font fixed > > hi > > i ve this message on my mandrake 9.0 > when i am booting > > what i do before ? > i stop abruptely after a froze when try to ending mandrake > > > i try to stop my xfs server > i do init 3 > and try to launch xfs > but i dont know the exact command > > (xfs start or stop dont work > i ve the message : > usage xfs -config config-file -port etc..... > > > i try to update the system > but i am blocked just after reconfiguring the rpm base > (from the cd rom install n 1 ) > > > i don't know what else to do > > thanks > > > > > -- Rudi Engelbertink Unix consultants v v rudi@snow.nl OO developers \ / ### ## ## # >---X---< http://snow.nl # # # # # # # # / \ Snow B.V. the Netherlands ## # # # # # # # ^ ^ Tel. +31-418-653333 # # # # # # # # Fax. +31-418-653666 ### # # ## ## ## From owner-linux-xfs@oss.sgi.com Thu Oct 2 05:16:17 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 02 Oct 2003 05:16:18 -0700 (PDT) Received: from khe-mailhub1.eigner.com (khe-mailhub1.eigner.com [194.120.231.246]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h92CGE25010890 for ; Thu, 2 Oct 2003 05:16:14 -0700 Received: from agile.com (unknown [194.120.231.18]) by khe-mailhub1.eigner.com (Postfix) with ESMTP id 812C637F for ; Thu, 2 Oct 2003 14:15:32 +0200 (CEST) Message-ID: <3F7C16EA.9060701@agile.com> Date: Thu, 02 Oct 2003 14:15:38 +0200 From: Klaus Strebel Organization: Agile Software Corp. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: de, en, de-de, en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Hang on mount with 2.6 Content-Type: multipart/mixed; boundary="------------060309090903090100000100" X-agile-MailScanner-Information: Please contact the ISP for more information X-agile-MailScanner: Found to be clean X-agile-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=0.1, required 5, MIME_MISSING_BOUNDARY 0.16, USER_AGENT_MOZILLA_UA 0.00, X_ACCEPT_LANG -0.10) X-archive-position: 610 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: klaus.strebel@agile.com Precedence: bulk X-list: linux-xfs Content-Length: 265800 Lines: 3661 This is a multi-part message in MIME format. --------------060309090903090100000100 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi all, the latest CVS from linux-2.5-xfs gives me the attached messages on mount of an xfs filesystem (/home), all preceding mounts are ext3/ext2 filesystems. I compiled with GCC-3.3 on SuSE-8.2. Any hints, ideas, patches? Ciao Klaus -- Klaus Strebel UNIX-Engineer klaus.strebel@agile.com Agile Software Corporation How Product Become Profits (TM) --------------060309090903090100000100 Content-Type: text/plain; name="2.6test5-mesg.txt" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="2.6test5-mesg.txt" T2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6IGtsb2dkIDEuNC4xLCBsb2cgc291cmNl ID0gL3Byb2Mva21zZyBzdGFydGVkLgpPY3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5lbDog Q2Fubm90IG9wZW4gbWFwIGZpbGU6IC9ib290L2JldGEvU3lzdGVtLm1hcC4KT2N0ICAyIDE1 OjA3OjE3IChub25lKSBrZXJuZWw6IE5vIG1vZHVsZSBzeW1ib2xzIGxvYWRlZCAtIGtlcm5l bCBtb2R1bGVzIG5vdCBlbmFibGVkLiAKT2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6 IENhbm5vdCBidWlsZCBzeW1ib2wgdGFibGUgLSBkaXNhYmxpbmcgc3ltYm9sIGxvb2t1cHMK T2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6IDkvMHhiMCBbeGZzXQpPY3QgIDIgMTU6 MDc6MTcgKG5vbmUpIGtlcm5lbDogIFs8ZDIwNzJhOTE+XSBsaW52ZnNfZmlsbF9zdXBlcisw eGExLzB4MjUwIFt4ZnNdCk9jdCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVsOiAgWzxjMDFh ZmY4Nz5dIHNucHJpbnRmKzB4MjcvMHgzMApPY3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5l bDogIFs8YzAxOTEwMWY+XSBkaXNrX25hbWUrMHhhZi8weGQwCk9jdCAgMiAxNTowNzoxNyAo bm9uZSkga2VybmVsOiAgWzxjMDE2MWY1Zj5dIHNiX3NldF9ibG9ja3NpemUrMHgxZi8weDYw Ck9jdCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVsOiAgWzxjMDE2MThlYT5dIGdldF9zYl9i ZGV2KzB4ZWEvMHgxODAKT2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6ICBbPGQyMDcy YzZmPl0gbGludmZzX2dldF9zYisweDJmLzB4NDAgW3hmc10KT2N0ICAyIDE1OjA3OjE3IChu b25lKSBrZXJuZWw6ICBbPGQyMDcyOWYwPl0gbGludmZzX2ZpbGxfc3VwZXIrMHgwLzB4MjUw IFt4ZnNdCk9jdCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVsOiAgWzxjMDE2MWJhZj5dIGRv X2tlcm5fbW91bnQrMHg1Zi8weGYwCk9jdCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVsOiAg WzxjMDE3ODlhNz5dIGRvX2FkZF9tb3VudCsweDk3LzB4MWEwCk9jdCAgMiAxNTowNzoxNyAo bm9uZSkga2VybmVsOiAgWzxjMDE3OGQyYz5dIGRvX21vdW50KzB4MTdjLzB4MWEwCk9jdCAg MiAxNTowNzoxNyAobm9uZSkga2VybmVsOiAgWzxjMDE3OGI5ND5dIGNvcHlfbW91bnRfb3B0 aW9ucysweGU0LzB4MTAwCk9jdCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVsOiAgWzxjMDE3 OTEwZj5dIHN5c19tb3VudCsweGJmLzB4MTQwCk9jdCAgMiAxNTowNzoxNyAobm9uZSkga2Vy bmVsOiAgWzxjMDEwOTQ0Yj5dIHN5c2NhbGxfY2FsbCsweDcvMHhiCk9jdCAgMiAxNTowNzox NyAobm9uZSkga2VybmVsOiAKT2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6IGJhZDog c2NoZWR1bGluZyB3aGlsZSBhdG9taWMhCk9jdCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVs OiBDYWxsIFRyYWNlOgpPY3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5lbDogIFs8YzAxMWU2 ZTY+XSBzY2hlZHVsZSsweDQwNi8weDQ0MApPY3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5l bDogIFs8YzAyMWNhODU+XSBpZGVfZG9fcmVxdWVzdCsweDIxNS8weDNhMApPY3QgIDIgMTU6 MDc6MTcgKG5vbmUpIGtlcm5lbDogIFs8YzAxMDgxM2I+XSBfX2Rvd24rMHg3Yi8weDExMApP Y3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5lbDogIFs8YzAxMWU3NzA+XSBkZWZhdWx0X3dh a2VfZnVuY3Rpb24rMHgwLzB4MzAKT2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6ICBb PGMwMjA5OGIxPl0gZ2VuZXJpY191bnBsdWdfZGV2aWNlKzB4NjEvMHg3MApPY3QgIDIgMTU6 MDc6MTcgKG5vbmUpIGtlcm5lbDogIFs8YzAxMDgzODA+XSBfX2Rvd25fZmFpbGVkKzB4OC8w eGMKT2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6ICBbPGQyMDY2ZDIyPl0gLnRleHQu bG9jay5wYWdlX2J1ZisweDIzLzB4MzEgW3hmc10KT2N0ICAyIDE1OjA3OjE3IChub25lKSBr ZXJuZWw6ICBbPGQyMDNmM2JmPl0geGxvZ19icmVhZCsweGZmLzB4MWYwIFt4ZnNdCk9jdCAg MiAxNTowNzoxNyAobm9uZSkga2VybmVsOiAgWzxkMjA0MDBiND5dIHhsb2dfZmluZF92ZXJp ZnlfbG9nX3JlY29yZCsweDE1NC8weDMzMCBbeGZzXQpPY3QgIDIgMTU6MDc6MTcgKG5vbmUp IGtlcm5lbDogIFs8ZDIwNDExMWY+XSB4bG9nX2ZpbmRfemVyb2VkKzB4MjdmLzB4MzcwIFt4 ZnNdCk9jdCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVsOiAgWzxkMjA0MDJiZT5dIHhsb2df ZmluZF9oZWFkKzB4MmUvMHg2YzAgW3hmc10KT2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJu ZWw6ICBbPGMwMTQzZjhmPl0gY2FjaGVfZ3JvdysweDE0Zi8weDI2MApPY3QgIDIgMTU6MDc6 MTcgKG5vbmUpIGtlcm5lbDogIFs8ZDIwNDA5ODE+XSB4bG9nX2ZpbmRfdGFpbCsweDMxLzB4 NTUwIFt4ZnNdCk9jdCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVsOiAgWzxjMDE0NDI5Mj5d IGNhY2hlX2FsbG9jX3JlZmlsbCsweDFmMi8weDIzMApPY3QgIDIgMTU6MDc6MTcgKG5vbmUp IGtlcm5lbDogIFs8ZDIwNjUzNWY+XSBwYWdlYnVmX2dldF9lbXB0eSsweDRmLzB4NjAgW3hm c10KT2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6ICBbPGQyMDQ2YWQ3Pl0geGxvZ19y ZWNvdmVyKzB4MzcvMHgxMDAgW3hmc10KT2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6 ICBbPGQyMDM5ZTZhPl0geGZzX2xvZ19tb3VudCsweDExYS8weDFhMCBbeGZzXQpPY3QgIDIg MTU6MDc6MTcgKG5vbmUpIGtlcm5lbDogIFs8ZDIwNGJlYzM+XSB4ZnNfbW91bnRmcysweDkz My8weDEwNzAgW3hmc10KT2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6ICBbPGQyMDcx ZjgwPl0geGZzX3NldHNpemVfYnVmdGFyZysweDQwLzB4OTAgW3hmc10KT2N0ICAyIDE1OjA3 OjE3IChub25lKSBrZXJuZWw6ICBbPGQyMDRiMWFhPl0geGZzX3JlYWRzYisweDJlYS8weDNh MCBbeGZzXQpPY3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5lbDogIFs8ZDIwNDc3OWE+XSB4 ZnNfdmZzdG9tKzB4MWEvMHgyMCBbeGZzXQpPY3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5l bDogIFs8ZDIwMzcwZDA+XSB4ZnNfaW9pbml0KzB4MTAvMHgzMCBbeGZzXQpPY3QgIDIgMTU6 MDc6MTcgKG5vbmUpIGtlcm5lbDogIFs8ZDIwNTc5NTE+XSB4ZnNfbW91bnQrMHgzOTEvMHg2 NDAgW3hmc10KT2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6ICBbPGQyMDcyZjU5Pl0g dmZzX21vdW50KzB4ODkvMHhiMCBbeGZzXQpPY3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5l bDogIFs8ZDIwNzJhOTE+XSBsaW52ZnNfZmlsbF9zdXBlcisweGExLzB4MjUwIFt4ZnNdCk9j dCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVsOiAgWzxjMDFhZmY4Nz5dIHNucHJpbnRmKzB4 MjcvMHgzMApPY3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5lbDogIFs8YzAxOTEwMWY+XSBk aXNrX25hbWUrMHhhZi8weGQwCk9jdCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVsOiAgWzxj MDE2MWY1Zj5dIHNiX3NldF9ibG9ja3NpemUrMHgxZi8weDYwCk9jdCAgMiAxNTowNzoxNyAo bm9uZSkga2VybmVsOiAgWzxjMDE2MThlYT5dIGdldF9zYl9iZGV2KzB4ZWEvMHgxODAKT2N0 ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6ICBbPGQyMDcyYzZmPl0gbGludmZzX2dldF9z YisweDJmLzB4NDAgW3hmc10KT2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6ICBbPGQy MDcyOWYwPl0gbGludmZzX2ZpbGxfc3VwZXIrMHgwLzB4MjUwIFt4ZnNdCk9jdCAgMiAxNTow NzoxNyAobm9uZSkga2VybmVsOiAgWzxjMDE2MWJhZj5dIGRvX2tlcm5fbW91bnQrMHg1Zi8w eGYwCk9jdCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVsOiAgWzxjMDE3ODlhNz5dIGRvX2Fk ZF9tb3VudCsweDk3LzB4MWEwCk9jdCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVsOiAgWzxj MDE3OGQyYz5dIGRvX21vdW50KzB4MTdjLzB4MWEwCk9jdCAgMiAxNTowNzoxNyAobm9uZSkg a2VybmVsOiAgWzxjMDE3OGI5ND5dIGNvcHlfbW91bnRfb3B0aW9ucysweGU0LzB4MTAwCk9j dCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVsOiAgWzxjMDE3OTEwZj5dIHN5c19tb3VudCsw eGJmLzB4MTQwCk9jdCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVsOiAgWzxjMDEwOTQ0Yj5d IHN5c2NhbGxfY2FsbCsweDcvMHhiCk9jdCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVsOiAK T2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6IGJhZDogc2NoZWR1bGluZyB3aGlsZSBh dG9taWMhCk9jdCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVsOiBDYWxsIFRyYWNlOgpPY3Qg IDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5lbDogIFs8YzAxMWU2ZTY+XSBzY2hlZHVsZSsweDQw Ni8weDQ0MApPY3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5lbDogIFs8YzAyMWNhODU+XSBp ZGVfZG9fcmVxdWVzdCsweDIxNS8weDNhMApPY3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5l bDogIFs8YzAxMDgxM2I+XSBfX2Rvd24rMHg3Yi8weDExMApPY3QgIDIgMTU6MDc6MTcgKG5v bmUpIGtlcm5lbDogIFs8YzAxMWU3NzA+XSBkZWZhdWx0X3dha2VfZnVuY3Rpb24rMHgwLzB4 MzAKT2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6ICBbPGMwMjA5OGIxPl0gZ2VuZXJp Y191bnBsdWdfZGV2aWNlKzB4NjEvMHg3MApPY3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5l bDogIFs8YzAxMDgzODA+XSBfX2Rvd25fZmFpbGVkKzB4OC8weGMKT2N0ICAyIDE1OjA3OjE3 IChub25lKSBrZXJuZWw6ICBbPGQyMDY2ZDIyPl0gLnRleHQubG9jay5wYWdlX2J1ZisweDIz LzB4MzEgW3hmc10KT2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6ICBbPGQyMDNmM2Jm Pl0geGxvZ19icmVhZCsweGZmLzB4MWYwIFt4ZnNdCk9jdCAgMiAxNTowNzoxNyAobm9uZSkg a2VybmVsOiAgWzxkMjA0MGEzNT5dIHhsb2dfZmluZF90YWlsKzB4ZTUvMHg1NTAgW3hmc10K T2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6ICBbPGQyMDQ2YWQ3Pl0geGxvZ19yZWNv dmVyKzB4MzcvMHgxMDAgW3hmc10KT2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6ICBb PGQyMDM5ZTZhPl0geGZzX2xvZ19tb3VudCsweDExYS8weDFhMCBbeGZzXQpPY3QgIDIgMTU6 MDc6MTcgKG5vbmUpIGtlcm5lbDogIFs8ZDIwNGJlYzM+XSB4ZnNfbW91bnRmcysweDkzMy8w eDEwNzAgW3hmc10KT2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6ICBbPGQyMDcxZjgw Pl0geGZzX3NldHNpemVfYnVmdGFyZysweDQwLzB4OTAgW3hmc10KT2N0ICAyIDE1OjA3OjE3 IChub25lKSBrZXJuZWw6ICBbPGQyMDRiMWFhPl0geGZzX3JlYWRzYisweDJlYS8weDNhMCBb eGZzXQpPY3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5lbDogIFs8ZDIwNDc3OWE+XSB4ZnNf dmZzdG9tKzB4MWEvMHgyMCBbeGZzXQpPY3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5lbDog IFs8ZDIwMzcwZDA+XSB4ZnNfaW9pbml0KzB4MTAvMHgzMCBbeGZzXQpPY3QgIDIgMTU6MDc6 MTcgKG5vbmUpIGtlcm5lbDogIFs8ZDIwNTc5NTE+XSB4ZnNfbW91bnQrMHgzOTEvMHg2NDAg W3hmc10KT2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6ICBbPGQyMDcyZjU5Pl0gdmZz X21vdW50KzB4ODkvMHhiMCBbeGZzXQpPY3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5lbDog IFs8ZDIwNzJhOTE+XSBsaW52ZnNfZmlsbF9zdXBlcisweGExLzB4MjUwIFt4ZnNdCk9jdCAg MiAxNTowNzoxNyAobm9uZSkga2VybmVsOiAgWzxjMDFhZmY4Nz5dIHNucHJpbnRmKzB4Mjcv MHgzMApPY3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5lbDogIFs8YzAxOTEwMWY+XSBkaXNr X25hbWUrMHhhZi8weGQwCk9jdCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVsOiAgWzxjMDE2 MWY1Zj5dIHNiX3NldF9ibG9ja3NpemUrMHgxZi8weDYwCk9jdCAgMiAxNTowNzoxNyAobm9u ZSkga2VybmVsOiAgWzxjMDE2MThlYT5dIGdldF9zYl9iZGV2KzB4ZWEvMHgxODAKT2N0ICAy IDE1OjA3OjE3IChub25lKSBrZXJuZWw6ICBbPGQyMDcyYzZmPl0gbGludmZzX2dldF9zYisw eDJmLzB4NDAgW3hmc10KT2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6ICBbPGQyMDcy OWYwPl0gbGludmZzX2ZpbGxfc3VwZXIrMHgwLzB4MjUwIFt4ZnNdCk9jdCAgMiAxNTowNzox NyAobm9uZSkga2VybmVsOiAgWzxjMDE2MWJhZj5dIGRvX2tlcm5fbW91bnQrMHg1Zi8weGYw Ck9jdCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVsOiAgWzxjMDE3ODlhNz5dIGRvX2FkZF9t b3VudCsweDk3LzB4MWEwCk9jdCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVsOiAgWzxjMDE3 OGQyYz5dIGRvX21vdW50KzB4MTdjLzB4MWEwCk9jdCAgMiAxNTowNzoxNyAobm9uZSkga2Vy bmVsOiAgWzxjMDE3OGI5ND5dIGNvcHlfbW91bnRfb3B0aW9ucysweGU0LzB4MTAwCk9jdCAg MiAxNTowNzoxNyAobm9uZSkga2VybmVsOiAgWzxjMDE3OTEwZj5dIHN5c19tb3VudCsweGJm LzB4MTQwCk9jdCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVsOiAgWzxjMDEwOTQ0Yj5dIHN5 c2NhbGxfY2FsbCsweDcvMHhiCk9jdCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVsOiAKT2N0 ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6IGJhZDogc2NoZWR1bGluZyB3aGlsZSBhdG9t aWMhCk9jdCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVsOiBDYWxsIFRyYWNlOgpPY3QgIDIg MTU6MDc6MTcgKG5vbmUpIGtlcm5lbDogIFs8YzAxMWU2ZTY+XSBzY2hlZHVsZSsweDQwNi8w eDQ0MApPY3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5lbDogIFs8YzAyMWNhODU+XSBpZGVf ZG9fcmVxdWVzdCsweDIxNS8weDNhMApPY3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5lbDog IFs8YzAxMDgxM2I+XSBfX2Rvd24rMHg3Yi8weDExMApPY3QgIDIgMTU6MDc6MTcgKG5vbmUp IGtlcm5lbDogIFs8YzAxMWU3NzA+XSBkZWZhdWx0X3dha2VfZnVuY3Rpb24rMHgwLzB4MzAK T2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6ICBbPGMwMjA5OGIxPl0gZ2VuZXJpY191 bnBsdWdfZGV2aWNlKzB4NjEvMHg3MApPY3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5lbDog IFs8YzAxMDgzODA+XSBfX2Rvd25fZmFpbGVkKzB4OC8weGMKT2N0ICAyIDE1OjA3OjE3IChu b25lKSBrZXJuZWw6ICBbPGQyMDY2ZDIyPl0gLnRleHQubG9jay5wYWdlX2J1ZisweDIzLzB4 MzEgW3hmc10KT2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6ICBbPGQyMDNmM2JmPl0g eGxvZ19icmVhZCsweGZmLzB4MWYwIFt4ZnNdCk9jdCAgMiAxNTowNzoxNyAobm9uZSkga2Vy bmVsOiAgWzxkMjA0MGEzNT5dIHhsb2dfZmluZF90YWlsKzB4ZTUvMHg1NTAgW3hmc10KT2N0 ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6ICBbPGQyMDQ2YWQ3Pl0geGxvZ19yZWNvdmVy KzB4MzcvMHgxMDAgW3hmc10KT2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6ICBbPGQy MDM5ZTZhPl0geGZzX2xvZ19tb3VudCsweDExYS8weDFhMCBbeGZzXQpPY3QgIDIgMTU6MDc6 MTcgKG5vbmUpIGtlcm5lbDogIFs8ZDIwNGJlYzM+XSB4ZnNfbW91bnRmcysweDkzMy8weDEw NzAgW3hmc10KT2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6ICBbPGQyMDcxZjgwPl0g eGZzX3NldHNpemVfYnVmdGFyZysweDQwLzB4OTAgW3hmc10KT2N0ICAyIDE1OjA3OjE3IChu b25lKSBrZXJuZWw6ICBbPGQyMDRiMWFhPl0geGZzX3JlYWRzYisweDJlYS8weDNhMCBbeGZz XQpPY3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5lbDogIFs8ZDIwNDc3OWE+XSB4ZnNfdmZz dG9tKzB4MWEvMHgyMCBbeGZzXQpPY3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5lbDogIFs8 ZDIwMzcwZDA+XSB4ZnNfaW9pbml0KzB4MTAvMHgzMCBbeGZzXQpPY3QgIDIgMTU6MDc6MTcg KG5vbmUpIGtlcm5lbDogIFs8ZDIwNTc5NTE+XSB4ZnNfbW91bnQrMHgzOTEvMHg2NDAgW3hm c10KT2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6ICBbPGQyMDcyZjU5Pl0gdmZzX21v dW50KzB4ODkvMHhiMCBbeGZzXQpPY3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5lbDogIFs8 ZDIwNzJhOTE+XSBsaW52ZnNfZmlsbF9zdXBlcisweGExLzB4MjUwIFt4ZnNdCk9jdCAgMiAx NTowNzoxNyAobm9uZSkga2VybmVsOiAgWzxjMDFhZmY4Nz5dIHNucHJpbnRmKzB4MjcvMHgz MApPY3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5lbDogIFs8YzAxOTEwMWY+XSBkaXNrX25h bWUrMHhhZi8weGQwCk9jdCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVsOiAgWzxjMDE2MWY1 Zj5dIHNiX3NldF9ibG9ja3NpemUrMHgxZi8weDYwCk9jdCAgMiAxNTowNzoxNyAobm9uZSkg a2VybmVsOiAgWzxjMDE2MThlYT5dIGdldF9zYl9iZGV2KzB4ZWEvMHgxODAKT2N0ICAyIDE1 OjA3OjE3IChub25lKSBrZXJuZWw6ICBbPGQyMDcyYzZmPl0gbGludmZzX2dldF9zYisweDJm LzB4NDAgW3hmc10KT2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6ICBbPGQyMDcyOWYw Pl0gbGludmZzX2ZpbGxfc3VwZXIrMHgwLzB4MjUwIFt4ZnNdCk9jdCAgMiAxNTowNzoxNyAo bm9uZSkga2VybmVsOiAgWzxjMDE2MWJhZj5dIGRvX2tlcm5fbW91bnQrMHg1Zi8weGYwCk9j dCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVsOiAgWzxjMDE3ODlhNz5dIGRvX2FkZF9tb3Vu dCsweDk3LzB4MWEwCk9jdCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVsOiAgWzxjMDE3OGQy Yz5dIGRvX21vdW50KzB4MTdjLzB4MWEwCk9jdCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVs OiAgWzxjMDE3OGI5ND5dIGNvcHlfbW91bnRfb3B0aW9ucysweGU0LzB4MTAwCk9jdCAgMiAx NTowNzoxNyAobm9uZSkga2VybmVsOiAgWzxjMDE3OTEwZj5dIHN5c19tb3VudCsweGJmLzB4 MTQwCk9jdCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVsOiAgWzxjMDEwOTQ0Yj5dIHN5c2Nh bGxfY2FsbCsweDcvMHhiCk9jdCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVsOiAKT2N0ICAy IDE1OjA3OjE3IChub25lKSBrZXJuZWw6IGJhZDogc2NoZWR1bGluZyB3aGlsZSBhdG9taWMh Ck9jdCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVsOiBDYWxsIFRyYWNlOgpPY3QgIDIgMTU6 MDc6MTcgKG5vbmUpIGtlcm5lbDogIFs8YzAxMWU2ZTY+XSBzY2hlZHVsZSsweDQwNi8weDQ0 MApPY3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5lbDogIFs8YzAyMWNhODU+XSBpZGVfZG9f cmVxdWVzdCsweDIxNS8weDNhMApPY3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5lbDogIFs8 YzAxMDgxM2I+XSBfX2Rvd24rMHg3Yi8weDExMApPY3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtl cm5lbDogIFs8YzAxMWU3NzA+XSBkZWZhdWx0X3dha2VfZnVuY3Rpb24rMHgwLzB4MzAKT2N0 ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6ICBbPGMwMjA5OGIxPl0gZ2VuZXJpY191bnBs dWdfZGV2aWNlKzB4NjEvMHg3MApPY3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5lbDogIFs8 YzAxMDgzODA+XSBfX2Rvd25fZmFpbGVkKzB4OC8weGMKT2N0ICAyIDE1OjA3OjE3IChub25l KSBrZXJuZWw6ICBbPGQyMDY2ZDIyPl0gLnRleHQubG9jay5wYWdlX2J1ZisweDIzLzB4MzEg W3hmc10KT2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6ICBbPGQyMDNmM2JmPl0geGxv Z19icmVhZCsweGZmLzB4MWYwIFt4ZnNdCk9jdCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVs OiAgWzxkMjA0MGUxMT5dIHhsb2dfZmluZF90YWlsKzB4NGMxLzB4NTUwIFt4ZnNdCk9jdCAg MiAxNTowNzoxNyAobm9uZSkga2VybmVsOiAgWzxkMjA0NmFkNz5dIHhsb2dfcmVjb3Zlcisw eDM3LzB4MTAwIFt4ZnNdCk9jdCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVsOiAgWzxkMjAz OWU2YT5dIHhmc19sb2dfbW91bnQrMHgxMWEvMHgxYTAgW3hmc10KT2N0ICAyIDE1OjA3OjE3 IChub25lKSBrZXJuZWw6ICBbPGQyMDRiZWMzPl0geGZzX21vdW50ZnMrMHg5MzMvMHgxMDcw IFt4ZnNdCk9jdCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVsOiAgWzxkMjA3MWY4MD5dIHhm c19zZXRzaXplX2J1ZnRhcmcrMHg0MC8weDkwIFt4ZnNdCk9jdCAgMiAxNTowNzoxNyAobm9u ZSkga2VybmVsOiAgWzxkMjA0YjFhYT5dIHhmc19yZWFkc2IrMHgyZWEvMHgzYTAgW3hmc10K T2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6ICBbPGQyMDQ3NzlhPl0geGZzX3Zmc3Rv bSsweDFhLzB4MjAgW3hmc10KT2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6ICBbPGQy MDM3MGQwPl0geGZzX2lvaW5pdCsweDEwLzB4MzAgW3hmc10KT2N0ICAyIDE1OjA3OjE3IChu b25lKSBrZXJuZWw6ICBbPGQyMDU3OTUxPl0geGZzX21vdW50KzB4MzkxLzB4NjQwIFt4ZnNd Ck9jdCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVsOiAgWzxkMjA3MmY1OT5dIHZmc19tb3Vu dCsweDg5LzB4YjAgW3hmc10KT2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6ICBbPGQy MDcyYTkxPl0gbGludmZzX2ZpbGxfc3VwZXIrMHhhMS8weDI1MCBbeGZzXQpPY3QgIDIgMTU6 MDc6MTcgKG5vbmUpIGtlcm5lbDogIFs8YzAxYWZmODc+XSBzbnByaW50ZisweDI3LzB4MzAK T2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6ICBbPGMwMTkxMDFmPl0gZGlza19uYW1l KzB4YWYvMHhkMApPY3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5lbDogIFs8YzAxNjFmNWY+ XSBzYl9zZXRfYmxvY2tzaXplKzB4MWYvMHg2MApPY3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtl cm5lbDogIFs8YzAxNjE4ZWE+XSBnZXRfc2JfYmRldisweGVhLzB4MTgwCk9jdCAgMiAxNTow NzoxNyAobm9uZSkga2VybmVsOiAgWzxkMjA3MmM2Zj5dIGxpbnZmc19nZXRfc2IrMHgyZi8w eDQwIFt4ZnNdCk9jdCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVsOiAgWzxkMjA3MjlmMD5d IGxpbnZmc19maWxsX3N1cGVyKzB4MC8weDI1MCBbeGZzXQpPY3QgIDIgMTU6MDc6MTcgKG5v bmUpIGtlcm5lbDogIFs8YzAxNjFiYWY+XSBkb19rZXJuX21vdW50KzB4NWYvMHhmMApPY3Qg IDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5lbDogIFs8YzAxNzg5YTc+XSBkb19hZGRfbW91bnQr MHg5Ny8weDFhMApPY3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5lbDogIFs8YzAxNzhkMmM+ XSBkb19tb3VudCsweDE3Yy8weDFhMApPY3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5lbDog IFs8YzAxNzhiOTQ+XSBjb3B5X21vdW50X29wdGlvbnMrMHhlNC8weDEwMApPY3QgIDIgMTU6 MDc6MTcgKG5vbmUpIGtlcm5lbDogIFs8YzAxNzkxMGY+XSBzeXNfbW91bnQrMHhiZi8weDE0 MApPY3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5lbDogIFs8YzAxMDk0NGI+XSBzeXNjYWxs X2NhbGwrMHg3LzB4YgpPY3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5lbDogCk9jdCAgMiAx NTowNzoxNyAobm9uZSkga2VybmVsOiBiYWQ6IHNjaGVkdWxpbmcgd2hpbGUgYXRvbWljIQpP Y3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5lbDogQ2FsbCBUcmFjZToKT2N0ICAyIDE1OjA3 OjE3IChub25lKSBrZXJuZWw6ICBbPGMwMTFlNmU2Pl0gc2NoZWR1bGUrMHg0MDYvMHg0NDAK T2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6ICBbPGMwMjFjYTg1Pl0gaWRlX2RvX3Jl cXVlc3QrMHgyMTUvMHgzYTAKT2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6ICBbPGMw MTA4MTNiPl0gX19kb3duKzB4N2IvMHgxMTAKT2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJu ZWw6ICBbPGMwMTFlNzcwPl0gZGVmYXVsdF93YWtlX2Z1bmN0aW9uKzB4MC8weDMwCk9jdCAg MiAxNTowNzoxNyAobm9uZSkga2VybmVsOiAgWzxjMDIwOThiMT5dIGdlbmVyaWNfdW5wbHVn X2RldmljZSsweDYxLzB4NzAKT2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6ICBbPGMw MTA4MzgwPl0gX19kb3duX2ZhaWxlZCsweDgvMHhjCk9jdCAgMiAxNTowNzoxNyAobm9uZSkg a2VybmVsOiAgWzxkMjA2NmQyMj5dIC50ZXh0LmxvY2sucGFnZV9idWYrMHgyMy8weDMxIFt4 ZnNdCk9jdCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVsOiAgWzxkMjA2NDJjNT5dIHhmc19i d3JpdGUrMHgxMDUvMHgxNjAgW3hmc10KT2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6 ICBbPGQyMDNmNWE0Pl0geGxvZ19id3JpdGUrMHhmNC8weDFkMCBbeGZzXQpPY3QgIDIgMTU6 MDc6MTcgKG5vbmUpIGtlcm5lbDogIFs8ZDIwNDEyYzY+XSB4bG9nX2FkZF9yZWNvcmQrMHhi Ni8weGQwIFt4ZnNdCk9jdCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVsOiAgWzxkMjA0MTQw MT5dIHhsb2dfd3JpdGVfbG9nX3JlY29yZHMrMHgxMjEvMHgyOTAgW3hmc10KT2N0ICAyIDE1 OjA3OjE3IChub25lKSBrZXJuZWw6ICBbPGQyMDQxNjkyPl0geGxvZ19jbGVhcl9zdGFsZV9i bG9ja3MrMHgxMjIvMHgyMjAgW3hmc10KT2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6 ICBbPGQyMDQwZDg5Pl0geGxvZ19maW5kX3RhaWwrMHg0MzkvMHg1NTAgW3hmc10KT2N0ICAy IDE1OjA3OjE3IChub25lKSBrZXJuZWw6ICBbPGQyMDQ2YWQ3Pl0geGxvZ19yZWNvdmVyKzB4 MzcvMHgxMDAgW3hmc10KT2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6ICBbPGQyMDM5 ZTZhPl0geGZzX2xvZ19tb3VudCsweDExYS8weDFhMCBbeGZzXQpPY3QgIDIgMTU6MDc6MTcg KG5vbmUpIGtlcm5lbDogIFs8ZDIwNGJlYzM+XSB4ZnNfbW91bnRmcysweDkzMy8weDEwNzAg W3hmc10KT2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6ICBbPGQyMDcxZjgwPl0geGZz X3NldHNpemVfYnVmdGFyZysweDQwLzB4OTAgW3hmc10KT2N0ICAyIDE1OjA3OjE3IChub25l KSBrZXJuZWw6ICBbPGQyMDRiMWFhPl0geGZzX3JlYWRzYisweDJlYS8weDNhMCBbeGZzXQpP Y3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5lbDogIFs8ZDIwNDc3OWE+XSB4ZnNfdmZzdG9t KzB4MWEvMHgyMCBbeGZzXQpPY3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5lbDogIFs8ZDIw MzcwZDA+XSB4ZnNfaW9pbml0KzB4MTAvMHgzMCBbeGZzXQpPY3QgIDIgMTU6MDc6MTcgKG5v bmUpIGtlcm5lbDogIFs8ZDIwNTc5NTE+XSB4ZnNfbW91bnQrMHgzOTEvMHg2NDAgW3hmc10K T2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6ICBbPGQyMDcyZjU5Pl0gdmZzX21vdW50 KzB4ODkvMHhiMCBbeGZzXQpPY3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5lbDogIFs8ZDIw NzJhOTE+XSBsaW52ZnNfZmlsbF9zdXBlcisweGExLzB4MjUwIFt4ZnNdCk9jdCAgMiAxNTow NzoxNyAobm9uZSkga2VybmVsOiAgWzxjMDFhZmY4Nz5dIHNucHJpbnRmKzB4MjcvMHgzMApP Y3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5lbDogIFs8YzAxOTEwMWY+XSBkaXNrX25hbWUr MHhhZi8weGQwCk9jdCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVsOiAgWzxjMDE2MWY1Zj5d IHNiX3NldF9ibG9ja3NpemUrMHgxZi8weDYwCk9jdCAgMiAxNTowNzoxNyAobm9uZSkga2Vy bmVsOiAgWzxjMDE2MThlYT5dIGdldF9zYl9iZGV2KzB4ZWEvMHgxODAKT2N0ICAyIDE1OjA3 OjE3IChub25lKSBrZXJuZWw6ICBbPGQyMDcyYzZmPl0gbGludmZzX2dldF9zYisweDJmLzB4 NDAgW3hmc10KT2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6ICBbPGQyMDcyOWYwPl0g bGludmZzX2ZpbGxfc3VwZXIrMHgwLzB4MjUwIFt4ZnNdCk9jdCAgMiAxNTowNzoxNyAobm9u ZSkga2VybmVsOiAgWzxjMDE2MWJhZj5dIGRvX2tlcm5fbW91bnQrMHg1Zi8weGYwCk9jdCAg MiAxNTowNzoxNyAobm9uZSkga2VybmVsOiAgWzxjMDE3ODlhNz5dIGRvX2FkZF9tb3VudCsw eDk3LzB4MWEwCk9jdCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVsOiAgWzxjMDE3OGQyYz5d IGRvX21vdW50KzB4MTdjLzB4MWEwCk9jdCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVsOiAg WzxjMDE3OGI5ND5dIGNvcHlfbW91bnRfb3B0aW9ucysweGU0LzB4MTAwCk9jdCAgMiAxNTow NzoxNyAobm9uZSkga2VybmVsOiAgWzxjMDE3OTEwZj5dIHN5c19tb3VudCsweGJmLzB4MTQw Ck9jdCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVsOiAgWzxjMDEwOTQ0Yj5dIHN5c2NhbGxf Y2FsbCsweDcvMHhiCk9jdCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVsOiAKT2N0ICAyIDE1 OjA3OjE3IChub25lKSBrZXJuZWw6IGJhZDogc2NoZWR1bGluZyB3aGlsZSBhdG9taWMhCk9j dCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVsOiBDYWxsIFRyYWNlOgpPY3QgIDIgMTU6MDc6 MTcgKG5vbmUpIGtlcm5lbDogIFs8YzAxMWU2ZTY+XSBzY2hlZHVsZSsweDQwNi8weDQ0MApP Y3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5lbDogIFs8YzAyMWNhODU+XSBpZGVfZG9fcmVx dWVzdCsweDIxNS8weDNhMApPY3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5lbDogIFs8YzAx MDgxM2I+XSBfX2Rvd24rMHg3Yi8weDExMApPY3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5l bDogIFs8YzAxMWU3NzA+XSBkZWZhdWx0X3dha2VfZnVuY3Rpb24rMHgwLzB4MzAKT2N0ICAy IDE1OjA3OjE3IChub25lKSBrZXJuZWw6ICBbPGMwMjA5OGIxPl0gZ2VuZXJpY191bnBsdWdf ZGV2aWNlKzB4NjEvMHg3MApPY3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5lbDogIFs8YzAx MDgzODA+XSBfX2Rvd25fZmFpbGVkKzB4OC8weGMKT2N0ICAyIDE1OjA3OjE3IChub25lKSBr ZXJuZWw6ICBbPGQyMDY2ZDIyPl0gLnRleHQubG9jay5wYWdlX2J1ZisweDIzLzB4MzEgW3hm c10KT2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6ICBbPGQyMDY0MmM1Pl0geGZzX2J3 cml0ZSsweDEwNS8weDE2MCBbeGZzXQpPY3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5lbDog IFs8ZDIwM2Y1YTQ+XSB4bG9nX2J3cml0ZSsweGY0LzB4MWQwIFt4ZnNdCk9jdCAgMiAxNTow NzoxNyAobm9uZSkga2VybmVsOiAgWzxkMjA0MTJjNj5dIHhsb2dfYWRkX3JlY29yZCsweGI2 LzB4ZDAgW3hmc10KT2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6ICBbPGQyMDQxNDAx Pl0geGxvZ193cml0ZV9sb2dfcmVjb3JkcysweDEyMS8weDI5MCBbeGZzXQpPY3QgIDIgMTU6 MDc6MTcgKG5vbmUpIGtlcm5lbDogIFs8ZDIwNDE2OTI+XSB4bG9nX2NsZWFyX3N0YWxlX2Js b2NrcysweDEyMi8weDIyMCBbeGZzXQpPY3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5lbDog IFs8ZDIwNDBkODk+XSB4bG9nX2ZpbmRfdGFpbCsweDQzOS8weDU1MCBbeGZzXQpPY3QgIDIg MTU6MDc6MTcgKG5vbmUpIGtlcm5lbDogIFs8ZDIwNDZhZDc+XSB4bG9nX3JlY292ZXIrMHgz Ny8weDEwMCBbeGZzXQpPY3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5lbDogIFs8ZDIwMzll NmE+XSB4ZnNfbG9nX21vdW50KzB4MTFhLzB4MWEwIFt4ZnNdCk9jdCAgMiAxNTowNzoxNyAo bm9uZSkga2VybmVsOiAgWzxkMjA0YmVjMz5dIHhmc19tb3VudGZzKzB4OTMzLzB4MTA3MCBb eGZzXQpPY3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5lbDogIFs8ZDIwNzFmODA+XSB4ZnNf c2V0c2l6ZV9idWZ0YXJnKzB4NDAvMHg5MCBbeGZzXQpPY3QgIDIgMTU6MDc6MTcgKG5vbmUp IGtlcm5lbDogIFs8ZDIwNGIxYWE+XSB4ZnNfcmVhZHNiKzB4MmVhLzB4M2EwIFt4ZnNdCk9j dCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVsOiAgWzxkMjA0Nzc5YT5dIHhmc192ZnN0b20r MHgxYS8weDIwIFt4ZnNdCk9jdCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVsOiAgWzxkMjAz NzBkMD5dIHhmc19pb2luaXQrMHgxMC8weDMwIFt4ZnNdCk9jdCAgMiAxNTowNzoxNyAobm9u ZSkga2VybmVsOiAgWzxkMjA1Nzk1MT5dIHhmc19tb3VudCsweDM5MS8weDY0MCBbeGZzXQpP Y3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5lbDogIFs8ZDIwNzJmNTk+XSB2ZnNfbW91bnQr MHg4OS8weGIwIFt4ZnNdCk9jdCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVsOiAgWzxkMjA3 MmE5MT5dIGxpbnZmc19maWxsX3N1cGVyKzB4YTEvMHgyNTAgW3hmc10KT2N0ICAyIDE1OjA3 OjE3IChub25lKSBrZXJuZWw6ICBbPGMwMWFmZjg3Pl0gc25wcmludGYrMHgyNy8weDMwCk9j dCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVsOiAgWzxjMDE5MTAxZj5dIGRpc2tfbmFtZSsw eGFmLzB4ZDAKT2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6ICBbPGMwMTYxZjVmPl0g c2Jfc2V0X2Jsb2Nrc2l6ZSsweDFmLzB4NjAKT2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJu ZWw6ICBbPGMwMTYxOGVhPl0gZ2V0X3NiX2JkZXYrMHhlYS8weDE4MApPY3QgIDIgMTU6MDc6 MTcgKG5vbmUpIGtlcm5lbDogIFs8ZDIwNzJjNmY+XSBsaW52ZnNfZ2V0X3NiKzB4MmYvMHg0 MCBbeGZzXQpPY3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5lbDogIFs8ZDIwNzI5ZjA+XSBs aW52ZnNfZmlsbF9zdXBlcisweDAvMHgyNTAgW3hmc10KT2N0ICAyIDE1OjA3OjE3IChub25l KSBrZXJuZWw6ICBbPGMwMTYxYmFmPl0gZG9fa2Vybl9tb3VudCsweDVmLzB4ZjAKT2N0ICAy IDE1OjA3OjE3IChub25lKSBrZXJuZWw6ICBbPGMwMTc4OWE3Pl0gZG9fYWRkX21vdW50KzB4 OTcvMHgxYTAKT2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6ICBbPGMwMTc4ZDJjPl0g ZG9fbW91bnQrMHgxN2MvMHgxYTAKT2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6ICBb PGMwMTc4Yjk0Pl0gY29weV9tb3VudF9vcHRpb25zKzB4ZTQvMHgxMDAKT2N0ICAyIDE1OjA3 OjE3IChub25lKSBrZXJuZWw6ICBbPGMwMTc5MTBmPl0gc3lzX21vdW50KzB4YmYvMHgxNDAK T2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6ICBbPGMwMTA5NDRiPl0gc3lzY2FsbF9j YWxsKzB4Ny8weGIKT2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6IApPY3QgIDIgMTU6 MDc6MTcgKG5vbmUpIGtlcm5lbDogYmFkOiBzY2hlZHVsaW5nIHdoaWxlIGF0b21pYyEKT2N0 ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6IENhbGwgVHJhY2U6Ck9jdCAgMiAxNTowNzox NyAobm9uZSkga2VybmVsOiAgWzxjMDExZTZlNj5dIHNjaGVkdWxlKzB4NDA2LzB4NDQwCk9j dCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVsOiAgWzxjMDIxY2E4NT5dIGlkZV9kb19yZXF1 ZXN0KzB4MjE1LzB4M2EwCk9jdCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVsOiAgWzxjMDEw ODEzYj5dIF9fZG93bisweDdiLzB4MTEwCk9jdCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVs OiAgWzxjMDExZTc3MD5dIGRlZmF1bHRfd2FrZV9mdW5jdGlvbisweDAvMHgzMApPY3QgIDIg MTU6MDc6MTcgKG5vbmUpIGtlcm5lbDogIFs8YzAyMDk4YjE+XSBnZW5lcmljX3VucGx1Z19k ZXZpY2UrMHg2MS8weDcwCk9jdCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVsOiAgWzxjMDEw ODM4MD5dIF9fZG93bl9mYWlsZWQrMHg4LzB4YwpPY3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtl cm5lbDogIFs8ZDIwNjZkMjI+XSAudGV4dC5sb2NrLnBhZ2VfYnVmKzB4MjMvMHgzMSBbeGZz XQpPY3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5lbDogIFs8ZDIwNjU5Yjg+XSBwYWdlYnVm X2lvc3RhcnQrMHg5OC8weGIwIFt4ZnNdCk9jdCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVs OiAgWzxkMjA2NTFjNT5dIHBhZ2VidWZfZ2V0KzB4MTI1LzB4MTYwIFt4ZnNdCk9jdCAgMiAx NTowNzoxNyAobm9uZSkga2VybmVsOiAgWzxkMjA1MzIxYz5dIHhmc190cmFuc19yZWFkX2J1 ZisweDI2Yy8weDdlMCBbeGZzXQpPY3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5lbDogIFs8 ZDIwMmQ1NjA+XSB4ZnNfaXRvYnArMHhiMC8weDRiMCBbeGZzXQpPY3QgIDIgMTU6MDc6MTcg KG5vbmUpIGtlcm5lbDogIFs8YzAxNDQyOTI+XSBjYWNoZV9hbGxvY19yZWZpbGwrMHgxZjIv MHgyMzAKT2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6ICBbPGQyMDJmOGJiPl0geGZz X2lyZWFkKzB4ZmIvMHgyZjAgW3hmc10KT2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6 ICBbPGMwMTc0ZjI3Pl0gZ2V0X25ld19pbm9kZV9mYXN0KzB4NDcvMHgxMTAKT2N0ICAyIDE1 OjA3OjE3IChub25lKSBrZXJuZWw6ICBbPGQyMDJiN2JhPl0geGZzX2lnZXRfY29yZSsweGRh LzB4NzkwIFt4ZnNdCk9jdCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVsOiAgWzxkMjAyYmZj ZD5dIHhmc19pZ2V0KzB4MTVkLzB4MWIwIFt4ZnNdCk9jdCAgMiAxNTowNzoxNyAobm9uZSkg a2VybmVsOiAgWzxkMjA0YmYxNj5dIHhmc19tb3VudGZzKzB4OTg2LzB4MTA3MCBbeGZzXQpP Y3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5lbDogIFs8ZDIwNzFmODA+XSB4ZnNfc2V0c2l6 ZV9idWZ0YXJnKzB4NDAvMHg5MCBbeGZzXQpPY3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5l bDogIFs8ZDIwNGIxYWE+XSB4ZnNfcmVhZHNiKzB4MmVhLzB4M2EwIFt4ZnNdCk9jdCAgMiAx NTowNzoxNyAobm9uZSkga2VybmVsOiAgWzxkMjA0Nzc5YT5dIHhmc192ZnN0b20rMHgxYS8w eDIwIFt4ZnNdCk9jdCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVsOiAgWzxkMjAzNzBkMD5d IHhmc19pb2luaXQrMHgxMC8weDMwIFt4ZnNdCk9jdCAgMiAxNTowNzoxNyAobm9uZSkga2Vy bmVsOiAgWzxkMjA1Nzk1MT5dIHhmc19tb3VudCsweDM5MS8weDY0MCBbeGZzXQpPY3QgIDIg MTU6MDc6MTcgKG5vbmUpIGtlcm5lbDogIFs8ZDIwNzJmNTk+XSB2ZnNfbW91bnQrMHg4OS8w eGIwIFt4ZnNdCk9jdCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVsOiAgWzxkMjA3MmE5MT5d IGxpbnZmc19maWxsX3N1cGVyKzB4YTEvMHgyNTAgW3hmc10KT2N0ICAyIDE1OjA3OjE3IChu b25lKSBrZXJuZWw6ICBbPGMwMWFmZjg3Pl0gc25wcmludGYrMHgyNy8weDMwCk9jdCAgMiAx NTowNzoxNyAobm9uZSkga2VybmVsOiAgWzxjMDE5MTAxZj5dIGRpc2tfbmFtZSsweGFmLzB4 ZDAKT2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6ICBbPGMwMTYxZjVmPl0gc2Jfc2V0 X2Jsb2Nrc2l6ZSsweDFmLzB4NjAKT2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6ICBb PGMwMTYxOGVhPl0gZ2V0X3NiX2JkZXYrMHhlYS8weDE4MApPY3QgIDIgMTU6MDc6MTcgKG5v bmUpIGtlcm5lbDogIFs8ZDIwNzJjNmY+XSBsaW52ZnNfZ2V0X3NiKzB4MmYvMHg0MCBbeGZz XQpPY3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5lbDogIFs8ZDIwNzI5ZjA+XSBsaW52ZnNf ZmlsbF9zdXBlcisweDAvMHgyNTAgW3hmc10KT2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJu ZWw6ICBbPGMwMTYxYmFmPl0gZG9fa2Vybl9tb3VudCsweDVmLzB4ZjAKT2N0ICAyIDE1OjA3 OjE3IChub25lKSBrZXJuZWw6ICBbPGMwMTc4OWE3Pl0gZG9fYWRkX21vdW50KzB4OTcvMHgx YTAKT2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6ICBbPGMwMTc4ZDJjPl0gZG9fbW91 bnQrMHgxN2MvMHgxYTAKT2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6ICBbPGMwMTc4 Yjk0Pl0gY29weV9tb3VudF9vcHRpb25zKzB4ZTQvMHgxMDAKT2N0ICAyIDE1OjA3OjE3IChu b25lKSBrZXJuZWw6ICBbPGMwMTc5MTBmPl0gc3lzX21vdW50KzB4YmYvMHgxNDAKT2N0ICAy IDE1OjA3OjE3IChub25lKSBrZXJuZWw6ICBbPGMwMTA5NDRiPl0gc3lzY2FsbF9jYWxsKzB4 Ny8weGIKT2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6IApPY3QgIDIgMTU6MDc6MTcg KG5vbmUpIGtlcm5lbDogRW5kaW5nIGNsZWFuIFhGUyBtb3VudCBmb3IgZmlsZXN5c3RlbTog ZG0tOApPY3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5lbDogYmFkOiBzY2hlZHVsaW5nIHdo aWxlIGF0b21pYyEKT2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6IENhbGwgVHJhY2U6 Ck9jdCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVsOiAgWzxjMDExZTZlNj5dIHNjaGVkdWxl KzB4NDA2LzB4NDQwCk9jdCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVsOiAgWzxjMDEwNzI1 MD5dIGtlcm5lbF90aHJlYWRfaGVscGVyKzB4MC8weDEwCk9jdCAgMiAxNTowNzoxNyAobm9u ZSkga2VybmVsOiAgWzxkMjA3MjM1NT5dIGxpbnZmc19zdGFydF9zeW5jZCsweDg1LzB4YjAg W3hmc10KT2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6ICBbPGQyMDcyMjEwPl0gc3lu Y2QrMHgwLzB4YzAgW3hmc10KT2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6ICBbPGMw MTFlNzcwPl0gZGVmYXVsdF93YWtlX2Z1bmN0aW9uKzB4MC8weDMwCk9jdCAgMiAxNTowNzox NyAobm9uZSkga2VybmVsOiAgWzxjMDE3MzI4Nz5dIGRfYWxsb2Nfcm9vdCsweDQ3LzB4NjAK T2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6ICBbPGQyMDcyYjQ4Pl0gbGludmZzX2Zp bGxfc3VwZXIrMHgxNTgvMHgyNTAgW3hmc10KT2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJu ZWw6ICBbPGMwMTYxZjVmPl0gc2Jfc2V0X2Jsb2Nrc2l6ZSsweDFmLzB4NjAKT2N0ICAyIDE1 OjA3OjE3IChub25lKSBrZXJuZWw6ICBbPGMwMTYxOGVhPl0gZ2V0X3NiX2JkZXYrMHhlYS8w eDE4MApPY3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5lbDogIFs8ZDIwNzJjNmY+XSBsaW52 ZnNfZ2V0X3NiKzB4MmYvMHg0MCBbeGZzXQpPY3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5l bDogIFs8ZDIwNzI5ZjA+XSBsaW52ZnNfZmlsbF9zdXBlcisweDAvMHgyNTAgW3hmc10KT2N0 ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6ICBbPGMwMTYxYmFmPl0gZG9fa2Vybl9tb3Vu dCsweDVmLzB4ZjAKT2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6ICBbPGMwMTc4OWE3 Pl0gZG9fYWRkX21vdW50KzB4OTcvMHgxYTAKT2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJu ZWw6ICBbPGMwMTc4ZDJjPl0gZG9fbW91bnQrMHgxN2MvMHgxYTAKT2N0ICAyIDE1OjA3OjE3 IChub25lKSBrZXJuZWw6ICBbPGMwMTc4Yjk0Pl0gY29weV9tb3VudF9vcHRpb25zKzB4ZTQv MHgxMDAKT2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6ICBbPGMwMTc5MTBmPl0gc3lz X21vdW50KzB4YmYvMHgxNDAKT2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6ICBbPGMw MTA5NDRiPl0gc3lzY2FsbF9jYWxsKzB4Ny8weGIKT2N0ICAyIDE1OjA3OjE3IChub25lKSBr ZXJuZWw6IApPY3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5lbDogVW5hYmxlIHRvIGhhbmRs ZSBrZXJuZWwgcGFnaW5nIHJlcXVlc3QgYXQgdmlydHVhbCBhZGRyZXNzIDA4MDU3MDAwCk9j dCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVsOiAgcHJpbnRpbmcgZWlwOgpPY3QgIDIgMTU6 MDc6MTcgKG5vbmUpIGtlcm5lbDogMDgwNGE0ODMKT2N0ICAyIDE1OjA3OjE3IChub25lKSBr ZXJuZWw6ICpwZGUgPSAwZjliZDA2NwpPY3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5lbDog KnB0ZSA9IDAwMDAwMDAwCk9jdCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVsOiBPb3BzOiAw MDA0IFsjMV0KT2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6IENQVTogICAgMApPY3Qg IDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5lbDogRUlQOiAgICAwMDczOls8MDgwNGE0ODM+XSAg ICBOb3QgdGFpbnRlZApPY3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5lbDogRUZMQUdTOiAw MDAxMDIwNgpPY3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5lbDogRUlQIGlzIGF0IDB4ODA0 YTQ4MwpPY3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5lbDogZWF4OiAwMDAwMDAwMSAgIGVi eDogMDgwNTcwMDAgICBlY3g6IDA4MDU2YTExICAgZWR4OiAwMDAwMDA0MApPY3QgIDIgMTU6 MDc6MTcgKG5vbmUpIGtlcm5lbDogZXNpOiAwMDAwMDAwMCAgIGVkaTogMDgwNWQyNjggICBl YnA6IDAwMDAwMDAwICAgZXNwOiBiZmZmZmJlMApPY3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtl cm5lbDogZHM6IDAwN2IgICBlczogMDA3YiAgIHNzOiAwMDdiCk9jdCAgMiAxNTowNzoxNyAo bm9uZSkga2VybmVsOiBQcm9jZXNzIG1vdW50IChwaWQ6IDIwOSwgdGhyZWFkaW5mbz1jZjkw MjAwMCB0YXNrPWNmZDAxMmIwKQpPY3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5lbDogIDw2 Pm5vdGU6IG1vdW50WzIwOV0gZXhpdGVkIHdpdGggcHJlZW1wdF9jb3VudCAyOApPY3QgIDIg MTU6MDc6MTcgKG5vbmUpIGtlcm5lbDogYmFkOiBzY2hlZHVsaW5nIHdoaWxlIGF0b21pYyEK T2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6IENhbGwgVHJhY2U6Ck9jdCAgMiAxNTow NzoxNyAobm9uZSkga2VybmVsOiAgWzxjMDExZTZlNj5dIHNjaGVkdWxlKzB4NDA2LzB4NDQw Ck9jdCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVsOiAgWzxjMDE0OTVkYj5dIHVubWFwX3Bh Z2VfcmFuZ2UrMHg0Yi8weGEwCk9jdCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVsOiAgWzxj MDE0OTg2YT5dIHVubWFwX3ZtYXMrMHgyM2EvMHgyNTAKT2N0ICAyIDE1OjA3OjE3IChub25l KSBrZXJuZWw6ICBbPGMwMTRkZDY4Pl0gZXhpdF9tbWFwKzB4NzgvMHgxYzAKT2N0ICAyIDE1 OjA3OjE3IChub25lKSBrZXJuZWw6ICBbPGMwMTIwMGY1Pl0gbW1wdXQrMHg2NS8weGMwCk9j dCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVsOiAgWzxjMDEyNDBkZT5dIGRvX2V4aXQrMHgx MWUvMHgzZTAKT2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6ICBbPGMwMTFjMDQwPl0g ZG9fcGFnZV9mYXVsdCsweDAvMHg0OTMKT2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6 ICBbPGMwMTBhNTQwPl0gZG9fZGl2aWRlX2Vycm9yKzB4MC8weDE0MApPY3QgIDIgMTU6MDc6 MTcgKG5vbmUpIGtlcm5lbDogIFs8YzAxMWM0NmQ+XSBkb19wYWdlX2ZhdWx0KzB4NDJkLzB4 NDkzCk9jdCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVsOiAgWzxjMDE3OGI5ND5dIGNvcHlf bW91bnRfb3B0aW9ucysweGU0LzB4MTAwCk9jdCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVs OiAgWzxjMDE3OTE1ZT5dIHN5c19tb3VudCsweDEwZS8weDE0MApPY3QgIDIgMTU6MDc6MTcg KG5vbmUpIGtlcm5lbDogIFs8YzAxMWMwNDA+XSBkb19wYWdlX2ZhdWx0KzB4MC8weDQ5MwpP Y3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5lbDogIFs8YzAxMDllNzU+XSBlcnJvcl9jb2Rl KzB4MmQvMHgzOApPY3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5lbDogCk9jdCAgMiAxNTow NzoxNyAobm9uZSkga2VybmVsOiBiYWQ6IHNjaGVkdWxpbmcgd2hpbGUgYXRvbWljIQpPY3Qg IDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5lbDogQ2FsbCBUcmFjZToKT2N0ICAyIDE1OjA3OjE3 IChub25lKSBrZXJuZWw6ICBbPGMwMTFlNmU2Pl0gc2NoZWR1bGUrMHg0MDYvMHg0NDAKT2N0 ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6ICBbPGMwMTQyNDk3Pl0gX19wZGZsdXNoKzB4 OTcvMHgxZjAKT2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6ICBbPGMwMTQyNWYwPl0g cGRmbHVzaCsweDAvMHgyMApPY3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5lbDogIFs8YzAx NDI1ZmY+XSBwZGZsdXNoKzB4Zi8weDIwCk9jdCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVs OiAgWzxjMDEwNzI1MD5dIGtlcm5lbF90aHJlYWRfaGVscGVyKzB4MC8weDEwCk9jdCAgMiAx NTowNzoxNyAobm9uZSkga2VybmVsOiAgWzxjMDEwNzI1NT5dIGtlcm5lbF90aHJlYWRfaGVs cGVyKzB4NS8weDEwCk9jdCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVsOiAKT2N0ICAyIDE1 OjA3OjE3IChub25lKSBrZXJuZWw6IGJhZDogc2NoZWR1bGluZyB3aGlsZSBhdG9taWMhCk9j dCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVsOiBDYWxsIFRyYWNlOgpPY3QgIDIgMTU6MDc6 MTcgKG5vbmUpIGtlcm5lbDogIFs8YzAxMWU2ZTY+XSBzY2hlZHVsZSsweDQwNi8weDQ0MApP Y3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5lbDogIFs8YzAxNDI0OTc+XSBfX3BkZmx1c2gr MHg5Ny8weDFmMApPY3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5lbDogIFs8YzAxNDI1ZjA+ XSBwZGZsdXNoKzB4MC8weDIwCk9jdCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVsOiAgWzxj MDE0MjVmZj5dIHBkZmx1c2grMHhmLzB4MjAKT2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJu ZWw6ICBbPGMwMTA3MjUwPl0ga2VybmVsX3RocmVhZF9oZWxwZXIrMHgwLzB4MTAKT2N0ICAy IDE1OjA3OjE3IChub25lKSBrZXJuZWw6ICBbPGMwMTA3MjU1Pl0ga2VybmVsX3RocmVhZF9o ZWxwZXIrMHg1LzB4MTAKT2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6IApPY3QgIDIg MTU6MDc6MTcgKG5vbmUpIGtlcm5lbDogYmFkOiBzY2hlZHVsaW5nIHdoaWxlIGF0b21pYyEK T2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6IENhbGwgVHJhY2U6Ck9jdCAgMiAxNTow NzoxNyAobm9uZSkga2VybmVsOiAgWzxjMDExZTZlNj5dIHNjaGVkdWxlKzB4NDA2LzB4NDQw Ck9jdCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVsOiAgWzxjMDE0MjQ5Nz5dIF9fcGRmbHVz aCsweDk3LzB4MWYwCk9jdCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVsOiAgWzxjMDE0MjVm MD5dIHBkZmx1c2grMHgwLzB4MjAKT2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6ICBb PGMwMTQyNWZmPl0gcGRmbHVzaCsweGYvMHgyMApPY3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtl cm5lbDogIFs8YzAxMDcyNTA+XSBrZXJuZWxfdGhyZWFkX2hlbHBlcisweDAvMHgxMApPY3Qg IDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5lbDogIFs8YzAxMDcyNTU+XSBrZXJuZWxfdGhyZWFk X2hlbHBlcisweDUvMHgxMApPY3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5lbDogCk9jdCAg MiAxNTowNzoxNyAobm9uZSkga2VybmVsOiBiYWQ6IHNjaGVkdWxpbmcgd2hpbGUgYXRvbWlj IQpPY3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5lbDogQ2FsbCBUcmFjZToKT2N0ICAyIDE1 OjA3OjE3IChub25lKSBrZXJuZWw6ICBbPGMwMTFlNmU2Pl0gc2NoZWR1bGUrMHg0MDYvMHg0 NDAKT2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6ICBbPGMwMTQyNDk3Pl0gX19wZGZs dXNoKzB4OTcvMHgxZjAKT2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6ICBbPGMwMTQy NWYwPl0gcGRmbHVzaCsweDAvMHgyMApPY3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5lbDog IFs8YzAxNDI1ZmY+XSBwZGZsdXNoKzB4Zi8weDIwCk9jdCAgMiAxNTowNzoxNyAobm9uZSkg a2VybmVsOiAgWzxjMDEwNzI1MD5dIGtlcm5lbF90aHJlYWRfaGVscGVyKzB4MC8weDEwCk9j dCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVsOiAgWzxjMDEwNzI1NT5dIGtlcm5lbF90aHJl YWRfaGVscGVyKzB4NS8weDEwCk9jdCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVsOiAKT2N0 ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6IGJhZDogc2NoZWR1bGluZyB3aGlsZSBhdG9t aWMhCk9jdCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVsOiBDYWxsIFRyYWNlOgpPY3QgIDIg MTU6MDc6MTcgKG5vbmUpIGtlcm5lbDogIFs8YzAxMWU2ZTY+XSBzY2hlZHVsZSsweDQwNi8w eDQ0MApPY3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5lbDogIFs8YzAxNDI0OTc+XSBfX3Bk Zmx1c2grMHg5Ny8weDFmMApPY3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5lbDogIFs8YzAx NDI1ZjA+XSBwZGZsdXNoKzB4MC8weDIwCk9jdCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVs OiAgWzxjMDE0MjVmZj5dIHBkZmx1c2grMHhmLzB4MjAKT2N0ICAyIDE1OjA3OjE3IChub25l KSBrZXJuZWw6ICBbPGMwMTA3MjUwPl0ga2VybmVsX3RocmVhZF9oZWxwZXIrMHgwLzB4MTAK T2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6ICBbPGMwMTA3MjU1Pl0ga2VybmVsX3Ro cmVhZF9oZWxwZXIrMHg1LzB4MTAKT2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6IApP Y3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5lbDogYmFkOiBzY2hlZHVsaW5nIHdoaWxlIGF0 b21pYyEKT2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6IENhbGwgVHJhY2U6Ck9jdCAg MiAxNTowNzoxNyAobm9uZSkga2VybmVsOiAgWzxjMDExZTZlNj5dIHNjaGVkdWxlKzB4NDA2 LzB4NDQwCk9jdCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVsOiAgWzxjMDE0MjQ5Nz5dIF9f cGRmbHVzaCsweDk3LzB4MWYwCk9jdCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVsOiAgWzxj MDE0MjVmMD5dIHBkZmx1c2grMHgwLzB4MjAKT2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJu ZWw6ICBbPGMwMTQyNWZmPl0gcGRmbHVzaCsweGYvMHgyMApPY3QgIDIgMTU6MDc6MTcgKG5v bmUpIGtlcm5lbDogIFs8YzAxMDcyNTA+XSBrZXJuZWxfdGhyZWFkX2hlbHBlcisweDAvMHgx MApPY3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5lbDogIFs8YzAxMDcyNTU+XSBrZXJuZWxf dGhyZWFkX2hlbHBlcisweDUvMHgxMApPY3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5lbDog Ck9jdCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVsOiBiYWQ6IHNjaGVkdWxpbmcgd2hpbGUg YXRvbWljIQpPY3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5lbDogQ2FsbCBUcmFjZToKT2N0 ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6ICBbPGMwMTFlNmU2Pl0gc2NoZWR1bGUrMHg0 MDYvMHg0NDAKT2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6ICBbPGMwMTJhNDZkPl0g c2NoZWR1bGVfdGltZW91dCsweDVkLzB4YjAKT2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJu ZWw6ICBbPGQyMDU4M2NmPl0geGZzX3N5bmMrMHgyZi8weDQwIFt4ZnNdCk9jdCAgMiAxNTow NzoxNyAobm9uZSkga2VybmVsOiAgWzxjMDEyYTQwMD5dIHByb2Nlc3NfdGltZW91dCsweDAv MHgxMApPY3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5lbDogIFs8ZDIwNzIyNjI+XSBzeW5j ZCsweDUyLzB4YzAgW3hmc10KT2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6ICBbPGQy MDcyMjEwPl0gc3luY2QrMHgwLzB4YzAgW3hmc10KT2N0ICAyIDE1OjA3OjE3IChub25lKSBr ZXJuZWw6ICBbPGMwMTA3MjU1Pl0ga2VybmVsX3RocmVhZF9oZWxwZXIrMHg1LzB4MTAKT2N0 ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6IApPY3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtl cm5lbDogYmFkOiBzY2hlZHVsaW5nIHdoaWxlIGF0b21pYyEKT2N0ICAyIDE1OjA3OjE3IChu b25lKSBrZXJuZWw6IENhbGwgVHJhY2U6Ck9jdCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVs OiAgWzxjMDExZTZlNj5dIHNjaGVkdWxlKzB4NDA2LzB4NDQwCk9jdCAgMiAxNTowNzoxNyAo bm9uZSkga2VybmVsOiAgWzxjMDE0MjQ5Nz5dIF9fcGRmbHVzaCsweDk3LzB4MWYwCk9jdCAg MiAxNTowNzoxNyAobm9uZSkga2VybmVsOiAgWzxjMDE0MjVmMD5dIHBkZmx1c2grMHgwLzB4 MjAKT2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6ICBbPGMwMTQyNWZmPl0gcGRmbHVz aCsweGYvMHgyMApPY3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5lbDogIFs8YzAxMDcyNTA+ XSBrZXJuZWxfdGhyZWFkX2hlbHBlcisweDAvMHgxMApPY3QgIDIgMTU6MDc6MTcgKG5vbmUp IGtlcm5lbDogIFs8YzAxMDcyNTU+XSBrZXJuZWxfdGhyZWFkX2hlbHBlcisweDUvMHgxMApP Y3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5lbDogCk9jdCAgMiAxNTowNzoxNyAobm9uZSkg a2VybmVsOiBiYWQ6IHNjaGVkdWxpbmcgd2hpbGUgYXRvbWljIQpPY3QgIDIgMTU6MDc6MTcg KG5vbmUpIGtlcm5lbDogQ2FsbCBUcmFjZToKT2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJu ZWw6ICBbPGMwMTFlNmU2Pl0gc2NoZWR1bGUrMHg0MDYvMHg0NDAKT2N0ICAyIDE1OjA3OjE3 IChub25lKSBrZXJuZWw6ICBbPGMwMTQyNDk3Pl0gX19wZGZsdXNoKzB4OTcvMHgxZjAKT2N0 ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6ICBbPGMwMTQyNWYwPl0gcGRmbHVzaCsweDAv MHgyMApPY3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5lbDogIFs8YzAxNDI1ZmY+XSBwZGZs dXNoKzB4Zi8weDIwCk9jdCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVsOiAgWzxjMDEwNzI1 MD5dIGtlcm5lbF90aHJlYWRfaGVscGVyKzB4MC8weDEwCk9jdCAgMiAxNTowNzoxNyAobm9u ZSkga2VybmVsOiAgWzxjMDEwNzI1NT5dIGtlcm5lbF90aHJlYWRfaGVscGVyKzB4NS8weDEw Ck9jdCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVsOiAKT2N0ICAyIDE1OjA3OjE3IChub25l KSBrZXJuZWw6IGJhZDogc2NoZWR1bGluZyB3aGlsZSBhdG9taWMhCk9jdCAgMiAxNTowNzox NyAobm9uZSkga2VybmVsOiBDYWxsIFRyYWNlOgpPY3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtl cm5lbDogIFs8YzAxMWU2ZTY+XSBzY2hlZHVsZSsweDQwNi8weDQ0MApPY3QgIDIgMTU6MDc6 MTcgKG5vbmUpIGtlcm5lbDogIFs8YzAxNDI0OTc+XSBfX3BkZmx1c2grMHg5Ny8weDFmMApP Y3QgIDIgMTU6MDc6MTcgKG5vbmUpIGtlcm5lbDogIFs8YzAxNDI1ZjA+XSBwZGZsdXNoKzB4 MC8weDIwCk9jdCAgMiAxNTowNzoxNyAobm9uZSkga2VybmVsOiAgWzxjMDE0MjVmZj5dIHBk Zmx1c2grMHhmLzB4MjAKT2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6ICBbPGMwMTA3 MjUwPl0ga2VybmVsX3RocmVhZF9oZWxwZXIrMHgwLzB4MTAKT2N0ICAyIDE1OjA3OjE3IChu b25lKSBrZXJuZWw6ICBbPGMwMTA3MjU1Pl0ga2VybmVsX3RocmVhZF9oZWxwZXIrMHg1LzB4 MTAKT2N0ICAyIDE1OjA3OjE3IChub25lKSBrZXJuZWw6IApPY3QgIDIgMTU6MDc6MjIgKG5v bmUpIGtlcm5lbDogYmFkOiBzY2hlZHVsaW5nIHdoaWxlIGF0b21pYyEKT2N0ICAyIDE1OjA3 OjIyIChub25lKSBrZXJuZWw6IENhbGwgVHJhY2U6Ck9jdCAgMiAxNTowNzoyMiAobm9uZSkg a2VybmVsOiAgWzxjMDExZTZlNj5dIHNjaGVkdWxlKzB4NDA2LzB4NDQwCk9jdCAgMiAxNTow NzoyMiAobm9uZSkga2VybmVsOiAgWzxjMDE0MjQ5Nz5dIF9fcGRmbHVzaCsweDk3LzB4MWYw Ck9jdCAgMiAxNTowNzoyMiAobm9uZSkga2VybmVsOiAgWzxjMDE0MjVmMD5dIHBkZmx1c2gr MHgwLzB4MjAKT2N0ICAyIDE1OjA3OjIyIChub25lKSBrZXJuZWw6ICBbPGMwMTQyNWZmPl0g cGRmbHVzaCsweGYvMHgyMApPY3QgIDIgMTU6MDc6MjIgKG5vbmUpIGtlcm5lbDogIFs8YzAx MDcyNTA+XSBrZXJuZWxfdGhyZWFkX2hlbHBlcisweDAvMHgxMApPY3QgIDIgMTU6MDc6MjIg KG5vbmUpIGtlcm5lbDogIFs8YzAxMDcyNTU+XSBrZXJuZWxfdGhyZWFkX2hlbHBlcisweDUv MHgxMApPY3QgIDIgMTU6MDc6MjIgKG5vbmUpIGtlcm5lbDogCk9jdCAgMiAxNTowNzoyNyAo bm9uZSkga2VybmVsOiBiYWQ6IHNjaGVkdWxpbmcgd2hpbGUgYXRvbWljIQpPY3QgIDIgMTU6 MDc6MjcgKG5vbmUpIGtlcm5lbDogQ2FsbCBUcmFjZToKT2N0ICAyIDE1OjA3OjI3IChub25l KSBrZXJuZWw6ICBbPGMwMTFlNmU2Pl0gc2NoZWR1bGUrMHg0MDYvMHg0NDAKT2N0ICAyIDE1 OjA3OjI3IChub25lKSBrZXJuZWw6ICBbPGMwMTQyNDk3Pl0gX19wZGZsdXNoKzB4OTcvMHgx ZjAKT2N0ICAyIDE1OjA3OjI3IChub25lKSBrZXJuZWw6ICBbPGMwMTQyNWYwPl0gcGRmbHVz aCsweDAvMHgyMApPY3QgIDIgMTU6MDc6MjcgKG5vbmUpIGtlcm5lbDogIFs8YzAxNDI1ZmY+ XSBwZGZsdXNoKzB4Zi8weDIwCk9jdCAgMiAxNTowNzoyNyAobm9uZSkga2VybmVsOiAgWzxj MDEwNzI1MD5dIGtlcm5lbF90aHJlYWRfaGVscGVyKzB4MC8weDEwCk9jdCAgMiAxNTowNzoy NyAobm9uZSkga2VybmVsOiAgWzxjMDEwNzI1NT5dIGtlcm5lbF90aHJlYWRfaGVscGVyKzB4 NS8weDEwCk9jdCAgMiAxNTowNzoyNyAobm9uZSkga2VybmVsOiAKT2N0ICAyIDE1OjA3OjMy IChub25lKSBrZXJuZWw6IGJhZDogc2NoZWR1bGluZyB3aGlsZSBhdG9taWMhCk9jdCAgMiAx NTowNzozMiAobm9uZSkga2VybmVsOiBDYWxsIFRyYWNlOgpPY3QgIDIgMTU6MDc6MzIgKG5v bmUpIGtlcm5lbDogIFs8YzAxMWU2ZTY+XSBzY2hlZHVsZSsweDQwNi8weDQ0MApPY3QgIDIg MTU6MDc6MzIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNDI0OTc+XSBfX3BkZmx1c2grMHg5Ny8w eDFmMApPY3QgIDIgMTU6MDc6MzIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNDI1ZjA+XSBwZGZs dXNoKzB4MC8weDIwCk9jdCAgMiAxNTowNzozMiAobm9uZSkga2VybmVsOiAgWzxjMDE0MjVm Zj5dIHBkZmx1c2grMHhmLzB4MjAKT2N0ICAyIDE1OjA3OjMyIChub25lKSBrZXJuZWw6ICBb PGMwMTA3MjUwPl0ga2VybmVsX3RocmVhZF9oZWxwZXIrMHgwLzB4MTAKT2N0ICAyIDE1OjA3 OjMyIChub25lKSBrZXJuZWw6ICBbPGMwMTA3MjU1Pl0ga2VybmVsX3RocmVhZF9oZWxwZXIr MHg1LzB4MTAKT2N0ICAyIDE1OjA3OjMyIChub25lKSBrZXJuZWw6IApPY3QgIDIgMTU6MDc6 MzMgKG5vbmUpIGtlcm5lbDogYmFkOiBzY2hlZHVsaW5nIHdoaWxlIGF0b21pYyEKT2N0ICAy IDE1OjA3OjMzIChub25lKSBrZXJuZWw6IENhbGwgVHJhY2U6Ck9jdCAgMiAxNTowNzozMyAo bm9uZSkga2VybmVsOiAgWzxjMDExZTZlNj5dIHNjaGVkdWxlKzB4NDA2LzB4NDQwCk9jdCAg MiAxNTowNzozMyAobm9uZSkga2VybmVsOiAgWzxjMDEyYTQ2ZD5dIHNjaGVkdWxlX3RpbWVv dXQrMHg1ZC8weGIwCk9jdCAgMiAxNTowNzozMyAobm9uZSkga2VybmVsOiAgWzxkMjA1ODNj Zj5dIHhmc19zeW5jKzB4MmYvMHg0MCBbeGZzXQpPY3QgIDIgMTU6MDc6MzMgKG5vbmUpIGtl cm5lbDogIFs8YzAxMmE0MDA+XSBwcm9jZXNzX3RpbWVvdXQrMHgwLzB4MTAKT2N0ICAyIDE1 OjA3OjMzIChub25lKSBrZXJuZWw6ICBbPGQyMDcyMjYyPl0gc3luY2QrMHg1Mi8weGMwIFt4 ZnNdCk9jdCAgMiAxNTowNzozMyAobm9uZSkga2VybmVsOiAgWzxkMjA3MjIxMD5dIHN5bmNk KzB4MC8weGMwIFt4ZnNdCk9jdCAgMiAxNTowNzozMyAobm9uZSkga2VybmVsOiAgWzxjMDEw NzI1NT5dIGtlcm5lbF90aHJlYWRfaGVscGVyKzB4NS8weDEwCk9jdCAgMiAxNTowNzozMyAo bm9uZSkga2VybmVsOiAKT2N0ICAyIDE1OjA3OjM3IChub25lKSBrZXJuZWw6IGJhZDogc2No ZWR1bGluZyB3aGlsZSBhdG9taWMhCk9jdCAgMiAxNTowNzozNyAobm9uZSkga2VybmVsOiBD YWxsIFRyYWNlOgpPY3QgIDIgMTU6MDc6MzcgKG5vbmUpIGtlcm5lbDogIFs8YzAxMWU2ZTY+ XSBzY2hlZHVsZSsweDQwNi8weDQ0MApPY3QgIDIgMTU6MDc6MzcgKG5vbmUpIGtlcm5lbDog IFs8YzAxNDI0OTc+XSBfX3BkZmx1c2grMHg5Ny8weDFmMApPY3QgIDIgMTU6MDc6MzcgKG5v bmUpIGtlcm5lbDogIFs8YzAxNDI1ZjA+XSBwZGZsdXNoKzB4MC8weDIwCk9jdCAgMiAxNTow NzozNyAobm9uZSkga2VybmVsOiAgWzxjMDE0MjVmZj5dIHBkZmx1c2grMHhmLzB4MjAKT2N0 ICAyIDE1OjA3OjM3IChub25lKSBrZXJuZWw6ICBbPGMwMTA3MjUwPl0ga2VybmVsX3RocmVh ZF9oZWxwZXIrMHgwLzB4MTAKT2N0ICAyIDE1OjA3OjM3IChub25lKSBrZXJuZWw6ICBbPGMw MTA3MjU1Pl0ga2VybmVsX3RocmVhZF9oZWxwZXIrMHg1LzB4MTAKT2N0ICAyIDE1OjA3OjM3 IChub25lKSBrZXJuZWw6IApPY3QgIDIgMTU6MDc6NDIgKG5vbmUpIGtlcm5lbDogYmFkOiBz Y2hlZHVsaW5nIHdoaWxlIGF0b21pYyEKT2N0ICAyIDE1OjA3OjQyIChub25lKSBrZXJuZWw6 IENhbGwgVHJhY2U6Ck9jdCAgMiAxNTowNzo0MiAobm9uZSkga2VybmVsOiAgWzxjMDExZTZl Nj5dIHNjaGVkdWxlKzB4NDA2LzB4NDQwCk9jdCAgMiAxNTowNzo0MiAobm9uZSkga2VybmVs OiAgWzxjMDE0MjQ5Nz5dIF9fcGRmbHVzaCsweDk3LzB4MWYwCk9jdCAgMiAxNTowNzo0MiAo bm9uZSkga2VybmVsOiAgWzxjMDE0MjVmMD5dIHBkZmx1c2grMHgwLzB4MjAKT2N0ICAyIDE1 OjA3OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTQyNWZmPl0gcGRmbHVzaCsweGYvMHgyMApP Y3QgIDIgMTU6MDc6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxMDcyNTA+XSBrZXJuZWxfdGhy ZWFkX2hlbHBlcisweDAvMHgxMApPY3QgIDIgMTU6MDc6NDIgKG5vbmUpIGtlcm5lbDogIFs8 YzAxMDcyNTU+XSBrZXJuZWxfdGhyZWFkX2hlbHBlcisweDUvMHgxMApPY3QgIDIgMTU6MDc6 NDIgKG5vbmUpIGtlcm5lbDogCk9jdCAgMiAxNTowNzo0NyAobm9uZSkga2VybmVsOiBiYWQ6 IHNjaGVkdWxpbmcgd2hpbGUgYXRvbWljIQpPY3QgIDIgMTU6MDc6NDcgKG5vbmUpIGtlcm5l bDogQ2FsbCBUcmFjZToKT2N0ICAyIDE1OjA3OjQ3IChub25lKSBrZXJuZWw6ICBbPGMwMTFl NmU2Pl0gc2NoZWR1bGUrMHg0MDYvMHg0NDAKT2N0ICAyIDE1OjA3OjQ3IChub25lKSBrZXJu ZWw6ICBbPGMwMTQyNDk3Pl0gX19wZGZsdXNoKzB4OTcvMHgxZjAKT2N0ICAyIDE1OjA3OjQ3 IChub25lKSBrZXJuZWw6ICBbPGMwMTQyNWYwPl0gcGRmbHVzaCsweDAvMHgyMApPY3QgIDIg MTU6MDc6NDcgKG5vbmUpIGtlcm5lbDogIFs8YzAxNDI1ZmY+XSBwZGZsdXNoKzB4Zi8weDIw Ck9jdCAgMiAxNTowNzo0NyAobm9uZSkga2VybmVsOiAgWzxjMDEwNzI1MD5dIGtlcm5lbF90 aHJlYWRfaGVscGVyKzB4MC8weDEwCk9jdCAgMiAxNTowNzo0NyAobm9uZSkga2VybmVsOiAg WzxjMDEwNzI1NT5dIGtlcm5lbF90aHJlYWRfaGVscGVyKzB4NS8weDEwCk9jdCAgMiAxNTow Nzo0NyAobm9uZSkga2VybmVsOiAKT2N0ICAyIDE1OjA3OjUyIChub25lKSBrZXJuZWw6IGJh ZDogc2NoZWR1bGluZyB3aGlsZSBhdG9taWMhCk9jdCAgMiAxNTowNzo1MiAobm9uZSkga2Vy bmVsOiBDYWxsIFRyYWNlOgpPY3QgIDIgMTU6MDc6NTIgKG5vbmUpIGtlcm5lbDogIFs8YzAx MWU2ZTY+XSBzY2hlZHVsZSsweDQwNi8weDQ0MApPY3QgIDIgMTU6MDc6NTIgKG5vbmUpIGtl cm5lbDogIFs8YzAxNDI0OTc+XSBfX3BkZmx1c2grMHg5Ny8weDFmMApPY3QgIDIgMTU6MDc6 NTIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNDI1ZjA+XSBwZGZsdXNoKzB4MC8weDIwCk9jdCAg MiAxNTowNzo1MiAobm9uZSkga2VybmVsOiAgWzxjMDE0MjVmZj5dIHBkZmx1c2grMHhmLzB4 MjAKT2N0ICAyIDE1OjA3OjUyIChub25lKSBrZXJuZWw6ICBbPGMwMTA3MjUwPl0ga2VybmVs X3RocmVhZF9oZWxwZXIrMHgwLzB4MTAKT2N0ICAyIDE1OjA3OjUyIChub25lKSBrZXJuZWw6 ICBbPGMwMTA3MjU1Pl0ga2VybmVsX3RocmVhZF9oZWxwZXIrMHg1LzB4MTAKT2N0ICAyIDE1 OjA3OjUyIChub25lKSBrZXJuZWw6IApPY3QgIDIgMTU6MDc6NTcgKG5vbmUpIGtlcm5lbDog YmFkOiBzY2hlZHVsaW5nIHdoaWxlIGF0b21pYyEKT2N0ICAyIDE1OjA3OjU3IChub25lKSBr ZXJuZWw6IENhbGwgVHJhY2U6Ck9jdCAgMiAxNTowNzo1NyAobm9uZSkga2VybmVsOiAgWzxj MDExZTZlNj5dIHNjaGVkdWxlKzB4NDA2LzB4NDQwCk9jdCAgMiAxNTowNzo1NyAobm9uZSkg a2VybmVsOiAgWzxjMDE0MjQ5Nz5dIF9fcGRmbHVzaCsweDk3LzB4MWYwCk9jdCAgMiAxNTow Nzo1NyAobm9uZSkga2VybmVsOiAgWzxjMDE0MjVmMD5dIHBkZmx1c2grMHgwLzB4MjAKT2N0 ICAyIDE1OjA3OjU3IChub25lKSBrZXJuZWw6ICBbPGMwMTQyNWZmPl0gcGRmbHVzaCsweGYv MHgyMApPY3QgIDIgMTU6MDc6NTcgKG5vbmUpIGtlcm5lbDogIFs8YzAxMDcyNTA+XSBrZXJu ZWxfdGhyZWFkX2hlbHBlcisweDAvMHgxMApPY3QgIDIgMTU6MDc6NTcgKG5vbmUpIGtlcm5l bDogIFs8YzAxMDcyNTU+XSBrZXJuZWxfdGhyZWFkX2hlbHBlcisweDUvMHgxMApPY3QgIDIg MTU6MDc6NTcgKG5vbmUpIGtlcm5lbDogCk9jdCAgMiAxNTowODowMiAobm9uZSkga2VybmVs OiBiYWQ6IHNjaGVkdWxpbmcgd2hpbGUgYXRvbWljIQpPY3QgIDIgMTU6MDg6MDIgKG5vbmUp IGtlcm5lbDogQ2FsbCBUcmFjZToKT2N0ICAyIDE1OjA4OjAyIChub25lKSBrZXJuZWw6ICBb PGMwMTFlNmU2Pl0gc2NoZWR1bGUrMHg0MDYvMHg0NDAKT2N0ICAyIDE1OjA4OjAyIChub25l KSBrZXJuZWw6ICBbPGMwMTQyNDk3Pl0gX19wZGZsdXNoKzB4OTcvMHgxZjAKT2N0ICAyIDE1 OjA4OjAyIChub25lKSBrZXJuZWw6ICBbPGMwMTQyNWYwPl0gcGRmbHVzaCsweDAvMHgyMApP Y3QgIDIgMTU6MDg6MDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNDI1ZmY+XSBwZGZsdXNoKzB4 Zi8weDIwCk9jdCAgMiAxNTowODowMiAobm9uZSkga2VybmVsOiAgWzxjMDEwNzI1MD5dIGtl cm5lbF90aHJlYWRfaGVscGVyKzB4MC8weDEwCk9jdCAgMiAxNTowODowMiAobm9uZSkga2Vy bmVsOiAgWzxjMDEwNzI1NT5dIGtlcm5lbF90aHJlYWRfaGVscGVyKzB4NS8weDEwCk9jdCAg MiAxNTowODowMiAobm9uZSkga2VybmVsOiAKT2N0ICAyIDE1OjA4OjAzIChub25lKSBrZXJu ZWw6IGJhZDogc2NoZWR1bGluZyB3aGlsZSBhdG9taWMhCk9jdCAgMiAxNTowODowMyAobm9u ZSkga2VybmVsOiBDYWxsIFRyYWNlOgpPY3QgIDIgMTU6MDg6MDMgKG5vbmUpIGtlcm5lbDog IFs8YzAxMWU2ZTY+XSBzY2hlZHVsZSsweDQwNi8weDQ0MApPY3QgIDIgMTU6MDg6MDMgKG5v bmUpIGtlcm5lbDogIFs8YzAxMmE0NmQ+XSBzY2hlZHVsZV90aW1lb3V0KzB4NWQvMHhiMApP Y3QgIDIgMTU6MDg6MDMgKG5vbmUpIGtlcm5lbDogIFs8ZDIwNTgzY2Y+XSB4ZnNfc3luYysw eDJmLzB4NDAgW3hmc10KT2N0ICAyIDE1OjA4OjAzIChub25lKSBrZXJuZWw6ICBbPGMwMTJh NDAwPl0gcHJvY2Vzc190aW1lb3V0KzB4MC8weDEwCk9jdCAgMiAxNTowODowMyAobm9uZSkg a2VybmVsOiAgWzxkMjA3MjI2Mj5dIHN5bmNkKzB4NTIvMHhjMCBbeGZzXQpPY3QgIDIgMTU6 MDg6MDMgKG5vbmUpIGtlcm5lbDogIFs8ZDIwNzIyMTA+XSBzeW5jZCsweDAvMHhjMCBbeGZz XQpPY3QgIDIgMTU6MDg6MDMgKG5vbmUpIGtlcm5lbDogIFs8YzAxMDcyNTU+XSBrZXJuZWxf dGhyZWFkX2hlbHBlcisweDUvMHgxMApPY3QgIDIgMTU6MDg6MDMgKG5vbmUpIGtlcm5lbDog Ck9jdCAgMiAxNTowODowNyAobm9uZSkga2VybmVsOiBiYWQ6IHNjaGVkdWxpbmcgd2hpbGUg YXRvbWljIQpPY3QgIDIgMTU6MDg6MDcgKG5vbmUpIGtlcm5lbDogQ2FsbCBUcmFjZToKT2N0 ICAyIDE1OjA4OjA3IChub25lKSBrZXJuZWw6ICBbPGMwMTFlNmU2Pl0gc2NoZWR1bGUrMHg0 MDYvMHg0NDAKT2N0ICAyIDE1OjA4OjA3IChub25lKSBrZXJuZWw6ICBbPGMwMTQyNDk3Pl0g X19wZGZsdXNoKzB4OTcvMHgxZjAKT2N0ICAyIDE1OjA4OjA3IChub25lKSBrZXJuZWw6ICBb PGMwMTQyNWYwPl0gcGRmbHVzaCsweDAvMHgyMApPY3QgIDIgMTU6MDg6MDcgKG5vbmUpIGtl cm5lbDogIFs8YzAxNDI1ZmY+XSBwZGZsdXNoKzB4Zi8weDIwCk9jdCAgMiAxNTowODowNyAo bm9uZSkga2VybmVsOiAgWzxjMDEwNzI1MD5dIGtlcm5lbF90aHJlYWRfaGVscGVyKzB4MC8w eDEwCk9jdCAgMiAxNTowODowNyAobm9uZSkga2VybmVsOiAgWzxjMDEwNzI1NT5dIGtlcm5l bF90aHJlYWRfaGVscGVyKzB4NS8weDEwCk9jdCAgMiAxNTowODowNyAobm9uZSkga2VybmVs OiAKT2N0ICAyIDE1OjA4OjEyIChub25lKSBrZXJuZWw6IGJhZDogc2NoZWR1bGluZyB3aGls ZSBhdG9taWMhCk9jdCAgMiAxNTowODoxMiAobm9uZSkga2VybmVsOiBDYWxsIFRyYWNlOgpP Y3QgIDIgMTU6MDg6MTIgKG5vbmUpIGtlcm5lbDogIFs8YzAxMWU2ZTY+XSBzY2hlZHVsZSsw eDQwNi8weDQ0MApPY3QgIDIgMTU6MDg6MTIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNDI0OTc+ XSBfX3BkZmx1c2grMHg5Ny8weDFmMApPY3QgIDIgMTU6MDg6MTIgKG5vbmUpIGtlcm5lbDog IFs8YzAxNDI1ZjA+XSBwZGZsdXNoKzB4MC8weDIwCk9jdCAgMiAxNTowODoxMiAobm9uZSkg a2VybmVsOiAgWzxjMDE0MjVmZj5dIHBkZmx1c2grMHhmLzB4MjAKT2N0ICAyIDE1OjA4OjEy IChub25lKSBrZXJuZWw6ICBbPGMwMTA3MjUwPl0ga2VybmVsX3RocmVhZF9oZWxwZXIrMHgw LzB4MTAKT2N0ICAyIDE1OjA4OjEyIChub25lKSBrZXJuZWw6ICBbPGMwMTA3MjU1Pl0ga2Vy bmVsX3RocmVhZF9oZWxwZXIrMHg1LzB4MTAKT2N0ICAyIDE1OjA4OjEyIChub25lKSBrZXJu ZWw6IApPY3QgIDIgMTU6MDg6MTcgKG5vbmUpIGtlcm5lbDogYmFkOiBzY2hlZHVsaW5nIHdo aWxlIGF0b21pYyEKT2N0ICAyIDE1OjA4OjE3IChub25lKSBrZXJuZWw6IENhbGwgVHJhY2U6 Ck9jdCAgMiAxNTowODoxNyAobm9uZSkga2VybmVsOiAgWzxjMDExZTZlNj5dIHNjaGVkdWxl KzB4NDA2LzB4NDQwCk9jdCAgMiAxNTowODoxNyAobm9uZSkga2VybmVsOiAgWzxjMDE0MjQ5 Nz5dIF9fcGRmbHVzaCsweDk3LzB4MWYwCk9jdCAgMiAxNTowODoxNyAobm9uZSkga2VybmVs OiAgWzxjMDE0MjVmMD5dIHBkZmx1c2grMHgwLzB4MjAKT2N0ICAyIDE1OjA4OjE3IChub25l KSBrZXJuZWw6ICBbPGMwMTQyNWZmPl0gcGRmbHVzaCsweGYvMHgyMApPY3QgIDIgMTU6MDg6 MTcgKG5vbmUpIGtlcm5lbDogIFs8YzAxMDcyNTA+XSBrZXJuZWxfdGhyZWFkX2hlbHBlcisw eDAvMHgxMApPY3QgIDIgMTU6MDg6MTcgKG5vbmUpIGtlcm5lbDogIFs8YzAxMDcyNTU+XSBr ZXJuZWxfdGhyZWFkX2hlbHBlcisweDUvMHgxMApPY3QgIDIgMTU6MDg6MTcgKG5vbmUpIGtl cm5lbDogCk9jdCAgMiAxNTowODoyMiAobm9uZSkga2VybmVsOiBiYWQ6IHNjaGVkdWxpbmcg d2hpbGUgYXRvbWljIQpPY3QgIDIgMTU6MDg6MjIgKG5vbmUpIGtlcm5lbDogQ2FsbCBUcmFj ZToKT2N0ICAyIDE1OjA4OjIyIChub25lKSBrZXJuZWw6ICBbPGMwMTFlNmU2Pl0gc2NoZWR1 bGUrMHg0MDYvMHg0NDAKT2N0ICAyIDE1OjA4OjIyIChub25lKSBrZXJuZWw6ICBbPGMwMTQy NDk3Pl0gX19wZGZsdXNoKzB4OTcvMHgxZjAKT2N0ICAyIDE1OjA4OjIyIChub25lKSBrZXJu ZWw6ICBbPGMwMTQyNWYwPl0gcGRmbHVzaCsweDAvMHgyMApPY3QgIDIgMTU6MDg6MjIgKG5v bmUpIGtlcm5lbDogIFs8YzAxNDI1ZmY+XSBwZGZsdXNoKzB4Zi8weDIwCk9jdCAgMiAxNTow ODoyMiAobm9uZSkga2VybmVsOiAgWzxjMDEwNzI1MD5dIGtlcm5lbF90aHJlYWRfaGVscGVy KzB4MC8weDEwCk9jdCAgMiAxNTowODoyMiAobm9uZSkga2VybmVsOiAgWzxjMDEwNzI1NT5d IGtlcm5lbF90aHJlYWRfaGVscGVyKzB4NS8weDEwCk9jdCAgMiAxNTowODoyMiAobm9uZSkg a2VybmVsOiAKT2N0ICAyIDE1OjA4OjI3IChub25lKSBrZXJuZWw6IGJhZDogc2NoZWR1bGlu ZyB3aGlsZSBhdG9taWMhCk9jdCAgMiAxNTowODoyNyAobm9uZSkga2VybmVsOiBDYWxsIFRy YWNlOgpPY3QgIDIgMTU6MDg6MjcgKG5vbmUpIGtlcm5lbDogIFs8YzAxMWU2ZTY+XSBzY2hl ZHVsZSsweDQwNi8weDQ0MApPY3QgIDIgMTU6MDg6MjcgKG5vbmUpIGtlcm5lbDogIFs8YzAx NDI0OTc+XSBfX3BkZmx1c2grMHg5Ny8weDFmMApPY3QgIDIgMTU6MDg6MjcgKG5vbmUpIGtl cm5lbDogIFs8YzAxNDI1ZjA+XSBwZGZsdXNoKzB4MC8weDIwCk9jdCAgMiAxNTowODoyNyAo bm9uZSkga2VybmVsOiAgWzxjMDE0MjVmZj5dIHBkZmx1c2grMHhmLzB4MjAKT2N0ICAyIDE1 OjA4OjI3IChub25lKSBrZXJuZWw6ICBbPGMwMTA3MjUwPl0ga2VybmVsX3RocmVhZF9oZWxw ZXIrMHgwLzB4MTAKT2N0ICAyIDE1OjA4OjI3IChub25lKSBrZXJuZWw6ICBbPGMwMTA3MjU1 Pl0ga2VybmVsX3RocmVhZF9oZWxwZXIrMHg1LzB4MTAKT2N0ICAyIDE1OjA4OjI3IChub25l KSBrZXJuZWw6IApPY3QgIDIgMTU6MDg6MzIgKG5vbmUpIGtlcm5lbDogYmFkOiBzY2hlZHVs aW5nIHdoaWxlIGF0b21pYyEKT2N0ICAyIDE1OjA4OjMyIChub25lKSBrZXJuZWw6IENhbGwg VHJhY2U6Ck9jdCAgMiAxNTowODozMiAobm9uZSkga2VybmVsOiAgWzxjMDExZTZlNj5dIHNj aGVkdWxlKzB4NDA2LzB4NDQwCk9jdCAgMiAxNTowODozMiAobm9uZSkga2VybmVsOiAgWzxj MDE0MjQ5Nz5dIF9fcGRmbHVzaCsweDk3LzB4MWYwCk9jdCAgMiAxNTowODozMiAobm9uZSkg a2VybmVsOiAgWzxjMDE0MjVmMD5dIHBkZmx1c2grMHgwLzB4MjAKT2N0ICAyIDE1OjA4OjMy IChub25lKSBrZXJuZWw6ICBbPGMwMTQyNWZmPl0gcGRmbHVzaCsweGYvMHgyMApPY3QgIDIg MTU6MDg6MzIgKG5vbmUpIGtlcm5lbDogIFs8YzAxMDcyNTA+XSBrZXJuZWxfdGhyZWFkX2hl bHBlcisweDAvMHgxMApPY3QgIDIgMTU6MDg6MzIgKG5vbmUpIGtlcm5lbDogIFs8YzAxMDcy NTU+XSBrZXJuZWxfdGhyZWFkX2hlbHBlcisweDUvMHgxMApPY3QgIDIgMTU6MDg6MzIgKG5v bmUpIGtlcm5lbDogCk9jdCAgMiAxNTowODozMyAobm9uZSkga2VybmVsOiBiYWQ6IHNjaGVk dWxpbmcgd2hpbGUgYXRvbWljIQpPY3QgIDIgMTU6MDg6MzMgKG5vbmUpIGtlcm5lbDogQ2Fs bCBUcmFjZToKT2N0ICAyIDE1OjA4OjMzIChub25lKSBrZXJuZWw6ICBbPGMwMTFlNmU2Pl0g c2NoZWR1bGUrMHg0MDYvMHg0NDAKT2N0ICAyIDE1OjA4OjMzIChub25lKSBrZXJuZWw6ICBb PGMwMTJhNDZkPl0gc2NoZWR1bGVfdGltZW91dCsweDVkLzB4YjAKT2N0ICAyIDE1OjA4OjMz IChub25lKSBrZXJuZWw6ICBbPGQyMDU4M2NmPl0geGZzX3N5bmMrMHgyZi8weDQwIFt4ZnNd Ck9jdCAgMiAxNTowODozMyAobm9uZSkga2VybmVsOiAgWzxjMDEyYTQwMD5dIHByb2Nlc3Nf dGltZW91dCsweDAvMHgxMApPY3QgIDIgMTU6MDg6MzMgKG5vbmUpIGtlcm5lbDogIFs8ZDIw NzIyNjI+XSBzeW5jZCsweDUyLzB4YzAgW3hmc10KT2N0ICAyIDE1OjA4OjMzIChub25lKSBr ZXJuZWw6ICBbPGQyMDcyMjEwPl0gc3luY2QrMHgwLzB4YzAgW3hmc10KT2N0ICAyIDE1OjA4 OjMzIChub25lKSBrZXJuZWw6ICBbPGMwMTA3MjU1Pl0ga2VybmVsX3RocmVhZF9oZWxwZXIr MHg1LzB4MTAKT2N0ICAyIDE1OjA4OjMzIChub25lKSBrZXJuZWw6IApPY3QgIDIgMTU6MDg6 MzcgKG5vbmUpIGtlcm5lbDogYmFkOiBzY2hlZHVsaW5nIHdoaWxlIGF0b21pYyEKT2N0ICAy IDE1OjA4OjM3IChub25lKSBrZXJuZWw6IENhbGwgVHJhY2U6Ck9jdCAgMiAxNTowODozNyAo bm9uZSkga2VybmVsOiAgWzxjMDExZTZlNj5dIHNjaGVkdWxlKzB4NDA2LzB4NDQwCk9jdCAg MiAxNTowODozNyAobm9uZSkga2VybmVsOiAgWzxjMDE0MjQ5Nz5dIF9fcGRmbHVzaCsweDk3 LzB4MWYwCk9jdCAgMiAxNTowODozNyAobm9uZSkga2VybmVsOiAgWzxjMDE0MjVmMD5dIHBk Zmx1c2grMHgwLzB4MjAKT2N0ICAyIDE1OjA4OjM3IChub25lKSBrZXJuZWw6ICBbPGMwMTQy NWZmPl0gcGRmbHVzaCsweGYvMHgyMApPY3QgIDIgMTU6MDg6MzcgKG5vbmUpIGtlcm5lbDog IFs8YzAxMDcyNTA+XSBrZXJuZWxfdGhyZWFkX2hlbHBlcisweDAvMHgxMApPY3QgIDIgMTU6 MDg6MzcgKG5vbmUpIGtlcm5lbDogIFs8YzAxMDcyNTU+XSBrZXJuZWxfdGhyZWFkX2hlbHBl cisweDUvMHgxMApPY3QgIDIgMTU6MDg6MzcgKG5vbmUpIGtlcm5lbDogCk9jdCAgMiAxNTow ODo0MCAobm9uZSkga2VybmVsOiBTeXNScSA6IEVtZXJnZW5jeSBTeW5jCk9jdCAgMiAxNTow ODo0MCAobm9uZSkga2VybmVsOiBiYWQ6IHNjaGVkdWxpbmcgd2hpbGUgYXRvbWljIQpPY3Qg IDIgMTU6MDg6NDAgKG5vbmUpIGtlcm5lbDogQ2FsbCBUcmFjZToKT2N0ICAyIDE1OjA4OjQw IChub25lKSBrZXJuZWw6ICBbPGMwMTFlNmU2Pl0gc2NoZWR1bGUrMHg0MDYvMHg0NDAKT2N0 ICAyIDE1OjA4OjQwIChub25lKSBrZXJuZWw6ICBbPGMwMTFmNjVlPl0gaW9fc2NoZWR1bGUr MHhlLzB4MjAKT2N0ICAyIDE1OjA4OjQwIChub25lKSBrZXJuZWw6ICBbPGMwMTNiZTE1Pl0g d2FpdF9vbl9wYWdlX2JpdCsweGE1LzB4ZDAKT2N0ICAyIDE1OjA4OjQwIChub25lKSBrZXJu ZWw6ICBbPGMwMTFmZTQwPl0gYXV0b3JlbW92ZV93YWtlX2Z1bmN0aW9uKzB4MC8weDUwCk9j dCAgMiAxNTowODo0MCAobm9uZSkga2VybmVsOiAgWzxjMDExZmU0MD5dIGF1dG9yZW1vdmVf d2FrZV9mdW5jdGlvbisweDAvMHg1MApPY3QgIDIgMTU6MDg6NDAgKG5vbmUpIGtlcm5lbDog IFs8YzAxM2JiNWU+XSBmaWxlbWFwX2ZkYXRhd2FpdCsweDFjZS8weDIxMApPY3QgIDIgMTU6 MDg6NDAgKG5vbmUpIGtlcm5lbDogIFs8YzAxNWI4MTk+XSBzeW5jX2Jsb2NrZGV2KzB4Mzkv MHg1MApPY3QgIDIgMTU6MDg6NDAgKG5vbmUpIGtlcm5lbDogIFs8YzAxN2M2MTA+XSBzeW5j X2lub2RlcysweDMwLzB4YTAKT2N0ICAyIDE1OjA4OjQwIChub25lKSBrZXJuZWw6ICBbPGMw MTViOTYwPl0gZG9fc3luYysweDIwLzB4ODAKT2N0ICAyIDE1OjA4OjQwIChub25lKSBrZXJu ZWw6ICBbPGMwMTQyNGRhPl0gX19wZGZsdXNoKzB4ZGEvMHgxZjAKT2N0ICAyIDE1OjA4OjQw IChub25lKSBrZXJuZWw6ICBbPGMwMTQyNWYwPl0gcGRmbHVzaCsweDAvMHgyMApPY3QgIDIg MTU6MDg6NDAgKG5vbmUpIGtlcm5lbDogIFs8YzAxNDI1ZmY+XSBwZGZsdXNoKzB4Zi8weDIw Ck9jdCAgMiAxNTowODo0MCAobm9uZSkga2VybmVsOiAgWzxjMDE1Yjk0MD5dIGRvX3N5bmMr MHgwLzB4ODAKT2N0ICAyIDE1OjA4OjQwIChub25lKSBrZXJuZWw6ICBbPGMwMTA3MjUwPl0g a2VybmVsX3RocmVhZF9oZWxwZXIrMHgwLzB4MTAKT2N0ICAyIDE1OjA4OjQwIChub25lKSBr ZXJuZWw6ICBbPGMwMTA3MjU1Pl0ga2VybmVsX3RocmVhZF9oZWxwZXIrMHg1LzB4MTAKT2N0 ICAyIDE1OjA4OjQwIChub25lKSBrZXJuZWw6IApPY3QgIDIgMTU6MDg6NDAgKG5vbmUpIGtl cm5lbDogYmFkOiBzY2hlZHVsaW5nIHdoaWxlIGF0b21pYyEKT2N0ICAyIDE1OjA4OjQwIChu b25lKSBrZXJuZWw6IENhbGwgVHJhY2U6Ck9jdCAgMiAxNTowODo0MCAobm9uZSkga2VybmVs OiAgWzxjMDExZTZlNj5dIHNjaGVkdWxlKzB4NDA2LzB4NDQwCk9jdCAgMiAxNTowODo0MCAo bm9uZSkga2VybmVsOiAgWzxjMDExZjY1ZT5dIGlvX3NjaGVkdWxlKzB4ZS8weDIwCk9jdCAg MiAxNTowODo0MCAobm9uZSkga2VybmVsOiAgWzxjMDEzYmUxNT5dIHdhaXRfb25fcGFnZV9i aXQrMHhhNS8weGQwCk9jdCAgMiAxNTowODo0MCAobm9uZSkga2VybmVsOiAgWzxjMDExZmU0 MD5dIGF1dG9yZW1vdmVfd2FrZV9mdW5jdGlvbisweDAvMHg1MApPY3QgIDIgMTU6MDg6NDAg KG5vbmUpIGtlcm5lbDogIFs8YzAxMWZlNDA+XSBhdXRvcmVtb3ZlX3dha2VfZnVuY3Rpb24r MHgwLzB4NTAKT2N0ICAyIDE1OjA4OjQwIChub25lKSBrZXJuZWw6ICBbPGMwMTNiYjVlPl0g ZmlsZW1hcF9mZGF0YXdhaXQrMHgxY2UvMHgyMTAKT2N0ICAyIDE1OjA4OjQwIChub25lKSBr ZXJuZWw6ICBbPGMwMTViODE5Pl0gc3luY19ibG9ja2RldisweDM5LzB4NTAKT2N0ICAyIDE1 OjA4OjQwIChub25lKSBrZXJuZWw6ICBbPGMwMTdjNjEwPl0gc3luY19pbm9kZXMrMHgzMC8w eGEwCk9jdCAgMiAxNTowODo0MCAobm9uZSkga2VybmVsOiAgWzxjMDE1Yjk2MD5dIGRvX3N5 bmMrMHgyMC8weDgwCk9jdCAgMiAxNTowODo0MCAobm9uZSkga2VybmVsOiAgWzxjMDE0MjRk YT5dIF9fcGRmbHVzaCsweGRhLzB4MWYwCk9jdCAgMiAxNTowODo0MCAobm9uZSkga2VybmVs OiAgWzxjMDE0MjVmMD5dIHBkZmx1c2grMHgwLzB4MjAKT2N0ICAyIDE1OjA4OjQwIChub25l KSBrZXJuZWw6ICBbPGMwMTQyNWZmPl0gcGRmbHVzaCsweGYvMHgyMApPY3QgIDIgMTU6MDg6 NDAgKG5vbmUpIGtlcm5lbDogIFs8YzAxNWI5NDA+XSBkb19zeW5jKzB4MC8weDgwCk9jdCAg MiAxNTowODo0MCAobm9uZSkga2VybmVsOiAgWzxjMDEwNzI1MD5dIGtlcm5lbF90aHJlYWRf aGVscGVyKzB4MC8weDEwCk9jdCAgMiAxNTowODo0MCAobm9uZSkga2VybmVsOiAgWzxjMDEw NzI1NT5dIGtlcm5lbF90aHJlYWRfaGVscGVyKzB4NS8weDEwCk9jdCAgMiAxNTowODo0MCAo bm9uZSkga2VybmVsOiAKT2N0ICAyIDE1OjA4OjQwIChub25lKSBrZXJuZWw6IGJhZDogc2No ZWR1bGluZyB3aGlsZSBhdG9taWMhCk9jdCAgMiAxNTowODo0MCAobm9uZSkga2VybmVsOiBD YWxsIFRyYWNlOgpPY3QgIDIgMTU6MDg6NDAgKG5vbmUpIGtlcm5lbDogIFs8YzAxMWU2ZTY+ XSBzY2hlZHVsZSsweDQwNi8weDQ0MApPY3QgIDIgMTU6MDg6NDAgKG5vbmUpIGtlcm5lbDog IFs8ZDIwNjVmN2I+XSBwYWdlYnVmX2lvcmVxdWVzdCsweGFiLzB4MTcwIFt4ZnNdCk9jdCAg MiAxNTowODo0MCAobm9uZSkga2VybmVsOiAgWzxjMDEwODEzYj5dIF9fZG93bisweDdiLzB4 MTEwCk9jdCAgMiAxNTowODo0MCAobm9uZSkga2VybmVsOiAgWzxjMDExZTc3MD5dIGRlZmF1 bHRfd2FrZV9mdW5jdGlvbisweDAvMHgzMApPY3QgIDIgMTU6MDg6NDAgKG5vbmUpIGtlcm5l bDogIFs8YzAxMWU3NzA+XSBkZWZhdWx0X3dha2VfZnVuY3Rpb24rMHgwLzB4MzAKT2N0ICAy IDE1OjA4OjQwIChub25lKSBrZXJuZWw6ICBbPGMwMTA4MzgwPl0gX19kb3duX2ZhaWxlZCsw eDgvMHhjCk9jdCAgMiAxNTowODo0MCAobm9uZSkga2VybmVsOiAgWzxkMjA2NmU4Zj5dIC50 ZXh0LmxvY2sucGFnZV9idWZfbG9ja2luZysweGYvMHgyMCBbeGZzXQpPY3QgIDIgMTU6MDg6 NDAgKG5vbmUpIGtlcm5lbDogIFs8ZDIwMzk5YWQ+XSB4ZnNfbG9nX2ZvcmNlKzB4N2QvMHhm MCBbeGZzXQpPY3QgIDIgMTU6MDg6NDAgKG5vbmUpIGtlcm5lbDogIFs8ZDIwNGQyMDg+XSB4 ZnNfZ2V0c2IrMHg5OC8weGQwIFt4ZnNdCk9jdCAgMiAxNTowODo0MCAobm9uZSkga2VybmVs OiAgWzxkMjA1OTdkMD5dIHhmc19zeW5jc3ViKzB4MTQwLzB4MzUwIFt4ZnNdCk9jdCAgMiAx NTowODo0MCAobm9uZSkga2VybmVsOiAgWzxkMjA1ODNjZj5dIHhmc19zeW5jKzB4MmYvMHg0 MCBbeGZzXQpPY3QgIDIgMTU6MDg6NDAgKG5vbmUpIGtlcm5lbDogIFs8ZDIwNzM0Mzg+XSB2 ZnNfc3luYysweDg4LzB4YjAgW3hmc10KT2N0ICAyIDE1OjA4OjQwIChub25lKSBrZXJuZWw6 ICBbPGQyMDcyNTQyPl0gbGludmZzX3N5bmNfc3VwZXIrMHgzMi8weDQwIFt4ZnNdCk9jdCAg MiAxNTowODo0MCAobm9uZSkga2VybmVsOiAgWzxjMDE2MTExZD5dIHN5bmNfZmlsZXN5c3Rl bXMrMHgxMWQvMHgxNDAKT2N0ICAyIDE1OjA4OjQwIChub25lKSBrZXJuZWw6ICBbPGMwMTVi OThkPl0gZG9fc3luYysweDRkLzB4ODAKT2N0ICAyIDE1OjA4OjQwIChub25lKSBrZXJuZWw6 ICBbPGMwMTQyNGRhPl0gX19wZGZsdXNoKzB4ZGEvMHgxZjAKT2N0ICAyIDE1OjA4OjQwIChu b25lKSBrZXJuZWw6ICBbPGMwMTQyNWYwPl0gcGRmbHVzaCsweDAvMHgyMApPY3QgIDIgMTU6 MDg6NDAgKG5vbmUpIGtlcm5lbDogIFs8YzAxNDI1ZmY+XSBwZGZsdXNoKzB4Zi8weDIwCk9j dCAgMiAxNTowODo0MCAobm9uZSkga2VybmVsOiAgWzxjMDE1Yjk0MD5dIGRvX3N5bmMrMHgw LzB4ODAKT2N0ICAyIDE1OjA4OjQwIChub25lKSBrZXJuZWw6ICBbPGMwMTA3MjUwPl0ga2Vy bmVsX3RocmVhZF9oZWxwZXIrMHgwLzB4MTAKT2N0ICAyIDE1OjA4OjQwIChub25lKSBrZXJu ZWw6ICBbPGMwMTA3MjU1Pl0ga2VybmVsX3RocmVhZF9oZWxwZXIrMHg1LzB4MTAKT2N0ICAy IDE1OjA4OjQwIChub25lKSBrZXJuZWw6IApPY3QgIDIgMTU6MDg6NDAgKG5vbmUpIGtlcm5l bDogRW1lcmdlbmN5IFN5bmMgY29tcGxldGUKT2N0ICAyIDE1OjA4OjQwIChub25lKSBrZXJu ZWw6IGJhZDogc2NoZWR1bGluZyB3aGlsZSBhdG9taWMhCk9jdCAgMiAxNTowODo0MCAobm9u ZSkga2VybmVsOiBDYWxsIFRyYWNlOgpPY3QgIDIgMTU6MDg6NDAgKG5vbmUpIGtlcm5lbDog IFs8YzAxMWU2ZTY+XSBzY2hlZHVsZSsweDQwNi8weDQ0MApPY3QgIDIgMTU6MDg6NDAgKG5v bmUpIGtlcm5lbDogIFs8YzAxNDI0OTc+XSBfX3BkZmx1c2grMHg5Ny8weDFmMApPY3QgIDIg MTU6MDg6NDAgKG5vbmUpIGtlcm5lbDogIFs8YzAxNDI1ZjA+XSBwZGZsdXNoKzB4MC8weDIw Ck9jdCAgMiAxNTowODo0MCAobm9uZSkga2VybmVsOiAgWzxjMDE0MjVmZj5dIHBkZmx1c2gr MHhmLzB4MjAKT2N0ICAyIDE1OjA4OjQwIChub25lKSBrZXJuZWw6ICBbPGMwMTA3MjUwPl0g a2VybmVsX3RocmVhZF9oZWxwZXIrMHgwLzB4MTAKT2N0ICAyIDE1OjA4OjQwIChub25lKSBr ZXJuZWw6ICBbPGMwMTA3MjU1Pl0ga2VybmVsX3RocmVhZF9oZWxwZXIrMHg1LzB4MTAKT2N0 ICAyIDE1OjA4OjQwIChub25lKSBrZXJuZWw6IApPY3QgIDIgMTU6MDg6NDAgKG5vbmUpIGtl cm5lbDogYXRrYmQuYzogVW5rbm93biBrZXkgKHNldCAyLCBzY2FuY29kZSAweDFiNywgb24g aXNhMDA2MC9zZXJpbzApIHByZXNzZWQuCk9jdCAgMiAxNTowODo0MiAobm9uZSkga2VybmVs OiBiYWQ6IHNjaGVkdWxpbmcgd2hpbGUgYXRvbWljIQpPY3QgIDIgMTU6MDg6NDIgKG5vbmUp IGtlcm5lbDogQ2FsbCBUcmFjZToKT2N0ICAyIDE1OjA4OjQyIChub25lKSBrZXJuZWw6ICBb PGMwMTFlNmU2Pl0gc2NoZWR1bGUrMHg0MDYvMHg0NDAKT2N0ICAyIDE1OjA4OjQyIChub25l KSBrZXJuZWw6ICBbPGMwMTQyNDk3Pl0gX19wZGZsdXNoKzB4OTcvMHgxZjAKT2N0ICAyIDE1 OjA4OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTQyNWYwPl0gcGRmbHVzaCsweDAvMHgyMApP Y3QgIDIgMTU6MDg6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNDI1ZmY+XSBwZGZsdXNoKzB4 Zi8weDIwCk9jdCAgMiAxNTowODo0MiAobm9uZSkga2VybmVsOiAgWzxjMDEwNzI1MD5dIGtl cm5lbF90aHJlYWRfaGVscGVyKzB4MC8weDEwCk9jdCAgMiAxNTowODo0MiAobm9uZSkga2Vy bmVsOiAgWzxjMDEwNzI1NT5dIGtlcm5lbF90aHJlYWRfaGVscGVyKzB4NS8weDEwCk9jdCAg MiAxNTowODo0MiAobm9uZSkga2VybmVsOiAKT2N0ICAyIDE1OjA4OjQzIChub25lKSBrZXJu ZWw6IFN5c1JxIDogSEVMUCA6IGxvZ2xldmVsMC04IHJlQm9vdCB0RXJtIGtJbGwgc2FLIHNo b3dNZW0gcG93ZXJPZmYgc2hvd1BjIHVuUmF3IFN5bmMgc2hvd1Rhc2tzIFVubW91bnQgCk9j dCAgMiAxNTowODo0NyAobm9uZSkga2VybmVsOiBiYWQ6IHNjaGVkdWxpbmcgd2hpbGUgYXRv bWljIQpPY3QgIDIgMTU6MDg6NDcgKG5vbmUpIGtlcm5lbDogQ2FsbCBUcmFjZToKT2N0ICAy IDE1OjA4OjQ3IChub25lKSBrZXJuZWw6ICBbPGMwMTFlNmU2Pl0gc2NoZWR1bGUrMHg0MDYv MHg0NDAKT2N0ICAyIDE1OjA4OjQ3IChub25lKSBrZXJuZWw6ICBbPGMwMTQyNDk3Pl0gX19w ZGZsdXNoKzB4OTcvMHgxZjAKT2N0ICAyIDE1OjA4OjQ3IChub25lKSBrZXJuZWw6ICBbPGMw MTQyNWYwPl0gcGRmbHVzaCsweDAvMHgyMApPY3QgIDIgMTU6MDg6NDcgKG5vbmUpIGtlcm5l bDogIFs8YzAxNDI1ZmY+XSBwZGZsdXNoKzB4Zi8weDIwCk9jdCAgMiAxNTowODo0NyAobm9u ZSkga2VybmVsOiAgWzxjMDEwNzI1MD5dIGtlcm5lbF90aHJlYWRfaGVscGVyKzB4MC8weDEw Ck9jdCAgMiAxNTowODo0NyAobm9uZSkga2VybmVsOiAgWzxjMDEwNzI1NT5dIGtlcm5lbF90 aHJlYWRfaGVscGVyKzB4NS8weDEwCk9jdCAgMiAxNTowODo0NyAobm9uZSkga2VybmVsOiAK T2N0ICAyIDE1OjA4OjQ3IChub25lKSBrZXJuZWw6IFN5c1JxIDogSEVMUCA6IGxvZ2xldmVs MC04IHJlQm9vdCB0RXJtIGtJbGwgc2FLIHNob3dNZW0gcG93ZXJPZmYgc2hvd1BjIHVuUmF3 IFN5bmMgc2hvd1Rhc2tzIFVubW91bnQgCk9jdCAgMiAxNTowODo0OCAobm9uZSkga2VybmVs OiBTeXNScSA6IEhFTFAgOiBsb2dsZXZlbDAtOCByZUJvb3QgdEVybSBrSWxsIHNhSyBzaG93 TWVtIHBvd2VyT2ZmIHNob3dQYyB1blJhdyBTeW5jIHNob3dUYXNrcyBVbm1vdW50IApPY3Qg IDIgMTU6MDg6NDkgKG5vbmUpIGtlcm5lbDogU3lzUnEgOiBTaG93IFN0YXRlCk9jdCAgMiAx NTowODo0OSAobm9uZSkga2VybmVsOiAKT2N0ICAyIDE1OjA4OjQ5IChub25lKSBrZXJuZWw6 ICAgICAgICAgICAgICAgICAgICAgICAgICBmcmVlICAgICAgICAgICAgICAgICAgICAgICAg c2libGluZwpPY3QgIDIgMTU6MDg6NDkgKG5vbmUpIGtlcm5lbDogICB0YXNrICAgICAgICAg ICAgIFBDICAgIHN0YWNrICAgcGlkIGZhdGhlciBjaGlsZCB5b3VuZ2VyIG9sZGVyCk9jdCAg MiAxNTowODo0OSAobm9uZSkga2VybmVsOiBpbml0ICAgICAgICAgIFMgMDAwMDAwMDAgIDU4 NzYgICAgIDEgICAgICAwICAgICAyICAgICAgICAgICAgICAgKE5PVExCKQpPY3QgIDIgMTU6 MDg6NDkgKG5vbmUpIGtlcm5lbDogYzEyOWZlYWMgMDAwMDAwODYgMDAwMDAwMDAgMDAwMDAw MDAgYzEyOWZlYzAgMDAwMDAyNDYgYzAzOWYxODAgYzEyOWZlYzAgCk9jdCAgMiAxNTowODo0 OSAobm9uZSkga2VybmVsOiAgICAgICAgMDAwMDAwMDAgMDAwMDllNTUgYzEyOWZlYzAgMDAw MDAwMGIgMDAwMDAwMDAgYzAxMmE0NmQgYzEyOWZlYzAgMDAwMDllNTUgCk9jdCAgMiAxNTow ODo0OSAobm9uZSkga2VybmVsOiAgICAgICAgMDAwMDAyNDYgYzAzOWZhNzggYzAzOWZhNzgg MDAwMDllNTUgNGI4N2FkNmUgYzAxMmE0MDAgYzEyOWQ4YzAgYzAzOWYxODAgCk9jdCAgMiAx NTowODo0OSAobm9uZSkga2VybmVsOiBDYWxsIFRyYWNlOgpPY3QgIDIgMTU6MDg6NDkgKG5v bmUpIGtlcm5lbDogIFs8YzAxMmE0NmQ+XSBzY2hlZHVsZV90aW1lb3V0KzB4NWQvMHhiMApP Y3QgIDIgMTU6MDg6NDkgKG5vbmUpIGtlcm5lbDogIFs8YzAxMmE0MDA+XSBwcm9jZXNzX3Rp bWVvdXQrMHgwLzB4MTAKT2N0ICAyIDE1OjA4OjQ5IChub25lKSBrZXJuZWw6ICBbPGMwMTZl MjVlPl0gZG9fc2VsZWN0KzB4MmJlLzB4MzEwCk9jdCAgMiAxNTowODo0OSAobm9uZSkga2Vy bmVsOiAgWzxjMDE2ZGRkMD5dIF9fcG9sbHdhaXQrMHgwLzB4ZDAKT2N0ICAyIDE1OjA4OjQ5 IChub25lKSBrZXJuZWw6ICBbPGMwMTZlNTg1Pl0gc3lzX3NlbGVjdCsweDJhNS8weDUwMApP Y3QgIDIgMTU6MDg6NDkgKG5vbmUpIGtlcm5lbDogIFs8YzAxMDk0NGI+XSBzeXNjYWxsX2Nh bGwrMHg3LzB4YgpPY3QgIDIgMTU6MDg6NDkgKG5vbmUpIGtlcm5lbDogCk9jdCAgMiAxNTow ODo0OSAobm9uZSkga2VybmVsOiBrc29mdGlycWQvMCAgIFMgQzAzOUVGMjggNDI5NDk2MDY0 OCAgICAgMiAgICAgIDEgICAgICAgICAgICAgMyAgICAgICAoTC1UTEIpCk9jdCAgMiAxNTow ODo0OSAobm9uZSkga2VybmVsOiBjMTI5YmZkNCAwMDAwMDA0NiAwMDAwMDAwMCBjMDM5ZWYy OCBjMDEyNWUzYiAwMDAwMDAwMCAwMDAwMDAwMSAwMDAwMDI0NiAKT2N0ICAyIDE1OjA4OjQ5 IChub25lKSBrZXJuZWw6ICAgICAgICBjMDM5ZWYyOCBjMTI5YTAwMCBjMTI5YTAwMCBmZmZm ZTAwMCAwMDAwMDAwMCBjMDEyNjA1YyBjMTI5ZDJiMCAwMDAwMDAxMyAKT2N0ICAyIDE1OjA4 OjQ5IChub25lKSBrZXJuZWw6ICAgICAgICBjMDEyNWZhMCAwMDAwMDAwMCAwMDAwMDAwMCBj MDEwNzI1NSAwMDAwMDAwMCAwMDAwMDAwMCAwMDAwMDAwMCAKT2N0ICAyIDE1OjA4OjQ5IChu b25lKSBrZXJuZWw6IENhbGwgVHJhY2U6Ck9jdCAgMiAxNTowODo0OSAobm9uZSkga2VybmVs OiAgWzxjMDEyNWUzYj5dIHRhc2tsZXRfYWN0aW9uKzB4M2IvMHg3MApPY3QgIDIgMTU6MDg6 NDkgKG5vbmUpIGtlcm5lbDogIFs8YzAxMjYwNWM+XSBrc29mdGlycWQrMHhiYy8weGQwCk9j dCAgMiAxNTowODo0OSAobm9uZSkga2VybmVsOiAgWzxjMDEyNWZhMD5dIGtzb2Z0aXJxZCsw eDAvMHhkMApPY3QgIDIgMTU6MDg6NDkgKG5vbmUpIGtlcm5lbDogIFs8YzAxMDcyNTU+XSBr ZXJuZWxfdGhyZWFkX2hlbHBlcisweDUvMHgxMApPY3QgIDIgMTU6MDg6NDkgKG5vbmUpIGtl cm5lbDogCk9jdCAgMiAxNTowODo0OSAobm9uZSkga2VybmVsOiBldmVudHMvMCAgICAgIFMg QzAzMzMwRTAgNDI5NDk1MzAzNiAgICAgMyAgICAgIDEgICAgICAgICAgICAgNCAgICAgMiAo TC1UTEIpCk9jdCAgMiAxNTowODo0OSAobm9uZSkga2VybmVsOiBjMTI5OWY3MCAwMDAwMDA0 NiAwMDAwMDA5MiBjMDMzMzBlMCBjMTI5OWY3MCAwMDAwMDA5MiBjZmZjNDcxOCAwMDAwMDAw MyAKT2N0ICAyIDE1OjA4OjQ5IChub25lKSBrZXJuZWw6ICAgICAgICAwMDAwMDAwMSBjMTI5 ODAwMCBjZmZjNDcwOCBjMDMzMzBlMCBjMTI5ODAwMCBjMDEzMThiNSAwMDAwMDAwMCBjMTI5 OWZhMCAKT2N0ICAyIDE1OjA4OjQ5IChub25lKSBrZXJuZWw6ICAgICAgICAwMDAwMDAwMCBj ZmZjNDcxOCBjZmZjNDcxMCAwMDAwMDAwMCBjMDIwMmE4MCBjZmZjNDcwOCBjMTI5ODAwMCBj ZmZjNDcwMCAKT2N0ICAyIDE1OjA4OjQ5IChub25lKSBrZXJuZWw6IENhbGwgVHJhY2U6Ck9j dCAgMiAxNTowODo0OSAobm9uZSkga2VybmVsOiAgWzxjMDEzMThiNT5dIHdvcmtlcl90aHJl YWQrMHgyODUvMHgyZDAKT2N0ICAyIDE1OjA4OjQ5IChub25lKSBrZXJuZWw6ICBbPGMwMjAy YTgwPl0gY29uc29sZV9jYWxsYmFjaysweDAvMHhkMApPY3QgIDIgMTU6MDg6NDkgKG5vbmUp IGtlcm5lbDogIFs8YzAxMWU3NzA+XSBkZWZhdWx0X3dha2VfZnVuY3Rpb24rMHgwLzB4MzAK T2N0ICAyIDE1OjA4OjQ5IChub25lKSBrZXJuZWw6ICBbPGMwMTA5MzIyPl0gcmV0X2Zyb21f Zm9yaysweDYvMHgxNApPY3QgIDIgMTU6MDg6NDkgKG5vbmUpIGtlcm5lbDogIFs8YzAxMWU3 NzA+XSBkZWZhdWx0X3dha2VfZnVuY3Rpb24rMHgwLzB4MzAKT2N0ICAyIDE1OjA4OjQ5IChu b25lKSBrZXJuZWw6ICBbPGMwMTMxNjMwPl0gd29ya2VyX3RocmVhZCsweDAvMHgyZDAKT2N0 ICAyIDE1OjA4OjQ5IChub25lKSBrZXJuZWw6ICBbPGMwMTA3MjU1Pl0ga2VybmVsX3RocmVh ZF9oZWxwZXIrMHg1LzB4MTAKT2N0ICAyIDE1OjA4OjQ5IChub25lKSBrZXJuZWw6IApPY3Qg IDIgMTU6MDg6NDkgKG5vbmUpIGtlcm5lbDoga2Jsb2NrZC8wICAgICBTIEMxMzU4QUYwIDEw Nzc1NjAgICAgIDQgICAgICAxICAgICAgICAgICAgIDUgICAgIDMgKEwtVExCKQpPY3QgIDIg MTU6MDg6NDkgKG5vbmUpIGtlcm5lbDogYzEzYTNmNzAgMDAwMDAwNDYgMDAwMDAwOTIgYzEz NThhZjAgYzEzYTNmNzAgMDAwMDAwOTIgYzEzZGE1OTggMDAwMDAwMDMgCk9jdCAgMiAxNTow ODo0OSAobm9uZSkga2VybmVsOiAgICAgICAgMDAwMDAwMDEgYzEzYTIwMDAgYzEzZGE1ODgg YzEzNThhZjAgYzEzYTIwMDAgYzAxMzE4YjUgYzEzNThhMDAgYzEzYTNmYTAgCk9jdCAgMiAx NTowODo0OSAobm9uZSkga2VybmVsOiAgICAgICAgMDAwMDAwMDAgYzEzZGE1OTggYzEzZGE1 OTAgYzEzNThhMDAgYzAyMDk4YzAgYzEzZGE1ODggYzEzYTIwMDAgYzEzZGE1ODAgCk9jdCAg MiAxNTowODo0OSAobm9uZSkga2VybmVsOiBDYWxsIFRyYWNlOgpPY3QgIDIgMTU6MDg6NDkg KG5vbmUpIGtlcm5lbDogIFs8YzAxMzE4YjU+XSB3b3JrZXJfdGhyZWFkKzB4Mjg1LzB4MmQw Ck9jdCAgMiAxNTowODo0OSAobm9uZSkga2VybmVsOiAgWzxjMDIwOThjMD5dIGJsa191bnBs dWdfd29yaysweDAvMHgyMApPY3QgIDIgMTU6MDg6NDkgKG5vbmUpIGtlcm5lbDogIFs8YzAx MWU3NzA+XSBkZWZhdWx0X3dha2VfZnVuY3Rpb24rMHgwLzB4MzAKT2N0ICAyIDE1OjA4OjQ5 IChub25lKSBrZXJuZWw6ICBbPGMwMTA5MzIyPl0gcmV0X2Zyb21fZm9yaysweDYvMHgxNApP Y3QgIDIgMTU6MDg6NDkgKG5vbmUpIGtlcm5lbDogIFs8YzAxMWU3NzA+XSBkZWZhdWx0X3dh a2VfZnVuY3Rpb24rMHgwLzB4MzAKT2N0ICAyIDE1OjA4OjQ5IChub25lKSBrZXJuZWw6ICBb PGMwMTMxNjMwPl0gd29ya2VyX3RocmVhZCsweDAvMHgyZDAKT2N0ICAyIDE1OjA4OjQ5IChu b25lKSBrZXJuZWw6ICBbPGMwMTA3MjU1Pl0ga2VybmVsX3RocmVhZF9oZWxwZXIrMHg1LzB4 MTAKT2N0ICAyIDE1OjA4OjQ5IChub25lKSBrZXJuZWw6IApPY3QgIDIgMTU6MDg6NDkgKG5v bmUpIGtlcm5lbDogcGRmbHVzaCAgICAgICBTIDAwMDAwMDAwIDY4NTE5MiAgICAgNSAgICAg IDEgICAgICAgICAgICAgNiAgICAgNCAoTC1UTEIpCk9jdCAgMiAxNTowODo0OSAobm9uZSkg a2VybmVsOiBjMTM0M2ZhYyAwMDAwMDA0NiAwMDAwMDAwMCAwMDAwMDAwMCAwMDAwMDNmZSAw MDAwMDAwMSAwMDAwMDAwMCAwMDAwMDAwMCAKT2N0ICAyIDE1OjA4OjQ5IChub25lKSBrZXJu ZWw6ICAgICAgICAwMDAwMDAwMCBjMTM0MjAwMCBjMTM0M2ZkYyBjMTM0MjAwMCBjMTM0M2Zk MCBjMDE0MjQ5NyAwMDAwMDAxOSBjMDE0MjVmMCAKT2N0ICAyIDE1OjA4OjQ5IChub25lKSBr ZXJuZWw6ICAgICAgICAwMDAwMDAwMCAwMDAwMDAwMCAwMDAwMDAwMCBjMDE0MjVmZiBjMTM0 M2ZkMCBjMTI5YzA4MCAwMDAwMDAwMCAwMDAwMDAxOSAKT2N0ICAyIDE1OjA4OjQ5IChub25l KSBrZXJuZWw6IENhbGwgVHJhY2U6Ck9jdCAgMiAxNTowODo0OSAobm9uZSkga2VybmVsOiAg WzxjMDE0MjQ5Nz5dIF9fcGRmbHVzaCsweDk3LzB4MWYwCk9jdCAgMiAxNTowODo0OSAobm9u ZSkga2VybmVsOiAgWzxjMDE0MjVmMD5dIHBkZmx1c2grMHgwLzB4MjAKT2N0ICAyIDE1OjA4 OjQ5IChub25lKSBrZXJuZWw6ICBbPGMwMTQyNWZmPl0gcGRmbHVzaCsweGYvMHgyMApPY3Qg IDIgMTU6MDg6NDkgKG5vbmUpIGtlcm5lbDogIFs8YzAxMDcyNTA+XSBrZXJuZWxfdGhyZWFk X2hlbHBlcisweDAvMHgxMApPY3QgIDIgMTU6MDg6NDkgKG5vbmUpIGtlcm5lbDogIFs8YzAx MDcyNTU+XSBrZXJuZWxfdGhyZWFkX2hlbHBlcisweDUvMHgxMApPY3QgIDIgMTU6MDg6NDkg KG5vbmUpIGtlcm5lbDogCk9jdCAgMiAxNTowODo0OSAobm9uZSkga2VybmVsOiBwZGZsdXNo ICAgICAgIFMgMDAwMDAwMDAgNDI5NDk1NzQ2MCAgICAgNiAgICAgIDEgICAgICAgICAgICAg NyAgICAgNSAoTC1UTEIpCk9jdCAgMiAxNTowODo0OSAobm9uZSkga2VybmVsOiBjMTMzZmZh YyAwMDAwMDA0NiBjMDJjMDg2MCAwMDAwMDAwMCAwMDAwMDAwMCAwMDAwMDAwMCAwMDAwMDAw MCAwMDAwMDAwMCAKT2N0ICAyIDE1OjA4OjQ5IChub25lKSBrZXJuZWw6ICAgICAgICAwMDAw MDAwMCBjMTMzZTAwMCBjMTMzZmZkYyBjMTMzZTAwMCBjMTMzZmZkMCBjMDE0MjQ5NyAwMDAw MDAwMCBjMDE0MjVmMCAKT2N0ICAyIDE1OjA4OjQ5IChub25lKSBrZXJuZWw6ICAgICAgICAw MDAwMDAwMCAwMDAwMDAwMCAwMDAwMDAwMCBjMDE0MjVmZiBjMTMzZmZkMCBjMTM0MTk0MCAw MDAwMDAwMCAwMDAwMDAwMCAKT2N0ICAyIDE1OjA4OjQ5IChub25lKSBrZXJuZWw6IENhbGwg VHJhY2U6Ck9jdCAgMiAxNTowODo0OSAobm9uZSkga2VybmVsOiAgWzxjMDE0MjQ5Nz5dIF9f cGRmbHVzaCsweDk3LzB4MWYwCk9jdCAgMiAxNTowODo0OSAobm9uZSkga2VybmVsOiAgWzxj MDE0MjVmMD5dIHBkZmx1c2grMHgwLzB4MjAKT2N0ICAyIDE1OjA4OjQ5IChub25lKSBrZXJu ZWw6ICBbPGMwMTQyNWZmPl0gcGRmbHVzaCsweGYvMHgyMApPY3QgIDIgMTU6MDg6NDkgKG5v bmUpIGtlcm5lbDogIFs8YzAxMDcyNTA+XSBrZXJuZWxfdGhyZWFkX2hlbHBlcisweDAvMHgx MApPY3QgIDIgMTU6MDg6NDkgKG5vbmUpIGtlcm5lbDogIFs8YzAxMDcyNTU+XSBrZXJuZWxf dGhyZWFkX2hlbHBlcisweDUvMHgxMApPY3QgIDIgMTU6MDg6NDkgKG5vbmUpIGtlcm5lbDog Ck9jdCAgMiAxNTowODo0OSAobm9uZSkga2VybmVsOiBrc3dhcGQwICAgICAgIFMgQzEzM0Mw MDAgNDI5NDk1MjE4MCAgICAgNyAgICAgIDEgICAgICAgICAgICAgOCAgICAgNiAoTC1UTEIp Ck9jdCAgMiAxNTowODo0OSAobm9uZSkga2VybmVsOiBjMTMzZGYwOCAwMDAwMDA0NiAwMDAw MDAwOCBjMTMzYzAwMCBjMTM0MTMzMCBjMDEyMzNkMCBjMTM0MTMzMCBjMTMzZGYwMCAKT2N0 ICAyIDE1OjA4OjQ5IChub25lKSBrZXJuZWw6ICAgICAgICAwMDAwMDAwMCBjMTMzYzAwMCBj MDMwMzJmMCBjMTMzZGYyMCBjMTMzZGZjMCBjMDE0N2VkMyBjMDJjOGM5MSAwMDAwMDAwMCAK T2N0ICAyIDE1OjA4OjQ5IChub25lKSBrZXJuZWw6ICAgICAgICAwMDAwMDAwMCAwMDAwMDAw MCAwMDAwMDAwMCAwMDAwMDAwMCAwMDAwMDAwMCAwMDAwMDAwMCAwMDAwMDAwMCAwMDAwMDAw MCAKT2N0ICAyIDE1OjA4OjQ5IChub25lKSBrZXJuZWw6IENhbGwgVHJhY2U6Ck9jdCAgMiAx NTowODo0OSAobm9uZSkga2VybmVsOiAgWzxjMDEyMzNkMD5dIGRhZW1vbml6ZSsweGQwLzB4 ZTAKT2N0ICAyIDE1OjA4OjQ5IChub25lKSBrZXJuZWw6ICBbPGMwMTQ3ZWQzPl0ga3N3YXBk KzB4ZTMvMHgxMzAKT2N0ICAyIDE1OjA4OjQ5IChub25lKSBrZXJuZWw6ICBbPGMwMTFlNzRk Pl0gcHJlZW1wdF9zY2hlZHVsZSsweDJkLzB4NTAKT2N0ICAyIDE1OjA4OjQ5IChub25lKSBr ZXJuZWw6ICBbPGMwMTFmZTQwPl0gYXV0b3JlbW92ZV93YWtlX2Z1bmN0aW9uKzB4MC8weDUw Ck9jdCAgMiAxNTowODo0OSAobm9uZSkga2VybmVsOiAgWzxjMDEwOTMyMj5dIHJldF9mcm9t X2ZvcmsrMHg2LzB4MTQKT2N0ICAyIDE1OjA4OjQ5IChub25lKSBrZXJuZWw6ICBbPGMwMTFm ZTQwPl0gYXV0b3JlbW92ZV93YWtlX2Z1bmN0aW9uKzB4MC8weDUwCk9jdCAgMiAxNTowODo0 OSAobm9uZSkga2VybmVsOiAgWzxjMDE0N2RmMD5dIGtzd2FwZCsweDAvMHgxMzAKT2N0ICAy IDE1OjA4OjQ5IChub25lKSBrZXJuZWw6ICBbPGMwMTA3MjU1Pl0ga2VybmVsX3RocmVhZF9o ZWxwZXIrMHg1LzB4MTAKT2N0ICAyIDE1OjA4OjQ5IChub25lKSBrZXJuZWw6IApPY3QgIDIg MTU6MDg6NDkgKG5vbmUpIGtlcm5lbDogYWlvLzAgICAgICAgICBTIEMxMzNBMDAwIDQyOTQ5 NDU2NDQgICAgIDggICAgICAxICAgICAgICAgICAgIDkgICAgIDcgKEwtVExCKQpPY3QgIDIg MTU6MDg6NDkgKG5vbmUpIGtlcm5lbDogYzEzM2JmNzAgMDAwMDAwNDYgYzEzNDBkMjAgYzEz M2EwMDAgMDAwMTAwMDAgYzAxMmU1OTQgMDAwMTAwMDAgYzEzNDEyZTQgCk9jdCAgMiAxNTow ODo0OSAobm9uZSkga2VybmVsOiAgICAgICAgMDAwMDAwMTAgYzEzM2EwMDAgMDAwMDAwMDAg YzEzM2JmYjQgYzEyOWZmNTggYzAxMzE4YjUgMDAwMDAwMTEgYzEzM2JmYTAgCk9jdCAgMiAx NTowODo0OSAobm9uZSkga2VybmVsOiAgICAgICAgMDAwMDAwMDAgMDAwMDAwMDAgYzEzNzY2 MTAgYzEzNDEzMzAgMDAwMDAwMDAgYzEzNzY2MDggYzEzM2EwMDAgYzEzNzY2MDAgCk9jdCAg MiAxNTowODo0OSAobm9uZSkga2VybmVsOiBDYWxsIFRyYWNlOgpPY3QgIDIgMTU6MDg6NDkg KG5vbmUpIGtlcm5lbDogIFs8YzAxMmU1OTQ+XSBkb19zaWdhY3Rpb24rMHgxYjQvMHgyNzAK T2N0ICAyIDE1OjA4OjQ5IChub25lKSBrZXJuZWw6ICBbPGMwMTMxOGI1Pl0gd29ya2VyX3Ro cmVhZCsweDI4NS8weDJkMApPY3QgIDIgMTU6MDg6NDkgKG5vbmUpIGtlcm5lbDogIFs8YzAx MWU3NzA+XSBkZWZhdWx0X3dha2VfZnVuY3Rpb24rMHgwLzB4MzAKT2N0ICAyIDE1OjA4OjQ5 IChub25lKSBrZXJuZWw6ICBbPGMwMTA5MzIyPl0gcmV0X2Zyb21fZm9yaysweDYvMHgxNApP Y3QgIDIgMTU6MDg6NDkgKG5vbmUpIGtlcm5lbDogIFs8YzAxMWU3NzA+XSBkZWZhdWx0X3dh a2VfZnVuY3Rpb24rMHgwLzB4MzAKT2N0ICAyIDE1OjA4OjQ5IChub25lKSBrZXJuZWw6ICBb PGMwMTMxNjMwPl0gd29ya2VyX3RocmVhZCsweDAvMHgyZDAKT2N0ICAyIDE1OjA4OjQ5IChu b25lKSBrZXJuZWw6ICBbPGMwMTA3MjU1Pl0ga2VybmVsX3RocmVhZF9oZWxwZXIrMHg1LzB4 MTAKT2N0ICAyIDE1OjA4OjQ5IChub25lKSBrZXJuZWw6IApPY3QgIDIgMTU6MDg6NDkgKG5v bmUpIGtlcm5lbDoga3BucGJpb3NkICAgICBTIDAwMDAwMDAwIDQyOTQ5MzkwNDggICAgIDkg ICAgICAxICAgICAgICAgICAgMTAgICAgIDggKEwtVExCKQpPY3QgIDIgMTU6MDg6NDkgKG5v bmUpIGtlcm5lbDogYzEzMzlmOWMgMDAwMDAwNDYgMDAwMDAwMDAgMDAwMDAwMDAgYzEzMzlm YjAgMDAwMDAyNDYgYzAzOWYxODAgYzEzMzlmYjAgCk9jdCAgMiAxNTowODo0OSAobm9uZSkg a2VybmVsOiAgICAgICAgMDAwMDAwMDAgMDAwMDkyMDMgYzEzMzlmYjAgMDAwMDAwMDAgMDAw MDAwMDAgYzAxMmE0NmQgYzEzMzlmYjAgMDAwMDkyMDMgCk9jdCAgMiAxNTowODo0OSAobm9u ZSkga2VybmVsOiAgICAgICAgZmZmZjAwN2IgYzAzYTE3OTQgYzAzOWZhMTggMDAwMDkyMDMg NGI4N2FkNmUgYzAxMmE0MDAgYzEzNDA3MTAgYzAzOWYxODAgCk9jdCAgMiAxNTowODo0OSAo bm9uZSkga2VybmVsOiBDYWxsIFRyYWNlOgpPY3QgIDIgMTU6MDg6NDkgKG5vbmUpIGtlcm5l bDogIFs8YzAxMmE0NmQ+XSBzY2hlZHVsZV90aW1lb3V0KzB4NWQvMHhiMApPY3QgIDIgMTU6 MDg6NDkgKG5vbmUpIGtlcm5lbDogIFs8YzAxMmE0MDA+XSBwcm9jZXNzX3RpbWVvdXQrMHgw LzB4MTAKT2N0ICAyIDE1OjA4OjQ5IChub25lKSBrZXJuZWw6ICBbPGMwMWVhMDgwPl0gcG5w X2RvY2tfdGhyZWFkKzB4NTAvMHhlMApPY3QgIDIgMTU6MDg6NDkgKG5vbmUpIGtlcm5lbDog IFs8YzAxZWEwMzA+XSBwbnBfZG9ja190aHJlYWQrMHgwLzB4ZTAKT2N0ICAyIDE1OjA4OjQ5 IChub25lKSBrZXJuZWw6ICBbPGMwMTA3MjU1Pl0ga2VybmVsX3RocmVhZF9oZWxwZXIrMHg1 LzB4MTAKT2N0ICAyIDE1OjA4OjQ5IChub25lKSBrZXJuZWw6IApPY3QgIDIgMTU6MDg6NDkg KG5vbmUpIGtlcm5lbDoga3NlcmlvZCAgICAgICBTIEMxMzFBMDAwIDQyOTQ4MDk4OTIgICAg MTAgICAgICAxICAgICAgICAgICAgMzUgICAgIDkgKEwtVExCKQpPY3QgIDIgMTU6MDg6NDkg KG5vbmUpIGtlcm5lbDogYzEzMWJmYjAgMDAwMDAwNDYgMDAwMDAwMDggYzEzMWEwMDAgZmZm ZmUwMDAgYzAxMjMzZDAgYzEzNDAxMDAgYzEzMWJmYTggCk9jdCAgMiAxNTowODo0OSAobm9u ZSkga2VybmVsOiAgICAgICAgYzEzMWEwMDAgYzEzMWEwMDAgZmZmZmUwMDAgYzEzMWJmYzAg YzEzMWEwMDAgYzAyNDhjYzUgMDAwMDAwMGYgYzAxMDkzMjIgCk9jdCAgMiAxNTowODo0OSAo bm9uZSkga2VybmVsOiAgICAgICAgMDAwMDAwMDAgYzEzNDAxMDAgYzAxMWU3NzAgYzAzM2Iw YzggYzAzM2IwYzggMDAwMDAwMDAgMDAwMDAwMDAgMDAwMDAwMDAgCk9jdCAgMiAxNTowODo0 OSAobm9uZSkga2VybmVsOiBDYWxsIFRyYWNlOgpPY3QgIDIgMTU6MDg6NDkgKG5vbmUpIGtl cm5lbDogIFs8YzAxMjMzZDA+XSBkYWVtb25pemUrMHhkMC8weGUwCk9jdCAgMiAxNTowODo0 OSAobm9uZSkga2VybmVsOiAgWzxjMDI0OGNjNT5dIHNlcmlvX3RocmVhZCsweGE1LzB4MTUw Ck9jdCAgMiAxNTowODo0OSAobm9uZSkga2VybmVsOiAgWzxjMDEwOTMyMj5dIHJldF9mcm9t X2ZvcmsrMHg2LzB4MTQKT2N0ICAyIDE1OjA4OjQ5IChub25lKSBrZXJuZWw6ICBbPGMwMTFl NzcwPl0gZGVmYXVsdF93YWtlX2Z1bmN0aW9uKzB4MC8weDMwCk9jdCAgMiAxNTowODo0OSAo bm9uZSkga2VybmVsOiAgWzxjMDI0OGMyMD5dIHNlcmlvX3RocmVhZCsweDAvMHgxNTAKT2N0 ICAyIDE1OjA4OjQ5IChub25lKSBrZXJuZWw6ICBbPGMwMTA3MjU1Pl0ga2VybmVsX3RocmVh ZF9oZWxwZXIrMHg1LzB4MTAKT2N0ICAyIDE1OjA4OjQ5IChub25lKSBrZXJuZWw6IApPY3Qg IDIgMTU6MDg6NDkgKG5vbmUpIGtlcm5lbDogYmFzaCAgICAgICAgICBTIENGREVCRkM0IDk1 MDYyNCAgICAzNSAgICAgIDEgICAyMzYgICAgICA1NiAgICAxMCAoTk9UTEIpCk9jdCAgMiAx NTowODo0OSAobm9uZSkga2VybmVsOiBjZmRlYmY1MCAwMDAwMDA4MiBjZTYwMjEwMCBjZmRl YmZjNCAwMDAzMDAwMiBjZTYwMjFhNCAwMDAwMDAwMCBjZmRlYmY1OCAKT2N0ICAyIDE1OjA4 OjQ5IChub25lKSBrZXJuZWw6ICAgICAgICAwMDAwMDI4NiBmZmZmZmUwMCBjZmRlYTAwMCBj ZmQwMTk1YyBjZmQwMTk1YyBjMDEyNGJiOCBmZmZmZmZmZiAwMDAwMDAwMiAKT2N0ICAyIDE1 OjA4OjQ5IChub25lKSBrZXJuZWw6ICAgICAgICBjZTYwMjEwMCBjZmRlYTAwMCBjZmRlYTAw MCAwMDAwMDAwMSAwMDAwMDAwMCBjZmQwMThjMCBjMDExZTc3MCAwMDAwMDAwMCAKT2N0ICAy IDE1OjA4OjQ5IChub25lKSBrZXJuZWw6IENhbGwgVHJhY2U6Ck9jdCAgMiAxNTowODo0OSAo bm9uZSkga2VybmVsOiAgWzxjMDEyNGJiOD5dIHN5c193YWl0NCsweDI2OC8weDJjMApPY3Qg IDIgMTU6MDg6NDkgKG5vbmUpIGtlcm5lbDogIFs8YzAxMWU3NzA+XSBkZWZhdWx0X3dha2Vf ZnVuY3Rpb24rMHgwLzB4MzAKT2N0ICAyIDE1OjA4OjQ5IChub25lKSBrZXJuZWw6ICBbPGMw MTJkOTZiPl0gc3lzX3J0X3NpZ3Byb2NtYXNrKzB4ZWIvMHgxODAKT2N0ICAyIDE1OjA4OjQ5 IChub25lKSBrZXJuZWw6ICBbPGMwMTFlNzcwPl0gZGVmYXVsdF93YWtlX2Z1bmN0aW9uKzB4 MC8weDMwCk9jdCAgMiAxNTowODo0OSAobm9uZSkga2VybmVsOiAgWzxjMDEwOTQ0Yj5dIHN5 c2NhbGxfY2FsbCsweDcvMHhiCk9jdCAgMiAxNTowODo0OSAobm9uZSkga2VybmVsOiAKT2N0 ICAyIDE1OjA4OjQ5IChub25lKSBrZXJuZWw6IGRldmZzZCAgICAgICAgUyBDRjhFNDAwMCA0 MjkwNjYwODI4ICAgIDU2ICAgICAgMSAgICAgICAgICAgMTk4ICAgIDM1IChOT1RMQikKT2N0 ICAyIDE1OjA4OjQ5IChub25lKSBrZXJuZWw6IGNmOGU1ZWU0IDAwMDAwMDg2IDAwMDAwMjk2 IGNmOGU0MDAwIGNmOGU1ZWU0IDAwMDAwMjk2IGMwM2EzZTUwIDAwMDAwMDAzIApPY3QgIDIg MTU6MDg6NDkgKG5vbmUpIGtlcm5lbDogICAgICAgIDAwMDAwMDAxIGMwM2EzZTUwIGMwM2Ez ZTIwIGNmOGU0MDAwIGMwM2EzZTQ4IGMwMWE0ZjlhIDZjMmY3NjY1IDAwMDA2NzZmIApPY3Qg IDIgMTU6MDg6NDkgKG5vbmUpIGtlcm5lbDogICAgICAgIDAwMDAwMDAwIGNmODllYTAwIGNm ODllYTgwIGNmOTI2ODAwIGMwMjRkZjhhIGNmODllYTgwIGNmZmMzNTI0IDAwMDAwYTM4IApP Y3QgIDIgMTU6MDg6NDkgKG5vbmUpIGtlcm5lbDogQ2FsbCBUcmFjZToKT2N0ICAyIDE1OjA4 OjQ5IChub25lKSBrZXJuZWw6ICBbPGMwMWE0ZjlhPl0gZGV2ZnNkX3JlYWQrMHhmYS8weDRj MApPY3QgIDIgMTU6MDg6NDkgKG5vbmUpIGtlcm5lbDogIFs8YzAyNGRmOGE+XSBzb2NrX21h cF9mZCsweDEwYS8weDE2MApPY3QgIDIgMTU6MDg6NDkgKG5vbmUpIGtlcm5lbDogIFs8YzAx MWU3NzA+XSBkZWZhdWx0X3dha2VfZnVuY3Rpb24rMHgwLzB4MzAKT2N0ICAyIDE1OjA4OjQ5 IChub25lKSBrZXJuZWw6ICBbPGMwMTFlNzcwPl0gZGVmYXVsdF93YWtlX2Z1bmN0aW9uKzB4 MC8weDMwCk9jdCAgMiAxNTowODo0OSAobm9uZSkga2VybmVsOiAgWzxjMDEyZWExNT5dIHN5 c19ydF9zaWdhY3Rpb24rMHhhNS8weDEzMApPY3QgIDIgMTU6MDg6NDkgKG5vbmUpIGtlcm5l bDogIFs8YzAxNTlmM2M+XSB2ZnNfcmVhZCsweGZjLzB4MTQwCk9jdCAgMiAxNTowODo0OSAo bm9uZSkga2VybmVsOiAgWzxjMDE2Y2I5Yj5dIGRvX2ZjbnRsKzB4MTZiLzB4MWUwCk9jdCAg MiAxNTowODo0OSAobm9uZSkga2VybmVsOiAgWzxjMDE1YTFlMj5dIHN5c19yZWFkKzB4NDIv MHg3MApPY3QgIDIgMTU6MDg6NDkgKG5vbmUpIGtlcm5lbDogIFs8YzAxMDk0NGI+XSBzeXNj YWxsX2NhbGwrMHg3LzB4YgpPY3QgIDIgMTU6MDg6NDkgKG5vbmUpIGtlcm5lbDogCk9jdCAg MiAxNTowODo0OSAobm9uZSkga2VybmVsOiBram91cm5hbGQgICAgIFMgMDAwMDAwMDAgNDI4 MzI4MjY3MiAgIDE5OCAgICAgIDEgICAgICAgICAgIDIwMCAgICA1NiAoTC1UTEIpCk9jdCAg MiAxNTowODo0OSAobm9uZSkga2VybmVsOiBjZjFkZGY2NCAwMDAwMDA0NiAwMDAwMDI5MiAw MDAwMDAwMCBjZjFkZGY2NCAwMDAwMDI5MiBjZjNkNTJjNCAwMDAwMDAwMyAKT2N0ICAyIDE1 OjA4OjQ5IChub25lKSBrZXJuZWw6ICAgICAgICAwMDAwMDAwMSBjZjFkYzAwMCAwMDAwMDAw MCAwMDAwMDAwMSBjZjNkNTI4MCBkMTg0ODM3YSBkMTg0Yjk2MCAwMDAwMDAwNSAKT2N0ICAy IDE1OjA4OjQ5IChub25lKSBrZXJuZWw6ICAgICAgICBjZjNkNTJjNCBjZjNkNTJkNCBjMTI5 ZDhjMCAwMDAwMDAwMCBjZmQwMGNhMCBjMDExZmU0MCBjZjFkZGZhYyBjZjFkZGZhYyAKT2N0 ICAyIDE1OjA4OjQ5IChub25lKSBrZXJuZWw6IENhbGwgVHJhY2U6Ck9jdCAgMiAxNTowODo0 OSAobm9uZSkga2VybmVsOiAgWzxkMTg0ODM3YT5dIGtqb3VybmFsZCsweDIxYS8weDI2MCBb amJkXQpPY3QgIDIgMTU6MDg6NDkgKG5vbmUpIGtlcm5lbDogIFs8YzAxMWZlNDA+XSBhdXRv cmVtb3ZlX3dha2VfZnVuY3Rpb24rMHgwLzB4NTAKT2N0ICAyIDE1OjA4OjQ5IChub25lKSBr ZXJuZWw6ICBbPGMwMTFmZTQwPl0gYXV0b3JlbW92ZV93YWtlX2Z1bmN0aW9uKzB4MC8weDUw Ck9jdCAgMiAxNTowODo0OSAobm9uZSkga2VybmVsOiAgWzxjMDEwOTMyMj5dIHJldF9mcm9t X2ZvcmsrMHg2LzB4MTQKT2N0ICAyIDE1OjA4OjQ5IChub25lKSBrZXJuZWw6ICBbPGQxODQ4 MTYwPl0ga2pvdXJuYWxkKzB4MC8weDI2MCBbamJkXQpPY3QgIDIgMTU6MDg6NDkgKG5vbmUp IGtlcm5lbDogIFs8ZDE4NDgxNDA+XSBjb21taXRfdGltZW91dCsweDAvMHgxMCBbamJkXQpP Y3QgIDIgMTU6MDg6NDkgKG5vbmUpIGtlcm5lbDogIFs8ZDE4NDgxNjA+XSBram91cm5hbGQr MHgwLzB4MjYwIFtqYmRdCk9jdCAgMiAxNTowODo0OSAobm9uZSkga2VybmVsOiAgWzxjMDEw NzI1NT5dIGtlcm5lbF90aHJlYWRfaGVscGVyKzB4NS8weDEwCk9jdCAgMiAxNTowODo0OSAo bm9uZSkga2VybmVsOiAKT2N0ICAyIDE1OjA4OjQ5IChub25lKSBrZXJuZWw6IGtqb3VybmFs ZCAgICAgUyAwMDAwMDAwMSA0Mjc5MDAxMzYwICAgMjAwICAgICAgMSAgICAgICAgICAgMjA0 ICAgMTk4IChMLVRMQikKT2N0ICAyIDE1OjA4OjQ5IChub25lKSBrZXJuZWw6IGNlZGM3ZjY0 IDAwMDAwMDQ2IDAwMDAwMjkyIDAwMDAwMDAxIGNlZGM3ZjY0IDAwMDAwMjkyIGNmM2Q1NGM0 IDAwMDAwMDAzIApPY3QgIDIgMTU6MDg6NDkgKG5vbmUpIGtlcm5lbDogICAgICAgIDAwMDAw MDAxIGNlZGM2MDAwIDAwMDAwMDAwIDAwMDAwMDAxIGNmM2Q1NDgwIGQxODQ4MzdhIGNmM2Q1 NDgwIDAwMDAwMDA1IApPY3QgIDIgMTU6MDg6NDkgKG5vbmUpIGtlcm5lbDogICAgICAgIGNm M2Q1NGM0IGNmM2Q1NGQ0IGNmZmUwYTYwIDAwMDAwMDAwIGNmZDAwMDgwIGMwMTFmZTQwIGNl ZGM3ZmFjIGNlZGM3ZmFjIApPY3QgIDIgMTU6MDg6NDkgKG5vbmUpIGtlcm5lbDogQ2FsbCBU cmFjZToKT2N0ICAyIDE1OjA4OjQ5IChub25lKSBrZXJuZWw6ICBbPGQxODQ4MzdhPl0ga2pv dXJuYWxkKzB4MjFhLzB4MjYwIFtqYmRdCk9jdCAgMiAxNTowODo0OSAobm9uZSkga2VybmVs OiAgWzxjMDExZmU0MD5dIGF1dG9yZW1vdmVfd2FrZV9mdW5jdGlvbisweDAvMHg1MApPY3Qg IDIgMTU6MDg6NDkgKG5vbmUpIGtlcm5lbDogIFs8YzAxMWZlNDA+XSBhdXRvcmVtb3ZlX3dh a2VfZnVuY3Rpb24rMHgwLzB4NTAKT2N0ICAyIDE1OjA4OjQ5IChub25lKSBrZXJuZWw6ICBb PGMwMTA5MzIyPl0gcmV0X2Zyb21fZm9yaysweDYvMHgxNApPY3QgIDIgMTU6MDg6NDkgKG5v bmUpIGtlcm5lbDogIFs8ZDE4NDgxNDA+XSBjb21taXRfdGltZW91dCsweDAvMHgxMCBbamJk XQpPY3QgIDIgMTU6MDg6NDkgKG5vbmUpIGtlcm5lbDogIFs8ZDE4NDgxNjA+XSBram91cm5h bGQrMHgwLzB4MjYwIFtqYmRdCk9jdCAgMiAxNTowODo0OSAobm9uZSkga2VybmVsOiAgWzxj MDEwNzI1NT5dIGtlcm5lbF90aHJlYWRfaGVscGVyKzB4NS8weDEwCk9jdCAgMiAxNTowODo0 OSAobm9uZSkga2VybmVsOiAKT2N0ICAyIDE1OjA4OjQ5IChub25lKSBrZXJuZWw6IGtqb3Vy bmFsZCAgICAgUyAwMDAwMDAwMSAyNzYxMTM2ICAgMjA0ICAgICAgMSAgICAgICAgICAgMjA2 ICAgMjAwIChMLVRMQikKT2N0ICAyIDE1OjA4OjQ5IChub25lKSBrZXJuZWw6IGNmNjdmZjY0 IDAwMDAwMDQ2IDAwMDAwMjkyIDAwMDAwMDAxIGNmNjdmZjY0IDAwMDAwMjkyIGNmM2Q1ZGM0 IDAwMDAwMDAzIApPY3QgIDIgMTU6MDg6NDkgKG5vbmUpIGtlcm5lbDogICAgICAgIDAwMDAw MDAxIGNmNjdlMDAwIDAwMDAwMDAwIDAwMDAwMDAxIGNmM2Q1ZDgwIGQxODQ4MzdhIGNmM2Q1 ZDgwIDAwMDAwMDA1IApPY3QgIDIgMTU6MDg6NDkgKG5vbmUpIGtlcm5lbDogICAgICAgIGNm M2Q1ZGM0IGNmM2Q1ZGQ0IDAwMDAwMDAwIDAwMDAwMDAwIGNmM2RiOGMwIGMwMTFmZTQwIGNm NjdmZmFjIGNmNjdmZmFjIApPY3QgIDIgMTU6MDg6NDkgKG5vbmUpIGtlcm5lbDogQ2FsbCBU cmFjZToKT2N0ICAyIDE1OjA4OjQ5IChub25lKSBrZXJuZWw6ICBbPGQxODQ4MzdhPl0ga2pv dXJuYWxkKzB4MjFhLzB4MjYwIFtqYmRdCk9jdCAgMiAxNTowODo0OSAobm9uZSkga2VybmVs OiAgWzxjMDExZmU0MD5dIGF1dG9yZW1vdmVfd2FrZV9mdW5jdGlvbisweDAvMHg1MApPY3Qg IDIgMTU6MDg6NDkgKG5vbmUpIGtlcm5lbDogIFs8YzAxMWZlNDA+XSBhdXRvcmVtb3ZlX3dh a2VfZnVuY3Rpb24rMHgwLzB4NTAKT2N0ICAyIDE1OjA4OjQ5IChub25lKSBrZXJuZWw6ICBb PGMwMTA5MzIyPl0gcmV0X2Zyb21fZm9yaysweDYvMHgxNApPY3QgIDIgMTU6MDg6NDkgKG5v bmUpIGtlcm5lbDogIFs8ZDE4NDgxNDA+XSBjb21taXRfdGltZW91dCsweDAvMHgxMCBbamJk XQpPY3QgIDIgMTU6MDg6NDkgKG5vbmUpIGtlcm5lbDogIFs8ZDE4NDgxNjA+XSBram91cm5h bGQrMHgwLzB4MjYwIFtqYmRdCk9jdCAgMiAxNTowODo0OSAobm9uZSkga2VybmVsOiAgWzxj MDEwNzI1NT5dIGtlcm5lbF90aHJlYWRfaGVscGVyKzB4NS8weDEwCk9jdCAgMiAxNTowODo0 OSAobm9uZSkga2VybmVsOiAKT2N0ICAyIDE1OjA4OjQ5IChub25lKSBrZXJuZWw6IGtqb3Vy bmFsZCAgICAgUyAwMDAwMDAwMCAyNzY1MTI0ICAgMjA2ICAgICAgMSAgICAgICAgICAgMjEy ICAgMjA0IChMLVRMQikKT2N0ICAyIDE1OjA4OjQ5IChub25lKSBrZXJuZWw6IGNmNjdkZjY0 IDAwMDAwMDQ2IDAwMDAwMjkyIDAwMDAwMDAwIGNmNjdkZjY0IDAwMDAwMjkyIGNmM2Q1NmM0 IDAwMDAwMDAzIApPY3QgIDIgMTU6MDg6NDkgKG5vbmUpIGtlcm5lbDogICAgICAgIDAwMDAw MDAxIGNmNjdjMDAwIDAwMDAwMDAwIDAwMDAwMDAxIGNmM2Q1NjgwIGQxODQ4MzdhIGQxODRi OTYwIDAwMDAwMDA1IApPY3QgIDIgMTU6MDg6NDkgKG5vbmUpIGtlcm5lbDogICAgICAgIGNm M2Q1NmM0IGNmM2Q1NmQ0IDQxMTQ3OGRjIDAwMDAwMDAwIGNmM2RhMDgwIGMwMTFmZTQwIGNm NjdkZmFjIGNmNjdkZmFjIApPY3QgIDIgMTU6MDg6NDkgKG5vbmUpIGtlcm5lbDogQ2FsbCBU cmFjZToKT2N0ICAyIDE1OjA4OjQ5IChub25lKSBrZXJuZWw6ICBbPGQxODQ4MzdhPl0ga2pv dXJuYWxkKzB4MjFhLzB4MjYwIFtqYmRdCk9jdCAgMiAxNTowODo0OSAobm9uZSkga2VybmVs OiAgWzxjMDExZmU0MD5dIGF1dG9yZW1vdmVfd2FrZV9mdW5jdGlvbisweDAvMHg1MApPY3Qg IDIgMTU6MDg6NDkgKG5vbmUpIGtlcm5lbDogIFs8YzAxMWZlNDA+XSBhdXRvcmVtb3ZlX3dh a2VfZnVuY3Rpb24rMHgwLzB4NTAKT2N0ICAyIDE1OjA4OjQ5IChub25lKSBrZXJuZWw6ICBb PGMwMTA5MzIyPl0gcmV0X2Zyb21fZm9yaysweDYvMHgxNApPY3QgIDIgMTU6MDg6NDkgKG5v bmUpIGtlcm5lbDogIFs8ZDE4NDgxNjA+XSBram91cm5hbGQrMHgwLzB4MjYwIFtqYmRdCk9j dCAgMiAxNTowODo0OSAobm9uZSkga2VybmVsOiAgWzxkMTg0ODE0MD5dIGNvbW1pdF90aW1l b3V0KzB4MC8weDEwIFtqYmRdCk9jdCAgMiAxNTowODo0OSAobm9uZSkga2VybmVsOiAgWzxk MTg0ODE2MD5dIGtqb3VybmFsZCsweDAvMHgyNjAgW2piZF0KT2N0ICAyIDE1OjA4OjQ5IChu b25lKSBrZXJuZWw6ICBbPGMwMTA3MjU1Pl0ga2VybmVsX3RocmVhZF9oZWxwZXIrMHg1LzB4 MTAKT2N0ICAyIDE1OjA4OjQ5IChub25lKSBrZXJuZWw6IApPY3QgIDIgMTU6MDg6NDkgKG5v bmUpIGtlcm5lbDogeGZzbG9nZC8wICAgICBTIENFQjc0RUQ4IDQyODA0Mzk2OTYgICAyMTIg ICAgICAxICAgICAgICAgICAyMTMgICAyMDYgKEwtVExCKQpPY3QgIDIgMTU6MDg6NDkgKG5v bmUpIGtlcm5lbDogY2U2MDFmNzAgMDAwMDAwNDYgMDAwMDAwOTIgY2ViNzRlZDggY2U2MDFm NzAgMDAwMDAwOTIgY2Y3ODIxMTggMDAwMDAwMDMgCk9jdCAgMiAxNTowODo0OSAobm9uZSkg a2VybmVsOiAgICAgICAgMDAwMDAwMDEgY2U2MDAwMDAgY2Y3ODIxMDggY2ViNzRlZDggY2U2 MDAwMDAgYzAxMzE4YjUgY2ViNzRlODAgY2U2MDFmYTAgCk9jdCAgMiAxNTowODo0OSAobm9u ZSkga2VybmVsOiAgICAgICAgMDAwMDAwMDAgY2Y3ODIxMTggY2Y3ODIxMTAgY2ViNzRlODAg ZDIwNjU4MTAgY2Y3ODIxMDggY2U2MDAwMDAgY2Y3ODIxMDAgCk9jdCAgMiAxNTowODo0OSAo bm9uZSkga2VybmVsOiBDYWxsIFRyYWNlOgpPY3QgIDIgMTU6MDg6NDkgKG5vbmUpIGtlcm5l bDogIFs8YzAxMzE4YjU+XSB3b3JrZXJfdGhyZWFkKzB4Mjg1LzB4MmQwCk9jdCAgMiAxNTow ODo0OSAobm9uZSkga2VybmVsOiAgWzxkMjA2NTgxMD5dIHBhZ2VidWZfaW9kb25lX3dvcmsr MHgwLzB4NTAgW3hmc10KT2N0ICAyIDE1OjA4OjQ5IChub25lKSBrZXJuZWw6ICBbPGMwMTFl NzcwPl0gZGVmYXVsdF93YWtlX2Z1bmN0aW9uKzB4MC8weDMwCk9jdCAgMiAxNTowODo0OSAo bm9uZSkga2VybmVsOiAgWzxjMDEwOTMyMj5dIHJldF9mcm9tX2ZvcmsrMHg2LzB4MTQKT2N0 ICAyIDE1OjA4OjQ5IChub25lKSBrZXJuZWw6ICBbPGMwMTFlNzcwPl0gZGVmYXVsdF93YWtl X2Z1bmN0aW9uKzB4MC8weDMwCk9jdCAgMiAxNTowODo0OSAobm9uZSkga2VybmVsOiAgWzxj MDEzMTYzMD5dIHdvcmtlcl90aHJlYWQrMHgwLzB4MmQwCk9jdCAgMiAxNTowODo0OSAobm9u ZSkga2VybmVsOiAgWzxjMDEwNzI1NT5dIGtlcm5lbF90aHJlYWRfaGVscGVyKzB4NS8weDEw Ck9jdCAgMiAxNTowODo0OSAobm9uZSkga2VybmVsOiAKT2N0ICAyIDE1OjA4OjQ5IChub25l KSBrZXJuZWw6IHhmc2RhdGFkLzAgICAgUyBDRTYyNDAwMCAxMzEyOTYgICAyMTMgICAgICAx ICAgICAgICAgICAyMTQgICAyMTIgKEwtVExCKQpPY3QgIDIgMTU6MDg6NDkgKG5vbmUpIGtl cm5lbDogY2U2MjVmNzAgMDAwMDAwNDYgY2U2MDM5NDAgY2U2MjQwMDAgMDAwMTAwMDAgYzAx MmU1OTQgMDAwMTAwMDAgY2U2MDNmMDQgCk9jdCAgMiAxNTowODo0OSAobm9uZSkga2VybmVs OiAgICAgICAgMDAwMDAwMTAgY2U2MjQwMDAgMDAwMDAwMDAgY2U2MjVmYjQgY2VkYzFlZDgg YzAxMzE4YjUgMDAwMDAwMTEgY2U2MjVmYTAgCk9jdCAgMiAxNTowODo0OSAobm9uZSkga2Vy bmVsOiAgICAgICAgMDAwMDAwMDAgNWIxY2M0ODMgY2Y3ODIxOTAgMDAwMDBkOGIgNDQ4YjAw MDAgY2Y3ODIxODggY2U2MjQwMDAgY2Y3ODIxODAgCk9jdCAgMiAxNTowODo0OSAobm9uZSkg a2VybmVsOiBDYWxsIFRyYWNlOgpPY3QgIDIgMTU6MDg6NDkgKG5vbmUpIGtlcm5lbDogIFs8 YzAxMmU1OTQ+XSBkb19zaWdhY3Rpb24rMHgxYjQvMHgyNzAKT2N0ICAyIDE1OjA4OjQ5IChu b25lKSBrZXJuZWw6ICBbPGMwMTMxOGI1Pl0gd29ya2VyX3RocmVhZCsweDI4NS8weDJkMApP Y3QgIDIgMTU6MDg6NDkgKG5vbmUpIGtlcm5lbDogIFs8YzAxMWU3NzA+XSBkZWZhdWx0X3dh a2VfZnVuY3Rpb24rMHgwLzB4MzAKT2N0ICAyIDE1OjA4OjQ5IChub25lKSBrZXJuZWw6ICBb PGMwMTA5MzIyPl0gcmV0X2Zyb21fZm9yaysweDYvMHgxNApPY3QgIDIgMTU6MDg6NDkgKG5v bmUpIGtlcm5lbDogIFs8YzAxMWU3NzA+XSBkZWZhdWx0X3dha2VfZnVuY3Rpb24rMHgwLzB4 MzAKT2N0ICAyIDE1OjA4OjQ5IChub25lKSBrZXJuZWw6ICBbPGMwMTMxNjMwPl0gd29ya2Vy X3RocmVhZCsweDAvMHgyZDAKT2N0ICAyIDE1OjA4OjQ5IChub25lKSBrZXJuZWw6ICBbPGMw MTA3MjU1Pl0ga2VybmVsX3RocmVhZF9oZWxwZXIrMHg1LzB4MTAKT2N0ICAyIDE1OjA4OjQ5 IChub25lKSBrZXJuZWw6IApPY3QgIDIgMTU6MDg6NDkgKG5vbmUpIGtlcm5lbDogcGFnZWJ1 ZmQgICAgICBTIENFNjAzMzMwICA5OTY4ICAgMjE0ICAgICAgMSAgICAgICAgICAgMjE1ICAg MjEzIChMLVRMQikKT2N0ICAyIDE1OjA4OjQ5IChub25lKSBrZXJuZWw6IGNlNjA3ZjcwIDAw MDAwMDQ2IDAwMDAwMDQ2IGNlNjAzMzMwIGNlNjA3ZjY4IGMwMzAyNDIwIGNlNjA2MDAwIGMw MTJhN2RjIApPY3QgIDIgMTU6MDg6NDkgKG5vbmUpIGtlcm5lbDogICAgICAgIGMwMmZlYjAw IGNlNjA2MDAwIDAwMDAwMjg2IDAwMDAwMDAwIGNlNjA3ZmEwIGMwMTFlYjBmIDAwMDAwMDAw IGNlNjAzMzMwIApPY3QgIDIgMTU6MDg6NDkgKG5vbmUpIGtlcm5lbDogICAgICAgIGMwMTFl NzcwIGQyMDlmMTdjIGQyMDlmMTdjIGNlNjA3ZmMwIDAwMDAwMDAwIDAwMDAwMDAwIDAwMDAw MDAwIGNlNjA2MDAwIApPY3QgIDIgMTU6MDg6NDkgKG5vbmUpIGtlcm5lbDogQ2FsbCBUcmFj ZToKT2N0ICAyIDE1OjA4OjQ5IChub25lKSBrZXJuZWw6ICBbPGMwMTJhN2RjPl0gZnJlZV91 aWQrMHgxYy8weDcwCk9jdCAgMiAxNTowODo0OSAobm9uZSkga2VybmVsOiAgWzxjMDExZWIw Zj5dIGludGVycnVwdGlibGVfc2xlZXBfb24rMHg0Zi8weDkwCk9jdCAgMiAxNTowODo0OSAo bm9uZSkga2VybmVsOiAgWzxjMDExZTc3MD5dIGRlZmF1bHRfd2FrZV9mdW5jdGlvbisweDAv MHgzMApPY3QgIDIgMTU6MDg6NDkgKG5vbmUpIGtlcm5lbDogIFs8ZDIwNjY2MWY+XSBwYWdl YnVmX2RhZW1vbisweDIzZi8weDI3MCBbeGZzXQpPY3QgIDIgMTU6MDg6NDkgKG5vbmUpIGtl cm5lbDogIFs8YzAxMDkzMjI+XSByZXRfZnJvbV9mb3JrKzB4Ni8weDE0Ck9jdCAgMiAxNTow ODo0OSAobm9uZSkga2VybmVsOiAgWzxkMjA2NjNiMD5dIHBhZ2VidWZfZGFlbW9uX3dha2V1 cCsweDAvMHgzMCBbeGZzXQpPY3QgIDIgMTU6MDg6NDkgKG5vbmUpIGtlcm5lbDogIFs8ZDIw NjYzZTA+XSBwYWdlYnVmX2RhZW1vbisweDAvMHgyNzAgW3hmc10KT2N0ICAyIDE1OjA4OjQ5 IChub25lKSBrZXJuZWw6ICBbPGMwMTA3MjU1Pl0ga2VybmVsX3RocmVhZF9oZWxwZXIrMHg1 LzB4MTAKT2N0ICAyIDE1OjA4OjQ5IChub25lKSBrZXJuZWw6IApPY3QgIDIgMTU6MDg6NDkg KG5vbmUpIGtlcm5lbDogeGZzX3N5bmNkICAgICBTIDAwMDAwMDAwIDQyODg1NjQ2ODggICAy MTUgICAgICAxICAgICAgICAgICAyMzIgICAyMTQgKEwtVExCKQpPY3QgIDIgMTU6MDg6NDkg KG5vbmUpIGtlcm5lbDogY2VkYzFmOWMgMDAwMDAwNDYgYzAyYzA4NjAgMDAwMDAwMDAgY2Vk YzFmYjAgMDAwMDAyNDYgYzAzOWYxODAgY2VkYzFmYjAgCk9jdCAgMiAxNTowODo0OSAobm9u ZSkga2VybmVsOiAgICAgICAgMDAwMDAwMDAgMDAwMGM5MjcgY2VkYzFmYjAgMDAwMDAwMDAg MDAwMDAwMDAgYzAxMmE0NmQgY2VkYzFmYjAgMDAwMGM5MjcgCk9jdCAgMiAxNTowODo0OSAo bm9uZSkga2VybmVsOiAgICAgICAgZDIwNTgzY2YgY2U2MDJlYTAgYzAzYWYwN2MgMDAwMGM5 MjcgNGI4N2FkNmUgYzAxMmE0MDAgY2YzZGFjYTAgYzAzOWYxODAgCk9jdCAgMiAxNTowODo0 OSAobm9uZSkga2VybmVsOiBDYWxsIFRyYWNlOgpPY3QgIDIgMTU6MDg6NDkgKG5vbmUpIGtl cm5lbDogIFs8YzAxMmE0NmQ+XSBzY2hlZHVsZV90aW1lb3V0KzB4NWQvMHhiMApPY3QgIDIg MTU6MDg6NDkgKG5vbmUpIGtlcm5lbDogIFs8ZDIwNTgzY2Y+XSB4ZnNfc3luYysweDJmLzB4 NDAgW3hmc10KT2N0ICAyIDE1OjA4OjQ5IChub25lKSBrZXJuZWw6ICBbPGMwMTJhNDAwPl0g cHJvY2Vzc190aW1lb3V0KzB4MC8weDEwCk9jdCAgMiAxNTowODo0OSAobm9uZSkga2VybmVs OiAgWzxkMjA3MjI2Mj5dIHN5bmNkKzB4NTIvMHhjMCBbeGZzXQpPY3QgIDIgMTU6MDg6NDkg KG5vbmUpIGtlcm5lbDogIFs8ZDIwNzIyMTA+XSBzeW5jZCsweDAvMHhjMCBbeGZzXQpPY3Qg IDIgMTU6MDg6NDkgKG5vbmUpIGtlcm5lbDogIFs8YzAxMDcyNTU+XSBrZXJuZWxfdGhyZWFk X2hlbHBlcisweDUvMHgxMApPY3QgIDIgMTU6MDg6NDkgKG5vbmUpIGtlcm5lbDogCk9jdCAg MiAxNTowODo0OSAobm9uZSkga2VybmVsOiBzeXNsb2dkICAgICAgIFMgMDAwMDAwRDAgMjg1 NDE0NCAgIDIyOSAgICAgIDEgICAgICAgICAgICAgICAgIDIzMiAoTk9UTEIpCk9jdCAgMiAx NTowODo0OSAobm9uZSkga2VybmVsOiBjZThiZGVhYyAwMDAwMDA4MiAwMDAwMDAwMCAwMDAw MDBkMCBjZmZjMzY4MCAwMDAwMDBkMCBjZjAyOGQ4MCBjZThiZGYzYyAKT2N0ICAyIDE1OjA4 OjQ5IChub25lKSBrZXJuZWw6ICAgICAgICBjZmZjMzY5OCAwMDAwMDAwMCA3ZmZmZmZmZiAw MDAwMDAwMSAwMDAwMDAwMCBjMDEyYTRiOSBjZThiZGYzYyAwMDAwMDAwMCAKT2N0ICAyIDE1 OjA4OjQ5IChub25lKSBrZXJuZWw6ICAgICAgICBjMDI1NDllMSBjZjAyOGQ4MCBjZmZjMzY5 OCBjZThiZGYzYyBjMDMzZjNjMCAwMDAwMDAwMSBjMDI0ZWFmNiBjZjAyOGQ4MCAKT2N0ICAy IDE1OjA4OjQ5IChub25lKSBrZXJuZWw6IENhbGwgVHJhY2U6Ck9jdCAgMiAxNTowODo0OSAo bm9uZSkga2VybmVsOiAgWzxjMDEyYTRiOT5dIHNjaGVkdWxlX3RpbWVvdXQrMHhhOS8weGIw Ck9jdCAgMiAxNTowODo0OSAobm9uZSkga2VybmVsOiAgWzxjMDI1NDllMT5dIGRhdGFncmFt X3BvbGwrMHhlMS8weGYwCk9jdCAgMiAxNTowODo0OSAobm9uZSkga2VybmVsOiAgWzxjMDI0 ZWFmNj5dIHNvY2tfcG9sbCsweDI2LzB4MzAKT2N0ICAyIDE1OjA4OjQ5IChub25lKSBrZXJu ZWw6ICBbPGMwMTZlMjVlPl0gZG9fc2VsZWN0KzB4MmJlLzB4MzEwCk9jdCAgMiAxNTowODo0 OSAobm9uZSkga2VybmVsOiAgWzxjMDE2ZGRkMD5dIF9fcG9sbHdhaXQrMHgwLzB4ZDAKT2N0 ICAyIDE1OjA4OjQ5IChub25lKSBrZXJuZWw6ICBbPGMwMTZlNTg1Pl0gc3lzX3NlbGVjdCsw eDJhNS8weDUwMApPY3QgIDIgMTU6MDg6NDkgKG5vbmUpIGtlcm5lbDogIFs8YzAxMDk0NGI+ XSBzeXNjYWxsX2NhbGwrMHg3LzB4YgpPY3QgIDIgMTU6MDg6NDkgKG5vbmUpIGtlcm5lbDog Ck9jdCAgMiAxNTowODo0OSAobm9uZSkga2VybmVsOiBrbG9nZCAgICAgICAgIFIgQ0ZERkU5 QTAgNjYwMzEwNCAgIDIzMiAgICAgIDEgICAgICAgICAgIDIyOSAgIDIxNSAoTk9UTEIpCk9j dCAgMiAxNTowODo0OSAobm9uZSkga2VybmVsOiBjZjNjN2YyNCAwMDAwMDA4MiBjZmRmZTk4 MCBjZmRmZTlhMCAwMDAwMDAwMCAwMDAwMDAwMCBjMDExYzFmNyBjZmRmZTk4MCAKT2N0ICAy IDE1OjA4OjQ5IChub25lKSBrZXJuZWw6ICAgICAgICBjMTI5Y2NhMCBjZjNjNjAwMCAwMDAw MDAwMCAwMDAyMDAwMCAwODA0ZDZhMCBjMDEyMjFkMSAwMDAwMDAwMiAwMDAwMDAwMSAKT2N0 ICAyIDE1OjA4OjQ5IChub25lKSBrZXJuZWw6ICAgICAgICAwMDAwMDAwMCAwMDAwMDAwMCBj ZjNjN2ZjNCBjMDEyYTA0NiAwMDAwMDAwMCBjZWQ3OThjMCBjMDExZTc3MCBjMDMwMTY1OCAK T2N0ICAyIDE1OjA4OjQ5IChub25lKSBrZXJuZWw6IENhbGwgVHJhY2U6Ck9jdCAgMiAxNTow ODo0OSAobm9uZSkga2VybmVsOiAgWzxjMDExYzFmNz5dIGRvX3BhZ2VfZmF1bHQrMHgxYjcv MHg0OTMKT2N0ICAyIDE1OjA4OjQ5IChub25lKSBrZXJuZWw6ICBbPGMwMTIyMWQxPl0gZG9f c3lzbG9nKzB4M2ExLzB4NDAwCk9jdCAgMiAxNTowODo0OSAobm9uZSkga2VybmVsOiAgWzxj MDEyYTA0Nj5dIHVwZGF0ZV9wcm9jZXNzX3RpbWVzKzB4NDYvMHg2MApPY3QgIDIgMTU6MDg6 NDkgKG5vbmUpIGtlcm5lbDogIFs8YzAxMWU3NzA+XSBkZWZhdWx0X3dha2VfZnVuY3Rpb24r MHgwLzB4MzAKT2N0ICAyIDE1OjA4OjQ5IChub25lKSBrZXJuZWw6ICBbPGMwMTJhMmE1Pl0g ZG9fdGltZXIrMHg2NS8weGYwCk9jdCAgMiAxNTowODo0OSAobm9uZSkga2VybmVsOiAgWzxj MDE1OWYzYz5dIHZmc19yZWFkKzB4ZmMvMHgxNDAKT2N0ICAyIDE1OjA4OjQ5IChub25lKSBr ZXJuZWw6ICBbPGMwMTVhMWUyPl0gc3lzX3JlYWQrMHg0Mi8weDcwCk9jdCAgMiAxNTowODo0 OSAobm9uZSkga2VybmVsOiAgWzxjMDEwOTQ0Yj5dIHN5c2NhbGxfY2FsbCsweDcvMHhiCk9j dCAgMiAxNTowODo0OSAobm9uZSkga2VybmVsOiAKT2N0ICAyIDE1OjA4OjQ5IChub25lKSBr ZXJuZWw6IHRhaWwgICAgICAgICAgUyBDMDEzRDY3RSAxNTc4NDIyNCAgIDIzNiAgICAgMzUg ICAgICAgICAgICAgICAgICAgICAoTk9UTEIpCk9jdCAgMiAxNTowODo0OSAobm9uZSkga2Vy bmVsOiBjZjUxMWU4MCAwMDAwMDA4MiBjMTI3NWM0MCBjMDEzZDY3ZSBjZmNlZDU4NCAwMDAw MDBkMSBjMDMwMzE1MCBjMTI0MzA4OCAKT2N0ICAyIDE1OjA4OjQ5IChub25lKSBrZXJuZWw6 ICAgICAgICBjMTI5Y2NhMCBjMTMyNjUwMCA3ZmZmZmZmZiBjZjUxMDAwMCAwMDAwMjAwMCBj MDEyYTRiOSAwMDAwMDAwMiAwMDAwMDAyNSAKT2N0ICAyIDE1OjA4OjQ5IChub25lKSBrZXJu ZWw6ICAgICAgICBjMDE0YjI1MiBjZjZmYmEwMCAwMDAwMDBkMSAwMDAwMDAwMCBjMDMwMzJi YyAwMDAwMDAwMCAwMDAwMDBkMiAwMDAwMDI0NiAKT2N0ICAyIDE1OjA4OjQ5IChub25lKSBr ZXJuZWw6IENhbGwgVHJhY2U6Ck9jdCAgMiAxNTowODo0OSAobm9uZSkga2VybmVsOiAgWzxj MDEzZDY3ZT5dIGZpbGVtYXBfbm9wYWdlKzB4MzllLzB4M2UwCk9jdCAgMiAxNTowODo0OSAo bm9uZSkga2VybmVsOiAgWzxjMDEyYTRiOT5dIHNjaGVkdWxlX3RpbWVvdXQrMHhhOS8weGIw Ck9jdCAgMiAxNTowODo0OSAobm9uZSkga2VybmVsOiAgWzxjMDE0YjI1Mj5dIGRvX25vX3Bh Z2UrMHgyNDIvMHg0ZDAKT2N0ICAyIDE1OjA4OjQ5IChub25lKSBrZXJuZWw6ICBbPGMwMWY0 NTQwPl0gcmVhZF9jaGFuKzB4NDkwLzB4OGIwCk9jdCAgMiAxNTowODo0OSAobm9uZSkga2Vy bmVsOiAgWzxjMDE0Yjc3Nz5dIGhhbmRsZV9tbV9mYXVsdCsweDE3Ny8weDFjMApPY3QgIDIg MTU6MDg6NDkgKG5vbmUpIGtlcm5lbDogIFs8YzAxMWU3NzA+XSBkZWZhdWx0X3dha2VfZnVu Y3Rpb24rMHgwLzB4MzAKT2N0ICAyIDE1OjA4OjQ5IChub25lKSBrZXJuZWw6ICBbPGMwMTFl NzcwPl0gZGVmYXVsdF93YWtlX2Z1bmN0aW9uKzB4MC8weDMwCk9jdCAgMiAxNTowODo0OSAo bm9uZSkga2VybmVsOiAgWzxjMDFlZWM3Nj5dIHR0eV9yZWFkKzB4MTM2LzB4MTYwCk9jdCAg MiAxNTowODo0OSAobm9uZSkga2VybmVsOiAgWzxjMDE1OWYzYz5dIHZmc19yZWFkKzB4ZmMv MHgxNDAKT2N0ICAyIDE1OjA4OjQ5IChub25lKSBrZXJuZWw6ICBbPGMwMTVhMWUyPl0gc3lz X3JlYWQrMHg0Mi8weDcwCk9jdCAgMiAxNTowODo0OSAobm9uZSkga2VybmVsOiAgWzxjMDEw OTQ0Yj5dIHN5c2NhbGxfY2FsbCsweDcvMHhiCk9jdCAgMiAxNTowODo0OSAobm9uZSkga2Vy bmVsOiAKT2N0ICAyIDE1OjA4OjQ5IChub25lKSBrZXJuZWw6IGF0a2JkLmM6IFVua25vd24g a2V5IChzZXQgMiwgc2NhbmNvZGUgMHgxYjcsIG9uIGlzYTAwNjAvc2VyaW8wKSBwcmVzc2Vk LgpPY3QgIDIgMTU6MDg6NTEgKG5vbmUpIGtlcm5lbDogU3lzUnEgOiBIRUxQIDogbG9nbGV2 ZWwwLTggcmVCb290IHRFcm0ga0lsbCBzYUsgc2hvd01lbSBwb3dlck9mZiBzaG93UGMgdW5S YXcgU3luYyBzaG93VGFza3MgVW5tb3VudCAKT2N0ICAyIDE1OjA4OjUyIChub25lKSBrZXJu ZWw6IGJhZDogc2NoZWR1bGluZyB3aGlsZSBhdG9taWMhCk9jdCAgMiAxNTowODo1MiAobm9u ZSkga2VybmVsOiBDYWxsIFRyYWNlOgpPY3QgIDIgMTU6MDg6NTIgKG5vbmUpIGtlcm5lbDog IFs8YzAxMWU2ZTY+XSBzY2hlZHVsZSsweDQwNi8weDQ0MApPY3QgIDIgMTU6MDg6NTIgKG5v bmUpIGtlcm5lbDogIFs8YzAxNDI0OTc+XSBfX3BkZmx1c2grMHg5Ny8weDFmMApPY3QgIDIg MTU6MDg6NTIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNDI1ZjA+XSBwZGZsdXNoKzB4MC8weDIw Ck9jdCAgMiAxNTowODo1MiAobm9uZSkga2VybmVsOiAgWzxjMDE0MjVmZj5dIHBkZmx1c2gr MHhmLzB4MjAKT2N0ICAyIDE1OjA4OjUyIChub25lKSBrZXJuZWw6ICBbPGMwMTA3MjUwPl0g a2VybmVsX3RocmVhZF9oZWxwZXIrMHgwLzB4MTAKT2N0ICAyIDE1OjA4OjUyIChub25lKSBr ZXJuZWw6ICBbPGMwMTA3MjU1Pl0ga2VybmVsX3RocmVhZF9oZWxwZXIrMHg1LzB4MTAKT2N0 ICAyIDE1OjA4OjUyIChub25lKSBrZXJuZWw6IApPY3QgIDIgMTU6MDg6NTIgKG5vbmUpIGtl cm5lbDogU3lzUnEgOiBTaG93IFN0YXRlCk9jdCAgMiAxNTowODo1MiAobm9uZSkga2VybmVs OiAKT2N0ICAyIDE1OjA4OjUyIChub25lKSBrZXJuZWw6ICAgICAgICAgICAgICAgICAgICAg ICAgICBmcmVlICAgICAgICAgICAgICAgICAgICAgICAgc2libGluZwpPY3QgIDIgMTU6MDg6 NTIgKG5vbmUpIGtlcm5lbDogICB0YXNrICAgICAgICAgICAgIFBDICAgIHN0YWNrICAgcGlk IGZhdGhlciBjaGlsZCB5b3VuZ2VyIG9sZGVyCk9jdCAgMiAxNTowODo1MiAobm9uZSkga2Vy bmVsOiBpbml0ICAgICAgICAgIFMgMDAwMDAwMDAgIDU4NzYgICAgIDEgICAgICAwICAgICAy ICAgICAgICAgICAgICAgKE5PVExCKQpPY3QgIDIgMTU6MDg6NTIgKG5vbmUpIGtlcm5lbDog YzEyOWZlYWMgMDAwMDAwODYgMDAwMDAwMDAgMDAwMDAwMDAgYzEyOWZlYzAgMDAwMDAyNDYg YzAzOWYxODAgYzEyOWZlYzAgCk9jdCAgMiAxNTowODo1MiAobm9uZSkga2VybmVsOiAgICAg ICAgMDAwMDAwMDAgMDAwMDllNTUgYzEyOWZlYzAgMDAwMDAwMGIgMDAwMDAwMDAgYzAxMmE0 NmQgYzEyOWZlYzAgMDAwMDllNTUgCk9jdCAgMiAxNTowODo1MiAobm9uZSkga2VybmVsOiAg ICAgICAgMDAwMDAyNDYgYzAzOWY0MzAgYzAzOWY0MzAgMDAwMDllNTUgNGI4N2FkNmUgYzAx MmE0MDAgYzEyOWQ4YzAgYzAzOWYxODAgCk9jdCAgMiAxNTowODo1MiAobm9uZSkga2VybmVs OiBDYWxsIFRyYWNlOgpPY3QgIDIgMTU6MDg6NTIgKG5vbmUpIGtlcm5lbDogIFs8YzAxMmE0 NmQ+XSBzY2hlZHVsZV90aW1lb3V0KzB4NWQvMHhiMApPY3QgIDIgMTU6MDg6NTIgKG5vbmUp IGtlcm5lbDogIFs8YzAxMmE0MDA+XSBwcm9jZXNzX3RpbWVvdXQrMHgwLzB4MTAKT2N0ICAy IDE1OjA4OjUyIChub25lKSBrZXJuZWw6ICBbPGMwMTZlMjVlPl0gZG9fc2VsZWN0KzB4MmJl LzB4MzEwCk9jdCAgMiAxNTowODo1MiAobm9uZSkga2VybmVsOiAgWzxjMDE2ZGRkMD5dIF9f cG9sbHdhaXQrMHgwLzB4ZDAKT2N0ICAyIDE1OjA4OjUyIChub25lKSBrZXJuZWw6ICBbPGMw MTZlNTg1Pl0gc3lzX3NlbGVjdCsweDJhNS8weDUwMApPY3QgIDIgMTU6MDg6NTIgKG5vbmUp IGtlcm5lbDogIFs8YzAxMDk0NGI+XSBzeXNjYWxsX2NhbGwrMHg3LzB4YgpPY3QgIDIgMTU6 MDg6NTIgKG5vbmUpIGtlcm5lbDogCk9jdCAgMiAxNTowODo1MiAobm9uZSkga2VybmVsOiBr c29mdGlycWQvMCAgIFMgQzAzOUVGMjggNDI5NDk2MDY0OCAgICAgMiAgICAgIDEgICAgICAg ICAgICAgMyAgICAgICAoTC1UTEIpCk9jdCAgMiAxNTowODo1MiAobm9uZSkga2VybmVsOiBj MTI5YmZkNCAwMDAwMDA0NiAwMDAwMDAwMCBjMDM5ZWYyOCBjMDEyNWUzYiAwMDAwMDAwMCAw MDAwMDAwMSAwMDAwMDI0NiAKT2N0ICAyIDE1OjA4OjUyIChub25lKSBrZXJuZWw6ICAgICAg ICBjMDM5ZWYyOCBjMTI5YTAwMCBjMTI5YTAwMCBmZmZmZTAwMCAwMDAwMDAwMCBjMDEyNjA1 YyBjMTI5ZDJiMCAwMDAwMDAxMyAKT2N0ICAyIDE1OjA4OjUyIChub25lKSBrZXJuZWw6ICAg ICAgICBjMDEyNWZhMCAwMDAwMDAwMCAwMDAwMDAwMCBjMDEwNzI1NSAwMDAwMDAwMCAwMDAw MDAwMCAwMDAwMDAwMCAKT2N0ICAyIDE1OjA4OjUyIChub25lKSBrZXJuZWw6IENhbGwgVHJh Y2U6Ck9jdCAgMiAxNTowODo1MiAobm9uZSkga2VybmVsOiAgWzxjMDEyNWUzYj5dIHRhc2ts ZXRfYWN0aW9uKzB4M2IvMHg3MApPY3QgIDIgMTU6MDg6NTIgKG5vbmUpIGtlcm5lbDogIFs8 YzAxMjYwNWM+XSBrc29mdGlycWQrMHhiYy8weGQwCk9jdCAgMiAxNTowODo1MiAobm9uZSkg a2VybmVsOiAgWzxjMDEyNWZhMD5dIGtzb2Z0aXJxZCsweDAvMHhkMApPY3QgIDIgMTU6MDg6 NTIgKG5vbmUpIGtlcm5lbDogIFs8YzAxMDcyNTU+XSBrZXJuZWxfdGhyZWFkX2hlbHBlcisw eDUvMHgxMApPY3QgIDIgMTU6MDg6NTIgKG5vbmUpIGtlcm5lbDogCk9jdCAgMiAxNTowODo1 MiAobm9uZSkga2VybmVsOiBldmVudHMvMCAgICAgIFMgQzAzMzMwRTAgNDI5NDk1MzAzNiAg ICAgMyAgICAgIDEgICAgICAgICAgICAgNCAgICAgMiAoTC1UTEIpCk9jdCAgMiAxNTowODo1 MiAobm9uZSkga2VybmVsOiBjMTI5OWY3MCAwMDAwMDA0NiAwMDAwMDA5MiBjMDMzMzBlMCBj MTI5OWY3MCAwMDAwMDA5MiBjZmZjNDcxOCAwMDAwMDAwMyAKT2N0ICAyIDE1OjA4OjUyIChu b25lKSBrZXJuZWw6ICAgICAgICAwMDAwMDAwMSBjMTI5ODAwMCBjZmZjNDcwOCBjMDMzMzBl MCBjMTI5ODAwMCBjMDEzMThiNSAwMDAwMDAwMCBjMTI5OWZhMCAKT2N0ICAyIDE1OjA4OjUy IChub25lKSBrZXJuZWw6ICAgICAgICAwMDAwMDAwMCBjZmZjNDcxOCBjZmZjNDcxMCAwMDAw MDAwMCBjMDIwMmE4MCBjZmZjNDcwOCBjMTI5ODAwMCBjZmZjNDcwMCAKT2N0ICAyIDE1OjA4 OjUyIChub25lKSBrZXJuZWw6IENhbGwgVHJhY2U6Ck9jdCAgMiAxNTowODo1MiAobm9uZSkg a2VybmVsOiAgWzxjMDEzMThiNT5dIHdvcmtlcl90aHJlYWQrMHgyODUvMHgyZDAKT2N0ICAy IDE1OjA4OjUyIChub25lKSBrZXJuZWw6ICBbPGMwMjAyYTgwPl0gY29uc29sZV9jYWxsYmFj aysweDAvMHhkMApPY3QgIDIgMTU6MDg6NTIgKG5vbmUpIGtlcm5lbDogIFs8YzAxMWU3NzA+ XSBkZWZhdWx0X3dha2VfZnVuY3Rpb24rMHgwLzB4MzAKT2N0ICAyIDE1OjA4OjUyIChub25l KSBrZXJuZWw6ICBbPGMwMTA5MzIyPl0gcmV0X2Zyb21fZm9yaysweDYvMHgxNApPY3QgIDIg MTU6MDg6NTIgKG5vbmUpIGtlcm5lbDogIFs8YzAxMWU3NzA+XSBkZWZhdWx0X3dha2VfZnVu Y3Rpb24rMHgwLzB4MzAKT2N0ICAyIDE1OjA4OjUyIChub25lKSBrZXJuZWw6ICBbPGMwMTMx NjMwPl0gd29ya2VyX3RocmVhZCsweDAvMHgyZDAKT2N0ICAyIDE1OjA4OjUyIChub25lKSBr ZXJuZWw6ICBbPGMwMTA3MjU1Pl0ga2VybmVsX3RocmVhZF9oZWxwZXIrMHg1LzB4MTAKT2N0 ICAyIDE1OjA4OjUyIChub25lKSBrZXJuZWw6IApPY3QgIDIgMTU6MDg6NTIgKG5vbmUpIGtl cm5lbDoga2Jsb2NrZC8wICAgICBTIEMxMzU4QUYwIDEwNzc1NjAgICAgIDQgICAgICAxICAg ICAgICAgICAgIDUgICAgIDMgKEwtVExCKQpPY3QgIDIgMTU6MDg6NTIgKG5vbmUpIGtlcm5l bDogYzEzYTNmNzAgMDAwMDAwNDYgMDAwMDAwOTIgYzEzNThhZjAgYzEzYTNmNzAgMDAwMDAw OTIgYzEzZGE1OTggMDAwMDAwMDMgCk9jdCAgMiAxNTowODo1MiAobm9uZSkga2VybmVsOiAg ICAgICAgMDAwMDAwMDEgYzEzYTIwMDAgYzEzZGE1ODggYzEzNThhZjAgYzEzYTIwMDAgYzAx MzE4YjUgYzEzNThhMDAgYzEzYTNmYTAgCk9jdCAgMiAxNTowODo1MiAobm9uZSkga2VybmVs OiAgICAgICAgMDAwMDAwMDAgYzEzZGE1OTggYzEzZGE1OTAgYzEzNThhMDAgYzAyMDk4YzAg YzEzZGE1ODggYzEzYTIwMDAgYzEzZGE1ODAgCk9jdCAgMiAxNTowODo1MiAobm9uZSkga2Vy bmVsOiBDYWxsIFRyYWNlOgpPY3QgIDIgMTU6MDg6NTIgKG5vbmUpIGtlcm5lbDogIFs8YzAx MzE4YjU+XSB3b3JrZXJfdGhyZWFkKzB4Mjg1LzB4MmQwCk9jdCAgMiAxNTowODo1MiAobm9u ZSkga2VybmVsOiAgWzxjMDIwOThjMD5dIGJsa191bnBsdWdfd29yaysweDAvMHgyMApPY3Qg IDIgMTU6MDg6NTIgKG5vbmUpIGtlcm5lbDogIFs8YzAxMWU3NzA+XSBkZWZhdWx0X3dha2Vf ZnVuY3Rpb24rMHgwLzB4MzAKT2N0ICAyIDE1OjA4OjUyIChub25lKSBrZXJuZWw6ICBbPGMw MTA5MzIyPl0gcmV0X2Zyb21fZm9yaysweDYvMHgxNApPY3QgIDIgMTU6MDg6NTIgKG5vbmUp IGtlcm5lbDogIFs8YzAxMWU3NzA+XSBkZWZhdWx0X3dha2VfZnVuY3Rpb24rMHgwLzB4MzAK T2N0ICAyIDE1OjA4OjUyIChub25lKSBrZXJuZWw6ICBbPGMwMTMxNjMwPl0gd29ya2VyX3Ro cmVhZCsweDAvMHgyZDAKT2N0ICAyIDE1OjA4OjUyIChub25lKSBrZXJuZWw6ICBbPGMwMTA3 MjU1Pl0ga2VybmVsX3RocmVhZF9oZWxwZXIrMHg1LzB4MTAKT2N0ICAyIDE1OjA4OjUyIChu b25lKSBrZXJuZWw6IApPY3QgIDIgMTU6MDg6NTIgKG5vbmUpIGtlcm5lbDogcGRmbHVzaCAg ICAgICBTIDAwMDAwMDAwIDY4NTE5MiAgICAgNSAgICAgIDEgICAgICAgICAgICAgNiAgICAg NCAoTC1UTEIpCk9jdCAgMiAxNTowODo1MiAobm9uZSkga2VybmVsOiBjMTM0M2ZhYyAwMDAw MDA0NiAwMDAwMDAwMCAwMDAwMDAwMCAwMDAwMDNmZSAwMDAwMDAwMSAwMDAwMDAwMCAwMDAw MDAwMCAKT2N0ICAyIDE1OjA4OjUyIChub25lKSBrZXJuZWw6ICAgICAgICAwMDAwMDAwMCBj MTM0MjAwMCBjMTM0M2ZkYyBjMTM0MjAwMCBjMTM0M2ZkMCBjMDE0MjQ5NyAwMDAwMDAxOSBj MDE0MjVmMCAKT2N0ICAyIDE1OjA4OjUyIChub25lKSBrZXJuZWw6ICAgICAgICAwMDAwMDAw MCAwMDAwMDAwMCAwMDAwMDAwMCBjMDE0MjVmZiBjMTM0M2ZkMCBjMTI5YzA4MCAwMDAwMDAw MCAwMDAwMDAxOSAKT2N0ICAyIDE1OjA4OjUyIChub25lKSBrZXJuZWw6IENhbGwgVHJhY2U6 Ck9jdCAgMiAxNTowODo1MiAobm9uZSkga2VybmVsOiAgWzxjMDE0MjQ5Nz5dIF9fcGRmbHVz aCsweDk3LzB4MWYwCk9jdCAgMiAxNTowODo1MiAobm9uZSkga2VybmVsOiAgWzxjMDE0MjVm MD5dIHBkZmx1c2grMHgwLzB4MjAKT2N0ICAyIDE1OjA4OjUyIChub25lKSBrZXJuZWw6ICBb PGMwMTQyNWZmPl0gcGRmbHVzaCsweGYvMHgyMApPY3QgIDIgMTU6MDg6NTIgKG5vbmUpIGtl cm5lbDogIFs8YzAxMDcyNTA+XSBrZXJuZWxfdGhyZWFkX2hlbHBlcisweDAvMHgxMApPY3Qg IDIgMTU6MDg6NTIgKG5vbmUpIGtlcm5lbDogIFs8YzAxMDcyNTU+XSBrZXJuZWxfdGhyZWFk X2hlbHBlcisweDUvMHgxMApPY3QgIDIgMTU6MDg6NTIgKG5vbmUpIGtlcm5lbDogCk9jdCAg MiAxNTowODo1MiAobm9uZSkga2VybmVsOiBwZGZsdXNoICAgICAgIFMgMDAwMDAwMDAgNDI5 NDk1NzQ2MCAgICAgNiAgICAgIDEgICAgICAgICAgICAgNyAgICAgNSAoTC1UTEIpCk9jdCAg MiAxNTowODo1MiAobm9uZSkga2VybmVsOiBjMTMzZmZhYyAwMDAwMDA0NiBjMDJjMDg2MCAw MDAwMDAwMCAwMDAwMDAwMCAwMDAwMDAwMCAwMDAwMDAwMCAwMDAwMDAwMCAKT2N0ICAyIDE1 OjA4OjUyIChub25lKSBrZXJuZWw6ICAgICAgICAwMDAwMDAwMCBjMTMzZTAwMCBjMTMzZmZk YyBjMTMzZTAwMCBjMTMzZmZkMCBjMDE0MjQ5NyAwMDAwMDAwMCBjMDE0MjVmMCAKT2N0ICAy IDE1OjA4OjUyIChub25lKSBrZXJuZWw6ICAgICAgICAwMDAwMDAwMCAwMDAwMDAwMCAwMDAw MDAwMCBjMDE0MjVmZiBjMTMzZmZkMCBjMTM0MTk0MCAwMDAwMDAwMCAwMDAwMDAwMCAKT2N0 ICAyIDE1OjA4OjUyIChub25lKSBrZXJuZWw6IENhbGwgVHJhY2U6Ck9jdCAgMiAxNTowODo1 MiAobm9uZSkga2VybmVsOiAgWzxjMDE0MjQ5Nz5dIF9fcGRmbHVzaCsweDk3LzB4MWYwCk9j dCAgMiAxNTowODo1MiAobm9uZSkga2VybmVsOiAgWzxjMDE0MjVmMD5dIHBkZmx1c2grMHgw LzB4MjAKT2N0ICAyIDE1OjA4OjUyIChub25lKSBrZXJuZWw6ICBbPGMwMTQyNWZmPl0gcGRm bHVzaCsweGYvMHgyMApPY3QgIDIgMTU6MDg6NTIgKG5vbmUpIGtlcm5lbDogIFs8YzAxMDcy NTA+XSBrZXJuZWxfdGhyZWFkX2hlbHBlcisweDAvMHgxMApPY3QgIDIgMTU6MDg6NTIgKG5v bmUpIGtlcm5lbDogIFs8YzAxMDcyNTU+XSBrZXJuZWxfdGhyZWFkX2hlbHBlcisweDUvMHgx MApPY3QgIDIgMTU6MDg6NTIgKG5vbmUpIGtlcm5lbDogCk9jdCAgMiAxNTowODo1MiAobm9u ZSkga2VybmVsOiBrc3dhcGQwICAgICAgIFMgQzEzM0MwMDAgNDI5NDk1MjE4MCAgICAgNyAg ICAgIDEgICAgICAgICAgICAgOCAgICAgNiAoTC1UTEIpCk9jdCAgMiAxNTowODo1MiAobm9u ZSkga2VybmVsOiBjMTMzZGYwOCAwMDAwMDA0NiAwMDAwMDAwOCBjMTMzYzAwMCBjMTM0MTMz MCBjMDEyMzNkMCBjMTM0MTMzMCBjMTMzZGYwMCAKT2N0ICAyIDE1OjA4OjUyIChub25lKSBr ZXJuZWw6ICAgICAgICAwMDAwMDAwMCBjMTMzYzAwMCBjMDMwMzJmMCBjMTMzZGYyMCBjMTMz ZGZjMCBjMDE0N2VkMyBjMDJjOGM5MSAwMDAwMDAwMCAKT2N0ICAyIDE1OjA4OjUyIChub25l KSBrZXJuZWw6ICAgICAgICAwMDAwMDAwMCAwMDAwMDAwMCAwMDAwMDAwMCAwMDAwMDAwMCAw MDAwMDAwMCAwMDAwMDAwMCAwMDAwMDAwMCAwMDAwMDAwMCAKT2N0ICAyIDE1OjA4OjUyIChu b25lKSBrZXJuZWw6IENhbGwgVHJhY2U6Ck9jdCAgMiAxNTowODo1MiAobm9uZSkga2VybmVs OiAgWzxjMDEyMzNkMD5dIGRhZW1vbml6ZSsweGQwLzB4ZTAKT2N0ICAyIDE1OjA4OjUyIChu b25lKSBrZXJuZWw6ICBbPGMwMTQ3ZWQzPl0ga3N3YXBkKzB4ZTMvMHgxMzAKT2N0ICAyIDE1 OjA4OjUyIChub25lKSBrZXJuZWw6ICBbPGMwMTFlNzRkPl0gcHJlZW1wdF9zY2hlZHVsZSsw eDJkLzB4NTAKT2N0ICAyIDE1OjA4OjUyIChub25lKSBrZXJuZWw6ICBbPGMwMTFmZTQwPl0g YXV0b3JlbW92ZV93YWtlX2Z1bmN0aW9uKzB4MC8weDUwCk9jdCAgMiAxNTowODo1MiAobm9u ZSkga2VybmVsOiAgWzxjMDEwOTMyMj5dIHJldF9mcm9tX2ZvcmsrMHg2LzB4MTQKT2N0ICAy IDE1OjA4OjUyIChub25lKSBrZXJuZWw6ICBbPGMwMTFmZTQwPl0gYXV0b3JlbW92ZV93YWtl X2Z1bmN0aW9uKzB4MC8weDUwCk9jdCAgMiAxNTowODo1MiAobm9uZSkga2VybmVsOiAgWzxj MDE0N2RmMD5dIGtzd2FwZCsweDAvMHgxMzAKT2N0ICAyIDE1OjA4OjUyIChub25lKSBrZXJu ZWw6ICBbPGMwMTA3MjU1Pl0ga2VybmVsX3RocmVhZF9oZWxwZXIrMHg1LzB4MTAKT2N0ICAy IDE1OjA4OjUyIChub25lKSBrZXJuZWw6IApPY3QgIDIgMTU6MDg6NTIgKG5vbmUpIGtlcm5l bDogYWlvLzAgICAgICAgICBTIEMxMzNBMDAwIDQyOTQ5NDU2NDQgICAgIDggICAgICAxICAg ICAgICAgICAgIDkgICAgIDcgKEwtVExCKQpPY3QgIDIgMTU6MDg6NTIgKG5vbmUpIGtlcm5l bDogYzEzM2JmNzAgMDAwMDAwNDYgYzEzNDBkMjAgYzEzM2EwMDAgMDAwMTAwMDAgYzAxMmU1 OTQgMDAwMTAwMDAgYzEzNDEyZTQgCk9jdCAgMiAxNTowODo1MiAobm9uZSkga2VybmVsOiAg ICAgICAgMDAwMDAwMTAgYzEzM2EwMDAgMDAwMDAwMDAgYzEzM2JmYjQgYzEyOWZmNTggYzAx MzE4YjUgMDAwMDAwMTEgYzEzM2JmYTAgCk9jdCAgMiAxNTowODo1MiAobm9uZSkga2VybmVs OiAgICAgICAgMDAwMDAwMDAgMDAwMDAwMDAgYzEzNzY2MTAgYzEzNDEzMzAgMDAwMDAwMDAg YzEzNzY2MDggYzEzM2EwMDAgYzEzNzY2MDAgCk9jdCAgMiAxNTowODo1MiAobm9uZSkga2Vy bmVsOiBDYWxsIFRyYWNlOgpPY3QgIDIgMTU6MDg6NTIgKG5vbmUpIGtlcm5lbDogIFs8YzAx MmU1OTQ+XSBkb19zaWdhY3Rpb24rMHgxYjQvMHgyNzAKT2N0ICAyIDE1OjA4OjUyIChub25l KSBrZXJuZWw6ICBbPGMwMTMxOGI1Pl0gd29ya2VyX3RocmVhZCsweDI4NS8weDJkMApPY3Qg IDIgMTU6MDg6NTIgKG5vbmUpIGtlcm5lbDogIFs8YzAxMWU3NzA+XSBkZWZhdWx0X3dha2Vf ZnVuY3Rpb24rMHgwLzB4MzAKT2N0ICAyIDE1OjA4OjUyIChub25lKSBrZXJuZWw6ICBbPGMw MTA5MzIyPl0gcmV0X2Zyb21fZm9yaysweDYvMHgxNApPY3QgIDIgMTU6MDg6NTIgKG5vbmUp IGtlcm5lbDogIFs8YzAxMWU3NzA+XSBkZWZhdWx0X3dha2VfZnVuY3Rpb24rMHgwLzB4MzAK T2N0ICAyIDE1OjA4OjUyIChub25lKSBrZXJuZWw6ICBbPGMwMTMxNjMwPl0gd29ya2VyX3Ro cmVhZCsweDAvMHgyZDAKT2N0ICAyIDE1OjA4OjUyIChub25lKSBrZXJuZWw6ICBbPGMwMTA3 MjU1Pl0ga2VybmVsX3RocmVhZF9oZWxwZXIrMHg1LzB4MTAKT2N0ICAyIDE1OjA4OjUyIChu b25lKSBrZXJuZWw6IApPY3QgIDIgMTU6MDg6NTIgKG5vbmUpIGtlcm5lbDoga3BucGJpb3Nk ICAgICBTIDAwMDAwMDAwIDQyOTQ5MzkwNDggICAgIDkgICAgICAxICAgICAgICAgICAgMTAg ICAgIDggKEwtVExCKQpPY3QgIDIgMTU6MDg6NTIgKG5vbmUpIGtlcm5lbDogYzEzMzlmOWMg MDAwMDAwNDYgMDAwMDAwMDAgMDAwMDAwMDAgYzEzMzlmYjAgMDAwMDAyNDYgYzAzOWYxODAg YzEzMzlmYjAgCk9jdCAgMiAxNTowODo1MiAobm9uZSkga2VybmVsOiAgICAgICAgMDAwMDAw MDAgMDAwMGExYTMgYzEzMzlmYjAgMDAwMDAwMDAgMDAwMDAwMDAgYzAxMmE0NmQgYzEzMzlm YjAgMDAwMGExYTMgCk9jdCAgMiAxNTowODo1MiAobm9uZSkga2VybmVsOiAgICAgICAgZmZm ZjAwN2IgYzAzOWZhOTAgYzAzOWZhOTAgMDAwMGExYTMgNGI4N2FkNmUgYzAxMmE0MDAgYzEz NDA3MTAgYzAzOWYxODAgCk9jdCAgMiAxNTowODo1MiAobm9uZSkga2VybmVsOiBDYWxsIFRy YWNlOgpPY3QgIDIgMTU6MDg6NTIgKG5vbmUpIGtlcm5lbDogIFs8YzAxMmE0NmQ+XSBzY2hl ZHVsZV90aW1lb3V0KzB4NWQvMHhiMApPY3QgIDIgMTU6MDg6NTIgKG5vbmUpIGtlcm5lbDog IFs8YzAxMmE0MDA+XSBwcm9jZXNzX3RpbWVvdXQrMHgwLzB4MTAKT2N0ICAyIDE1OjA4OjUy IChub25lKSBrZXJuZWw6ICBbPGMwMWVhMDgwPl0gcG5wX2RvY2tfdGhyZWFkKzB4NTAvMHhl MApPY3QgIDIgMTU6MDg6NTIgKG5vbmUpIGtlcm5lbDogIFs8YzAxZWEwMzA+XSBwbnBfZG9j a190aHJlYWQrMHgwLzB4ZTAKT2N0ICAyIDE1OjA4OjUyIChub25lKSBrZXJuZWw6ICBbPGMw MTA3MjU1Pl0ga2VybmVsX3RocmVhZF9oZWxwZXIrMHg1LzB4MTAKT2N0ICAyIDE1OjA4OjUy IChub25lKSBrZXJuZWw6IApPY3QgIDIgMTU6MDg6NTIgKG5vbmUpIGtlcm5lbDoga3Nlcmlv ZCAgICAgICBTIEMxMzFBMDAwIDQyOTQ4MDk4OTIgICAgMTAgICAgICAxICAgICAgICAgICAg MzUgICAgIDkgKEwtVExCKQpPY3QgIDIgMTU6MDg6NTIgKG5vbmUpIGtlcm5lbDogYzEzMWJm YjAgMDAwMDAwNDYgMDAwMDAwMDggYzEzMWEwMDAgZmZmZmUwMDAgYzAxMjMzZDAgYzEzNDAx MDAgYzEzMWJmYTggCk9jdCAgMiAxNTowODo1MiAobm9uZSkga2VybmVsOiAgICAgICAgYzEz MWEwMDAgYzEzMWEwMDAgZmZmZmUwMDAgYzEzMWJmYzAgYzEzMWEwMDAgYzAyNDhjYzUgMDAw MDAwMGYgYzAxMDkzMjIgCk9jdCAgMiAxNTowODo1MiAobm9uZSkga2VybmVsOiAgICAgICAg MDAwMDAwMDAgYzEzNDAxMDAgYzAxMWU3NzAgYzAzM2IwYzggYzAzM2IwYzggMDAwMDAwMDAg MDAwMDAwMDAgMDAwMDAwMDAgCk9jdCAgMiAxNTowODo1MiAobm9uZSkga2VybmVsOiBDYWxs IFRyYWNlOgpPY3QgIDIgMTU6MDg6NTIgKG5vbmUpIGtlcm5lbDogIFs8YzAxMjMzZDA+XSBk YWVtb25pemUrMHhkMC8weGUwCk9jdCAgMiAxNTowODo1MiAobm9uZSkga2VybmVsOiAgWzxj MDI0OGNjNT5dIHNlcmlvX3RocmVhZCsweGE1LzB4MTUwCk9jdCAgMiAxNTowODo1MiAobm9u ZSkga2VybmVsOiAgWzxjMDEwOTMyMj5dIHJldF9mcm9tX2ZvcmsrMHg2LzB4MTQKT2N0ICAy IDE1OjA4OjUyIChub25lKSBrZXJuZWw6ICBbPGMwMTFlNzcwPl0gZGVmYXVsdF93YWtlX2Z1 bmN0aW9uKzB4MC8weDMwCk9jdCAgMiAxNTowODo1MiAobm9uZSkga2VybmVsOiAgWzxjMDI0 OGMyMD5dIHNlcmlvX3RocmVhZCsweDAvMHgxNTAKT2N0ICAyIDE1OjA4OjUyIChub25lKSBr ZXJuZWw6ICBbPGMwMTA3MjU1Pl0ga2VybmVsX3RocmVhZF9oZWxwZXIrMHg1LzB4MTAKT2N0 ICAyIDE1OjA4OjUyIChub25lKSBrZXJuZWw6IApPY3QgIDIgMTU6MDg6NTIgKG5vbmUpIGtl cm5lbDogYmFzaCAgICAgICAgICBTIENGREVCRkM0IDk1MDYyNCAgICAzNSAgICAgIDEgICAy MzYgICAgICA1NiAgICAxMCAoTk9UTEIpCk9jdCAgMiAxNTowODo1MiAobm9uZSkga2VybmVs OiBjZmRlYmY1MCAwMDAwMDA4MiBjZTYwMjEwMCBjZmRlYmZjNCAwMDAzMDAwMiBjZTYwMjFh NCAwMDAwMDAwMCBjZmRlYmY1OCAKT2N0ICAyIDE1OjA4OjUyIChub25lKSBrZXJuZWw6ICAg ICAgICAwMDAwMDI4NiBmZmZmZmUwMCBjZmRlYTAwMCBjZmQwMTk1YyBjZmQwMTk1YyBjMDEy NGJiOCBmZmZmZmZmZiAwMDAwMDAwMiAKT2N0ICAyIDE1OjA4OjUyIChub25lKSBrZXJuZWw6 ICAgICAgICBjZTYwMjEwMCBjZmRlYTAwMCBjZmRlYTAwMCAwMDAwMDAwMSAwMDAwMDAwMCBj ZmQwMThjMCBjMDExZTc3MCAwMDAwMDAwMCAKT2N0ICAyIDE1OjA4OjUyIChub25lKSBrZXJu ZWw6IENhbGwgVHJhY2U6Ck9jdCAgMiAxNTowODo1MiAobm9uZSkga2VybmVsOiAgWzxjMDEy NGJiOD5dIHN5c193YWl0NCsweDI2OC8weDJjMApPY3QgIDIgMTU6MDg6NTIgKG5vbmUpIGtl cm5lbDogIFs8YzAxMWU3NzA+XSBkZWZhdWx0X3dha2VfZnVuY3Rpb24rMHgwLzB4MzAKT2N0 ICAyIDE1OjA4OjUyIChub25lKSBrZXJuZWw6ICBbPGMwMTJkOTZiPl0gc3lzX3J0X3NpZ3By b2NtYXNrKzB4ZWIvMHgxODAKT2N0ICAyIDE1OjA4OjUyIChub25lKSBrZXJuZWw6ICBbPGMw MTFlNzcwPl0gZGVmYXVsdF93YWtlX2Z1bmN0aW9uKzB4MC8weDMwCk9jdCAgMiAxNTowODo1 MiAobm9uZSkga2VybmVsOiAgWzxjMDEwOTQ0Yj5dIHN5c2NhbGxfY2FsbCsweDcvMHhiCk9j dCAgMiAxNTowODo1MiAobm9uZSkga2VybmVsOiAKT2N0ICAyIDE1OjA4OjUyIChub25lKSBr ZXJuZWw6IGRldmZzZCAgICAgICAgUyBDRjhFNDAwMCA0MjkwNjYwODI4ICAgIDU2ICAgICAg MSAgICAgICAgICAgMTk4ICAgIDM1IChOT1RMQikKT2N0ICAyIDE1OjA4OjUyIChub25lKSBr ZXJuZWw6IGNmOGU1ZWU0IDAwMDAwMDg2IDAwMDAwMjk2IGNmOGU0MDAwIGNmOGU1ZWU0IDAw MDAwMjk2IGMwM2EzZTUwIDAwMDAwMDAzIApPY3QgIDIgMTU6MDg6NTIgKG5vbmUpIGtlcm5l bDogICAgICAgIDAwMDAwMDAxIGMwM2EzZTUwIGMwM2EzZTIwIGNmOGU0MDAwIGMwM2EzZTQ4 IGMwMWE0ZjlhIDZjMmY3NjY1IDAwMDA2NzZmIApPY3QgIDIgMTU6MDg6NTIgKG5vbmUpIGtl cm5lbDogICAgICAgIDAwMDAwMDAwIGNmODllYTAwIGNmODllYTgwIGNmOTI2ODAwIGMwMjRk ZjhhIGNmODllYTgwIGNmZmMzNTI0IDAwMDAwYTM4IApPY3QgIDIgMTU6MDg6NTIgKG5vbmUp IGtlcm5lbDogQ2FsbCBUcmFjZToKT2N0ICAyIDE1OjA4OjUyIChub25lKSBrZXJuZWw6ICBb PGMwMWE0ZjlhPl0gZGV2ZnNkX3JlYWQrMHhmYS8weDRjMApPY3QgIDIgMTU6MDg6NTIgKG5v bmUpIGtlcm5lbDogIFs8YzAyNGRmOGE+XSBzb2NrX21hcF9mZCsweDEwYS8weDE2MApPY3Qg IDIgMTU6MDg6NTIgKG5vbmUpIGtlcm5lbDogIFs8YzAxMWU3NzA+XSBkZWZhdWx0X3dha2Vf ZnVuY3Rpb24rMHgwLzB4MzAKT2N0ICAyIDE1OjA4OjUyIChub25lKSBrZXJuZWw6ICBbPGMw MTFlNzcwPl0gZGVmYXVsdF93YWtlX2Z1bmN0aW9uKzB4MC8weDMwCk9jdCAgMiAxNTowODo1 MiAobm9uZSkga2VybmVsOiAgWzxjMDEyZWExNT5dIHN5c19ydF9zaWdhY3Rpb24rMHhhNS8w eDEzMApPY3QgIDIgMTU6MDg6NTIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNTlmM2M+XSB2ZnNf cmVhZCsweGZjLzB4MTQwCk9jdCAgMiAxNTowODo1MiAobm9uZSkga2VybmVsOiAgWzxjMDE2 Y2I5Yj5dIGRvX2ZjbnRsKzB4MTZiLzB4MWUwCk9jdCAgMiAxNTowODo1MiAobm9uZSkga2Vy bmVsOiAgWzxjMDE1YTFlMj5dIHN5c19yZWFkKzB4NDIvMHg3MApPY3QgIDIgMTU6MDg6NTIg KG5vbmUpIGtlcm5lbDogIFs8YzAxMDk0NGI+XSBzeXNjYWxsX2NhbGwrMHg3LzB4YgpPY3Qg IDIgMTU6MDg6NTIgKG5vbmUpIGtlcm5lbDogCk9jdCAgMiAxNTowODo1MiAobm9uZSkga2Vy bmVsOiBram91cm5hbGQgICAgIFMgMDAwMDAwMDAgNDI4MzI4MjY3MiAgIDE5OCAgICAgIDEg ICAgICAgICAgIDIwMCAgICA1NiAoTC1UTEIpCk9jdCAgMiAxNTowODo1MiAobm9uZSkga2Vy bmVsOiBjZjFkZGY2NCAwMDAwMDA0NiAwMDAwMDI5MiAwMDAwMDAwMCBjZjFkZGY2NCAwMDAw MDI5MiBjZjNkNTJjNCAwMDAwMDAwMyAKT2N0ICAyIDE1OjA4OjUyIChub25lKSBrZXJuZWw6 ICAgICAgICAwMDAwMDAwMSBjZjFkYzAwMCAwMDAwMDAwMCAwMDAwMDAwMSBjZjNkNTI4MCBk MTg0ODM3YSBkMTg0Yjk2MCAwMDAwMDAwNSAKT2N0ICAyIDE1OjA4OjUyIChub25lKSBrZXJu ZWw6ICAgICAgICBjZjNkNTJjNCBjZjNkNTJkNCBjMTI5ZDhjMCAwMDAwMDAwMCBjZmQwMGNh MCBjMDExZmU0MCBjZjFkZGZhYyBjZjFkZGZhYyAKT2N0ICAyIDE1OjA4OjUyIChub25lKSBr ZXJuZWw6IENhbGwgVHJhY2U6Ck9jdCAgMiAxNTowODo1MiAobm9uZSkga2VybmVsOiAgWzxk MTg0ODM3YT5dIGtqb3VybmFsZCsweDIxYS8weDI2MCBbamJkXQpPY3QgIDIgMTU6MDg6NTIg KG5vbmUpIGtlcm5lbDogIFs8YzAxMWZlNDA+XSBhdXRvcmVtb3ZlX3dha2VfZnVuY3Rpb24r MHgwLzB4NTAKT2N0ICAyIDE1OjA4OjUyIChub25lKSBrZXJuZWw6ICBbPGMwMTFmZTQwPl0g YXV0b3JlbW92ZV93YWtlX2Z1bmN0aW9uKzB4MC8weDUwCk9jdCAgMiAxNTowODo1MiAobm9u ZSkga2VybmVsOiAgWzxjMDEwOTMyMj5dIHJldF9mcm9tX2ZvcmsrMHg2LzB4MTQKT2N0ICAy IDE1OjA4OjUyIChub25lKSBrZXJuZWw6ICBbPGQxODQ4MTYwPl0ga2pvdXJuYWxkKzB4MC8w eDI2MCBbamJkXQpPY3QgIDIgMTU6MDg6NTIgKG5vbmUpIGtlcm5lbDogIFs8ZDE4NDgxNDA+ XSBjb21taXRfdGltZW91dCsweDAvMHgxMCBbamJkXQpPY3QgIDIgMTU6MDg6NTIgKG5vbmUp IGtlcm5lbDogIFs8ZDE4NDgxNjA+XSBram91cm5hbGQrMHgwLzB4MjYwIFtqYmRdCk9jdCAg MiAxNTowODo1MiAobm9uZSkga2VybmVsOiAgWzxjMDEwNzI1NT5dIGtlcm5lbF90aHJlYWRf aGVscGVyKzB4NS8weDEwCk9jdCAgMiAxNTowODo1MiAobm9uZSkga2VybmVsOiAKT2N0ICAy IDE1OjA4OjUyIChub25lKSBrZXJuZWw6IGtqb3VybmFsZCAgICAgUyAwMDAwMDAwMSA0Mjc5 MDAxMzYwICAgMjAwICAgICAgMSAgICAgICAgICAgMjA0ICAgMTk4IChMLVRMQikKT2N0ICAy IDE1OjA4OjUyIChub25lKSBrZXJuZWw6IGNlZGM3ZjY0IDAwMDAwMDQ2IDAwMDAwMjkyIDAw MDAwMDAxIGNlZGM3ZjY0IDAwMDAwMjkyIGNmM2Q1NGM0IDAwMDAwMDAzIApPY3QgIDIgMTU6 MDg6NTIgKG5vbmUpIGtlcm5lbDogICAgICAgIDAwMDAwMDAxIGNlZGM2MDAwIDAwMDAwMDAw IDAwMDAwMDAxIGNmM2Q1NDgwIGQxODQ4MzdhIGNmM2Q1NDgwIDAwMDAwMDA1IApPY3QgIDIg MTU6MDg6NTIgKG5vbmUpIGtlcm5lbDogICAgICAgIGNmM2Q1NGM0IGNmM2Q1NGQ0IGNmZmUw YTYwIDAwMDAwMDAwIGNmZDAwMDgwIGMwMTFmZTQwIGNlZGM3ZmFjIGNlZGM3ZmFjIApPY3Qg IDIgMTU6MDg6NTIgKG5vbmUpIGtlcm5lbDogQ2FsbCBUcmFjZToKT2N0ICAyIDE1OjA4OjUy IChub25lKSBrZXJuZWw6ICBbPGQxODQ4MzdhPl0ga2pvdXJuYWxkKzB4MjFhLzB4MjYwIFtq YmRdCk9jdCAgMiAxNTowODo1MiAobm9uZSkga2VybmVsOiAgWzxjMDExZmU0MD5dIGF1dG9y ZW1vdmVfd2FrZV9mdW5jdGlvbisweDAvMHg1MApPY3QgIDIgMTU6MDg6NTIgKG5vbmUpIGtl cm5lbDogIFs8YzAxMWZlNDA+XSBhdXRvcmVtb3ZlX3dha2VfZnVuY3Rpb24rMHgwLzB4NTAK T2N0ICAyIDE1OjA4OjUyIChub25lKSBrZXJuZWw6ICBbPGMwMTA5MzIyPl0gcmV0X2Zyb21f Zm9yaysweDYvMHgxNApPY3QgIDIgMTU6MDg6NTIgKG5vbmUpIGtlcm5lbDogIFs8ZDE4NDgx NDA+XSBjb21taXRfdGltZW91dCsweDAvMHgxMCBbamJkXQpPY3QgIDIgMTU6MDg6NTIgKG5v bmUpIGtlcm5lbDogIFs8ZDE4NDgxNjA+XSBram91cm5hbGQrMHgwLzB4MjYwIFtqYmRdCk9j dCAgMiAxNTowODo1MiAobm9uZSkga2VybmVsOiAgWzxjMDEwNzI1NT5dIGtlcm5lbF90aHJl YWRfaGVscGVyKzB4NS8weDEwCk9jdCAgMiAxNTowODo1MiAobm9uZSkga2VybmVsOiAKT2N0 ICAyIDE1OjA4OjUyIChub25lKSBrZXJuZWw6IGtqb3VybmFsZCAgICAgUyAwMDAwMDAwMSAy NzYxMTM2ICAgMjA0ICAgICAgMSAgICAgICAgICAgMjA2ICAgMjAwIChMLVRMQikKT2N0ICAy IDE1OjA4OjUyIChub25lKSBrZXJuZWw6IGNmNjdmZjY0IDAwMDAwMDQ2IDAwMDAwMjkyIDAw MDAwMDAxIGNmNjdmZjY0IDAwMDAwMjkyIGNmM2Q1ZGM0IDAwMDAwMDAzIApPY3QgIDIgMTU6 MDg6NTIgKG5vbmUpIGtlcm5lbDogICAgICAgIDAwMDAwMDAxIGNmNjdlMDAwIDAwMDAwMDAw IDAwMDAwMDAxIGNmM2Q1ZDgwIGQxODQ4MzdhIGNmM2Q1ZDgwIDAwMDAwMDA1IApPY3QgIDIg MTU6MDg6NTIgKG5vbmUpIGtlcm5lbDogICAgICAgIGNmM2Q1ZGM0IGNmM2Q1ZGQ0IDAwMDAw MDAwIDAwMDAwMDAwIGNmM2RiOGMwIGMwMTFmZTQwIGNmNjdmZmFjIGNmNjdmZmFjIApPY3Qg IDIgMTU6MDg6NTIgKG5vbmUpIGtlcm5lbDogQ2FsbCBUcmFjZToKT2N0ICAyIDE1OjA4OjUy IChub25lKSBrZXJuZWw6ICBbPGQxODQ4MzdhPl0ga2pvdXJuYWxkKzB4MjFhLzB4MjYwIFtq YmRdCk9jdCAgMiAxNTowODo1MiAobm9uZSkga2VybmVsOiAgWzxjMDExZmU0MD5dIGF1dG9y ZW1vdmVfd2FrZV9mdW5jdGlvbisweDAvMHg1MApPY3QgIDIgMTU6MDg6NTIgKG5vbmUpIGtl cm5lbDogIFs8YzAxMWZlNDA+XSBhdXRvcmVtb3ZlX3dha2VfZnVuY3Rpb24rMHgwLzB4NTAK T2N0ICAyIDE1OjA4OjUyIChub25lKSBrZXJuZWw6ICBbPGMwMTA5MzIyPl0gcmV0X2Zyb21f Zm9yaysweDYvMHgxNApPY3QgIDIgMTU6MDg6NTIgKG5vbmUpIGtlcm5lbDogIFs8ZDE4NDgx NDA+XSBjb21taXRfdGltZW91dCsweDAvMHgxMCBbamJkXQpPY3QgIDIgMTU6MDg6NTIgKG5v bmUpIGtlcm5lbDogIFs8ZDE4NDgxNjA+XSBram91cm5hbGQrMHgwLzB4MjYwIFtqYmRdCk9j dCAgMiAxNTowODo1MiAobm9uZSkga2VybmVsOiAgWzxjMDEwNzI1NT5dIGtlcm5lbF90aHJl YWRfaGVscGVyKzB4NS8weDEwCk9jdCAgMiAxNTowODo1MiAobm9uZSkga2VybmVsOiAKT2N0 ICAyIDE1OjA4OjUyIChub25lKSBrZXJuZWw6IGtqb3VybmFsZCAgICAgUyAwMDAwMDAwMCAy NzY1MTI0ICAgMjA2ICAgICAgMSAgICAgICAgICAgMjEyICAgMjA0IChMLVRMQikKT2N0ICAy IDE1OjA4OjUyIChub25lKSBrZXJuZWw6IGNmNjdkZjY0IDAwMDAwMDQ2IDAwMDAwMjkyIDAw MDAwMDAwIGNmNjdkZjY0IDAwMDAwMjkyIGNmM2Q1NmM0IDAwMDAwMDAzIApPY3QgIDIgMTU6 MDg6NTIgKG5vbmUpIGtlcm5lbDogICAgICAgIDAwMDAwMDAxIGNmNjdjMDAwIDAwMDAwMDAw IDAwMDAwMDAxIGNmM2Q1NjgwIGQxODQ4MzdhIGQxODRiOTYwIDAwMDAwMDA1IApPY3QgIDIg MTU6MDg6NTIgKG5vbmUpIGtlcm5lbDogICAgICAgIGNmM2Q1NmM0IGNmM2Q1NmQ0IDQxMTQ3 OGRjIDAwMDAwMDAwIGNmM2RhMDgwIGMwMTFmZTQwIGNmNjdkZmFjIGNmNjdkZmFjIApPY3Qg IDIgMTU6MDg6NTIgKG5vbmUpIGtlcm5lbDogQ2FsbCBUcmFjZToKT2N0ICAyIDE1OjA4OjUy IChub25lKSBrZXJuZWw6ICBbPGQxODQ4MzdhPl0ga2pvdXJuYWxkKzB4MjFhLzB4MjYwIFtq YmRdCk9jdCAgMiAxNTowODo1MiAobm9uZSkga2VybmVsOiAgWzxjMDExZmU0MD5dIGF1dG9y ZW1vdmVfd2FrZV9mdW5jdGlvbisweDAvMHg1MApPY3QgIDIgMTU6MDg6NTIgKG5vbmUpIGtl cm5lbDogIFs8YzAxMWZlNDA+XSBhdXRvcmVtb3ZlX3dha2VfZnVuY3Rpb24rMHgwLzB4NTAK T2N0ICAyIDE1OjA4OjUyIChub25lKSBrZXJuZWw6ICBbPGMwMTA5MzIyPl0gcmV0X2Zyb21f Zm9yaysweDYvMHgxNApPY3QgIDIgMTU6MDg6NTIgKG5vbmUpIGtlcm5lbDogIFs8ZDE4NDgx NjA+XSBram91cm5hbGQrMHgwLzB4MjYwIFtqYmRdCk9jdCAgMiAxNTowODo1MiAobm9uZSkg a2VybmVsOiAgWzxkMTg0ODE0MD5dIGNvbW1pdF90aW1lb3V0KzB4MC8weDEwIFtqYmRdCk9j dCAgMiAxNTowODo1MiAobm9uZSkga2VybmVsOiAgWzxkMTg0ODE2MD5dIGtqb3VybmFsZCsw eDAvMHgyNjAgW2piZF0KT2N0ICAyIDE1OjA4OjUyIChub25lKSBrZXJuZWw6ICBbPGMwMTA3 MjU1Pl0ga2VybmVsX3RocmVhZF9oZWxwZXIrMHg1LzB4MTAKT2N0ICAyIDE1OjA4OjUyIChu b25lKSBrZXJuZWw6IApPY3QgIDIgMTU6MDg6NTIgKG5vbmUpIGtlcm5lbDogeGZzbG9nZC8w ICAgICBTIENFQjc0RUQ4IDQyODA0Mzk2OTYgICAyMTIgICAgICAxICAgICAgICAgICAyMTMg ICAyMDYgKEwtVExCKQpPY3QgIDIgMTU6MDg6NTIgKG5vbmUpIGtlcm5lbDogY2U2MDFmNzAg MDAwMDAwNDYgMDAwMDAwOTIgY2ViNzRlZDggY2U2MDFmNzAgMDAwMDAwOTIgY2Y3ODIxMTgg MDAwMDAwMDMgCk9jdCAgMiAxNTowODo1MiAobm9uZSkga2VybmVsOiAgICAgICAgMDAwMDAw MDEgY2U2MDAwMDAgY2Y3ODIxMDggY2ViNzRlZDggY2U2MDAwMDAgYzAxMzE4YjUgY2ViNzRl ODAgY2U2MDFmYTAgCk9jdCAgMiAxNTowODo1MiAobm9uZSkga2VybmVsOiAgICAgICAgMDAw MDAwMDAgY2Y3ODIxMTggY2Y3ODIxMTAgY2ViNzRlODAgZDIwNjU4MTAgY2Y3ODIxMDggY2U2 MDAwMDAgY2Y3ODIxMDAgCk9jdCAgMiAxNTowODo1MiAobm9uZSkga2VybmVsOiBDYWxsIFRy YWNlOgpPY3QgIDIgMTU6MDg6NTIgKG5vbmUpIGtlcm5lbDogIFs8YzAxMzE4YjU+XSB3b3Jr ZXJfdGhyZWFkKzB4Mjg1LzB4MmQwCk9jdCAgMiAxNTowODo1MiAobm9uZSkga2VybmVsOiAg WzxkMjA2NTgxMD5dIHBhZ2VidWZfaW9kb25lX3dvcmsrMHgwLzB4NTAgW3hmc10KT2N0ICAy IDE1OjA4OjUyIChub25lKSBrZXJuZWw6ICBbPGMwMTFlNzcwPl0gZGVmYXVsdF93YWtlX2Z1 bmN0aW9uKzB4MC8weDMwCk9jdCAgMiAxNTowODo1MiAobm9uZSkga2VybmVsOiAgWzxjMDEw OTMyMj5dIHJldF9mcm9tX2ZvcmsrMHg2LzB4MTQKT2N0ICAyIDE1OjA4OjUyIChub25lKSBr ZXJuZWw6ICBbPGMwMTFlNzcwPl0gZGVmYXVsdF93YWtlX2Z1bmN0aW9uKzB4MC8weDMwCk9j dCAgMiAxNTowODo1MiAobm9uZSkga2VybmVsOiAgWzxjMDEzMTYzMD5dIHdvcmtlcl90aHJl YWQrMHgwLzB4MmQwCk9jdCAgMiAxNTowODo1MiAobm9uZSkga2VybmVsOiAgWzxjMDEwNzI1 NT5dIGtlcm5lbF90aHJlYWRfaGVscGVyKzB4NS8weDEwCk9jdCAgMiAxNTowODo1MiAobm9u ZSkga2VybmVsOiAKT2N0ICAyIDE1OjA4OjUyIChub25lKSBrZXJuZWw6IHhmc2RhdGFkLzAg ICAgUyBDRTYyNDAwMCAxMzEyOTYgICAyMTMgICAgICAxICAgICAgICAgICAyMTQgICAyMTIg KEwtVExCKQpPY3QgIDIgMTU6MDg6NTIgKG5vbmUpIGtlcm5lbDogY2U2MjVmNzAgMDAwMDAw NDYgY2U2MDM5NDAgY2U2MjQwMDAgMDAwMTAwMDAgYzAxMmU1OTQgMDAwMTAwMDAgY2U2MDNm MDQgCk9jdCAgMiAxNTowODo1MiAobm9uZSkga2VybmVsOiAgICAgICAgMDAwMDAwMTAgY2U2 MjQwMDAgMDAwMDAwMDAgY2U2MjVmYjQgY2VkYzFlZDggYzAxMzE4YjUgMDAwMDAwMTEgY2U2 MjVmYTAgCk9jdCAgMiAxNTowODo1MiAobm9uZSkga2VybmVsOiAgICAgICAgMDAwMDAwMDAg NWIxY2M0ODMgY2Y3ODIxOTAgMDAwMDBkOGIgNDQ4YjAwMDAgY2Y3ODIxODggY2U2MjQwMDAg Y2Y3ODIxODAgCk9jdCAgMiAxNTowODo1MiAobm9uZSkga2VybmVsOiBDYWxsIFRyYWNlOgpP Y3QgIDIgMTU6MDg6NTIgKG5vbmUpIGtlcm5lbDogIFs8YzAxMmU1OTQ+XSBkb19zaWdhY3Rp b24rMHgxYjQvMHgyNzAKT2N0ICAyIDE1OjA4OjUyIChub25lKSBrZXJuZWw6ICBbPGMwMTMx OGI1Pl0gd29ya2VyX3RocmVhZCsweDI4NS8weDJkMApPY3QgIDIgMTU6MDg6NTIgKG5vbmUp IGtlcm5lbDogIFs8YzAxMWU3NzA+XSBkZWZhdWx0X3dha2VfZnVuY3Rpb24rMHgwLzB4MzAK T2N0ICAyIDE1OjA4OjUyIChub25lKSBrZXJuZWw6ICBbPGMwMTA5MzIyPl0gcmV0X2Zyb21f Zm9yaysweDYvMHgxNApPY3QgIDIgMTU6MDg6NTIgKG5vbmUpIGtlcm5lbDogIFs8YzAxMWU3 NzA+XSBkZWZhdWx0X3dha2VfZnVuY3Rpb24rMHgwLzB4MzAKT2N0ICAyIDE1OjA4OjUyIChu b25lKSBrZXJuZWw6ICBbPGMwMTMxNjMwPl0gd29ya2VyX3RocmVhZCsweDAvMHgyZDAKT2N0 ICAyIDE1OjA4OjUyIChub25lKSBrZXJuZWw6ICBbPGMwMTA3MjU1Pl0ga2VybmVsX3RocmVh ZF9oZWxwZXIrMHg1LzB4MTAKT2N0ICAyIDE1OjA4OjUyIChub25lKSBrZXJuZWw6IApPY3Qg IDIgMTU6MDg6NTIgKG5vbmUpIGtlcm5lbDogcGFnZWJ1ZmQgICAgICBTIENFNjAzMzMwICA5 OTY4ICAgMjE0ICAgICAgMSAgICAgICAgICAgMjE1ICAgMjEzIChMLVRMQikKT2N0ICAyIDE1 OjA4OjUyIChub25lKSBrZXJuZWw6IGNlNjA3ZjcwIDAwMDAwMDQ2IDAwMDAwMDQ2IGNlNjAz MzMwIGNlNjA3ZjY4IGMwMzAyNDIwIGNlNjA2MDAwIGMwMTJhN2RjIApPY3QgIDIgMTU6MDg6 NTIgKG5vbmUpIGtlcm5lbDogICAgICAgIGMwMmZlYjAwIGNlNjA2MDAwIDAwMDAwMjg2IDAw MDAwMDAwIGNlNjA3ZmEwIGMwMTFlYjBmIDAwMDAwMDAwIGNlNjAzMzMwIApPY3QgIDIgMTU6 MDg6NTIgKG5vbmUpIGtlcm5lbDogICAgICAgIGMwMTFlNzcwIGQyMDlmMTdjIGQyMDlmMTdj IGNlNjA3ZmMwIDAwMDAwMDAwIDAwMDAwMDAwIDAwMDAwMDAwIGNlNjA2MDAwIApPY3QgIDIg MTU6MDg6NTIgKG5vbmUpIGtlcm5lbDogQ2FsbCBUcmFjZToKT2N0ICAyIDE1OjA4OjUyIChu b25lKSBrZXJuZWw6ICBbPGMwMTJhN2RjPl0gZnJlZV91aWQrMHgxYy8weDcwCk9jdCAgMiAx NTowODo1MiAobm9uZSkga2VybmVsOiAgWzxjMDExZWIwZj5dIGludGVycnVwdGlibGVfc2xl ZXBfb24rMHg0Zi8weDkwCk9jdCAgMiAxNTowODo1MiAobm9uZSkga2VybmVsOiAgWzxjMDEx ZTc3MD5dIGRlZmF1bHRfd2FrZV9mdW5jdGlvbisweDAvMHgzMApPY3QgIDIgMTU6MDg6NTIg KG5vbmUpIGtlcm5lbDogIFs8ZDIwNjY2MWY+XSBwYWdlYnVmX2RhZW1vbisweDIzZi8weDI3 MCBbeGZzXQpPY3QgIDIgMTU6MDg6NTIgKG5vbmUpIGtlcm5lbDogIFs8YzAxMDkzMjI+XSBy ZXRfZnJvbV9mb3JrKzB4Ni8weDE0Ck9jdCAgMiAxNTowODo1MiAobm9uZSkga2VybmVsOiAg WzxkMjA2NjNiMD5dIHBhZ2VidWZfZGFlbW9uX3dha2V1cCsweDAvMHgzMCBbeGZzXQpPY3Qg IDIgMTU6MDg6NTIgKG5vbmUpIGtlcm5lbDogIFs8ZDIwNjYzZTA+XSBwYWdlYnVmX2RhZW1v bisweDAvMHgyNzAgW3hmc10KT2N0ICAyIDE1OjA4OjUyIChub25lKSBrZXJuZWw6ICBbPGMw MTA3MjU1Pl0ga2VybmVsX3RocmVhZF9oZWxwZXIrMHg1LzB4MTAKT2N0ICAyIDE1OjA4OjUy IChub25lKSBrZXJuZWw6IApPY3QgIDIgMTU6MDg6NTIgKG5vbmUpIGtlcm5lbDogeGZzX3N5 bmNkICAgICBTIDAwMDAwMDAwIDQyODg1NjQ2ODggICAyMTUgICAgICAxICAgICAgICAgICAy MzIgICAyMTQgKEwtVExCKQpPY3QgIDIgMTU6MDg6NTIgKG5vbmUpIGtlcm5lbDogY2VkYzFm OWMgMDAwMDAwNDYgYzAyYzA4NjAgMDAwMDAwMDAgY2VkYzFmYjAgMDAwMDAyNDYgYzAzOWYx ODAgY2VkYzFmYjAgCk9jdCAgMiAxNTowODo1MiAobm9uZSkga2VybmVsOiAgICAgICAgMDAw MDAwMDAgMDAwMGM5MjcgY2VkYzFmYjAgMDAwMDAwMDAgMDAwMDAwMDAgYzAxMmE0NmQgY2Vk YzFmYjAgMDAwMGM5MjcgCk9jdCAgMiAxNTowODo1MiAobm9uZSkga2VybmVsOiAgICAgICAg ZDIwNTgzY2YgY2U2MDJlYTAgYzAzYWYwN2MgMDAwMGM5MjcgNGI4N2FkNmUgYzAxMmE0MDAg Y2YzZGFjYTAgYzAzOWYxODAgCk9jdCAgMiAxNTowODo1MiAobm9uZSkga2VybmVsOiBDYWxs IFRyYWNlOgpPY3QgIDIgMTU6MDg6NTIgKG5vbmUpIGtlcm5lbDogIFs8YzAxMmE0NmQ+XSBz Y2hlZHVsZV90aW1lb3V0KzB4NWQvMHhiMApPY3QgIDIgMTU6MDg6NTIgKG5vbmUpIGtlcm5l bDogIFs8ZDIwNTgzY2Y+XSB4ZnNfc3luYysweDJmLzB4NDAgW3hmc10KT2N0ICAyIDE1OjA4 OjUyIChub25lKSBrZXJuZWw6ICBbPGMwMTJhNDAwPl0gcHJvY2Vzc190aW1lb3V0KzB4MC8w eDEwCk9jdCAgMiAxNTowODo1MiAobm9uZSkga2VybmVsOiAgWzxkMjA3MjI2Mj5dIHN5bmNk KzB4NTIvMHhjMCBbeGZzXQpPY3QgIDIgMTU6MDg6NTIgKG5vbmUpIGtlcm5lbDogIFs8ZDIw NzIyMTA+XSBzeW5jZCsweDAvMHhjMCBbeGZzXQpPY3QgIDIgMTU6MDg6NTIgKG5vbmUpIGtl cm5lbDogIFs8YzAxMDcyNTU+XSBrZXJuZWxfdGhyZWFkX2hlbHBlcisweDUvMHgxMApPY3Qg IDIgMTU6MDg6NTIgKG5vbmUpIGtlcm5lbDogCk9jdCAgMiAxNTowODo1MiAobm9uZSkga2Vy bmVsOiBzeXNsb2dkICAgICAgIFMgMDAwMDAwRDAgMjg1NDE0NCAgIDIyOSAgICAgIDEgICAg ICAgICAgICAgICAgIDIzMiAoTk9UTEIpCk9jdCAgMiAxNTowODo1MiAobm9uZSkga2VybmVs OiBjZThiZGVhYyAwMDAwMDA4MiAwMDAwMDAwMCAwMDAwMDBkMCBjMDExZTc3MCAwMDAwMDBk MCBjZjAyOGQ4MCBjZThiZGYzYyAKT2N0ICAyIDE1OjA4OjUyIChub25lKSBrZXJuZWw6ICAg ICAgICBjZmZjMzY5OCAwMDAwMDAwMCA3ZmZmZmZmZiAwMDAwMDAwMSAwMDAwMDAwMCBjMDEy YTRiOSBjZThiZGYzYyAwMDAwMDAwMCAKT2N0ICAyIDE1OjA4OjUyIChub25lKSBrZXJuZWw6 ICAgICAgICBjMDI1NDllMSBjZjAyOGQ4MCBjZmZjMzY5OCBjZThiZGYzYyBjMDMzZjNjMCAw MDAwMDAwMSBjMDI0ZWFmNiBjZjAyOGQ4MCAKT2N0ICAyIDE1OjA4OjUyIChub25lKSBrZXJu ZWw6IENhbGwgVHJhY2U6Ck9jdCAgMiAxNTowODo1MiAobm9uZSkga2VybmVsOiAgWzxjMDEx ZTc3MD5dIGRlZmF1bHRfd2FrZV9mdW5jdGlvbisweDAvMHgzMApPY3QgIDIgMTU6MDg6NTIg KG5vbmUpIGtlcm5lbDogIFs8YzAxMmE0Yjk+XSBzY2hlZHVsZV90aW1lb3V0KzB4YTkvMHhi MApPY3QgIDIgMTU6MDg6NTIgKG5vbmUpIGtlcm5lbDogIFs8YzAyNTQ5ZTE+XSBkYXRhZ3Jh bV9wb2xsKzB4ZTEvMHhmMApPY3QgIDIgMTU6MDg6NTIgKG5vbmUpIGtlcm5lbDogIFs8YzAy NGVhZjY+XSBzb2NrX3BvbGwrMHgyNi8weDMwCk9jdCAgMiAxNTowODo1MiAobm9uZSkga2Vy bmVsOiAgWzxjMDE2ZTI1ZT5dIGRvX3NlbGVjdCsweDJiZS8weDMxMApPY3QgIDIgMTU6MDg6 NTIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNmRkZDA+XSBfX3BvbGx3YWl0KzB4MC8weGQwCk9j dCAgMiAxNTowODo1MiAobm9uZSkga2VybmVsOiAgWzxjMDE2ZTU4NT5dIHN5c19zZWxlY3Qr MHgyYTUvMHg1MDAKT2N0ICAyIDE1OjA4OjUyIChub25lKSBrZXJuZWw6ICBbPGMwMTA5NDRi Pl0gc3lzY2FsbF9jYWxsKzB4Ny8weGIKT2N0ICAyIDE1OjA4OjUyIChub25lKSBrZXJuZWw6 IApPY3QgIDIgMTU6MDg6NTIgKG5vbmUpIGtlcm5lbDoga2xvZ2QgICAgICAgICBSIENGREZF OUEwIDY2MDMxMDQgICAyMzIgICAgICAxICAgICAgICAgICAyMjkgICAyMTUgKE5PVExCKQpP Y3QgIDIgMTU6MDg6NTIgKG5vbmUpIGtlcm5lbDogY2YzYzdmMjQgMDAwMDAwODIgY2ZkZmU5 ODAgY2ZkZmU5YTAgMDAwMDAwMDAgMDAwMDAwMDAgYzAxMWMxZjcgY2ZkZmU5ODAgCk9jdCAg MiAxNTowODo1MiAobm9uZSkga2VybmVsOiAgICAgICAgYzEzNDE5NDAgY2YzYzYwMDAgMDAw MDAwMDAgMDAwMjAwMDAgMDgwNGQ2YTAgYzAxMjIxZDEgMDAwMDAwMDIgMDAwMDAwMDAgCk9j dCAgMiAxNTowODo1MiAobm9uZSkga2VybmVsOiAgICAgICAgMDAwMDAwMDAgMDAwMDAwMDEg MDAwMDAwMDAgMDAwMDAwMDAgMDAwMDAwMDAgY2VkNzk4YzAgYzAxMWU3NzAgYzAzMDE2NTgg Ck9jdCAgMiAxNTowODo1MiAobm9uZSkga2VybmVsOiBDYWxsIFRyYWNlOgpPY3QgIDIgMTU6 MDg6NTIgKG5vbmUpIGtlcm5lbDogIFs8YzAxMWMxZjc+XSBkb19wYWdlX2ZhdWx0KzB4MWI3 LzB4NDkzCk9jdCAgMiAxNTowODo1MiAobm9uZSkga2VybmVsOiAgWzxjMDEyMjFkMT5dIGRv X3N5c2xvZysweDNhMS8weDQwMApPY3QgIDIgMTU6MDg6NTIgKG5vbmUpIGtlcm5lbDogIFs8 YzAxMWU3NzA+XSBkZWZhdWx0X3dha2VfZnVuY3Rpb24rMHgwLzB4MzAKT2N0ICAyIDE1OjA4 OjUyIChub25lKSBrZXJuZWw6ICBbPGMwMTJhMmE1Pl0gZG9fdGltZXIrMHg2NS8weGYwCk9j dCAgMiAxNTowODo1MiAobm9uZSkga2VybmVsOiAgWzxjMDE1OWYzYz5dIHZmc19yZWFkKzB4 ZmMvMHgxNDAKT2N0ICAyIDE1OjA4OjUyIChub25lKSBrZXJuZWw6ICBbPGMwMTVhMWUyPl0g c3lzX3JlYWQrMHg0Mi8weDcwCk9jdCAgMiAxNTowODo1MiAobm9uZSkga2VybmVsOiAgWzxj MDEwOTQ0Yj5dIHN5c2NhbGxfY2FsbCsweDcvMHhiCk9jdCAgMiAxNTowODo1MiAobm9uZSkg a2VybmVsOiAKT2N0ICAyIDE1OjA4OjUyIChub25lKSBrZXJuZWw6IHRhaWwgICAgICAgICAg UyBDMDEzRDY3RSAxNTc4NDIyNCAgIDIzNiAgICAgMzUgICAgICAgICAgICAgICAgICAgICAo Tk9UTEIpCk9jdCAgMiAxNTowODo1MiAobm9uZSkga2VybmVsOiBjZjUxMWU4MCAwMDAwMDA4 MiBjMTI3NWM0MCBjMDEzZDY3ZSBjZmNlZDU4NCAwMDAwMDBkMSBjMDMwMzE1MCBjMTI0MzA4 OCAKT2N0ICAyIDE1OjA4OjUyIChub25lKSBrZXJuZWw6ICAgICAgICBjMTI5Y2NhMCBjMTMy NjUwMCA3ZmZmZmZmZiBjZjUxMDAwMCAwMDAwMjAwMCBjMDEyYTRiOSAwMDAwMDAwMiAwMDAw MDAyNSAKT2N0ICAyIDE1OjA4OjUyIChub25lKSBrZXJuZWw6ICAgICAgICBjMDE0YjI1MiBj ZjZmYmEwMCAwMDAwMDBkMSAwMDAwMDAwMCBjMDMwMzJiYyAwMDAwMDAwMCAwMDAwMDBkMiAw MDAwMDI0NiAKT2N0ICAyIDE1OjA4OjUyIChub25lKSBrZXJuZWw6IENhbGwgVHJhY2U6Ck9j dCAgMiAxNTowODo1MiAobm9uZSkga2VybmVsOiAgWzxjMDEzZDY3ZT5dIGZpbGVtYXBfbm9w YWdlKzB4MzllLzB4M2UwCk9jdCAgMiAxNTowODo1MiAobm9uZSkga2VybmVsOiAgWzxjMDEy YTRiOT5dIHNjaGVkdWxlX3RpbWVvdXQrMHhhOS8weGIwCk9jdCAgMiAxNTowODo1MiAobm9u ZSkga2VybmVsOiAgWzxjMDE0YjI1Mj5dIGRvX25vX3BhZ2UrMHgyNDIvMHg0ZDAKT2N0ICAy IDE1OjA4OjUyIChub25lKSBrZXJuZWw6ICBbPGMwMWY0NTQwPl0gcmVhZF9jaGFuKzB4NDkw LzB4OGIwCk9jdCAgMiAxNTowODo1MiAobm9uZSkga2VybmVsOiAgWzxjMDE0Yjc3Nz5dIGhh bmRsZV9tbV9mYXVsdCsweDE3Ny8weDFjMApPY3QgIDIgMTU6MDg6NTIgKG5vbmUpIGtlcm5l bDogIFs8YzAxMWU3NzA+XSBkZWZhdWx0X3dha2VfZnVuY3Rpb24rMHgwLzB4MzAKT2N0ICAy IDE1OjA4OjUyIChub25lKSBrZXJuZWw6ICBbPGMwMTFlNzcwPl0gZGVmYXVsdF93YWtlX2Z1 bmN0aW9uKzB4MC8weDMwCk9jdCAgMiAxNTowODo1MiAobm9uZSkga2VybmVsOiAgWzxjMDFl ZWM3Nj5dIHR0eV9yZWFkKzB4MTM2LzB4MTYwCk9jdCAgMiAxNTowODo1MiAobm9uZSkga2Vy bmVsOiAgWzxjMDE1OWYzYz5dIHZmc19yZWFkKzB4ZmMvMHgxNDAKT2N0ICAyIDE1OjA4OjUy IChub25lKSBrZXJuZWw6ICBbPGMwMTVhMWUyPl0gc3lzX3JlYWQrMHg0Mi8weDcwCk9jdCAg MiAxNTowODo1MiAobm9uZSkga2VybmVsOiAgWzxjMDEwOTQ0Yj5dIHN5c2NhbGxfY2FsbCsw eDcvMHhiCk9jdCAgMiAxNTowODo1MiAobm9uZSkga2VybmVsOiAKT2N0ICAyIDE1OjA4OjUz IChub25lKSBrZXJuZWw6IGF0a2JkLmM6IFVua25vd24ga2V5IChzZXQgMiwgc2NhbmNvZGUg MHgxYjcsIG9uIGlzYTAwNjAvc2VyaW8wKSBwcmVzc2VkLgpPY3QgIDIgMTU6MDg6NTYgKG5v bmUpIGtlcm5lbDogU3lzUnEgOiBIRUxQIDogbG9nbGV2ZWwwLTggcmVCb290IHRFcm0ga0ls bCBzYUsgc2hvd01lbSBwb3dlck9mZiBzaG93UGMgdW5SYXcgU3luYyBzaG93VGFza3MgVW5t b3VudCAKT2N0ICAyIDE1OjA4OjU3IChub25lKSBrZXJuZWw6IGJhZDogc2NoZWR1bGluZyB3 aGlsZSBhdG9taWMhCk9jdCAgMiAxNTowODo1NyAobm9uZSkga2VybmVsOiBDYWxsIFRyYWNl OgpPY3QgIDIgMTU6MDg6NTcgKG5vbmUpIGtlcm5lbDogIFs8YzAxMWU2ZTY+XSBzY2hlZHVs ZSsweDQwNi8weDQ0MApPY3QgIDIgMTU6MDg6NTcgKG5vbmUpIGtlcm5lbDogIFs8YzAxNDI0 OTc+XSBfX3BkZmx1c2grMHg5Ny8weDFmMApPY3QgIDIgMTU6MDg6NTcgKG5vbmUpIGtlcm5l bDogIFs8YzAxNDI1ZjA+XSBwZGZsdXNoKzB4MC8weDIwCk9jdCAgMiAxNTowODo1NyAobm9u ZSkga2VybmVsOiAgWzxjMDE0MjVmZj5dIHBkZmx1c2grMHhmLzB4MjAKT2N0ICAyIDE1OjA4 OjU3IChub25lKSBrZXJuZWw6ICBbPGMwMTA3MjUwPl0ga2VybmVsX3RocmVhZF9oZWxwZXIr MHgwLzB4MTAKT2N0ICAyIDE1OjA4OjU3IChub25lKSBrZXJuZWw6ICBbPGMwMTA3MjU1Pl0g a2VybmVsX3RocmVhZF9oZWxwZXIrMHg1LzB4MTAKT2N0ICAyIDE1OjA4OjU3IChub25lKSBr ZXJuZWw6IApPY3QgIDIgMTU6MDk6MDIgKG5vbmUpIGtlcm5lbDogYmFkOiBzY2hlZHVsaW5n IHdoaWxlIGF0b21pYyEKT2N0ICAyIDE1OjA5OjAyIChub25lKSBrZXJuZWw6IENhbGwgVHJh Y2U6Ck9jdCAgMiAxNTowOTowMiAobm9uZSkga2VybmVsOiAgWzxjMDExZTZlNj5dIHNjaGVk dWxlKzB4NDA2LzB4NDQwCk9jdCAgMiAxNTowOTowMiAobm9uZSkga2VybmVsOiAgWzxjMDE0 MjQ5Nz5dIF9fcGRmbHVzaCsweDk3LzB4MWYwCk9jdCAgMiAxNTowOTowMiAobm9uZSkga2Vy bmVsOiAgWzxjMDE0MjVmMD5dIHBkZmx1c2grMHgwLzB4MjAKT2N0ICAyIDE1OjA5OjAyIChu b25lKSBrZXJuZWw6ICBbPGMwMTQyNWZmPl0gcGRmbHVzaCsweGYvMHgyMApPY3QgIDIgMTU6 MDk6MDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxMDcyNTA+XSBrZXJuZWxfdGhyZWFkX2hlbHBl cisweDAvMHgxMApPY3QgIDIgMTU6MDk6MDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxMDcyNTU+ XSBrZXJuZWxfdGhyZWFkX2hlbHBlcisweDUvMHgxMApPY3QgIDIgMTU6MDk6MDIgKG5vbmUp IGtlcm5lbDogCk9jdCAgMiAxNTowOTowMyAobm9uZSkga2VybmVsOiBiYWQ6IHNjaGVkdWxp bmcgd2hpbGUgYXRvbWljIQpPY3QgIDIgMTU6MDk6MDMgKG5vbmUpIGtlcm5lbDogQ2FsbCBU cmFjZToKT2N0ICAyIDE1OjA5OjAzIChub25lKSBrZXJuZWw6ICBbPGMwMTFlNmU2Pl0gc2No ZWR1bGUrMHg0MDYvMHg0NDAKT2N0ICAyIDE1OjA5OjAzIChub25lKSBrZXJuZWw6ICBbPGMw MTJhNDZkPl0gc2NoZWR1bGVfdGltZW91dCsweDVkLzB4YjAKT2N0ICAyIDE1OjA5OjAzIChu b25lKSBrZXJuZWw6ICBbPGQyMDU4M2NmPl0geGZzX3N5bmMrMHgyZi8weDQwIFt4ZnNdCk9j dCAgMiAxNTowOTowMyAobm9uZSkga2VybmVsOiAgWzxjMDEyYTQwMD5dIHByb2Nlc3NfdGlt ZW91dCsweDAvMHgxMApPY3QgIDIgMTU6MDk6MDMgKG5vbmUpIGtlcm5lbDogIFs8ZDIwNzIy NjI+XSBzeW5jZCsweDUyLzB4YzAgW3hmc10KT2N0ICAyIDE1OjA5OjAzIChub25lKSBrZXJu ZWw6ICBbPGQyMDcyMjEwPl0gc3luY2QrMHgwLzB4YzAgW3hmc10KT2N0ICAyIDE1OjA5OjAz IChub25lKSBrZXJuZWw6ICBbPGMwMTA3MjU1Pl0ga2VybmVsX3RocmVhZF9oZWxwZXIrMHg1 LzB4MTAKT2N0ICAyIDE1OjA5OjAzIChub25lKSBrZXJuZWw6IApPY3QgIDIgMTU6MDk6MDcg KG5vbmUpIGtlcm5lbDogYmFkOiBzY2hlZHVsaW5nIHdoaWxlIGF0b21pYyEKT2N0ICAyIDE1 OjA5OjA3IChub25lKSBrZXJuZWw6IENhbGwgVHJhY2U6Ck9jdCAgMiAxNTowOTowNyAobm9u ZSkga2VybmVsOiAgWzxjMDExZTZlNj5dIHNjaGVkdWxlKzB4NDA2LzB4NDQwCk9jdCAgMiAx NTowOTowNyAobm9uZSkga2VybmVsOiAgWzxjMDE0MjQ5Nz5dIF9fcGRmbHVzaCsweDk3LzB4 MWYwCk9jdCAgMiAxNTowOTowNyAobm9uZSkga2VybmVsOiAgWzxjMDE0MjVmMD5dIHBkZmx1 c2grMHgwLzB4MjAKT2N0ICAyIDE1OjA5OjA3IChub25lKSBrZXJuZWw6ICBbPGMwMTQyNWZm Pl0gcGRmbHVzaCsweGYvMHgyMApPY3QgIDIgMTU6MDk6MDcgKG5vbmUpIGtlcm5lbDogIFs8 YzAxMDcyNTA+XSBrZXJuZWxfdGhyZWFkX2hlbHBlcisweDAvMHgxMApPY3QgIDIgMTU6MDk6 MDcgKG5vbmUpIGtlcm5lbDogIFs8YzAxMDcyNTU+XSBrZXJuZWxfdGhyZWFkX2hlbHBlcisw eDUvMHgxMApPY3QgIDIgMTU6MDk6MDcgKG5vbmUpIGtlcm5lbDogCk9jdCAgMiAxNTowOTox MiAobm9uZSkga2VybmVsOiBiYWQ6IHNjaGVkdWxpbmcgd2hpbGUgYXRvbWljIQpPY3QgIDIg MTU6MDk6MTIgKG5vbmUpIGtlcm5lbDogQ2FsbCBUcmFjZToKT2N0ICAyIDE1OjA5OjEyIChu b25lKSBrZXJuZWw6ICBbPGMwMTFlNmU2Pl0gc2NoZWR1bGUrMHg0MDYvMHg0NDAKT2N0ICAy IDE1OjA5OjEyIChub25lKSBrZXJuZWw6ICBbPGMwMTQyNDk3Pl0gX19wZGZsdXNoKzB4OTcv MHgxZjAKT2N0ICAyIDE1OjA5OjEyIChub25lKSBrZXJuZWw6ICBbPGMwMTQyNWYwPl0gcGRm bHVzaCsweDAvMHgyMApPY3QgIDIgMTU6MDk6MTIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNDI1 ZmY+XSBwZGZsdXNoKzB4Zi8weDIwCk9jdCAgMiAxNTowOToxMiAobm9uZSkga2VybmVsOiAg WzxjMDEwNzI1MD5dIGtlcm5lbF90aHJlYWRfaGVscGVyKzB4MC8weDEwCk9jdCAgMiAxNTow OToxMiAobm9uZSkga2VybmVsOiAgWzxjMDEwNzI1NT5dIGtlcm5lbF90aHJlYWRfaGVscGVy KzB4NS8weDEwCk9jdCAgMiAxNTowOToxMiAobm9uZSkga2VybmVsOiAKT2N0ICAyIDE1OjA5 OjE3IChub25lKSBrZXJuZWw6IGJhZDogc2NoZWR1bGluZyB3aGlsZSBhdG9taWMhCk9jdCAg MiAxNTowOToxNyAobm9uZSkga2VybmVsOiBDYWxsIFRyYWNlOgpPY3QgIDIgMTU6MDk6MTcg KG5vbmUpIGtlcm5lbDogIFs8YzAxMWU2ZTY+XSBzY2hlZHVsZSsweDQwNi8weDQ0MApPY3Qg IDIgMTU6MDk6MTcgKG5vbmUpIGtlcm5lbDogIFs8YzAxNDI0OTc+XSBfX3BkZmx1c2grMHg5 Ny8weDFmMApPY3QgIDIgMTU6MDk6MTcgKG5vbmUpIGtlcm5lbDogIFs8YzAxNDI1ZjA+XSBw ZGZsdXNoKzB4MC8weDIwCk9jdCAgMiAxNTowOToxNyAobm9uZSkga2VybmVsOiAgWzxjMDE0 MjVmZj5dIHBkZmx1c2grMHhmLzB4MjAKT2N0ICAyIDE1OjA5OjE3IChub25lKSBrZXJuZWw6 ICBbPGMwMTA3MjUwPl0ga2VybmVsX3RocmVhZF9oZWxwZXIrMHgwLzB4MTAKT2N0ICAyIDE1 OjA5OjE3IChub25lKSBrZXJuZWw6ICBbPGMwMTA3MjU1Pl0ga2VybmVsX3RocmVhZF9oZWxw ZXIrMHg1LzB4MTAKT2N0ICAyIDE1OjA5OjE3IChub25lKSBrZXJuZWw6IApPY3QgIDIgMTU6 MDk6MjIgKG5vbmUpIGtlcm5lbDogYmFkOiBzY2hlZHVsaW5nIHdoaWxlIGF0b21pYyEKT2N0 ICAyIDE1OjA5OjIyIChub25lKSBrZXJuZWw6IENhbGwgVHJhY2U6Ck9jdCAgMiAxNTowOToy MiAobm9uZSkga2VybmVsOiAgWzxjMDExZTZlNj5dIHNjaGVkdWxlKzB4NDA2LzB4NDQwCk9j dCAgMiAxNTowOToyMiAobm9uZSkga2VybmVsOiAgWzxjMDE0MjQ5Nz5dIF9fcGRmbHVzaCsw eDk3LzB4MWYwCk9jdCAgMiAxNTowOToyMiAobm9uZSkga2VybmVsOiAgWzxjMDE0MjVmMD5d IHBkZmx1c2grMHgwLzB4MjAKT2N0ICAyIDE1OjA5OjIyIChub25lKSBrZXJuZWw6ICBbPGMw MTQyNWZmPl0gcGRmbHVzaCsweGYvMHgyMApPY3QgIDIgMTU6MDk6MjIgKG5vbmUpIGtlcm5l bDogIFs8YzAxMDcyNTA+XSBrZXJuZWxfdGhyZWFkX2hlbHBlcisweDAvMHgxMApPY3QgIDIg MTU6MDk6MjIgKG5vbmUpIGtlcm5lbDogIFs8YzAxMDcyNTU+XSBrZXJuZWxfdGhyZWFkX2hl bHBlcisweDUvMHgxMApPY3QgIDIgMTU6MDk6MjIgKG5vbmUpIGtlcm5lbDogCk9jdCAgMiAx NTowOToyNyAobm9uZSkga2VybmVsOiBiYWQ6IHNjaGVkdWxpbmcgd2hpbGUgYXRvbWljIQpP Y3QgIDIgMTU6MDk6MjcgKG5vbmUpIGtlcm5lbDogQ2FsbCBUcmFjZToKT2N0ICAyIDE1OjA5 OjI3IChub25lKSBrZXJuZWw6ICBbPGMwMTFlNmU2Pl0gc2NoZWR1bGUrMHg0MDYvMHg0NDAK T2N0ICAyIDE1OjA5OjI3IChub25lKSBrZXJuZWw6ICBbPGMwMTQyNDk3Pl0gX19wZGZsdXNo KzB4OTcvMHgxZjAKT2N0ICAyIDE1OjA5OjI3IChub25lKSBrZXJuZWw6ICBbPGMwMTQyNWYw Pl0gcGRmbHVzaCsweDAvMHgyMApPY3QgIDIgMTU6MDk6MjcgKG5vbmUpIGtlcm5lbDogIFs8 YzAxNDI1ZmY+XSBwZGZsdXNoKzB4Zi8weDIwCk9jdCAgMiAxNTowOToyNyAobm9uZSkga2Vy bmVsOiAgWzxjMDEwNzI1MD5dIGtlcm5lbF90aHJlYWRfaGVscGVyKzB4MC8weDEwCk9jdCAg MiAxNTowOToyNyAobm9uZSkga2VybmVsOiAgWzxjMDEwNzI1NT5dIGtlcm5lbF90aHJlYWRf aGVscGVyKzB4NS8weDEwCk9jdCAgMiAxNTowOToyNyAobm9uZSkga2VybmVsOiAKT2N0ICAy IDE1OjA5OjMyIChub25lKSBrZXJuZWw6IGJhZDogc2NoZWR1bGluZyB3aGlsZSBhdG9taWMh Ck9jdCAgMiAxNTowOTozMiAobm9uZSkga2VybmVsOiBDYWxsIFRyYWNlOgpPY3QgIDIgMTU6 MDk6MzIgKG5vbmUpIGtlcm5lbDogIFs8YzAxMWU2ZTY+XSBzY2hlZHVsZSsweDQwNi8weDQ0 MApPY3QgIDIgMTU6MDk6MzIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNDI0OTc+XSBfX3BkZmx1 c2grMHg5Ny8weDFmMApPY3QgIDIgMTU6MDk6MzIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNDI1 ZjA+XSBwZGZsdXNoKzB4MC8weDIwCk9jdCAgMiAxNTowOTozMiAobm9uZSkga2VybmVsOiAg WzxjMDE0MjVmZj5dIHBkZmx1c2grMHhmLzB4MjAKT2N0ICAyIDE1OjA5OjMyIChub25lKSBr ZXJuZWw6ICBbPGMwMTA3MjUwPl0ga2VybmVsX3RocmVhZF9oZWxwZXIrMHgwLzB4MTAKT2N0 ICAyIDE1OjA5OjMyIChub25lKSBrZXJuZWw6ICBbPGMwMTA3MjU1Pl0ga2VybmVsX3RocmVh ZF9oZWxwZXIrMHg1LzB4MTAKT2N0ICAyIDE1OjA5OjMyIChub25lKSBrZXJuZWw6IApPY3Qg IDIgMTU6MDk6MzMgKG5vbmUpIGtlcm5lbDogYmFkOiBzY2hlZHVsaW5nIHdoaWxlIGF0b21p YyEKT2N0ICAyIDE1OjA5OjMzIChub25lKSBrZXJuZWw6IENhbGwgVHJhY2U6Ck9jdCAgMiAx NTowOTozMyAobm9uZSkga2VybmVsOiAgWzxjMDExZTZlNj5dIHNjaGVkdWxlKzB4NDA2LzB4 NDQwCk9jdCAgMiAxNTowOTozMyAobm9uZSkga2VybmVsOiAgWzxjMDEyYTQ2ZD5dIHNjaGVk dWxlX3RpbWVvdXQrMHg1ZC8weGIwCk9jdCAgMiAxNTowOTozMyAobm9uZSkga2VybmVsOiAg WzxkMjA1ODNjZj5dIHhmc19zeW5jKzB4MmYvMHg0MCBbeGZzXQpPY3QgIDIgMTU6MDk6MzMg KG5vbmUpIGtlcm5lbDogIFs8YzAxMmE0MDA+XSBwcm9jZXNzX3RpbWVvdXQrMHgwLzB4MTAK T2N0ICAyIDE1OjA5OjMzIChub25lKSBrZXJuZWw6ICBbPGQyMDcyMjYyPl0gc3luY2QrMHg1 Mi8weGMwIFt4ZnNdCk9jdCAgMiAxNTowOTozMyAobm9uZSkga2VybmVsOiAgWzxkMjA3MjIx MD5dIHN5bmNkKzB4MC8weGMwIFt4ZnNdCk9jdCAgMiAxNTowOTozMyAobm9uZSkga2VybmVs OiAgWzxjMDEwNzI1NT5dIGtlcm5lbF90aHJlYWRfaGVscGVyKzB4NS8weDEwCk9jdCAgMiAx NTowOTozMyAobm9uZSkga2VybmVsOiAKT2N0ICAyIDE1OjA5OjM3IChub25lKSBrZXJuZWw6 IGJhZDogc2NoZWR1bGluZyB3aGlsZSBhdG9taWMhCk9jdCAgMiAxNTowOTozNyAobm9uZSkg a2VybmVsOiBDYWxsIFRyYWNlOgpPY3QgIDIgMTU6MDk6MzcgKG5vbmUpIGtlcm5lbDogIFs8 YzAxMWU2ZTY+XSBzY2hlZHVsZSsweDQwNi8weDQ0MApPY3QgIDIgMTU6MDk6MzcgKG5vbmUp IGtlcm5lbDogIFs8YzAxNDI0OTc+XSBfX3BkZmx1c2grMHg5Ny8weDFmMApPY3QgIDIgMTU6 MDk6MzcgKG5vbmUpIGtlcm5lbDogIFs8YzAxNDI1ZjA+XSBwZGZsdXNoKzB4MC8weDIwCk9j dCAgMiAxNTowOTozNyAobm9uZSkga2VybmVsOiAgWzxjMDE0MjVmZj5dIHBkZmx1c2grMHhm LzB4MjAKT2N0ICAyIDE1OjA5OjM3IChub25lKSBrZXJuZWw6ICBbPGMwMTA3MjUwPl0ga2Vy bmVsX3RocmVhZF9oZWxwZXIrMHgwLzB4MTAKT2N0ICAyIDE1OjA5OjM3IChub25lKSBrZXJu ZWw6ICBbPGMwMTA3MjU1Pl0ga2VybmVsX3RocmVhZF9oZWxwZXIrMHg1LzB4MTAKT2N0ICAy IDE1OjA5OjM3IChub25lKSBrZXJuZWw6IApPY3QgIDIgMTU6MDk6NDEgKG5vbmUpIGtlcm5l bDogU3lzUnEgOiBFbWVyZ2VuY3kgUmVtb3VudCBSL08KT2N0ICAyIDE1OjA5OjQxIChub25l KSBrZXJuZWw6IGJhZDogc2NoZWR1bGluZyB3aGlsZSBhdG9taWMhCk9jdCAgMiAxNTowOTo0 MSAobm9uZSkga2VybmVsOiBDYWxsIFRyYWNlOgpPY3QgIDIgMTU6MDk6NDEgKG5vbmUpIGtl cm5lbDogIFs8YzAxMWU2ZTY+XSBzY2hlZHVsZSsweDQwNi8weDQ0MApPY3QgIDIgMTU6MDk6 NDEgKG5vbmUpIGtlcm5lbDogIFs8YzAyMDk4YjE+XSBnZW5lcmljX3VucGx1Z19kZXZpY2Ur MHg2MS8weDcwCk9jdCAgMiAxNTowOTo0MSAobm9uZSkga2VybmVsOiAgWzxjMDIwOWExYT5d IGJsa19ydW5fcXVldWVzKzB4N2EvMHhjMApPY3QgIDIgMTU6MDk6NDEgKG5vbmUpIGtlcm5l bDogIFs8YzAxMWY2NWU+XSBpb19zY2hlZHVsZSsweGUvMHgyMApPY3QgIDIgMTU6MDk6NDEg KG5vbmUpIGtlcm5lbDogIFs8YzAxNWI1ZmE+XSBfX3dhaXRfb25fYnVmZmVyKzB4YWEvMHhl MApPY3QgIDIgMTU6MDk6NDEgKG5vbmUpIGtlcm5lbDogIFs8YzAxMWZlNDA+XSBhdXRvcmVt b3ZlX3dha2VfZnVuY3Rpb24rMHgwLzB4NTAKT2N0ICAyIDE1OjA5OjQxIChub25lKSBrZXJu ZWw6ICBbPGMwMTFmZTQwPl0gYXV0b3JlbW92ZV93YWtlX2Z1bmN0aW9uKzB4MC8weDUwCk9j dCAgMiAxNTowOTo0MSAobm9uZSkga2VybmVsOiAgWzxjMDE1ZjRiZT5dIHN5bmNfZGlydHlf YnVmZmVyKzB4NWUvMHhiMApPY3QgIDIgMTU6MDk6NDEgKG5vbmUpIGtlcm5lbDogIFs8ZDE4 ODBiMjk+XSBleHQzX21hcmtfcmVjb3ZlcnlfY29tcGxldGUrMHg1OS8weDYwIFtleHQzXQpP Y3QgIDIgMTU6MDk6NDEgKG5vbmUpIGtlcm5lbDogIFs8ZDE4ODBmMmM+XSBleHQzX3JlbW91 bnQrMHgxM2MvMHgxOTAgW2V4dDNdCk9jdCAgMiAxNTowOTo0MSAobm9uZSkga2VybmVsOiAg WzxjMDE2MTUwNz5dIGRvX3JlbW91bnRfc2IrMHhiNy8weGYwCk9jdCAgMiAxNTowOTo0MSAo bm9uZSkga2VybmVsOiAgWzxjMDE2MTVlNz5dIGRvX2VtZXJnZW5jeV9yZW1vdW50KzB4YTcv MHgxNjAKT2N0ICAyIDE1OjA5OjQxIChub25lKSBrZXJuZWw6ICBbPGMwMTQyNGRhPl0gX19w ZGZsdXNoKzB4ZGEvMHgxZjAKT2N0ICAyIDE1OjA5OjQxIChub25lKSBrZXJuZWw6ICBbPGMw MTQyNWYwPl0gcGRmbHVzaCsweDAvMHgyMApPY3QgIDIgMTU6MDk6NDEgKG5vbmUpIGtlcm5l bDogIFs8YzAxNDI1ZmY+XSBwZGZsdXNoKzB4Zi8weDIwCk9jdCAgMiAxNTowOTo0MSAobm9u ZSkga2VybmVsOiAgWzxjMDE2MTU0MD5dIGRvX2VtZXJnZW5jeV9yZW1vdW50KzB4MC8weDE2 MApPY3QgIDIgMTU6MDk6NDEgKG5vbmUpIGtlcm5lbDogIFs8YzAxMDcyNTA+XSBrZXJuZWxf dGhyZWFkX2hlbHBlcisweDAvMHgxMApPY3QgIDIgMTU6MDk6NDEgKG5vbmUpIGtlcm5lbDog IFs8YzAxMDcyNTU+XSBrZXJuZWxfdGhyZWFkX2hlbHBlcisweDUvMHgxMApPY3QgIDIgMTU6 MDk6NDEgKG5vbmUpIGtlcm5lbDogCk9jdCAgMiAxNTowOTo0MSAobm9uZSkga2VybmVsOiBi YWQ6IHNjaGVkdWxpbmcgd2hpbGUgYXRvbWljIQpPY3QgIDIgMTU6MDk6NDEgKG5vbmUpIGtl cm5lbDogQ2FsbCBUcmFjZToKT2N0ICAyIDE1OjA5OjQxIChub25lKSBrZXJuZWw6ICBbPGMw MTFlNmU2Pl0gc2NoZWR1bGUrMHg0MDYvMHg0NDAKT2N0ICAyIDE1OjA5OjQxIChub25lKSBr ZXJuZWw6ICBbPGQxODQ4YTc4Pl0gbG9nX3dhaXRfY29tbWl0KzB4YjgvMHgxNDAgW2piZF0K T2N0ICAyIDE1OjA5OjQxIChub25lKSBrZXJuZWw6ICBbPGMwMTFlNzcwPl0gZGVmYXVsdF93 YWtlX2Z1bmN0aW9uKzB4MC8weDMwCk9jdCAgMiAxNTowOTo0MSAobm9uZSkga2VybmVsOiAg WzxkMTg0ODhiZD5dIF9fbG9nX3N0YXJ0X2NvbW1pdCsweDJkLzB4NDAgW2piZF0KT2N0ICAy IDE1OjA5OjQxIChub25lKSBrZXJuZWw6ICBbPGQxODQ4OTlmPl0gam91cm5hbF9zdGFydF9j b21taXQrMHg3Zi8weGEwIFtqYmRdCk9jdCAgMiAxNTowOTo0MSAobm9uZSkga2VybmVsOiAg WzxkMTg4MGM3MD5dIGV4dDNfc3luY19mcysweDAvMHg3MCBbZXh0M10KT2N0ICAyIDE1OjA5 OjQxIChub25lKSBrZXJuZWw6ICBbPGQxODgwY2NjPl0gZXh0M19zeW5jX2ZzKzB4NWMvMHg3 MCBbZXh0M10KT2N0ICAyIDE1OjA5OjQxIChub25lKSBrZXJuZWw6ICBbPGMwMTViOGNlPl0g ZnN5bmNfc3VwZXIrMHg5ZS8weGIwCk9jdCAgMiAxNTowOTo0MSAobm9uZSkga2VybmVsOiAg WzxjMDE2MTQ4Nz5dIGRvX3JlbW91bnRfc2IrMHgzNy8weGYwCk9jdCAgMiAxNTowOTo0MSAo bm9uZSkga2VybmVsOiAgWzxjMDE2MTVlNz5dIGRvX2VtZXJnZW5jeV9yZW1vdW50KzB4YTcv MHgxNjAKT2N0ICAyIDE1OjA5OjQxIChub25lKSBrZXJuZWw6ICBbPGMwMTQyNGRhPl0gX19w ZGZsdXNoKzB4ZGEvMHgxZjAKT2N0ICAyIDE1OjA5OjQxIChub25lKSBrZXJuZWw6ICBbPGMw MTQyNWYwPl0gcGRmbHVzaCsweDAvMHgyMApPY3QgIDIgMTU6MDk6NDEgKG5vbmUpIGtlcm5l bDogIFs8YzAxNDI1ZmY+XSBwZGZsdXNoKzB4Zi8weDIwCk9jdCAgMiAxNTowOTo0MSAobm9u ZSkga2VybmVsOiAgWzxjMDE2MTU0MD5dIGRvX2VtZXJnZW5jeV9yZW1vdW50KzB4MC8weDE2 MApPY3QgIDIgMTU6MDk6NDEgKG5vbmUpIGtlcm5lbDogIFs8YzAxMDcyNTA+XSBrZXJuZWxf dGhyZWFkX2hlbHBlcisweDAvMHgxMApPY3QgIDIgMTU6MDk6NDEgKG5vbmUpIGtlcm5lbDog IFs8YzAxMDcyNTU+XSBrZXJuZWxfdGhyZWFkX2hlbHBlcisweDUvMHgxMApPY3QgIDIgMTU6 MDk6NDEgKG5vbmUpIGtlcm5lbDogCk9jdCAgMiAxNTowOTo0MSAobm9uZSkga2VybmVsOiBi YWQ6IHNjaGVkdWxpbmcgd2hpbGUgYXRvbWljIQpPY3QgIDIgMTU6MDk6NDEgKG5vbmUpIGtl cm5lbDogQ2FsbCBUcmFjZToKT2N0ICAyIDE1OjA5OjQxIChub25lKSBrZXJuZWw6ICBbPGMw MTFlNmU2Pl0gc2NoZWR1bGUrMHg0MDYvMHg0NDAKT2N0ICAyIDE1OjA5OjQxIChub25lKSBr ZXJuZWw6ICBbPGQxODc3MjYwPl0gYnB1dF9vbmUrMHgwLzB4MTAgW2V4dDNdCk9jdCAgMiAx NTowOTo0MSAobm9uZSkga2VybmVsOiAgWzxkMTg0M2MxNz5dIGpvdXJuYWxfc3RvcCsweDFm Ny8weDJlMCBbamJkXQpPY3QgIDIgMTU6MDk6NDEgKG5vbmUpIGtlcm5lbDogIFs8ZDE4NDI1 NDk+XSBqb3VybmFsX3N0YXJ0KzB4YTkvMHhkMCBbamJkXQpPY3QgIDIgMTU6MDk6NDEgKG5v bmUpIGtlcm5lbDogIFs8ZDE4NDNkMzI+XSBqb3VybmFsX2ZvcmNlX2NvbW1pdCsweDMyLzB4 NDAgW2piZF0KT2N0ICAyIDE1OjA5OjQxIChub25lKSBrZXJuZWw6ICBbPGQxODgwYzM5Pl0g ZXh0M19mb3JjZV9jb21taXQrMHgyOS8weDMwIFtleHQzXQpPY3QgIDIgMTU6MDk6NDEgKG5v bmUpIGtlcm5lbDogIFs8YzAxN2JlMDM+XSB3cml0ZV9pbm9kZSsweDQzLzB4NTAKT2N0ICAy IDE1OjA5OjQxIChub25lKSBrZXJuZWw6ICBbPGMwMTdiZjYwPl0gX19zeW5jX3NpbmdsZV9p bm9kZSsweDE1MC8weDI0MApPY3QgIDIgMTU6MDk6NDEgKG5vbmUpIGtlcm5lbDogIFs8YzAx N2MyOGU+XSBzeW5jX3NiX2lub2RlcysweDE3ZS8weDJhMApPY3QgIDIgMTU6MDk6NDEgKG5v bmUpIGtlcm5lbDogIFs8YzAxN2M0ZTQ+XSBzeW5jX2lub2Rlc19zYisweDg0LzB4YTAKT2N0 ICAyIDE1OjA5OjQxIChub25lKSBrZXJuZWw6ICBbPGQxODgwYzcwPl0gZXh0M19zeW5jX2Zz KzB4MC8weDcwIFtleHQzXQpPY3QgIDIgMTU6MDk6NDEgKG5vbmUpIGtlcm5lbDogIFs8YzAx NWI4YWE+XSBmc3luY19zdXBlcisweDdhLzB4YjAKT2N0ICAyIDE1OjA5OjQxIChub25lKSBr ZXJuZWw6ICBbPGMwMTYxNDg3Pl0gZG9fcmVtb3VudF9zYisweDM3LzB4ZjAKT2N0ICAyIDE1 OjA5OjQxIChub25lKSBrZXJuZWw6ICBbPGMwMTYxNWU3Pl0gZG9fZW1lcmdlbmN5X3JlbW91 bnQrMHhhNy8weDE2MApPY3QgIDIgMTU6MDk6NDEgKG5vbmUpIGtlcm5lbDogIFs8YzAxNDI0 ZGE+XSBfX3BkZmx1c2grMHhkYS8weDFmMApPY3QgIDIgMTU6MDk6NDEgKG5vbmUpIGtlcm5l bDogIFs8YzAxNDI1ZjA+XSBwZGZsdXNoKzB4MC8weDIwCk9jdCAgMiAxNTowOTo0MSAobm9u ZSkga2VybmVsOiAgWzxjMDE0MjVmZj5dIHBkZmx1c2grMHhmLzB4MjAKT2N0ICAyIDE1OjA5 OjQxIChub25lKSBrZXJuZWw6ICBbPGMwMTYxNTQwPl0gZG9fZW1lcmdlbmN5X3JlbW91bnQr MHgwLzB4MTYwCk9jdCAgMiAxNTowOTo0MSAobm9uZSkga2VybmVsOiAgWzxjMDEwNzI1MD5d IGtlcm5lbF90aHJlYWRfaGVscGVyKzB4MC8weDEwCk9jdCAgMiAxNTowOTo0MSAobm9uZSkg a2VybmVsOiAgWzxjMDEwNzI1NT5dIGtlcm5lbF90aHJlYWRfaGVscGVyKzB4NS8weDEwCk9j dCAgMiAxNTowOTo0MSAobm9uZSkga2VybmVsOiAKT2N0ICAyIDE1OjA5OjQxIChub25lKSBr ZXJuZWw6IGJhZDogc2NoZWR1bGluZyB3aGlsZSBhdG9taWMhCk9jdCAgMiAxNTowOTo0MSAo bm9uZSkga2VybmVsOiBDYWxsIFRyYWNlOgpPY3QgIDIgMTU6MDk6NDEgKG5vbmUpIGtlcm5l bDogIFs8YzAxMWU2ZTY+XSBzY2hlZHVsZSsweDQwNi8weDQ0MApPY3QgIDIgMTU6MDk6NDEg KG5vbmUpIGtlcm5lbDogIFs8ZDE4NzcyNjA+XSBicHV0X29uZSsweDAvMHgxMCBbZXh0M10K T2N0ICAyIDE1OjA5OjQxIChub25lKSBrZXJuZWw6ICBbPGQxODQzYzE3Pl0gam91cm5hbF9z dG9wKzB4MWY3LzB4MmUwIFtqYmRdCk9jdCAgMiAxNTowOTo0MSAobm9uZSkga2VybmVsOiAg WzxkMTg0MjU0OT5dIGpvdXJuYWxfc3RhcnQrMHhhOS8weGQwIFtqYmRdCk9jdCAgMiAxNTow OTo0MSAobm9uZSkga2VybmVsOiAgWzxkMTg0M2QzMj5dIGpvdXJuYWxfZm9yY2VfY29tbWl0 KzB4MzIvMHg0MCBbamJkXQpPY3QgIDIgMTU6MDk6NDEgKG5vbmUpIGtlcm5lbDogIFs8ZDE4 ODBjMzk+XSBleHQzX2ZvcmNlX2NvbW1pdCsweDI5LzB4MzAgW2V4dDNdCk9jdCAgMiAxNTow OTo0MSAobm9uZSkga2VybmVsOiAgWzxjMDE3YmUwMz5dIHdyaXRlX2lub2RlKzB4NDMvMHg1 MApPY3QgIDIgMTU6MDk6NDEgKG5vbmUpIGtlcm5lbDogIFs8YzAxN2JmNjA+XSBfX3N5bmNf c2luZ2xlX2lub2RlKzB4MTUwLzB4MjQwCk9jdCAgMiAxNTowOTo0MSAobm9uZSkga2VybmVs OiAgWzxjMDE3YzI4ZT5dIHN5bmNfc2JfaW5vZGVzKzB4MTdlLzB4MmEwCk9jdCAgMiAxNTow OTo0MSAobm9uZSkga2VybmVsOiAgWzxjMDE3YzRlND5dIHN5bmNfaW5vZGVzX3NiKzB4ODQv MHhhMApPY3QgIDIgMTU6MDk6NDEgKG5vbmUpIGtlcm5lbDogIFs8ZDE4ODBjNzA+XSBleHQz X3N5bmNfZnMrMHgwLzB4NzAgW2V4dDNdCk9jdCAgMiAxNTowOTo0MSAobm9uZSkga2VybmVs OiAgWzxjMDE1YjhhYT5dIGZzeW5jX3N1cGVyKzB4N2EvMHhiMApPY3QgIDIgMTU6MDk6NDEg KG5vbmUpIGtlcm5lbDogIFs8YzAxNjE0ODc+XSBkb19yZW1vdW50X3NiKzB4MzcvMHhmMApP Y3QgIDIgMTU6MDk6NDEgKG5vbmUpIGtlcm5lbDogIFs8YzAxNjE1ZTc+XSBkb19lbWVyZ2Vu Y3lfcmVtb3VudCsweGE3LzB4MTYwCk9jdCAgMiAxNTowOTo0MSAobm9uZSkga2VybmVsOiAg WzxjMDE0MjRkYT5dIF9fcGRmbHVzaCsweGRhLzB4MWYwCk9jdCAgMiAxNTowOTo0MSAobm9u ZSkga2VybmVsOiAgWzxjMDE0MjVmMD5dIHBkZmx1c2grMHgwLzB4MjAKT2N0ICAyIDE1OjA5 OjQxIChub25lKSBrZXJuZWw6ICBbPGMwMTQyNWZmPl0gcGRmbHVzaCsweGYvMHgyMApPY3Qg IDIgMTU6MDk6NDEgKG5vbmUpIGtlcm5lbDogIFs8YzAxNjE1NDA+XSBkb19lbWVyZ2VuY3lf cmVtb3VudCsweDAvMHgxNjAKT2N0ICAyIDE1OjA5OjQxIChub25lKSBrZXJuZWw6ICBbPGMw MTA3MjUwPl0ga2VybmVsX3RocmVhZF9oZWxwZXIrMHgwLzB4MTAKT2N0ICAyIDE1OjA5OjQx IChub25lKSBrZXJuZWw6ICBbPGMwMTA3MjU1Pl0ga2VybmVsX3RocmVhZF9oZWxwZXIrMHg1 LzB4MTAKT2N0ICAyIDE1OjA5OjQxIChub25lKSBrZXJuZWw6IApPY3QgIDIgMTU6MDk6NDIg KG5vbmUpIGtlcm5lbDogYmFkOiBzY2hlZHVsaW5nIHdoaWxlIGF0b21pYyEKT2N0ICAyIDE1 OjA5OjQyIChub25lKSBrZXJuZWw6IENhbGwgVHJhY2U6Ck9jdCAgMiAxNTowOTo0MiAobm9u ZSkga2VybmVsOiAgWzxjMDExZTZlNj5dIHNjaGVkdWxlKzB4NDA2LzB4NDQwCk9jdCAgMiAx NTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxkMTg3NzI2MD5dIGJwdXRfb25lKzB4MC8weDEw IFtleHQzXQpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8ZDE4NDNjMTc+XSBq b3VybmFsX3N0b3ArMHgxZjcvMHgyZTAgW2piZF0KT2N0ICAyIDE1OjA5OjQyIChub25lKSBr ZXJuZWw6ICBbPGQxODQyNTQ5Pl0gam91cm5hbF9zdGFydCsweGE5LzB4ZDAgW2piZF0KT2N0 ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGQxODQzZDMyPl0gam91cm5hbF9mb3Jj ZV9jb21taXQrMHgzMi8weDQwIFtqYmRdCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVs OiAgWzxkMTg4MGMzOT5dIGV4dDNfZm9yY2VfY29tbWl0KzB4MjkvMHgzMCBbZXh0M10KT2N0 ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTdiZTAzPl0gd3JpdGVfaW5vZGUr MHg0My8weDUwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE3YmY2MD5d IF9fc3luY19zaW5nbGVfaW5vZGUrMHgxNTAvMHgyNDAKT2N0ICAyIDE1OjA5OjQyIChub25l KSBrZXJuZWw6ICBbPGMwMTdjMjhlPl0gc3luY19zYl9pbm9kZXMrMHgxN2UvMHgyYTAKT2N0 ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTdjNGU0Pl0gc3luY19pbm9kZXNf c2IrMHg4NC8weGEwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxkMTg4MGM3 MD5dIGV4dDNfc3luY19mcysweDAvMHg3MCBbZXh0M10KT2N0ICAyIDE1OjA5OjQyIChub25l KSBrZXJuZWw6ICBbPGMwMTViOGFhPl0gZnN5bmNfc3VwZXIrMHg3YS8weGIwCk9jdCAgMiAx NTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE2MTQ4Nz5dIGRvX3JlbW91bnRfc2IrMHgz Ny8weGYwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE2MTVlNz5dIGRv X2VtZXJnZW5jeV9yZW1vdW50KzB4YTcvMHgxNjAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBr ZXJuZWw6ICBbPGMwMTQyNGRhPl0gX19wZGZsdXNoKzB4ZGEvMHgxZjAKT2N0ICAyIDE1OjA5 OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTQyNWYwPl0gcGRmbHVzaCsweDAvMHgyMApPY3Qg IDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNDI1ZmY+XSBwZGZsdXNoKzB4Zi8w eDIwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE2MTU0MD5dIGRvX2Vt ZXJnZW5jeV9yZW1vdW50KzB4MC8weDE2MApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5l bDogIFs8YzAxMDcyNTA+XSBrZXJuZWxfdGhyZWFkX2hlbHBlcisweDAvMHgxMApPY3QgIDIg MTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxMDcyNTU+XSBrZXJuZWxfdGhyZWFkX2hl bHBlcisweDUvMHgxMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogCk9jdCAgMiAx NTowOTo0MiAobm9uZSkga2VybmVsOiBiYWQ6IHNjaGVkdWxpbmcgd2hpbGUgYXRvbWljIQpP Y3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogQ2FsbCBUcmFjZToKT2N0ICAyIDE1OjA5 OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTFlNmU2Pl0gc2NoZWR1bGUrMHg0MDYvMHg0NDAK T2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGQxODc3MjYwPl0gYnB1dF9vbmUr MHgwLzB4MTAgW2V4dDNdCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxkMTg0 M2MxNz5dIGpvdXJuYWxfc3RvcCsweDFmNy8weDJlMCBbamJkXQpPY3QgIDIgMTU6MDk6NDIg KG5vbmUpIGtlcm5lbDogIFs8ZDE4NDI1NDk+XSBqb3VybmFsX3N0YXJ0KzB4YTkvMHhkMCBb amJkXQpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8ZDE4NDNkMzI+XSBqb3Vy bmFsX2ZvcmNlX2NvbW1pdCsweDMyLzB4NDAgW2piZF0KT2N0ICAyIDE1OjA5OjQyIChub25l KSBrZXJuZWw6ICBbPGQxODgwYzM5Pl0gZXh0M19mb3JjZV9jb21taXQrMHgyOS8weDMwIFtl eHQzXQpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxN2JlMDM+XSB3cml0 ZV9pbm9kZSsweDQzLzB4NTAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMw MTdiZjYwPl0gX19zeW5jX3NpbmdsZV9pbm9kZSsweDE1MC8weDI0MApPY3QgIDIgMTU6MDk6 NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxN2MyOGU+XSBzeW5jX3NiX2lub2RlcysweDE3ZS8w eDJhMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxN2M0ZTQ+XSBzeW5j X2lub2Rlc19zYisweDg0LzB4YTAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBb PGQxODgwYzcwPl0gZXh0M19zeW5jX2ZzKzB4MC8weDcwIFtleHQzXQpPY3QgIDIgMTU6MDk6 NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNWI4YWE+XSBmc3luY19zdXBlcisweDdhLzB4YjAK T2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTYxNDg3Pl0gZG9fcmVtb3Vu dF9zYisweDM3LzB4ZjAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTYx NWU3Pl0gZG9fZW1lcmdlbmN5X3JlbW91bnQrMHhhNy8weDE2MApPY3QgIDIgMTU6MDk6NDIg KG5vbmUpIGtlcm5lbDogIFs8YzAxNDI0ZGE+XSBfX3BkZmx1c2grMHhkYS8weDFmMApPY3Qg IDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNDI1ZjA+XSBwZGZsdXNoKzB4MC8w eDIwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE0MjVmZj5dIHBkZmx1 c2grMHhmLzB4MjAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTYxNTQw Pl0gZG9fZW1lcmdlbmN5X3JlbW91bnQrMHgwLzB4MTYwCk9jdCAgMiAxNTowOTo0MiAobm9u ZSkga2VybmVsOiAgWzxjMDEwNzI1MD5dIGtlcm5lbF90aHJlYWRfaGVscGVyKzB4MC8weDEw Ck9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDEwNzI1NT5dIGtlcm5lbF90 aHJlYWRfaGVscGVyKzB4NS8weDEwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAK T2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6IGJhZDogc2NoZWR1bGluZyB3aGlsZSBh dG9taWMhCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiBDYWxsIFRyYWNlOgpPY3Qg IDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxMWU2ZTY+XSBzY2hlZHVsZSsweDQw Ni8weDQ0MApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8ZDE4NzcyNjA+XSBi cHV0X29uZSsweDAvMHgxMCBbZXh0M10KT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6 ICBbPGQxODQzYzE3Pl0gam91cm5hbF9zdG9wKzB4MWY3LzB4MmUwIFtqYmRdCk9jdCAgMiAx NTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxkMTg0MjU0OT5dIGpvdXJuYWxfc3RhcnQrMHhh OS8weGQwIFtqYmRdCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxkMTg0M2Qz Mj5dIGpvdXJuYWxfZm9yY2VfY29tbWl0KzB4MzIvMHg0MCBbamJkXQpPY3QgIDIgMTU6MDk6 NDIgKG5vbmUpIGtlcm5lbDogIFs8ZDE4ODBjMzk+XSBleHQzX2ZvcmNlX2NvbW1pdCsweDI5 LzB4MzAgW2V4dDNdCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE3YmUw Mz5dIHdyaXRlX2lub2RlKzB4NDMvMHg1MApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5l bDogIFs8YzAxN2JmNjA+XSBfX3N5bmNfc2luZ2xlX2lub2RlKzB4MTUwLzB4MjQwCk9jdCAg MiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE3YzI4ZT5dIHN5bmNfc2JfaW5vZGVz KzB4MTdlLzB4MmEwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE3YzRl ND5dIHN5bmNfaW5vZGVzX3NiKzB4ODQvMHhhMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtl cm5lbDogIFs8ZDE4ODBjNzA+XSBleHQzX3N5bmNfZnMrMHgwLzB4NzAgW2V4dDNdCk9jdCAg MiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE1YjhhYT5dIGZzeW5jX3N1cGVyKzB4 N2EvMHhiMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNjE0ODc+XSBk b19yZW1vdW50X3NiKzB4MzcvMHhmMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDog IFs8YzAxNjE1ZTc+XSBkb19lbWVyZ2VuY3lfcmVtb3VudCsweGE3LzB4MTYwCk9jdCAgMiAx NTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE0MjRkYT5dIF9fcGRmbHVzaCsweGRhLzB4 MWYwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE0MjVmMD5dIHBkZmx1 c2grMHgwLzB4MjAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTQyNWZm Pl0gcGRmbHVzaCsweGYvMHgyMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8 YzAxNjE1NDA+XSBkb19lbWVyZ2VuY3lfcmVtb3VudCsweDAvMHgxNjAKT2N0ICAyIDE1OjA5 OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTA3MjUwPl0ga2VybmVsX3RocmVhZF9oZWxwZXIr MHgwLzB4MTAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTA3MjU1Pl0g a2VybmVsX3RocmVhZF9oZWxwZXIrMHg1LzB4MTAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBr ZXJuZWw6IApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogYmFkOiBzY2hlZHVsaW5n IHdoaWxlIGF0b21pYyEKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6IENhbGwgVHJh Y2U6Ck9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDExZTZlNj5dIHNjaGVk dWxlKzB4NDA2LzB4NDQwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxkMTg3 NzI2MD5dIGJwdXRfb25lKzB4MC8weDEwIFtleHQzXQpPY3QgIDIgMTU6MDk6NDIgKG5vbmUp IGtlcm5lbDogIFs8ZDE4NDNjMTc+XSBqb3VybmFsX3N0b3ArMHgxZjcvMHgyZTAgW2piZF0K T2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGQxODQyNTQ5Pl0gam91cm5hbF9z dGFydCsweGE5LzB4ZDAgW2piZF0KT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBb PGQxODQzZDMyPl0gam91cm5hbF9mb3JjZV9jb21taXQrMHgzMi8weDQwIFtqYmRdCk9jdCAg MiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxkMTg4MGMzOT5dIGV4dDNfZm9yY2VfY29t bWl0KzB4MjkvMHgzMCBbZXh0M10KT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBb PGMwMTdiZTAzPl0gd3JpdGVfaW5vZGUrMHg0My8weDUwCk9jdCAgMiAxNTowOTo0MiAobm9u ZSkga2VybmVsOiAgWzxjMDE3YmY2MD5dIF9fc3luY19zaW5nbGVfaW5vZGUrMHgxNTAvMHgy NDAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTdjMjhlPl0gc3luY19z Yl9pbm9kZXMrMHgxN2UvMHgyYTAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBb PGMwMTdjNGU0Pl0gc3luY19pbm9kZXNfc2IrMHg4NC8weGEwCk9jdCAgMiAxNTowOTo0MiAo bm9uZSkga2VybmVsOiAgWzxkMTg4MGM3MD5dIGV4dDNfc3luY19mcysweDAvMHg3MCBbZXh0 M10KT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTViOGFhPl0gZnN5bmNf c3VwZXIrMHg3YS8weGIwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE2 MTQ4Nz5dIGRvX3JlbW91bnRfc2IrMHgzNy8weGYwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkg a2VybmVsOiAgWzxjMDE2MTVlNz5dIGRvX2VtZXJnZW5jeV9yZW1vdW50KzB4YTcvMHgxNjAK T2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTQyNGRhPl0gX19wZGZsdXNo KzB4ZGEvMHgxZjAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTQyNWYw Pl0gcGRmbHVzaCsweDAvMHgyMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8 YzAxNDI1ZmY+XSBwZGZsdXNoKzB4Zi8weDIwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2Vy bmVsOiAgWzxjMDE2MTU0MD5dIGRvX2VtZXJnZW5jeV9yZW1vdW50KzB4MC8weDE2MApPY3Qg IDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxMDcyNTA+XSBrZXJuZWxfdGhyZWFk X2hlbHBlcisweDAvMHgxMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAx MDcyNTU+XSBrZXJuZWxfdGhyZWFkX2hlbHBlcisweDUvMHgxMApPY3QgIDIgMTU6MDk6NDIg KG5vbmUpIGtlcm5lbDogCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiBiYWQ6IHNj aGVkdWxpbmcgd2hpbGUgYXRvbWljIQpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDog Q2FsbCBUcmFjZToKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTFlNmU2 Pl0gc2NoZWR1bGUrMHg0MDYvMHg0NDAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6 ICBbPGQxODc3MjYwPl0gYnB1dF9vbmUrMHgwLzB4MTAgW2V4dDNdCk9jdCAgMiAxNTowOTo0 MiAobm9uZSkga2VybmVsOiAgWzxkMTg0M2MxNz5dIGpvdXJuYWxfc3RvcCsweDFmNy8weDJl MCBbamJkXQpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8ZDE4NDI1NDk+XSBq b3VybmFsX3N0YXJ0KzB4YTkvMHhkMCBbamJkXQpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtl cm5lbDogIFs8ZDE4NDNkMzI+XSBqb3VybmFsX2ZvcmNlX2NvbW1pdCsweDMyLzB4NDAgW2pi ZF0KT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGQxODgwYzM5Pl0gZXh0M19m b3JjZV9jb21taXQrMHgyOS8weDMwIFtleHQzXQpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtl cm5lbDogIFs8YzAxN2JlMDM+XSB3cml0ZV9pbm9kZSsweDQzLzB4NTAKT2N0ICAyIDE1OjA5 OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTdiZjYwPl0gX19zeW5jX3NpbmdsZV9pbm9kZSsw eDE1MC8weDI0MApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxN2MyOGU+ XSBzeW5jX3NiX2lub2RlcysweDE3ZS8weDJhMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtl cm5lbDogIFs8YzAxN2M0ZTQ+XSBzeW5jX2lub2Rlc19zYisweDg0LzB4YTAKT2N0ICAyIDE1 OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGQxODgwYzcwPl0gZXh0M19zeW5jX2ZzKzB4MC8w eDcwIFtleHQzXQpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNWI4YWE+ XSBmc3luY19zdXBlcisweDdhLzB4YjAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6 ICBbPGMwMTYxNDg3Pl0gZG9fcmVtb3VudF9zYisweDM3LzB4ZjAKT2N0ICAyIDE1OjA5OjQy IChub25lKSBrZXJuZWw6ICBbPGMwMTYxNWU3Pl0gZG9fZW1lcmdlbmN5X3JlbW91bnQrMHhh Ny8weDE2MApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNDI0ZGE+XSBf X3BkZmx1c2grMHhkYS8weDFmMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8 YzAxNDI1ZjA+XSBwZGZsdXNoKzB4MC8weDIwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2Vy bmVsOiAgWzxjMDE0MjVmZj5dIHBkZmx1c2grMHhmLzB4MjAKT2N0ICAyIDE1OjA5OjQyIChu b25lKSBrZXJuZWw6ICBbPGMwMTYxNTQwPl0gZG9fZW1lcmdlbmN5X3JlbW91bnQrMHgwLzB4 MTYwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDEwNzI1MD5dIGtlcm5l bF90aHJlYWRfaGVscGVyKzB4MC8weDEwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVs OiAgWzxjMDEwNzI1NT5dIGtlcm5lbF90aHJlYWRfaGVscGVyKzB4NS8weDEwCk9jdCAgMiAx NTowOTo0MiAobm9uZSkga2VybmVsOiAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6 IGJhZDogc2NoZWR1bGluZyB3aGlsZSBhdG9taWMhCk9jdCAgMiAxNTowOTo0MiAobm9uZSkg a2VybmVsOiBDYWxsIFRyYWNlOgpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8 YzAxMWU2ZTY+XSBzY2hlZHVsZSsweDQwNi8weDQ0MApPY3QgIDIgMTU6MDk6NDIgKG5vbmUp IGtlcm5lbDogIFs8ZDE4NzcyNjA+XSBicHV0X29uZSsweDAvMHgxMCBbZXh0M10KT2N0ICAy IDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGQxODQzYzE3Pl0gam91cm5hbF9zdG9wKzB4 MWY3LzB4MmUwIFtqYmRdCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxkMTg0 MjU0OT5dIGpvdXJuYWxfc3RhcnQrMHhhOS8weGQwIFtqYmRdCk9jdCAgMiAxNTowOTo0MiAo bm9uZSkga2VybmVsOiAgWzxkMTg0M2QzMj5dIGpvdXJuYWxfZm9yY2VfY29tbWl0KzB4MzIv MHg0MCBbamJkXQpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8ZDE4ODBjMzk+ XSBleHQzX2ZvcmNlX2NvbW1pdCsweDI5LzB4MzAgW2V4dDNdCk9jdCAgMiAxNTowOTo0MiAo bm9uZSkga2VybmVsOiAgWzxjMDE3YmUwMz5dIHdyaXRlX2lub2RlKzB4NDMvMHg1MApPY3Qg IDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxN2JmNjA+XSBfX3N5bmNfc2luZ2xl X2lub2RlKzB4MTUwLzB4MjQwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxj MDE3YzI4ZT5dIHN5bmNfc2JfaW5vZGVzKzB4MTdlLzB4MmEwCk9jdCAgMiAxNTowOTo0MiAo bm9uZSkga2VybmVsOiAgWzxjMDE3YzRlND5dIHN5bmNfaW5vZGVzX3NiKzB4ODQvMHhhMApP Y3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8ZDE4ODBjNzA+XSBleHQzX3N5bmNf ZnMrMHgwLzB4NzAgW2V4dDNdCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxj MDE1YjhhYT5dIGZzeW5jX3N1cGVyKzB4N2EvMHhiMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUp IGtlcm5lbDogIFs8YzAxNjE0ODc+XSBkb19yZW1vdW50X3NiKzB4MzcvMHhmMApPY3QgIDIg MTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNjE1ZTc+XSBkb19lbWVyZ2VuY3lfcmVt b3VudCsweGE3LzB4MTYwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE0 MjRkYT5dIF9fcGRmbHVzaCsweGRhLzB4MWYwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2Vy bmVsOiAgWzxjMDE0MjVmMD5dIHBkZmx1c2grMHgwLzB4MjAKT2N0ICAyIDE1OjA5OjQyIChu b25lKSBrZXJuZWw6ICBbPGMwMTQyNWZmPl0gcGRmbHVzaCsweGYvMHgyMApPY3QgIDIgMTU6 MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNjE1NDA+XSBkb19lbWVyZ2VuY3lfcmVtb3Vu dCsweDAvMHgxNjAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTA3MjUw Pl0ga2VybmVsX3RocmVhZF9oZWxwZXIrMHgwLzB4MTAKT2N0ICAyIDE1OjA5OjQyIChub25l KSBrZXJuZWw6ICBbPGMwMTA3MjU1Pl0ga2VybmVsX3RocmVhZF9oZWxwZXIrMHg1LzB4MTAK T2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6IApPY3QgIDIgMTU6MDk6NDIgKG5vbmUp IGtlcm5lbDogYmFkOiBzY2hlZHVsaW5nIHdoaWxlIGF0b21pYyEKT2N0ICAyIDE1OjA5OjQy IChub25lKSBrZXJuZWw6IENhbGwgVHJhY2U6Ck9jdCAgMiAxNTowOTo0MiAobm9uZSkga2Vy bmVsOiAgWzxjMDExZTZlNj5dIHNjaGVkdWxlKzB4NDA2LzB4NDQwCk9jdCAgMiAxNTowOTo0 MiAobm9uZSkga2VybmVsOiAgWzxkMTg3NzI2MD5dIGJwdXRfb25lKzB4MC8weDEwIFtleHQz XQpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8ZDE4NDNjMTc+XSBqb3VybmFs X3N0b3ArMHgxZjcvMHgyZTAgW2piZF0KT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6 ICBbPGQxODQyNTQ5Pl0gam91cm5hbF9zdGFydCsweGE5LzB4ZDAgW2piZF0KT2N0ICAyIDE1 OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGQxODQzZDMyPl0gam91cm5hbF9mb3JjZV9jb21t aXQrMHgzMi8weDQwIFtqYmRdCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxk MTg4MGMzOT5dIGV4dDNfZm9yY2VfY29tbWl0KzB4MjkvMHgzMCBbZXh0M10KT2N0ICAyIDE1 OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTdiZTAzPl0gd3JpdGVfaW5vZGUrMHg0My8w eDUwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE3YmY2MD5dIF9fc3lu Y19zaW5nbGVfaW5vZGUrMHgxNTAvMHgyNDAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJu ZWw6ICBbPGMwMTdjMjhlPl0gc3luY19zYl9pbm9kZXMrMHgxN2UvMHgyYTAKT2N0ICAyIDE1 OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTdjNGU0Pl0gc3luY19pbm9kZXNfc2IrMHg4 NC8weGEwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxkMTg4MGM3MD5dIGV4 dDNfc3luY19mcysweDAvMHg3MCBbZXh0M10KT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJu ZWw6ICBbPGMwMTViOGFhPl0gZnN5bmNfc3VwZXIrMHg3YS8weGIwCk9jdCAgMiAxNTowOTo0 MiAobm9uZSkga2VybmVsOiAgWzxjMDE2MTQ4Nz5dIGRvX3JlbW91bnRfc2IrMHgzNy8weGYw Ck9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE2MTVlNz5dIGRvX2VtZXJn ZW5jeV9yZW1vdW50KzB4YTcvMHgxNjAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6 ICBbPGMwMTQyNGRhPl0gX19wZGZsdXNoKzB4ZGEvMHgxZjAKT2N0ICAyIDE1OjA5OjQyIChu b25lKSBrZXJuZWw6ICBbPGMwMTQyNWYwPl0gcGRmbHVzaCsweDAvMHgyMApPY3QgIDIgMTU6 MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNDI1ZmY+XSBwZGZsdXNoKzB4Zi8weDIwCk9j dCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE2MTU0MD5dIGRvX2VtZXJnZW5j eV9yZW1vdW50KzB4MC8weDE2MApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8 YzAxMDcyNTA+XSBrZXJuZWxfdGhyZWFkX2hlbHBlcisweDAvMHgxMApPY3QgIDIgMTU6MDk6 NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxMDcyNTU+XSBrZXJuZWxfdGhyZWFkX2hlbHBlcisw eDUvMHgxMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogCk9jdCAgMiAxNTowOTo0 MiAobm9uZSkga2VybmVsOiBiYWQ6IHNjaGVkdWxpbmcgd2hpbGUgYXRvbWljIQpPY3QgIDIg MTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogQ2FsbCBUcmFjZToKT2N0ICAyIDE1OjA5OjQyIChu b25lKSBrZXJuZWw6ICBbPGMwMTFlNmU2Pl0gc2NoZWR1bGUrMHg0MDYvMHg0NDAKT2N0ICAy IDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGQxODc3MjYwPl0gYnB1dF9vbmUrMHgwLzB4 MTAgW2V4dDNdCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxkMTg0M2MxNz5d IGpvdXJuYWxfc3RvcCsweDFmNy8weDJlMCBbamJkXQpPY3QgIDIgMTU6MDk6NDIgKG5vbmUp IGtlcm5lbDogIFs8ZDE4NDI1NDk+XSBqb3VybmFsX3N0YXJ0KzB4YTkvMHhkMCBbamJkXQpP Y3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8ZDE4NDNkMzI+XSBqb3VybmFsX2Zv cmNlX2NvbW1pdCsweDMyLzB4NDAgW2piZF0KT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJu ZWw6ICBbPGQxODgwYzM5Pl0gZXh0M19mb3JjZV9jb21taXQrMHgyOS8weDMwIFtleHQzXQpP Y3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxN2JlMDM+XSB3cml0ZV9pbm9k ZSsweDQzLzB4NTAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTdiZjYw Pl0gX19zeW5jX3NpbmdsZV9pbm9kZSsweDE1MC8weDI0MApPY3QgIDIgMTU6MDk6NDIgKG5v bmUpIGtlcm5lbDogIFs8YzAxN2MyOGU+XSBzeW5jX3NiX2lub2RlcysweDE3ZS8weDJhMApP Y3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxN2M0ZTQ+XSBzeW5jX2lub2Rl c19zYisweDg0LzB4YTAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGQxODgw YzcwPl0gZXh0M19zeW5jX2ZzKzB4MC8weDcwIFtleHQzXQpPY3QgIDIgMTU6MDk6NDIgKG5v bmUpIGtlcm5lbDogIFs8YzAxNWI4YWE+XSBmc3luY19zdXBlcisweDdhLzB4YjAKT2N0ICAy IDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTYxNDg3Pl0gZG9fcmVtb3VudF9zYisw eDM3LzB4ZjAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTYxNWU3Pl0g ZG9fZW1lcmdlbmN5X3JlbW91bnQrMHhhNy8weDE2MApPY3QgIDIgMTU6MDk6NDIgKG5vbmUp IGtlcm5lbDogIFs8YzAxNDI0ZGE+XSBfX3BkZmx1c2grMHhkYS8weDFmMApPY3QgIDIgMTU6 MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNDI1ZjA+XSBwZGZsdXNoKzB4MC8weDIwCk9j dCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE0MjVmZj5dIHBkZmx1c2grMHhm LzB4MjAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTYxNTQwPl0gZG9f ZW1lcmdlbmN5X3JlbW91bnQrMHgwLzB4MTYwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2Vy bmVsOiAgWzxjMDEwNzI1MD5dIGtlcm5lbF90aHJlYWRfaGVscGVyKzB4MC8weDEwCk9jdCAg MiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDEwNzI1NT5dIGtlcm5lbF90aHJlYWRf aGVscGVyKzB4NS8weDEwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAKT2N0ICAy IDE1OjA5OjQyIChub25lKSBrZXJuZWw6IGJhZDogc2NoZWR1bGluZyB3aGlsZSBhdG9taWMh Ck9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiBDYWxsIFRyYWNlOgpPY3QgIDIgMTU6 MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxMWU2ZTY+XSBzY2hlZHVsZSsweDQwNi8weDQ0 MApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8ZDE4NzcyNjA+XSBicHV0X29u ZSsweDAvMHgxMCBbZXh0M10KT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGQx ODQzYzE3Pl0gam91cm5hbF9zdG9wKzB4MWY3LzB4MmUwIFtqYmRdCk9jdCAgMiAxNTowOTo0 MiAobm9uZSkga2VybmVsOiAgWzxkMTg0MjU0OT5dIGpvdXJuYWxfc3RhcnQrMHhhOS8weGQw IFtqYmRdCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxkMTg0M2QzMj5dIGpv dXJuYWxfZm9yY2VfY29tbWl0KzB4MzIvMHg0MCBbamJkXQpPY3QgIDIgMTU6MDk6NDIgKG5v bmUpIGtlcm5lbDogIFs8ZDE4ODBjMzk+XSBleHQzX2ZvcmNlX2NvbW1pdCsweDI5LzB4MzAg W2V4dDNdCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE3YmUwMz5dIHdy aXRlX2lub2RlKzB4NDMvMHg1MApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8 YzAxN2JmNjA+XSBfX3N5bmNfc2luZ2xlX2lub2RlKzB4MTUwLzB4MjQwCk9jdCAgMiAxNTow OTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE3YzI4ZT5dIHN5bmNfc2JfaW5vZGVzKzB4MTdl LzB4MmEwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE3YzRlND5dIHN5 bmNfaW5vZGVzX3NiKzB4ODQvMHhhMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDog IFs8ZDE4ODBjNzA+XSBleHQzX3N5bmNfZnMrMHgwLzB4NzAgW2V4dDNdCk9jdCAgMiAxNTow OTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE1YjhhYT5dIGZzeW5jX3N1cGVyKzB4N2EvMHhi MApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNjE0ODc+XSBkb19yZW1v dW50X3NiKzB4MzcvMHhmMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAx NjE1ZTc+XSBkb19lbWVyZ2VuY3lfcmVtb3VudCsweGE3LzB4MTYwCk9jdCAgMiAxNTowOTo0 MiAobm9uZSkga2VybmVsOiAgWzxjMDE0MjRkYT5dIF9fcGRmbHVzaCsweGRhLzB4MWYwCk9j dCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE0MjVmMD5dIHBkZmx1c2grMHgw LzB4MjAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTQyNWZmPl0gcGRm bHVzaCsweGYvMHgyMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNjE1 NDA+XSBkb19lbWVyZ2VuY3lfcmVtb3VudCsweDAvMHgxNjAKT2N0ICAyIDE1OjA5OjQyIChu b25lKSBrZXJuZWw6ICBbPGMwMTA3MjUwPl0ga2VybmVsX3RocmVhZF9oZWxwZXIrMHgwLzB4 MTAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTA3MjU1Pl0ga2VybmVs X3RocmVhZF9oZWxwZXIrMHg1LzB4MTAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6 IApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogYmFkOiBzY2hlZHVsaW5nIHdoaWxl IGF0b21pYyEKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6IENhbGwgVHJhY2U6Ck9j dCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDExZTZlNj5dIHNjaGVkdWxlKzB4 NDA2LzB4NDQwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxkMTg3NzI2MD5d IGJwdXRfb25lKzB4MC8weDEwIFtleHQzXQpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5l bDogIFs8ZDE4NDNjMTc+XSBqb3VybmFsX3N0b3ArMHgxZjcvMHgyZTAgW2piZF0KT2N0ICAy IDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGQxODQyNTQ5Pl0gam91cm5hbF9zdGFydCsw eGE5LzB4ZDAgW2piZF0KT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGQxODQz ZDMyPl0gam91cm5hbF9mb3JjZV9jb21taXQrMHgzMi8weDQwIFtqYmRdCk9jdCAgMiAxNTow OTo0MiAobm9uZSkga2VybmVsOiAgWzxkMTg4MGMzOT5dIGV4dDNfZm9yY2VfY29tbWl0KzB4 MjkvMHgzMCBbZXh0M10KT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTdi ZTAzPl0gd3JpdGVfaW5vZGUrMHg0My8weDUwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2Vy bmVsOiAgWzxjMDE3YmY2MD5dIF9fc3luY19zaW5nbGVfaW5vZGUrMHgxNTAvMHgyNDAKT2N0 ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTdjMjhlPl0gc3luY19zYl9pbm9k ZXMrMHgxN2UvMHgyYTAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTdj NGU0Pl0gc3luY19pbm9kZXNfc2IrMHg4NC8weGEwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkg a2VybmVsOiAgWzxkMTg4MGM3MD5dIGV4dDNfc3luY19mcysweDAvMHg3MCBbZXh0M10KT2N0 ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTViOGFhPl0gZnN5bmNfc3VwZXIr MHg3YS8weGIwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE2MTQ4Nz5d IGRvX3JlbW91bnRfc2IrMHgzNy8weGYwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVs OiAgWzxjMDE2MTVlNz5dIGRvX2VtZXJnZW5jeV9yZW1vdW50KzB4YTcvMHgxNjAKT2N0ICAy IDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTQyNGRhPl0gX19wZGZsdXNoKzB4ZGEv MHgxZjAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTQyNWYwPl0gcGRm bHVzaCsweDAvMHgyMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNDI1 ZmY+XSBwZGZsdXNoKzB4Zi8weDIwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAg WzxjMDE2MTU0MD5dIGRvX2VtZXJnZW5jeV9yZW1vdW50KzB4MC8weDE2MApPY3QgIDIgMTU6 MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxMDcyNTA+XSBrZXJuZWxfdGhyZWFkX2hlbHBl cisweDAvMHgxMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxMDcyNTU+ XSBrZXJuZWxfdGhyZWFkX2hlbHBlcisweDUvMHgxMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUp IGtlcm5lbDogCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiBiYWQ6IHNjaGVkdWxp bmcgd2hpbGUgYXRvbWljIQpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogQ2FsbCBU cmFjZToKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTFlNmU2Pl0gc2No ZWR1bGUrMHg0MDYvMHg0NDAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGQx ODc3MjYwPl0gYnB1dF9vbmUrMHgwLzB4MTAgW2V4dDNdCk9jdCAgMiAxNTowOTo0MiAobm9u ZSkga2VybmVsOiAgWzxkMTg0M2MxNz5dIGpvdXJuYWxfc3RvcCsweDFmNy8weDJlMCBbamJk XQpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8ZDE4NDI1NDk+XSBqb3VybmFs X3N0YXJ0KzB4YTkvMHhkMCBbamJkXQpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDog IFs8ZDE4NDNkMzI+XSBqb3VybmFsX2ZvcmNlX2NvbW1pdCsweDMyLzB4NDAgW2piZF0KT2N0 ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGQxODgwYzM5Pl0gZXh0M19mb3JjZV9j b21taXQrMHgyOS8weDMwIFtleHQzXQpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDog IFs8YzAxN2JlMDM+XSB3cml0ZV9pbm9kZSsweDQzLzB4NTAKT2N0ICAyIDE1OjA5OjQyIChu b25lKSBrZXJuZWw6ICBbPGMwMTdiZjYwPl0gX19zeW5jX3NpbmdsZV9pbm9kZSsweDE1MC8w eDI0MApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxN2MyOGU+XSBzeW5j X3NiX2lub2RlcysweDE3ZS8weDJhMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDog IFs8YzAxN2M0ZTQ+XSBzeW5jX2lub2Rlc19zYisweDg0LzB4YTAKT2N0ICAyIDE1OjA5OjQy IChub25lKSBrZXJuZWw6ICBbPGQxODgwYzcwPl0gZXh0M19zeW5jX2ZzKzB4MC8weDcwIFtl eHQzXQpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNWI4YWE+XSBmc3lu Y19zdXBlcisweDdhLzB4YjAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMw MTYxNDg3Pl0gZG9fcmVtb3VudF9zYisweDM3LzB4ZjAKT2N0ICAyIDE1OjA5OjQyIChub25l KSBrZXJuZWw6ICBbPGMwMTYxNWU3Pl0gZG9fZW1lcmdlbmN5X3JlbW91bnQrMHhhNy8weDE2 MApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNDI0ZGE+XSBfX3BkZmx1 c2grMHhkYS8weDFmMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNDI1 ZjA+XSBwZGZsdXNoKzB4MC8weDIwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAg WzxjMDE0MjVmZj5dIHBkZmx1c2grMHhmLzB4MjAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBr ZXJuZWw6ICBbPGMwMTYxNTQwPl0gZG9fZW1lcmdlbmN5X3JlbW91bnQrMHgwLzB4MTYwCk9j dCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDEwNzI1MD5dIGtlcm5lbF90aHJl YWRfaGVscGVyKzB4MC8weDEwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxj MDEwNzI1NT5dIGtlcm5lbF90aHJlYWRfaGVscGVyKzB4NS8weDEwCk9jdCAgMiAxNTowOTo0 MiAobm9uZSkga2VybmVsOiAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6IGJhZDog c2NoZWR1bGluZyB3aGlsZSBhdG9taWMhCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVs OiBDYWxsIFRyYWNlOgpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxMWU2 ZTY+XSBzY2hlZHVsZSsweDQwNi8weDQ0MApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5l bDogIFs8ZDE4NzcyNjA+XSBicHV0X29uZSsweDAvMHgxMCBbZXh0M10KT2N0ICAyIDE1OjA5 OjQyIChub25lKSBrZXJuZWw6ICBbPGQxODQzYzE3Pl0gam91cm5hbF9zdG9wKzB4MWY3LzB4 MmUwIFtqYmRdCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxkMTg0MjU0OT5d IGpvdXJuYWxfc3RhcnQrMHhhOS8weGQwIFtqYmRdCk9jdCAgMiAxNTowOTo0MiAobm9uZSkg a2VybmVsOiAgWzxkMTg0M2QzMj5dIGpvdXJuYWxfZm9yY2VfY29tbWl0KzB4MzIvMHg0MCBb amJkXQpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8ZDE4ODBjMzk+XSBleHQz X2ZvcmNlX2NvbW1pdCsweDI5LzB4MzAgW2V4dDNdCk9jdCAgMiAxNTowOTo0MiAobm9uZSkg a2VybmVsOiAgWzxjMDE3YmUwMz5dIHdyaXRlX2lub2RlKzB4NDMvMHg1MApPY3QgIDIgMTU6 MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxN2JmNjA+XSBfX3N5bmNfc2luZ2xlX2lub2Rl KzB4MTUwLzB4MjQwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE3YzI4 ZT5dIHN5bmNfc2JfaW5vZGVzKzB4MTdlLzB4MmEwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkg a2VybmVsOiAgWzxjMDE3YzRlND5dIHN5bmNfaW5vZGVzX3NiKzB4ODQvMHhhMApPY3QgIDIg MTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8ZDE4ODBjNzA+XSBleHQzX3N5bmNfZnMrMHgw LzB4NzAgW2V4dDNdCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE1Yjhh YT5dIGZzeW5jX3N1cGVyKzB4N2EvMHhiMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5l bDogIFs8YzAxNjE0ODc+XSBkb19yZW1vdW50X3NiKzB4MzcvMHhmMApPY3QgIDIgMTU6MDk6 NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNjE1ZTc+XSBkb19lbWVyZ2VuY3lfcmVtb3VudCsw eGE3LzB4MTYwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE0MjRkYT5d IF9fcGRmbHVzaCsweGRhLzB4MWYwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAg WzxjMDE0MjVmMD5dIHBkZmx1c2grMHgwLzB4MjAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBr ZXJuZWw6ICBbPGMwMTQyNWZmPl0gcGRmbHVzaCsweGYvMHgyMApPY3QgIDIgMTU6MDk6NDIg KG5vbmUpIGtlcm5lbDogIFs8YzAxNjE1NDA+XSBkb19lbWVyZ2VuY3lfcmVtb3VudCsweDAv MHgxNjAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTA3MjUwPl0ga2Vy bmVsX3RocmVhZF9oZWxwZXIrMHgwLzB4MTAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJu ZWw6ICBbPGMwMTA3MjU1Pl0ga2VybmVsX3RocmVhZF9oZWxwZXIrMHg1LzB4MTAKT2N0ICAy IDE1OjA5OjQyIChub25lKSBrZXJuZWw6IApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5l bDogYmFkOiBzY2hlZHVsaW5nIHdoaWxlIGF0b21pYyEKT2N0ICAyIDE1OjA5OjQyIChub25l KSBrZXJuZWw6IENhbGwgVHJhY2U6Ck9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAg WzxjMDExZTZlNj5dIHNjaGVkdWxlKzB4NDA2LzB4NDQwCk9jdCAgMiAxNTowOTo0MiAobm9u ZSkga2VybmVsOiAgWzxkMTg0OGE3OD5dIGxvZ193YWl0X2NvbW1pdCsweGI4LzB4MTQwIFtq YmRdCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDExZTc3MD5dIGRlZmF1 bHRfd2FrZV9mdW5jdGlvbisweDAvMHgzMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5l bDogIFs8ZDE4NDNjZDA+XSBqb3VybmFsX3N0b3ArMHgyYjAvMHgyZTAgW2piZF0KT2N0ICAy IDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGQxODQyNTQ5Pl0gam91cm5hbF9zdGFydCsw eGE5LzB4ZDAgW2piZF0KT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGQxODQz ZDMyPl0gam91cm5hbF9mb3JjZV9jb21taXQrMHgzMi8weDQwIFtqYmRdCk9jdCAgMiAxNTow OTo0MiAobm9uZSkga2VybmVsOiAgWzxkMTg4MGMzOT5dIGV4dDNfZm9yY2VfY29tbWl0KzB4 MjkvMHgzMCBbZXh0M10KT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTdi ZTAzPl0gd3JpdGVfaW5vZGUrMHg0My8weDUwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2Vy bmVsOiAgWzxjMDE3YmY2MD5dIF9fc3luY19zaW5nbGVfaW5vZGUrMHgxNTAvMHgyNDAKT2N0 ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTdjMjhlPl0gc3luY19zYl9pbm9k ZXMrMHgxN2UvMHgyYTAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTdj NGU0Pl0gc3luY19pbm9kZXNfc2IrMHg4NC8weGEwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkg a2VybmVsOiAgWzxkMTg4MGM3MD5dIGV4dDNfc3luY19mcysweDAvMHg3MCBbZXh0M10KT2N0 ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTViOGFhPl0gZnN5bmNfc3VwZXIr MHg3YS8weGIwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE2MTQ4Nz5d IGRvX3JlbW91bnRfc2IrMHgzNy8weGYwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVs OiAgWzxjMDE2MTVlNz5dIGRvX2VtZXJnZW5jeV9yZW1vdW50KzB4YTcvMHgxNjAKT2N0ICAy IDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTQyNGRhPl0gX19wZGZsdXNoKzB4ZGEv MHgxZjAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTQyNWYwPl0gcGRm bHVzaCsweDAvMHgyMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNDI1 ZmY+XSBwZGZsdXNoKzB4Zi8weDIwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAg WzxjMDE2MTU0MD5dIGRvX2VtZXJnZW5jeV9yZW1vdW50KzB4MC8weDE2MApPY3QgIDIgMTU6 MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxMDcyNTA+XSBrZXJuZWxfdGhyZWFkX2hlbHBl cisweDAvMHgxMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxMDcyNTU+ XSBrZXJuZWxfdGhyZWFkX2hlbHBlcisweDUvMHgxMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUp IGtlcm5lbDogCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiBiYWQ6IHNjaGVkdWxp bmcgd2hpbGUgYXRvbWljIQpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogQ2FsbCBU cmFjZToKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTFlNmU2Pl0gc2No ZWR1bGUrMHg0MDYvMHg0NDAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGQx ODc3MjYwPl0gYnB1dF9vbmUrMHgwLzB4MTAgW2V4dDNdCk9jdCAgMiAxNTowOTo0MiAobm9u ZSkga2VybmVsOiAgWzxkMTg0M2MxNz5dIGpvdXJuYWxfc3RvcCsweDFmNy8weDJlMCBbamJk XQpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8ZDE4NDI1NDk+XSBqb3VybmFs X3N0YXJ0KzB4YTkvMHhkMCBbamJkXQpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDog IFs8ZDE4NDNkMzI+XSBqb3VybmFsX2ZvcmNlX2NvbW1pdCsweDMyLzB4NDAgW2piZF0KT2N0 ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGQxODgwYzM5Pl0gZXh0M19mb3JjZV9j b21taXQrMHgyOS8weDMwIFtleHQzXQpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDog IFs8YzAxN2JlMDM+XSB3cml0ZV9pbm9kZSsweDQzLzB4NTAKT2N0ICAyIDE1OjA5OjQyIChu b25lKSBrZXJuZWw6ICBbPGMwMTdiZjYwPl0gX19zeW5jX3NpbmdsZV9pbm9kZSsweDE1MC8w eDI0MApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxN2MyOGU+XSBzeW5j X3NiX2lub2RlcysweDE3ZS8weDJhMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDog IFs8YzAxN2M0ZTQ+XSBzeW5jX2lub2Rlc19zYisweDg0LzB4YTAKT2N0ICAyIDE1OjA5OjQy IChub25lKSBrZXJuZWw6ICBbPGQxODgwYzcwPl0gZXh0M19zeW5jX2ZzKzB4MC8weDcwIFtl eHQzXQpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNWI4YWE+XSBmc3lu Y19zdXBlcisweDdhLzB4YjAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMw MTYxNDg3Pl0gZG9fcmVtb3VudF9zYisweDM3LzB4ZjAKT2N0ICAyIDE1OjA5OjQyIChub25l KSBrZXJuZWw6ICBbPGMwMTYxNWU3Pl0gZG9fZW1lcmdlbmN5X3JlbW91bnQrMHhhNy8weDE2 MApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNDI0ZGE+XSBfX3BkZmx1 c2grMHhkYS8weDFmMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNDI1 ZjA+XSBwZGZsdXNoKzB4MC8weDIwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAg WzxjMDE0MjVmZj5dIHBkZmx1c2grMHhmLzB4MjAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBr ZXJuZWw6ICBbPGMwMTYxNTQwPl0gZG9fZW1lcmdlbmN5X3JlbW91bnQrMHgwLzB4MTYwCk9j dCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDEwNzI1MD5dIGtlcm5lbF90aHJl YWRfaGVscGVyKzB4MC8weDEwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxj MDEwNzI1NT5dIGtlcm5lbF90aHJlYWRfaGVscGVyKzB4NS8weDEwCk9jdCAgMiAxNTowOTo0 MiAobm9uZSkga2VybmVsOiAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6IGJhZDog c2NoZWR1bGluZyB3aGlsZSBhdG9taWMhCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVs OiBDYWxsIFRyYWNlOgpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxMWU2 ZTY+XSBzY2hlZHVsZSsweDQwNi8weDQ0MApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5l bDogIFs8ZDE4NzcyNjA+XSBicHV0X29uZSsweDAvMHgxMCBbZXh0M10KT2N0ICAyIDE1OjA5 OjQyIChub25lKSBrZXJuZWw6ICBbPGQxODQzYzE3Pl0gam91cm5hbF9zdG9wKzB4MWY3LzB4 MmUwIFtqYmRdCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxkMTg0MjU0OT5d IGpvdXJuYWxfc3RhcnQrMHhhOS8weGQwIFtqYmRdCk9jdCAgMiAxNTowOTo0MiAobm9uZSkg a2VybmVsOiAgWzxkMTg0M2QzMj5dIGpvdXJuYWxfZm9yY2VfY29tbWl0KzB4MzIvMHg0MCBb amJkXQpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8ZDE4ODBjMzk+XSBleHQz X2ZvcmNlX2NvbW1pdCsweDI5LzB4MzAgW2V4dDNdCk9jdCAgMiAxNTowOTo0MiAobm9uZSkg a2VybmVsOiAgWzxjMDE3YmUwMz5dIHdyaXRlX2lub2RlKzB4NDMvMHg1MApPY3QgIDIgMTU6 MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxN2JmNjA+XSBfX3N5bmNfc2luZ2xlX2lub2Rl KzB4MTUwLzB4MjQwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE3YzI4 ZT5dIHN5bmNfc2JfaW5vZGVzKzB4MTdlLzB4MmEwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkg a2VybmVsOiAgWzxjMDE3YzRlND5dIHN5bmNfaW5vZGVzX3NiKzB4ODQvMHhhMApPY3QgIDIg MTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8ZDE4ODBjNzA+XSBleHQzX3N5bmNfZnMrMHgw LzB4NzAgW2V4dDNdCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE1Yjhh YT5dIGZzeW5jX3N1cGVyKzB4N2EvMHhiMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5l bDogIFs8YzAxNjE0ODc+XSBkb19yZW1vdW50X3NiKzB4MzcvMHhmMApPY3QgIDIgMTU6MDk6 NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNjE1ZTc+XSBkb19lbWVyZ2VuY3lfcmVtb3VudCsw eGE3LzB4MTYwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE0MjRkYT5d IF9fcGRmbHVzaCsweGRhLzB4MWYwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAg WzxjMDE0MjVmMD5dIHBkZmx1c2grMHgwLzB4MjAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBr ZXJuZWw6ICBbPGMwMTQyNWZmPl0gcGRmbHVzaCsweGYvMHgyMApPY3QgIDIgMTU6MDk6NDIg KG5vbmUpIGtlcm5lbDogIFs8YzAxNjE1NDA+XSBkb19lbWVyZ2VuY3lfcmVtb3VudCsweDAv MHgxNjAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTA3MjUwPl0ga2Vy bmVsX3RocmVhZF9oZWxwZXIrMHgwLzB4MTAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJu ZWw6ICBbPGMwMTA3MjU1Pl0ga2VybmVsX3RocmVhZF9oZWxwZXIrMHg1LzB4MTAKT2N0ICAy IDE1OjA5OjQyIChub25lKSBrZXJuZWw6IApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5l bDogYmFkOiBzY2hlZHVsaW5nIHdoaWxlIGF0b21pYyEKT2N0ICAyIDE1OjA5OjQyIChub25l KSBrZXJuZWw6IENhbGwgVHJhY2U6Ck9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAg WzxjMDExZTZlNj5dIHNjaGVkdWxlKzB4NDA2LzB4NDQwCk9jdCAgMiAxNTowOTo0MiAobm9u ZSkga2VybmVsOiAgWzxkMTg3NzI2MD5dIGJwdXRfb25lKzB4MC8weDEwIFtleHQzXQpPY3Qg IDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8ZDE4NDNjMTc+XSBqb3VybmFsX3N0b3Ar MHgxZjcvMHgyZTAgW2piZF0KT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGQx ODQyNTQ5Pl0gam91cm5hbF9zdGFydCsweGE5LzB4ZDAgW2piZF0KT2N0ICAyIDE1OjA5OjQy IChub25lKSBrZXJuZWw6ICBbPGQxODQzZDMyPl0gam91cm5hbF9mb3JjZV9jb21taXQrMHgz Mi8weDQwIFtqYmRdCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxkMTg4MGMz OT5dIGV4dDNfZm9yY2VfY29tbWl0KzB4MjkvMHgzMCBbZXh0M10KT2N0ICAyIDE1OjA5OjQy IChub25lKSBrZXJuZWw6ICBbPGMwMTdiZTAzPl0gd3JpdGVfaW5vZGUrMHg0My8weDUwCk9j dCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE3YmY2MD5dIF9fc3luY19zaW5n bGVfaW5vZGUrMHgxNTAvMHgyNDAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBb PGMwMTdjMjhlPl0gc3luY19zYl9pbm9kZXMrMHgxN2UvMHgyYTAKT2N0ICAyIDE1OjA5OjQy IChub25lKSBrZXJuZWw6ICBbPGMwMTdjNGU0Pl0gc3luY19pbm9kZXNfc2IrMHg4NC8weGEw Ck9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxkMTg4MGM3MD5dIGV4dDNfc3lu Y19mcysweDAvMHg3MCBbZXh0M10KT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBb PGMwMTViOGFhPl0gZnN5bmNfc3VwZXIrMHg3YS8weGIwCk9jdCAgMiAxNTowOTo0MiAobm9u ZSkga2VybmVsOiAgWzxjMDE2MTQ4Nz5dIGRvX3JlbW91bnRfc2IrMHgzNy8weGYwCk9jdCAg MiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE2MTVlNz5dIGRvX2VtZXJnZW5jeV9y ZW1vdW50KzB4YTcvMHgxNjAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMw MTQyNGRhPl0gX19wZGZsdXNoKzB4ZGEvMHgxZjAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBr ZXJuZWw6ICBbPGMwMTQyNWYwPl0gcGRmbHVzaCsweDAvMHgyMApPY3QgIDIgMTU6MDk6NDIg KG5vbmUpIGtlcm5lbDogIFs8YzAxNDI1ZmY+XSBwZGZsdXNoKzB4Zi8weDIwCk9jdCAgMiAx NTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE2MTU0MD5dIGRvX2VtZXJnZW5jeV9yZW1v dW50KzB4MC8weDE2MApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxMDcy NTA+XSBrZXJuZWxfdGhyZWFkX2hlbHBlcisweDAvMHgxMApPY3QgIDIgMTU6MDk6NDIgKG5v bmUpIGtlcm5lbDogIFs8YzAxMDcyNTU+XSBrZXJuZWxfdGhyZWFkX2hlbHBlcisweDUvMHgx MApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogCk9jdCAgMiAxNTowOTo0MiAobm9u ZSkga2VybmVsOiBiYWQ6IHNjaGVkdWxpbmcgd2hpbGUgYXRvbWljIQpPY3QgIDIgMTU6MDk6 NDIgKG5vbmUpIGtlcm5lbDogQ2FsbCBUcmFjZToKT2N0ICAyIDE1OjA5OjQyIChub25lKSBr ZXJuZWw6ICBbPGMwMTFlNmU2Pl0gc2NoZWR1bGUrMHg0MDYvMHg0NDAKT2N0ICAyIDE1OjA5 OjQyIChub25lKSBrZXJuZWw6ICBbPGQxODc3MjYwPl0gYnB1dF9vbmUrMHgwLzB4MTAgW2V4 dDNdCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxkMTg0M2MxNz5dIGpvdXJu YWxfc3RvcCsweDFmNy8weDJlMCBbamJkXQpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5l bDogIFs8ZDE4NDI1NDk+XSBqb3VybmFsX3N0YXJ0KzB4YTkvMHhkMCBbamJkXQpPY3QgIDIg MTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8ZDE4NDNkMzI+XSBqb3VybmFsX2ZvcmNlX2Nv bW1pdCsweDMyLzB4NDAgW2piZF0KT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBb PGQxODgwYzM5Pl0gZXh0M19mb3JjZV9jb21taXQrMHgyOS8weDMwIFtleHQzXQpPY3QgIDIg MTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxN2JlMDM+XSB3cml0ZV9pbm9kZSsweDQz LzB4NTAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTdiZjYwPl0gX19z eW5jX3NpbmdsZV9pbm9kZSsweDE1MC8weDI0MApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtl cm5lbDogIFs8YzAxN2MyOGU+XSBzeW5jX3NiX2lub2RlcysweDE3ZS8weDJhMApPY3QgIDIg MTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxN2M0ZTQ+XSBzeW5jX2lub2Rlc19zYisw eDg0LzB4YTAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGQxODgwYzcwPl0g ZXh0M19zeW5jX2ZzKzB4MC8weDcwIFtleHQzXQpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtl cm5lbDogIFs8YzAxNWI4YWE+XSBmc3luY19zdXBlcisweDdhLzB4YjAKT2N0ICAyIDE1OjA5 OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTYxNDg3Pl0gZG9fcmVtb3VudF9zYisweDM3LzB4 ZjAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTYxNWU3Pl0gZG9fZW1l cmdlbmN5X3JlbW91bnQrMHhhNy8weDE2MApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5l bDogIFs8YzAxNDI0ZGE+XSBfX3BkZmx1c2grMHhkYS8weDFmMApPY3QgIDIgMTU6MDk6NDIg KG5vbmUpIGtlcm5lbDogIFs8YzAxNDI1ZjA+XSBwZGZsdXNoKzB4MC8weDIwCk9jdCAgMiAx NTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE0MjVmZj5dIHBkZmx1c2grMHhmLzB4MjAK T2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTYxNTQwPl0gZG9fZW1lcmdl bmN5X3JlbW91bnQrMHgwLzB4MTYwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAg WzxjMDEwNzI1MD5dIGtlcm5lbF90aHJlYWRfaGVscGVyKzB4MC8weDEwCk9jdCAgMiAxNTow OTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDEwNzI1NT5dIGtlcm5lbF90aHJlYWRfaGVscGVy KzB4NS8weDEwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAKT2N0ICAyIDE1OjA5 OjQyIChub25lKSBrZXJuZWw6IGJhZDogc2NoZWR1bGluZyB3aGlsZSBhdG9taWMhCk9jdCAg MiAxNTowOTo0MiAobm9uZSkga2VybmVsOiBDYWxsIFRyYWNlOgpPY3QgIDIgMTU6MDk6NDIg KG5vbmUpIGtlcm5lbDogIFs8YzAxMWU2ZTY+XSBzY2hlZHVsZSsweDQwNi8weDQ0MApPY3Qg IDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8ZDE4NzcyNjA+XSBicHV0X29uZSsweDAv MHgxMCBbZXh0M10KT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGQxODQzYzE3 Pl0gam91cm5hbF9zdG9wKzB4MWY3LzB4MmUwIFtqYmRdCk9jdCAgMiAxNTowOTo0MiAobm9u ZSkga2VybmVsOiAgWzxkMTg0MjU0OT5dIGpvdXJuYWxfc3RhcnQrMHhhOS8weGQwIFtqYmRd Ck9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxkMTg0M2QzMj5dIGpvdXJuYWxf Zm9yY2VfY29tbWl0KzB4MzIvMHg0MCBbamJkXQpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtl cm5lbDogIFs8ZDE4ODBjMzk+XSBleHQzX2ZvcmNlX2NvbW1pdCsweDI5LzB4MzAgW2V4dDNd Ck9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE3YmUwMz5dIHdyaXRlX2lu b2RlKzB4NDMvMHg1MApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxN2Jm NjA+XSBfX3N5bmNfc2luZ2xlX2lub2RlKzB4MTUwLzB4MjQwCk9jdCAgMiAxNTowOTo0MiAo bm9uZSkga2VybmVsOiAgWzxjMDE3YzI4ZT5dIHN5bmNfc2JfaW5vZGVzKzB4MTdlLzB4MmEw Ck9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE3YzRlND5dIHN5bmNfaW5v ZGVzX3NiKzB4ODQvMHhhMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8ZDE4 ODBjNzA+XSBleHQzX3N5bmNfZnMrMHgwLzB4NzAgW2V4dDNdCk9jdCAgMiAxNTowOTo0MiAo bm9uZSkga2VybmVsOiAgWzxjMDE1YjhhYT5dIGZzeW5jX3N1cGVyKzB4N2EvMHhiMApPY3Qg IDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNjE0ODc+XSBkb19yZW1vdW50X3Ni KzB4MzcvMHhmMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNjE1ZTc+ XSBkb19lbWVyZ2VuY3lfcmVtb3VudCsweGE3LzB4MTYwCk9jdCAgMiAxNTowOTo0MiAobm9u ZSkga2VybmVsOiAgWzxjMDE0MjRkYT5dIF9fcGRmbHVzaCsweGRhLzB4MWYwCk9jdCAgMiAx NTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE0MjVmMD5dIHBkZmx1c2grMHgwLzB4MjAK T2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTQyNWZmPl0gcGRmbHVzaCsw eGYvMHgyMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNjE1NDA+XSBk b19lbWVyZ2VuY3lfcmVtb3VudCsweDAvMHgxNjAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBr ZXJuZWw6ICBbPGMwMTA3MjUwPl0ga2VybmVsX3RocmVhZF9oZWxwZXIrMHgwLzB4MTAKT2N0 ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTA3MjU1Pl0ga2VybmVsX3RocmVh ZF9oZWxwZXIrMHg1LzB4MTAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6IApPY3Qg IDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogYmFkOiBzY2hlZHVsaW5nIHdoaWxlIGF0b21p YyEKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6IENhbGwgVHJhY2U6Ck9jdCAgMiAx NTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDExZTZlNj5dIHNjaGVkdWxlKzB4NDA2LzB4 NDQwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxkMTg3NzI2MD5dIGJwdXRf b25lKzB4MC8weDEwIFtleHQzXQpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8 ZDE4NDNjMTc+XSBqb3VybmFsX3N0b3ArMHgxZjcvMHgyZTAgW2piZF0KT2N0ICAyIDE1OjA5 OjQyIChub25lKSBrZXJuZWw6ICBbPGQxODQyNTQ5Pl0gam91cm5hbF9zdGFydCsweGE5LzB4 ZDAgW2piZF0KT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGQxODQzZDMyPl0g am91cm5hbF9mb3JjZV9jb21taXQrMHgzMi8weDQwIFtqYmRdCk9jdCAgMiAxNTowOTo0MiAo bm9uZSkga2VybmVsOiAgWzxkMTg4MGMzOT5dIGV4dDNfZm9yY2VfY29tbWl0KzB4MjkvMHgz MCBbZXh0M10KT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTdiZTAzPl0g d3JpdGVfaW5vZGUrMHg0My8weDUwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAg WzxjMDE3YmY2MD5dIF9fc3luY19zaW5nbGVfaW5vZGUrMHgxNTAvMHgyNDAKT2N0ICAyIDE1 OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTdjMjhlPl0gc3luY19zYl9pbm9kZXMrMHgx N2UvMHgyYTAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTdjNGU0Pl0g c3luY19pbm9kZXNfc2IrMHg4NC8weGEwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVs OiAgWzxkMTg4MGM3MD5dIGV4dDNfc3luY19mcysweDAvMHg3MCBbZXh0M10KT2N0ICAyIDE1 OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTViOGFhPl0gZnN5bmNfc3VwZXIrMHg3YS8w eGIwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE2MTQ4Nz5dIGRvX3Jl bW91bnRfc2IrMHgzNy8weGYwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxj MDE2MTVlNz5dIGRvX2VtZXJnZW5jeV9yZW1vdW50KzB4YTcvMHgxNjAKT2N0ICAyIDE1OjA5 OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTQyNGRhPl0gX19wZGZsdXNoKzB4ZGEvMHgxZjAK T2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTQyNWYwPl0gcGRmbHVzaCsw eDAvMHgyMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNDI1ZmY+XSBw ZGZsdXNoKzB4Zi8weDIwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE2 MTU0MD5dIGRvX2VtZXJnZW5jeV9yZW1vdW50KzB4MC8weDE2MApPY3QgIDIgMTU6MDk6NDIg KG5vbmUpIGtlcm5lbDogIFs8YzAxMDcyNTA+XSBrZXJuZWxfdGhyZWFkX2hlbHBlcisweDAv MHgxMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxMDcyNTU+XSBrZXJu ZWxfdGhyZWFkX2hlbHBlcisweDUvMHgxMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5l bDogCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiBiYWQ6IHNjaGVkdWxpbmcgd2hp bGUgYXRvbWljIQpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogQ2FsbCBUcmFjZToK T2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTFlNmU2Pl0gc2NoZWR1bGUr MHg0MDYvMHg0NDAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGQxODc3MjYw Pl0gYnB1dF9vbmUrMHgwLzB4MTAgW2V4dDNdCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2Vy bmVsOiAgWzxkMTg0M2MxNz5dIGpvdXJuYWxfc3RvcCsweDFmNy8weDJlMCBbamJkXQpPY3Qg IDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8ZDE4NDI1NDk+XSBqb3VybmFsX3N0YXJ0 KzB4YTkvMHhkMCBbamJkXQpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8ZDE4 NDNkMzI+XSBqb3VybmFsX2ZvcmNlX2NvbW1pdCsweDMyLzB4NDAgW2piZF0KT2N0ICAyIDE1 OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGQxODgwYzM5Pl0gZXh0M19mb3JjZV9jb21taXQr MHgyOS8weDMwIFtleHQzXQpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAx N2JlMDM+XSB3cml0ZV9pbm9kZSsweDQzLzB4NTAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBr ZXJuZWw6ICBbPGMwMTdiZjYwPl0gX19zeW5jX3NpbmdsZV9pbm9kZSsweDE1MC8weDI0MApP Y3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxN2MyOGU+XSBzeW5jX3NiX2lu b2RlcysweDE3ZS8weDJhMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAx N2M0ZTQ+XSBzeW5jX2lub2Rlc19zYisweDg0LzB4YTAKT2N0ICAyIDE1OjA5OjQyIChub25l KSBrZXJuZWw6ICBbPGQxODgwYzcwPl0gZXh0M19zeW5jX2ZzKzB4MC8weDcwIFtleHQzXQpP Y3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNWI4YWE+XSBmc3luY19zdXBl cisweDdhLzB4YjAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTYxNDg3 Pl0gZG9fcmVtb3VudF9zYisweDM3LzB4ZjAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJu ZWw6ICBbPGMwMTYxNWU3Pl0gZG9fZW1lcmdlbmN5X3JlbW91bnQrMHhhNy8weDE2MApPY3Qg IDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNDI0ZGE+XSBfX3BkZmx1c2grMHhk YS8weDFmMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNDI1ZjA+XSBw ZGZsdXNoKzB4MC8weDIwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE0 MjVmZj5dIHBkZmx1c2grMHhmLzB4MjAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6 ICBbPGMwMTYxNTQwPl0gZG9fZW1lcmdlbmN5X3JlbW91bnQrMHgwLzB4MTYwCk9jdCAgMiAx NTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDEwNzI1MD5dIGtlcm5lbF90aHJlYWRfaGVs cGVyKzB4MC8weDEwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDEwNzI1 NT5dIGtlcm5lbF90aHJlYWRfaGVscGVyKzB4NS8weDEwCk9jdCAgMiAxNTowOTo0MiAobm9u ZSkga2VybmVsOiAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6IGJhZDogc2NoZWR1 bGluZyB3aGlsZSBhdG9taWMhCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiBDYWxs IFRyYWNlOgpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxMWU2ZTY+XSBz Y2hlZHVsZSsweDQwNi8weDQ0MApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8 ZDE4NzcyNjA+XSBicHV0X29uZSsweDAvMHgxMCBbZXh0M10KT2N0ICAyIDE1OjA5OjQyIChu b25lKSBrZXJuZWw6ICBbPGQxODQzYzE3Pl0gam91cm5hbF9zdG9wKzB4MWY3LzB4MmUwIFtq YmRdCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxkMTg0MjU0OT5dIGpvdXJu YWxfc3RhcnQrMHhhOS8weGQwIFtqYmRdCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVs OiAgWzxkMTg0M2QzMj5dIGpvdXJuYWxfZm9yY2VfY29tbWl0KzB4MzIvMHg0MCBbamJkXQpP Y3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8ZDE4ODBjMzk+XSBleHQzX2ZvcmNl X2NvbW1pdCsweDI5LzB4MzAgW2V4dDNdCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVs OiAgWzxjMDE3YmUwMz5dIHdyaXRlX2lub2RlKzB4NDMvMHg1MApPY3QgIDIgMTU6MDk6NDIg KG5vbmUpIGtlcm5lbDogIFs8YzAxN2JmNjA+XSBfX3N5bmNfc2luZ2xlX2lub2RlKzB4MTUw LzB4MjQwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE3YzI4ZT5dIHN5 bmNfc2JfaW5vZGVzKzB4MTdlLzB4MmEwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVs OiAgWzxjMDE3YzRlND5dIHN5bmNfaW5vZGVzX3NiKzB4ODQvMHhhMApPY3QgIDIgMTU6MDk6 NDIgKG5vbmUpIGtlcm5lbDogIFs8ZDE4ODBjNzA+XSBleHQzX3N5bmNfZnMrMHgwLzB4NzAg W2V4dDNdCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE1YjhhYT5dIGZz eW5jX3N1cGVyKzB4N2EvMHhiMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8 YzAxNjE0ODc+XSBkb19yZW1vdW50X3NiKzB4MzcvMHhmMApPY3QgIDIgMTU6MDk6NDIgKG5v bmUpIGtlcm5lbDogIFs8YzAxNjE1ZTc+XSBkb19lbWVyZ2VuY3lfcmVtb3VudCsweGE3LzB4 MTYwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE0MjRkYT5dIF9fcGRm bHVzaCsweGRhLzB4MWYwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE0 MjVmMD5dIHBkZmx1c2grMHgwLzB4MjAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6 ICBbPGMwMTQyNWZmPl0gcGRmbHVzaCsweGYvMHgyMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUp IGtlcm5lbDogIFs8YzAxNjE1NDA+XSBkb19lbWVyZ2VuY3lfcmVtb3VudCsweDAvMHgxNjAK T2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTA3MjUwPl0ga2VybmVsX3Ro cmVhZF9oZWxwZXIrMHgwLzB4MTAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBb PGMwMTA3MjU1Pl0ga2VybmVsX3RocmVhZF9oZWxwZXIrMHg1LzB4MTAKT2N0ICAyIDE1OjA5 OjQyIChub25lKSBrZXJuZWw6IApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogYmFk OiBzY2hlZHVsaW5nIHdoaWxlIGF0b21pYyEKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJu ZWw6IENhbGwgVHJhY2U6Ck9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDEx ZTZlNj5dIHNjaGVkdWxlKzB4NDA2LzB4NDQwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2Vy bmVsOiAgWzxkMTg3NzI2MD5dIGJwdXRfb25lKzB4MC8weDEwIFtleHQzXQpPY3QgIDIgMTU6 MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8ZDE4NDNjMTc+XSBqb3VybmFsX3N0b3ArMHgxZjcv MHgyZTAgW2piZF0KT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGQxODQyNTQ5 Pl0gam91cm5hbF9zdGFydCsweGE5LzB4ZDAgW2piZF0KT2N0ICAyIDE1OjA5OjQyIChub25l KSBrZXJuZWw6ICBbPGQxODQzZDMyPl0gam91cm5hbF9mb3JjZV9jb21taXQrMHgzMi8weDQw IFtqYmRdCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxkMTg4MGMzOT5dIGV4 dDNfZm9yY2VfY29tbWl0KzB4MjkvMHgzMCBbZXh0M10KT2N0ICAyIDE1OjA5OjQyIChub25l KSBrZXJuZWw6ICBbPGMwMTdiZTAzPl0gd3JpdGVfaW5vZGUrMHg0My8weDUwCk9jdCAgMiAx NTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE3YmY2MD5dIF9fc3luY19zaW5nbGVfaW5v ZGUrMHgxNTAvMHgyNDAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTdj MjhlPl0gc3luY19zYl9pbm9kZXMrMHgxN2UvMHgyYTAKT2N0ICAyIDE1OjA5OjQyIChub25l KSBrZXJuZWw6ICBbPGMwMTdjNGU0Pl0gc3luY19pbm9kZXNfc2IrMHg4NC8weGEwCk9jdCAg MiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxkMTg4MGM3MD5dIGV4dDNfc3luY19mcysw eDAvMHg3MCBbZXh0M10KT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTVi OGFhPl0gZnN5bmNfc3VwZXIrMHg3YS8weGIwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2Vy bmVsOiAgWzxjMDE2MTQ4Nz5dIGRvX3JlbW91bnRfc2IrMHgzNy8weGYwCk9jdCAgMiAxNTow OTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE2MTVlNz5dIGRvX2VtZXJnZW5jeV9yZW1vdW50 KzB4YTcvMHgxNjAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTQyNGRh Pl0gX19wZGZsdXNoKzB4ZGEvMHgxZjAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6 ICBbPGMwMTQyNWYwPl0gcGRmbHVzaCsweDAvMHgyMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUp IGtlcm5lbDogIFs8YzAxNDI1ZmY+XSBwZGZsdXNoKzB4Zi8weDIwCk9jdCAgMiAxNTowOTo0 MiAobm9uZSkga2VybmVsOiAgWzxjMDE2MTU0MD5dIGRvX2VtZXJnZW5jeV9yZW1vdW50KzB4 MC8weDE2MApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxMDcyNTA+XSBr ZXJuZWxfdGhyZWFkX2hlbHBlcisweDAvMHgxMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtl cm5lbDogIFs8YzAxMDcyNTU+XSBrZXJuZWxfdGhyZWFkX2hlbHBlcisweDUvMHgxMApPY3Qg IDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2Vy bmVsOiBiYWQ6IHNjaGVkdWxpbmcgd2hpbGUgYXRvbWljIQpPY3QgIDIgMTU6MDk6NDIgKG5v bmUpIGtlcm5lbDogQ2FsbCBUcmFjZToKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6 ICBbPGMwMTFlNmU2Pl0gc2NoZWR1bGUrMHg0MDYvMHg0NDAKT2N0ICAyIDE1OjA5OjQyIChu b25lKSBrZXJuZWw6ICBbPGQxODc3MjYwPl0gYnB1dF9vbmUrMHgwLzB4MTAgW2V4dDNdCk9j dCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxkMTg0M2MxNz5dIGpvdXJuYWxfc3Rv cCsweDFmNy8weDJlMCBbamJkXQpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8 ZDE4NDI1NDk+XSBqb3VybmFsX3N0YXJ0KzB4YTkvMHhkMCBbamJkXQpPY3QgIDIgMTU6MDk6 NDIgKG5vbmUpIGtlcm5lbDogIFs8ZDE4NDNkMzI+XSBqb3VybmFsX2ZvcmNlX2NvbW1pdCsw eDMyLzB4NDAgW2piZF0KT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGQxODgw YzM5Pl0gZXh0M19mb3JjZV9jb21taXQrMHgyOS8weDMwIFtleHQzXQpPY3QgIDIgMTU6MDk6 NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxN2JlMDM+XSB3cml0ZV9pbm9kZSsweDQzLzB4NTAK T2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTdiZjYwPl0gX19zeW5jX3Np bmdsZV9pbm9kZSsweDE1MC8weDI0MApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDog IFs8YzAxN2MyOGU+XSBzeW5jX3NiX2lub2RlcysweDE3ZS8weDJhMApPY3QgIDIgMTU6MDk6 NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxN2M0ZTQ+XSBzeW5jX2lub2Rlc19zYisweDg0LzB4 YTAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGQxODgwYzcwPl0gZXh0M19z eW5jX2ZzKzB4MC8weDcwIFtleHQzXQpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDog IFs8YzAxNWI4YWE+XSBmc3luY19zdXBlcisweDdhLzB4YjAKT2N0ICAyIDE1OjA5OjQyIChu b25lKSBrZXJuZWw6ICBbPGMwMTYxNDg3Pl0gZG9fcmVtb3VudF9zYisweDM3LzB4ZjAKT2N0 ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTYxNWU3Pl0gZG9fZW1lcmdlbmN5 X3JlbW91bnQrMHhhNy8weDE2MApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8 YzAxNDI0ZGE+XSBfX3BkZmx1c2grMHhkYS8weDFmMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUp IGtlcm5lbDogIFs8YzAxNDI1ZjA+XSBwZGZsdXNoKzB4MC8weDIwCk9jdCAgMiAxNTowOTo0 MiAobm9uZSkga2VybmVsOiAgWzxjMDE0MjVmZj5dIHBkZmx1c2grMHhmLzB4MjAKT2N0ICAy IDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTYxNTQwPl0gZG9fZW1lcmdlbmN5X3Jl bW91bnQrMHgwLzB4MTYwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDEw NzI1MD5dIGtlcm5lbF90aHJlYWRfaGVscGVyKzB4MC8weDEwCk9jdCAgMiAxNTowOTo0MiAo bm9uZSkga2VybmVsOiAgWzxjMDEwNzI1NT5dIGtlcm5lbF90aHJlYWRfaGVscGVyKzB4NS8w eDEwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAKT2N0ICAyIDE1OjA5OjQyIChu b25lKSBrZXJuZWw6IGJhZDogc2NoZWR1bGluZyB3aGlsZSBhdG9taWMhCk9jdCAgMiAxNTow OTo0MiAobm9uZSkga2VybmVsOiBDYWxsIFRyYWNlOgpPY3QgIDIgMTU6MDk6NDIgKG5vbmUp IGtlcm5lbDogIFs8YzAxMWU2ZTY+XSBzY2hlZHVsZSsweDQwNi8weDQ0MApPY3QgIDIgMTU6 MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8ZDE4NzcyNjA+XSBicHV0X29uZSsweDAvMHgxMCBb ZXh0M10KT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGQxODQzYzE3Pl0gam91 cm5hbF9zdG9wKzB4MWY3LzB4MmUwIFtqYmRdCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2Vy bmVsOiAgWzxkMTg0MjU0OT5dIGpvdXJuYWxfc3RhcnQrMHhhOS8weGQwIFtqYmRdCk9jdCAg MiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxkMTg0M2QzMj5dIGpvdXJuYWxfZm9yY2Vf Y29tbWl0KzB4MzIvMHg0MCBbamJkXQpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDog IFs8ZDE4ODBjMzk+XSBleHQzX2ZvcmNlX2NvbW1pdCsweDI5LzB4MzAgW2V4dDNdCk9jdCAg MiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE3YmUwMz5dIHdyaXRlX2lub2RlKzB4 NDMvMHg1MApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxN2JmNjA+XSBf X3N5bmNfc2luZ2xlX2lub2RlKzB4MTUwLzB4MjQwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkg a2VybmVsOiAgWzxjMDE3YzI4ZT5dIHN5bmNfc2JfaW5vZGVzKzB4MTdlLzB4MmEwCk9jdCAg MiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE3YzRlND5dIHN5bmNfaW5vZGVzX3Ni KzB4ODQvMHhhMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8ZDE4ODBjNzA+ XSBleHQzX3N5bmNfZnMrMHgwLzB4NzAgW2V4dDNdCk9jdCAgMiAxNTowOTo0MiAobm9uZSkg a2VybmVsOiAgWzxjMDE1YjhhYT5dIGZzeW5jX3N1cGVyKzB4N2EvMHhiMApPY3QgIDIgMTU6 MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNjE0ODc+XSBkb19yZW1vdW50X3NiKzB4Mzcv MHhmMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNjE1ZTc+XSBkb19l bWVyZ2VuY3lfcmVtb3VudCsweGE3LzB4MTYwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2Vy bmVsOiAgWzxjMDE0MjRkYT5dIF9fcGRmbHVzaCsweGRhLzB4MWYwCk9jdCAgMiAxNTowOTo0 MiAobm9uZSkga2VybmVsOiAgWzxjMDE0MjVmMD5dIHBkZmx1c2grMHgwLzB4MjAKT2N0ICAy IDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTQyNWZmPl0gcGRmbHVzaCsweGYvMHgy MApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNjE1NDA+XSBkb19lbWVy Z2VuY3lfcmVtb3VudCsweDAvMHgxNjAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6 ICBbPGMwMTA3MjUwPl0ga2VybmVsX3RocmVhZF9oZWxwZXIrMHgwLzB4MTAKT2N0ICAyIDE1 OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTA3MjU1Pl0ga2VybmVsX3RocmVhZF9oZWxw ZXIrMHg1LzB4MTAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6IApPY3QgIDIgMTU6 MDk6NDIgKG5vbmUpIGtlcm5lbDogYmFkOiBzY2hlZHVsaW5nIHdoaWxlIGF0b21pYyEKT2N0 ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6IENhbGwgVHJhY2U6Ck9jdCAgMiAxNTowOTo0 MiAobm9uZSkga2VybmVsOiAgWzxjMDExZTZlNj5dIHNjaGVkdWxlKzB4NDA2LzB4NDQwCk9j dCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxkMTg3NzI2MD5dIGJwdXRfb25lKzB4 MC8weDEwIFtleHQzXQpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8ZDE4NDNj MTc+XSBqb3VybmFsX3N0b3ArMHgxZjcvMHgyZTAgW2piZF0KT2N0ICAyIDE1OjA5OjQyIChu b25lKSBrZXJuZWw6ICBbPGQxODQyNTQ5Pl0gam91cm5hbF9zdGFydCsweGE5LzB4ZDAgW2pi ZF0KT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGQxODQzZDMyPl0gam91cm5h bF9mb3JjZV9jb21taXQrMHgzMi8weDQwIFtqYmRdCk9jdCAgMiAxNTowOTo0MiAobm9uZSkg a2VybmVsOiAgWzxkMTg4MGMzOT5dIGV4dDNfZm9yY2VfY29tbWl0KzB4MjkvMHgzMCBbZXh0 M10KT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTdiZTAzPl0gd3JpdGVf aW5vZGUrMHg0My8weDUwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE3 YmY2MD5dIF9fc3luY19zaW5nbGVfaW5vZGUrMHgxNTAvMHgyNDAKT2N0ICAyIDE1OjA5OjQy IChub25lKSBrZXJuZWw6ICBbPGMwMTdjMjhlPl0gc3luY19zYl9pbm9kZXMrMHgxN2UvMHgy YTAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTdjNGU0Pl0gc3luY19p bm9kZXNfc2IrMHg4NC8weGEwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxk MTg4MGM3MD5dIGV4dDNfc3luY19mcysweDAvMHg3MCBbZXh0M10KT2N0ICAyIDE1OjA5OjQy IChub25lKSBrZXJuZWw6ICBbPGMwMTViOGFhPl0gZnN5bmNfc3VwZXIrMHg3YS8weGIwCk9j dCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE2MTQ4Nz5dIGRvX3JlbW91bnRf c2IrMHgzNy8weGYwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE2MTVl Nz5dIGRvX2VtZXJnZW5jeV9yZW1vdW50KzB4YTcvMHgxNjAKT2N0ICAyIDE1OjA5OjQyIChu b25lKSBrZXJuZWw6ICBbPGMwMTQyNGRhPl0gX19wZGZsdXNoKzB4ZGEvMHgxZjAKT2N0ICAy IDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTQyNWYwPl0gcGRmbHVzaCsweDAvMHgy MApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNDI1ZmY+XSBwZGZsdXNo KzB4Zi8weDIwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE2MTU0MD5d IGRvX2VtZXJnZW5jeV9yZW1vdW50KzB4MC8weDE2MApPY3QgIDIgMTU6MDk6NDIgKG5vbmUp IGtlcm5lbDogIFs8YzAxMDcyNTA+XSBrZXJuZWxfdGhyZWFkX2hlbHBlcisweDAvMHgxMApP Y3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxMDcyNTU+XSBrZXJuZWxfdGhy ZWFkX2hlbHBlcisweDUvMHgxMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogCk9j dCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiBiYWQ6IHNjaGVkdWxpbmcgd2hpbGUgYXRv bWljIQpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogQ2FsbCBUcmFjZToKT2N0ICAy IDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTFlNmU2Pl0gc2NoZWR1bGUrMHg0MDYv MHg0NDAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGQxODc3MjYwPl0gYnB1 dF9vbmUrMHgwLzB4MTAgW2V4dDNdCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAg WzxkMTg0M2MxNz5dIGpvdXJuYWxfc3RvcCsweDFmNy8weDJlMCBbamJkXQpPY3QgIDIgMTU6 MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8ZDE4NDI1NDk+XSBqb3VybmFsX3N0YXJ0KzB4YTkv MHhkMCBbamJkXQpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8ZDE4NDNkMzI+ XSBqb3VybmFsX2ZvcmNlX2NvbW1pdCsweDMyLzB4NDAgW2piZF0KT2N0ICAyIDE1OjA5OjQy IChub25lKSBrZXJuZWw6ICBbPGQxODgwYzM5Pl0gZXh0M19mb3JjZV9jb21taXQrMHgyOS8w eDMwIFtleHQzXQpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxN2JlMDM+ XSB3cml0ZV9pbm9kZSsweDQzLzB4NTAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6 ICBbPGMwMTdiZjYwPl0gX19zeW5jX3NpbmdsZV9pbm9kZSsweDE1MC8weDI0MApPY3QgIDIg MTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxN2MyOGU+XSBzeW5jX3NiX2lub2Rlcysw eDE3ZS8weDJhMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxN2M0ZTQ+ XSBzeW5jX2lub2Rlc19zYisweDg0LzB4YTAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJu ZWw6ICBbPGQxODgwYzcwPl0gZXh0M19zeW5jX2ZzKzB4MC8weDcwIFtleHQzXQpPY3QgIDIg MTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNWI4YWE+XSBmc3luY19zdXBlcisweDdh LzB4YjAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTYxNDg3Pl0gZG9f cmVtb3VudF9zYisweDM3LzB4ZjAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBb PGMwMTYxNWU3Pl0gZG9fZW1lcmdlbmN5X3JlbW91bnQrMHhhNy8weDE2MApPY3QgIDIgMTU6 MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNDI0ZGE+XSBfX3BkZmx1c2grMHhkYS8weDFm MApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNDI1ZjA+XSBwZGZsdXNo KzB4MC8weDIwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE0MjVmZj5d IHBkZmx1c2grMHhmLzB4MjAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMw MTYxNTQwPl0gZG9fZW1lcmdlbmN5X3JlbW91bnQrMHgwLzB4MTYwCk9jdCAgMiAxNTowOTo0 MiAobm9uZSkga2VybmVsOiAgWzxjMDEwNzI1MD5dIGtlcm5lbF90aHJlYWRfaGVscGVyKzB4 MC8weDEwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDEwNzI1NT5dIGtl cm5lbF90aHJlYWRfaGVscGVyKzB4NS8weDEwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2Vy bmVsOiAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6IGJhZDogc2NoZWR1bGluZyB3 aGlsZSBhdG9taWMhCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiBDYWxsIFRyYWNl OgpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxMWU2ZTY+XSBzY2hlZHVs ZSsweDQwNi8weDQ0MApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8ZDE4Nzcy NjA+XSBicHV0X29uZSsweDAvMHgxMCBbZXh0M10KT2N0ICAyIDE1OjA5OjQyIChub25lKSBr ZXJuZWw6ICBbPGQxODQzYzE3Pl0gam91cm5hbF9zdG9wKzB4MWY3LzB4MmUwIFtqYmRdCk9j dCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxkMTg0MjU0OT5dIGpvdXJuYWxfc3Rh cnQrMHhhOS8weGQwIFtqYmRdCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxk MTg0M2QzMj5dIGpvdXJuYWxfZm9yY2VfY29tbWl0KzB4MzIvMHg0MCBbamJkXQpPY3QgIDIg MTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8ZDE4ODBjMzk+XSBleHQzX2ZvcmNlX2NvbW1p dCsweDI5LzB4MzAgW2V4dDNdCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxj MDE3YmUwMz5dIHdyaXRlX2lub2RlKzB4NDMvMHg1MApPY3QgIDIgMTU6MDk6NDIgKG5vbmUp IGtlcm5lbDogIFs8YzAxN2JmNjA+XSBfX3N5bmNfc2luZ2xlX2lub2RlKzB4MTUwLzB4MjQw Ck9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE3YzI4ZT5dIHN5bmNfc2Jf aW5vZGVzKzB4MTdlLzB4MmEwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxj MDE3YzRlND5dIHN5bmNfaW5vZGVzX3NiKzB4ODQvMHhhMApPY3QgIDIgMTU6MDk6NDIgKG5v bmUpIGtlcm5lbDogIFs8ZDE4ODBjNzA+XSBleHQzX3N5bmNfZnMrMHgwLzB4NzAgW2V4dDNd Ck9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE1YjhhYT5dIGZzeW5jX3N1 cGVyKzB4N2EvMHhiMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNjE0 ODc+XSBkb19yZW1vdW50X3NiKzB4MzcvMHhmMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtl cm5lbDogIFs8YzAxNjE1ZTc+XSBkb19lbWVyZ2VuY3lfcmVtb3VudCsweGE3LzB4MTYwCk9j dCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE0MjRkYT5dIF9fcGRmbHVzaCsw eGRhLzB4MWYwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE0MjVmMD5d IHBkZmx1c2grMHgwLzB4MjAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMw MTQyNWZmPl0gcGRmbHVzaCsweGYvMHgyMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5l bDogIFs8YzAxNjE1NDA+XSBkb19lbWVyZ2VuY3lfcmVtb3VudCsweDAvMHgxNjAKT2N0ICAy IDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTA3MjUwPl0ga2VybmVsX3RocmVhZF9o ZWxwZXIrMHgwLzB4MTAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTA3 MjU1Pl0ga2VybmVsX3RocmVhZF9oZWxwZXIrMHg1LzB4MTAKT2N0ICAyIDE1OjA5OjQyIChu b25lKSBrZXJuZWw6IApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogYmFkOiBzY2hl ZHVsaW5nIHdoaWxlIGF0b21pYyEKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6IENh bGwgVHJhY2U6Ck9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDExZTZlNj5d IHNjaGVkdWxlKzB4NDA2LzB4NDQwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAg WzxkMTg3NzI2MD5dIGJwdXRfb25lKzB4MC8weDEwIFtleHQzXQpPY3QgIDIgMTU6MDk6NDIg KG5vbmUpIGtlcm5lbDogIFs8ZDE4NDNjMTc+XSBqb3VybmFsX3N0b3ArMHgxZjcvMHgyZTAg W2piZF0KT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGQxODQyNTQ5Pl0gam91 cm5hbF9zdGFydCsweGE5LzB4ZDAgW2piZF0KT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJu ZWw6ICBbPGQxODQzZDMyPl0gam91cm5hbF9mb3JjZV9jb21taXQrMHgzMi8weDQwIFtqYmRd Ck9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxkMTg4MGMzOT5dIGV4dDNfZm9y Y2VfY29tbWl0KzB4MjkvMHgzMCBbZXh0M10KT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJu ZWw6ICBbPGMwMTdiZTAzPl0gd3JpdGVfaW5vZGUrMHg0My8weDUwCk9jdCAgMiAxNTowOTo0 MiAobm9uZSkga2VybmVsOiAgWzxjMDE3YmY2MD5dIF9fc3luY19zaW5nbGVfaW5vZGUrMHgx NTAvMHgyNDAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTdjMjhlPl0g c3luY19zYl9pbm9kZXMrMHgxN2UvMHgyYTAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJu ZWw6ICBbPGMwMTdjNGU0Pl0gc3luY19pbm9kZXNfc2IrMHg4NC8weGEwCk9jdCAgMiAxNTow OTo0MiAobm9uZSkga2VybmVsOiAgWzxkMTg4MGM3MD5dIGV4dDNfc3luY19mcysweDAvMHg3 MCBbZXh0M10KT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTViOGFhPl0g ZnN5bmNfc3VwZXIrMHg3YS8weGIwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAg WzxjMDE2MTQ4Nz5dIGRvX3JlbW91bnRfc2IrMHgzNy8weGYwCk9jdCAgMiAxNTowOTo0MiAo bm9uZSkga2VybmVsOiAgWzxjMDE2MTVlNz5dIGRvX2VtZXJnZW5jeV9yZW1vdW50KzB4YTcv MHgxNjAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTQyNGRhPl0gX19w ZGZsdXNoKzB4ZGEvMHgxZjAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMw MTQyNWYwPl0gcGRmbHVzaCsweDAvMHgyMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5l bDogIFs8YzAxNDI1ZmY+XSBwZGZsdXNoKzB4Zi8weDIwCk9jdCAgMiAxNTowOTo0MiAobm9u ZSkga2VybmVsOiAgWzxjMDE2MTU0MD5dIGRvX2VtZXJnZW5jeV9yZW1vdW50KzB4MC8weDE2 MApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxMDcyNTA+XSBrZXJuZWxf dGhyZWFkX2hlbHBlcisweDAvMHgxMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDog IFs8YzAxMDcyNTU+XSBrZXJuZWxfdGhyZWFkX2hlbHBlcisweDUvMHgxMApPY3QgIDIgMTU6 MDk6NDIgKG5vbmUpIGtlcm5lbDogCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiBi YWQ6IHNjaGVkdWxpbmcgd2hpbGUgYXRvbWljIQpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtl cm5lbDogQ2FsbCBUcmFjZToKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMw MTFlNmU2Pl0gc2NoZWR1bGUrMHg0MDYvMHg0NDAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBr ZXJuZWw6ICBbPGQxODc3MjYwPl0gYnB1dF9vbmUrMHgwLzB4MTAgW2V4dDNdCk9jdCAgMiAx NTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxkMTg0M2MxNz5dIGpvdXJuYWxfc3RvcCsweDFm Ny8weDJlMCBbamJkXQpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8ZDE4NDI1 NDk+XSBqb3VybmFsX3N0YXJ0KzB4YTkvMHhkMCBbamJkXQpPY3QgIDIgMTU6MDk6NDIgKG5v bmUpIGtlcm5lbDogIFs8ZDE4NDNkMzI+XSBqb3VybmFsX2ZvcmNlX2NvbW1pdCsweDMyLzB4 NDAgW2piZF0KT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGQxODgwYzM5Pl0g ZXh0M19mb3JjZV9jb21taXQrMHgyOS8weDMwIFtleHQzXQpPY3QgIDIgMTU6MDk6NDIgKG5v bmUpIGtlcm5lbDogIFs8YzAxN2JlMDM+XSB3cml0ZV9pbm9kZSsweDQzLzB4NTAKT2N0ICAy IDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTdiZjYwPl0gX19zeW5jX3NpbmdsZV9p bm9kZSsweDE1MC8weDI0MApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAx N2MyOGU+XSBzeW5jX3NiX2lub2RlcysweDE3ZS8weDJhMApPY3QgIDIgMTU6MDk6NDIgKG5v bmUpIGtlcm5lbDogIFs8YzAxN2M0ZTQ+XSBzeW5jX2lub2Rlc19zYisweDg0LzB4YTAKT2N0 ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGQxODgwYzcwPl0gZXh0M19zeW5jX2Zz KzB4MC8weDcwIFtleHQzXQpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAx NWI4YWE+XSBmc3luY19zdXBlcisweDdhLzB4YjAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBr ZXJuZWw6ICBbPGMwMTYxNDg3Pl0gZG9fcmVtb3VudF9zYisweDM3LzB4ZjAKT2N0ICAyIDE1 OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTYxNWU3Pl0gZG9fZW1lcmdlbmN5X3JlbW91 bnQrMHhhNy8weDE2MApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNDI0 ZGE+XSBfX3BkZmx1c2grMHhkYS8weDFmMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5l bDogIFs8YzAxNDI1ZjA+XSBwZGZsdXNoKzB4MC8weDIwCk9jdCAgMiAxNTowOTo0MiAobm9u ZSkga2VybmVsOiAgWzxjMDE0MjVmZj5dIHBkZmx1c2grMHhmLzB4MjAKT2N0ICAyIDE1OjA5 OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTYxNTQwPl0gZG9fZW1lcmdlbmN5X3JlbW91bnQr MHgwLzB4MTYwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDEwNzI1MD5d IGtlcm5lbF90aHJlYWRfaGVscGVyKzB4MC8weDEwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkg a2VybmVsOiAgWzxjMDEwNzI1NT5dIGtlcm5lbF90aHJlYWRfaGVscGVyKzB4NS8weDEwCk9j dCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBr ZXJuZWw6IGJhZDogc2NoZWR1bGluZyB3aGlsZSBhdG9taWMhCk9jdCAgMiAxNTowOTo0MiAo bm9uZSkga2VybmVsOiBDYWxsIFRyYWNlOgpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5l bDogIFs8YzAxMWU2ZTY+XSBzY2hlZHVsZSsweDQwNi8weDQ0MApPY3QgIDIgMTU6MDk6NDIg KG5vbmUpIGtlcm5lbDogIFs8ZDE4NzcyNjA+XSBicHV0X29uZSsweDAvMHgxMCBbZXh0M10K T2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGQxODQzYzE3Pl0gam91cm5hbF9z dG9wKzB4MWY3LzB4MmUwIFtqYmRdCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAg WzxkMTg0MjU0OT5dIGpvdXJuYWxfc3RhcnQrMHhhOS8weGQwIFtqYmRdCk9jdCAgMiAxNTow OTo0MiAobm9uZSkga2VybmVsOiAgWzxkMTg0M2QzMj5dIGpvdXJuYWxfZm9yY2VfY29tbWl0 KzB4MzIvMHg0MCBbamJkXQpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8ZDE4 ODBjMzk+XSBleHQzX2ZvcmNlX2NvbW1pdCsweDI5LzB4MzAgW2V4dDNdCk9jdCAgMiAxNTow OTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE3YmUwMz5dIHdyaXRlX2lub2RlKzB4NDMvMHg1 MApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxN2JmNjA+XSBfX3N5bmNf c2luZ2xlX2lub2RlKzB4MTUwLzB4MjQwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVs OiAgWzxjMDE3YzI4ZT5dIHN5bmNfc2JfaW5vZGVzKzB4MTdlLzB4MmEwCk9jdCAgMiAxNTow OTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE3YzRlND5dIHN5bmNfaW5vZGVzX3NiKzB4ODQv MHhhMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8ZDE4ODBjNzA+XSBleHQz X3N5bmNfZnMrMHgwLzB4NzAgW2V4dDNdCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVs OiAgWzxjMDE1YjhhYT5dIGZzeW5jX3N1cGVyKzB4N2EvMHhiMApPY3QgIDIgMTU6MDk6NDIg KG5vbmUpIGtlcm5lbDogIFs8YzAxNjE0ODc+XSBkb19yZW1vdW50X3NiKzB4MzcvMHhmMApP Y3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNjE1ZTc+XSBkb19lbWVyZ2Vu Y3lfcmVtb3VudCsweGE3LzB4MTYwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAg WzxjMDE0MjRkYT5dIF9fcGRmbHVzaCsweGRhLzB4MWYwCk9jdCAgMiAxNTowOTo0MiAobm9u ZSkga2VybmVsOiAgWzxjMDE0MjVmMD5dIHBkZmx1c2grMHgwLzB4MjAKT2N0ICAyIDE1OjA5 OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTQyNWZmPl0gcGRmbHVzaCsweGYvMHgyMApPY3Qg IDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNjE1NDA+XSBkb19lbWVyZ2VuY3lf cmVtb3VudCsweDAvMHgxNjAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMw MTA3MjUwPl0ga2VybmVsX3RocmVhZF9oZWxwZXIrMHgwLzB4MTAKT2N0ICAyIDE1OjA5OjQy IChub25lKSBrZXJuZWw6ICBbPGMwMTA3MjU1Pl0ga2VybmVsX3RocmVhZF9oZWxwZXIrMHg1 LzB4MTAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6IApPY3QgIDIgMTU6MDk6NDIg KG5vbmUpIGtlcm5lbDogYmFkOiBzY2hlZHVsaW5nIHdoaWxlIGF0b21pYyEKT2N0ICAyIDE1 OjA5OjQyIChub25lKSBrZXJuZWw6IENhbGwgVHJhY2U6Ck9jdCAgMiAxNTowOTo0MiAobm9u ZSkga2VybmVsOiAgWzxjMDExZTZlNj5dIHNjaGVkdWxlKzB4NDA2LzB4NDQwCk9jdCAgMiAx NTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxkMTg3NzI2MD5dIGJwdXRfb25lKzB4MC8weDEw IFtleHQzXQpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8ZDE4NDNjMTc+XSBq b3VybmFsX3N0b3ArMHgxZjcvMHgyZTAgW2piZF0KT2N0ICAyIDE1OjA5OjQyIChub25lKSBr ZXJuZWw6ICBbPGQxODQyNTQ5Pl0gam91cm5hbF9zdGFydCsweGE5LzB4ZDAgW2piZF0KT2N0 ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGQxODQzZDMyPl0gam91cm5hbF9mb3Jj ZV9jb21taXQrMHgzMi8weDQwIFtqYmRdCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVs OiAgWzxkMTg4MGMzOT5dIGV4dDNfZm9yY2VfY29tbWl0KzB4MjkvMHgzMCBbZXh0M10KT2N0 ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTdiZTAzPl0gd3JpdGVfaW5vZGUr MHg0My8weDUwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE3YmY2MD5d IF9fc3luY19zaW5nbGVfaW5vZGUrMHgxNTAvMHgyNDAKT2N0ICAyIDE1OjA5OjQyIChub25l KSBrZXJuZWw6ICBbPGMwMTdjMjhlPl0gc3luY19zYl9pbm9kZXMrMHgxN2UvMHgyYTAKT2N0 ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTdjNGU0Pl0gc3luY19pbm9kZXNf c2IrMHg4NC8weGEwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxkMTg4MGM3 MD5dIGV4dDNfc3luY19mcysweDAvMHg3MCBbZXh0M10KT2N0ICAyIDE1OjA5OjQyIChub25l KSBrZXJuZWw6ICBbPGMwMTViOGFhPl0gZnN5bmNfc3VwZXIrMHg3YS8weGIwCk9jdCAgMiAx NTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE2MTQ4Nz5dIGRvX3JlbW91bnRfc2IrMHgz Ny8weGYwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE2MTVlNz5dIGRv X2VtZXJnZW5jeV9yZW1vdW50KzB4YTcvMHgxNjAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBr ZXJuZWw6ICBbPGMwMTQyNGRhPl0gX19wZGZsdXNoKzB4ZGEvMHgxZjAKT2N0ICAyIDE1OjA5 OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTQyNWYwPl0gcGRmbHVzaCsweDAvMHgyMApPY3Qg IDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNDI1ZmY+XSBwZGZsdXNoKzB4Zi8w eDIwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE2MTU0MD5dIGRvX2Vt ZXJnZW5jeV9yZW1vdW50KzB4MC8weDE2MApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5l bDogIFs8YzAxMDcyNTA+XSBrZXJuZWxfdGhyZWFkX2hlbHBlcisweDAvMHgxMApPY3QgIDIg MTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxMDcyNTU+XSBrZXJuZWxfdGhyZWFkX2hl bHBlcisweDUvMHgxMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogCk9jdCAgMiAx NTowOTo0MiAobm9uZSkga2VybmVsOiBiYWQ6IHNjaGVkdWxpbmcgd2hpbGUgYXRvbWljIQpP Y3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogQ2FsbCBUcmFjZToKT2N0ICAyIDE1OjA5 OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTFlNmU2Pl0gc2NoZWR1bGUrMHg0MDYvMHg0NDAK T2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGQxODc3MjYwPl0gYnB1dF9vbmUr MHgwLzB4MTAgW2V4dDNdCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxkMTg0 M2MxNz5dIGpvdXJuYWxfc3RvcCsweDFmNy8weDJlMCBbamJkXQpPY3QgIDIgMTU6MDk6NDIg KG5vbmUpIGtlcm5lbDogIFs8ZDE4NDI1NDk+XSBqb3VybmFsX3N0YXJ0KzB4YTkvMHhkMCBb amJkXQpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8ZDE4NDNkMzI+XSBqb3Vy bmFsX2ZvcmNlX2NvbW1pdCsweDMyLzB4NDAgW2piZF0KT2N0ICAyIDE1OjA5OjQyIChub25l KSBrZXJuZWw6ICBbPGQxODgwYzM5Pl0gZXh0M19mb3JjZV9jb21taXQrMHgyOS8weDMwIFtl eHQzXQpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxN2JlMDM+XSB3cml0 ZV9pbm9kZSsweDQzLzB4NTAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMw MTdiZjYwPl0gX19zeW5jX3NpbmdsZV9pbm9kZSsweDE1MC8weDI0MApPY3QgIDIgMTU6MDk6 NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxN2MyOGU+XSBzeW5jX3NiX2lub2RlcysweDE3ZS8w eDJhMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxN2M0ZTQ+XSBzeW5j X2lub2Rlc19zYisweDg0LzB4YTAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBb PGQxODgwYzcwPl0gZXh0M19zeW5jX2ZzKzB4MC8weDcwIFtleHQzXQpPY3QgIDIgMTU6MDk6 NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNWI4YWE+XSBmc3luY19zdXBlcisweDdhLzB4YjAK T2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTYxNDg3Pl0gZG9fcmVtb3Vu dF9zYisweDM3LzB4ZjAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTYx NWU3Pl0gZG9fZW1lcmdlbmN5X3JlbW91bnQrMHhhNy8weDE2MApPY3QgIDIgMTU6MDk6NDIg KG5vbmUpIGtlcm5lbDogIFs8YzAxNDI0ZGE+XSBfX3BkZmx1c2grMHhkYS8weDFmMApPY3Qg IDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNDI1ZjA+XSBwZGZsdXNoKzB4MC8w eDIwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE0MjVmZj5dIHBkZmx1 c2grMHhmLzB4MjAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTYxNTQw Pl0gZG9fZW1lcmdlbmN5X3JlbW91bnQrMHgwLzB4MTYwCk9jdCAgMiAxNTowOTo0MiAobm9u ZSkga2VybmVsOiAgWzxjMDEwNzI1MD5dIGtlcm5lbF90aHJlYWRfaGVscGVyKzB4MC8weDEw Ck9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDEwNzI1NT5dIGtlcm5lbF90 aHJlYWRfaGVscGVyKzB4NS8weDEwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAK T2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6IGJhZDogc2NoZWR1bGluZyB3aGlsZSBh dG9taWMhCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiBDYWxsIFRyYWNlOgpPY3Qg IDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxMWU2ZTY+XSBzY2hlZHVsZSsweDQw Ni8weDQ0MApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8ZDE4NzcyNjA+XSBi cHV0X29uZSsweDAvMHgxMCBbZXh0M10KT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6 ICBbPGQxODQzYzE3Pl0gam91cm5hbF9zdG9wKzB4MWY3LzB4MmUwIFtqYmRdCk9jdCAgMiAx NTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxkMTg0MjU0OT5dIGpvdXJuYWxfc3RhcnQrMHhh OS8weGQwIFtqYmRdCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxkMTg0M2Qz Mj5dIGpvdXJuYWxfZm9yY2VfY29tbWl0KzB4MzIvMHg0MCBbamJkXQpPY3QgIDIgMTU6MDk6 NDIgKG5vbmUpIGtlcm5lbDogIFs8ZDE4ODBjMzk+XSBleHQzX2ZvcmNlX2NvbW1pdCsweDI5 LzB4MzAgW2V4dDNdCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE3YmUw Mz5dIHdyaXRlX2lub2RlKzB4NDMvMHg1MApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5l bDogIFs8YzAxN2JmNjA+XSBfX3N5bmNfc2luZ2xlX2lub2RlKzB4MTUwLzB4MjQwCk9jdCAg MiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE3YzI4ZT5dIHN5bmNfc2JfaW5vZGVz KzB4MTdlLzB4MmEwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE3YzRl ND5dIHN5bmNfaW5vZGVzX3NiKzB4ODQvMHhhMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtl cm5lbDogIFs8ZDE4ODBjNzA+XSBleHQzX3N5bmNfZnMrMHgwLzB4NzAgW2V4dDNdCk9jdCAg MiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE1YjhhYT5dIGZzeW5jX3N1cGVyKzB4 N2EvMHhiMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNjE0ODc+XSBk b19yZW1vdW50X3NiKzB4MzcvMHhmMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDog IFs8YzAxNjE1ZTc+XSBkb19lbWVyZ2VuY3lfcmVtb3VudCsweGE3LzB4MTYwCk9jdCAgMiAx NTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE0MjRkYT5dIF9fcGRmbHVzaCsweGRhLzB4 MWYwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE0MjVmMD5dIHBkZmx1 c2grMHgwLzB4MjAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTQyNWZm Pl0gcGRmbHVzaCsweGYvMHgyMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8 YzAxNjE1NDA+XSBkb19lbWVyZ2VuY3lfcmVtb3VudCsweDAvMHgxNjAKT2N0ICAyIDE1OjA5 OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTA3MjUwPl0ga2VybmVsX3RocmVhZF9oZWxwZXIr MHgwLzB4MTAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTA3MjU1Pl0g a2VybmVsX3RocmVhZF9oZWxwZXIrMHg1LzB4MTAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBr ZXJuZWw6IApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogYmFkOiBzY2hlZHVsaW5n IHdoaWxlIGF0b21pYyEKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6IENhbGwgVHJh Y2U6Ck9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDExZTZlNj5dIHNjaGVk dWxlKzB4NDA2LzB4NDQwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxkMTg3 NzI2MD5dIGJwdXRfb25lKzB4MC8weDEwIFtleHQzXQpPY3QgIDIgMTU6MDk6NDIgKG5vbmUp IGtlcm5lbDogIFs8ZDE4NDNjMTc+XSBqb3VybmFsX3N0b3ArMHgxZjcvMHgyZTAgW2piZF0K T2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGQxODQyNTQ5Pl0gam91cm5hbF9z dGFydCsweGE5LzB4ZDAgW2piZF0KT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBb PGQxODQzZDMyPl0gam91cm5hbF9mb3JjZV9jb21taXQrMHgzMi8weDQwIFtqYmRdCk9jdCAg MiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxkMTg4MGMzOT5dIGV4dDNfZm9yY2VfY29t bWl0KzB4MjkvMHgzMCBbZXh0M10KT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBb PGMwMTdiZTAzPl0gd3JpdGVfaW5vZGUrMHg0My8weDUwCk9jdCAgMiAxNTowOTo0MiAobm9u ZSkga2VybmVsOiAgWzxjMDE3YmY2MD5dIF9fc3luY19zaW5nbGVfaW5vZGUrMHgxNTAvMHgy NDAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTdjMjhlPl0gc3luY19z Yl9pbm9kZXMrMHgxN2UvMHgyYTAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBb PGMwMTdjNGU0Pl0gc3luY19pbm9kZXNfc2IrMHg4NC8weGEwCk9jdCAgMiAxNTowOTo0MiAo bm9uZSkga2VybmVsOiAgWzxkMTg4MGM3MD5dIGV4dDNfc3luY19mcysweDAvMHg3MCBbZXh0 M10KT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTViOGFhPl0gZnN5bmNf c3VwZXIrMHg3YS8weGIwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE2 MTQ4Nz5dIGRvX3JlbW91bnRfc2IrMHgzNy8weGYwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkg a2VybmVsOiAgWzxjMDE2MTVlNz5dIGRvX2VtZXJnZW5jeV9yZW1vdW50KzB4YTcvMHgxNjAK T2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTQyNGRhPl0gX19wZGZsdXNo KzB4ZGEvMHgxZjAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTQyNWYw Pl0gcGRmbHVzaCsweDAvMHgyMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8 YzAxNDI1ZmY+XSBwZGZsdXNoKzB4Zi8weDIwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2Vy bmVsOiAgWzxjMDE2MTU0MD5dIGRvX2VtZXJnZW5jeV9yZW1vdW50KzB4MC8weDE2MApPY3Qg IDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxMDcyNTA+XSBrZXJuZWxfdGhyZWFk X2hlbHBlcisweDAvMHgxMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAx MDcyNTU+XSBrZXJuZWxfdGhyZWFkX2hlbHBlcisweDUvMHgxMApPY3QgIDIgMTU6MDk6NDIg KG5vbmUpIGtlcm5lbDogCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiBiYWQ6IHNj aGVkdWxpbmcgd2hpbGUgYXRvbWljIQpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDog Q2FsbCBUcmFjZToKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTFlNmU2 Pl0gc2NoZWR1bGUrMHg0MDYvMHg0NDAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6 ICBbPGQxODc3MjYwPl0gYnB1dF9vbmUrMHgwLzB4MTAgW2V4dDNdCk9jdCAgMiAxNTowOTo0 MiAobm9uZSkga2VybmVsOiAgWzxkMTg0M2MxNz5dIGpvdXJuYWxfc3RvcCsweDFmNy8weDJl MCBbamJkXQpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8ZDE4NDI1NDk+XSBq b3VybmFsX3N0YXJ0KzB4YTkvMHhkMCBbamJkXQpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtl cm5lbDogIFs8ZDE4NDNkMzI+XSBqb3VybmFsX2ZvcmNlX2NvbW1pdCsweDMyLzB4NDAgW2pi ZF0KT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGQxODgwYzM5Pl0gZXh0M19m b3JjZV9jb21taXQrMHgyOS8weDMwIFtleHQzXQpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtl cm5lbDogIFs8YzAxN2JlMDM+XSB3cml0ZV9pbm9kZSsweDQzLzB4NTAKT2N0ICAyIDE1OjA5 OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTdiZjYwPl0gX19zeW5jX3NpbmdsZV9pbm9kZSsw eDE1MC8weDI0MApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxN2MyOGU+ XSBzeW5jX3NiX2lub2RlcysweDE3ZS8weDJhMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtl cm5lbDogIFs8YzAxN2M0ZTQ+XSBzeW5jX2lub2Rlc19zYisweDg0LzB4YTAKT2N0ICAyIDE1 OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGQxODgwYzcwPl0gZXh0M19zeW5jX2ZzKzB4MC8w eDcwIFtleHQzXQpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNWI4YWE+ XSBmc3luY19zdXBlcisweDdhLzB4YjAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6 ICBbPGMwMTYxNDg3Pl0gZG9fcmVtb3VudF9zYisweDM3LzB4ZjAKT2N0ICAyIDE1OjA5OjQy IChub25lKSBrZXJuZWw6ICBbPGMwMTYxNWU3Pl0gZG9fZW1lcmdlbmN5X3JlbW91bnQrMHhh Ny8weDE2MApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNDI0ZGE+XSBf X3BkZmx1c2grMHhkYS8weDFmMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8 YzAxNDI1ZjA+XSBwZGZsdXNoKzB4MC8weDIwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2Vy bmVsOiAgWzxjMDE0MjVmZj5dIHBkZmx1c2grMHhmLzB4MjAKT2N0ICAyIDE1OjA5OjQyIChu b25lKSBrZXJuZWw6ICBbPGMwMTYxNTQwPl0gZG9fZW1lcmdlbmN5X3JlbW91bnQrMHgwLzB4 MTYwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDEwNzI1MD5dIGtlcm5l bF90aHJlYWRfaGVscGVyKzB4MC8weDEwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVs OiAgWzxjMDEwNzI1NT5dIGtlcm5lbF90aHJlYWRfaGVscGVyKzB4NS8weDEwCk9jdCAgMiAx NTowOTo0MiAobm9uZSkga2VybmVsOiAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6 IGJhZDogc2NoZWR1bGluZyB3aGlsZSBhdG9taWMhCk9jdCAgMiAxNTowOTo0MiAobm9uZSkg a2VybmVsOiBDYWxsIFRyYWNlOgpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8 YzAxMWU2ZTY+XSBzY2hlZHVsZSsweDQwNi8weDQ0MApPY3QgIDIgMTU6MDk6NDIgKG5vbmUp IGtlcm5lbDogIFs8ZDE4NzcyNjA+XSBicHV0X29uZSsweDAvMHgxMCBbZXh0M10KT2N0ICAy IDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGQxODQzYzE3Pl0gam91cm5hbF9zdG9wKzB4 MWY3LzB4MmUwIFtqYmRdCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxkMTg0 MjU0OT5dIGpvdXJuYWxfc3RhcnQrMHhhOS8weGQwIFtqYmRdCk9jdCAgMiAxNTowOTo0MiAo bm9uZSkga2VybmVsOiAgWzxkMTg0M2QzMj5dIGpvdXJuYWxfZm9yY2VfY29tbWl0KzB4MzIv MHg0MCBbamJkXQpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8ZDE4ODBjMzk+ XSBleHQzX2ZvcmNlX2NvbW1pdCsweDI5LzB4MzAgW2V4dDNdCk9jdCAgMiAxNTowOTo0MiAo bm9uZSkga2VybmVsOiAgWzxjMDE3YmUwMz5dIHdyaXRlX2lub2RlKzB4NDMvMHg1MApPY3Qg IDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxN2JmNjA+XSBfX3N5bmNfc2luZ2xl X2lub2RlKzB4MTUwLzB4MjQwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxj MDE3YzI4ZT5dIHN5bmNfc2JfaW5vZGVzKzB4MTdlLzB4MmEwCk9jdCAgMiAxNTowOTo0MiAo bm9uZSkga2VybmVsOiAgWzxjMDE3YzRlND5dIHN5bmNfaW5vZGVzX3NiKzB4ODQvMHhhMApP Y3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8ZDE4ODBjNzA+XSBleHQzX3N5bmNf ZnMrMHgwLzB4NzAgW2V4dDNdCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxj MDE1YjhhYT5dIGZzeW5jX3N1cGVyKzB4N2EvMHhiMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUp IGtlcm5lbDogIFs8YzAxNjE0ODc+XSBkb19yZW1vdW50X3NiKzB4MzcvMHhmMApPY3QgIDIg MTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNjE1ZTc+XSBkb19lbWVyZ2VuY3lfcmVt b3VudCsweGE3LzB4MTYwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE0 MjRkYT5dIF9fcGRmbHVzaCsweGRhLzB4MWYwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2Vy bmVsOiAgWzxjMDE0MjVmMD5dIHBkZmx1c2grMHgwLzB4MjAKT2N0ICAyIDE1OjA5OjQyIChu b25lKSBrZXJuZWw6ICBbPGMwMTQyNWZmPl0gcGRmbHVzaCsweGYvMHgyMApPY3QgIDIgMTU6 MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNjE1NDA+XSBkb19lbWVyZ2VuY3lfcmVtb3Vu dCsweDAvMHgxNjAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTA3MjUw Pl0ga2VybmVsX3RocmVhZF9oZWxwZXIrMHgwLzB4MTAKT2N0ICAyIDE1OjA5OjQyIChub25l KSBrZXJuZWw6ICBbPGMwMTA3MjU1Pl0ga2VybmVsX3RocmVhZF9oZWxwZXIrMHg1LzB4MTAK T2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6IApPY3QgIDIgMTU6MDk6NDIgKG5vbmUp IGtlcm5lbDogYmFkOiBzY2hlZHVsaW5nIHdoaWxlIGF0b21pYyEKT2N0ICAyIDE1OjA5OjQy IChub25lKSBrZXJuZWw6IENhbGwgVHJhY2U6Ck9jdCAgMiAxNTowOTo0MiAobm9uZSkga2Vy bmVsOiAgWzxjMDExZTZlNj5dIHNjaGVkdWxlKzB4NDA2LzB4NDQwCk9jdCAgMiAxNTowOTo0 MiAobm9uZSkga2VybmVsOiAgWzxkMTg3NzI2MD5dIGJwdXRfb25lKzB4MC8weDEwIFtleHQz XQpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8ZDE4NDNjMTc+XSBqb3VybmFs X3N0b3ArMHgxZjcvMHgyZTAgW2piZF0KT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6 ICBbPGQxODQyNTQ5Pl0gam91cm5hbF9zdGFydCsweGE5LzB4ZDAgW2piZF0KT2N0ICAyIDE1 OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGQxODQzZDMyPl0gam91cm5hbF9mb3JjZV9jb21t aXQrMHgzMi8weDQwIFtqYmRdCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxk MTg4MGMzOT5dIGV4dDNfZm9yY2VfY29tbWl0KzB4MjkvMHgzMCBbZXh0M10KT2N0ICAyIDE1 OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTdiZTAzPl0gd3JpdGVfaW5vZGUrMHg0My8w eDUwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE3YmY2MD5dIF9fc3lu Y19zaW5nbGVfaW5vZGUrMHgxNTAvMHgyNDAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJu ZWw6ICBbPGMwMTdjMjhlPl0gc3luY19zYl9pbm9kZXMrMHgxN2UvMHgyYTAKT2N0ICAyIDE1 OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTdjNGU0Pl0gc3luY19pbm9kZXNfc2IrMHg4 NC8weGEwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxkMTg4MGM3MD5dIGV4 dDNfc3luY19mcysweDAvMHg3MCBbZXh0M10KT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJu ZWw6ICBbPGMwMTViOGFhPl0gZnN5bmNfc3VwZXIrMHg3YS8weGIwCk9jdCAgMiAxNTowOTo0 MiAobm9uZSkga2VybmVsOiAgWzxjMDE2MTQ4Nz5dIGRvX3JlbW91bnRfc2IrMHgzNy8weGYw Ck9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE2MTVlNz5dIGRvX2VtZXJn ZW5jeV9yZW1vdW50KzB4YTcvMHgxNjAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6 ICBbPGMwMTQyNGRhPl0gX19wZGZsdXNoKzB4ZGEvMHgxZjAKT2N0ICAyIDE1OjA5OjQyIChu b25lKSBrZXJuZWw6ICBbPGMwMTQyNWYwPl0gcGRmbHVzaCsweDAvMHgyMApPY3QgIDIgMTU6 MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNDI1ZmY+XSBwZGZsdXNoKzB4Zi8weDIwCk9j dCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE2MTU0MD5dIGRvX2VtZXJnZW5j eV9yZW1vdW50KzB4MC8weDE2MApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8 YzAxMDcyNTA+XSBrZXJuZWxfdGhyZWFkX2hlbHBlcisweDAvMHgxMApPY3QgIDIgMTU6MDk6 NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxMDcyNTU+XSBrZXJuZWxfdGhyZWFkX2hlbHBlcisw eDUvMHgxMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogCk9jdCAgMiAxNTowOTo0 MiAobm9uZSkga2VybmVsOiBiYWQ6IHNjaGVkdWxpbmcgd2hpbGUgYXRvbWljIQpPY3QgIDIg MTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogQ2FsbCBUcmFjZToKT2N0ICAyIDE1OjA5OjQyIChu b25lKSBrZXJuZWw6ICBbPGMwMTFlNmU2Pl0gc2NoZWR1bGUrMHg0MDYvMHg0NDAKT2N0ICAy IDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGQxODc3MjYwPl0gYnB1dF9vbmUrMHgwLzB4 MTAgW2V4dDNdCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxkMTg0M2MxNz5d IGpvdXJuYWxfc3RvcCsweDFmNy8weDJlMCBbamJkXQpPY3QgIDIgMTU6MDk6NDIgKG5vbmUp IGtlcm5lbDogIFs8ZDE4NDI1NDk+XSBqb3VybmFsX3N0YXJ0KzB4YTkvMHhkMCBbamJkXQpP Y3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8ZDE4NDNkMzI+XSBqb3VybmFsX2Zv cmNlX2NvbW1pdCsweDMyLzB4NDAgW2piZF0KT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJu ZWw6ICBbPGQxODgwYzM5Pl0gZXh0M19mb3JjZV9jb21taXQrMHgyOS8weDMwIFtleHQzXQpP Y3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxN2JlMDM+XSB3cml0ZV9pbm9k ZSsweDQzLzB4NTAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTdiZjYw Pl0gX19zeW5jX3NpbmdsZV9pbm9kZSsweDE1MC8weDI0MApPY3QgIDIgMTU6MDk6NDIgKG5v bmUpIGtlcm5lbDogIFs8YzAxN2MyOGU+XSBzeW5jX3NiX2lub2RlcysweDE3ZS8weDJhMApP Y3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxN2M0ZTQ+XSBzeW5jX2lub2Rl c19zYisweDg0LzB4YTAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGQxODgw YzcwPl0gZXh0M19zeW5jX2ZzKzB4MC8weDcwIFtleHQzXQpPY3QgIDIgMTU6MDk6NDIgKG5v bmUpIGtlcm5lbDogIFs8YzAxNWI4YWE+XSBmc3luY19zdXBlcisweDdhLzB4YjAKT2N0ICAy IDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTYxNDg3Pl0gZG9fcmVtb3VudF9zYisw eDM3LzB4ZjAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTYxNWU3Pl0g ZG9fZW1lcmdlbmN5X3JlbW91bnQrMHhhNy8weDE2MApPY3QgIDIgMTU6MDk6NDIgKG5vbmUp IGtlcm5lbDogIFs8YzAxNDI0ZGE+XSBfX3BkZmx1c2grMHhkYS8weDFmMApPY3QgIDIgMTU6 MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNDI1ZjA+XSBwZGZsdXNoKzB4MC8weDIwCk9j dCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE0MjVmZj5dIHBkZmx1c2grMHhm LzB4MjAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTYxNTQwPl0gZG9f ZW1lcmdlbmN5X3JlbW91bnQrMHgwLzB4MTYwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2Vy bmVsOiAgWzxjMDEwNzI1MD5dIGtlcm5lbF90aHJlYWRfaGVscGVyKzB4MC8weDEwCk9jdCAg MiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDEwNzI1NT5dIGtlcm5lbF90aHJlYWRf aGVscGVyKzB4NS8weDEwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAKT2N0ICAy IDE1OjA5OjQyIChub25lKSBrZXJuZWw6IGJhZDogc2NoZWR1bGluZyB3aGlsZSBhdG9taWMh Ck9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiBDYWxsIFRyYWNlOgpPY3QgIDIgMTU6 MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxMWU2ZTY+XSBzY2hlZHVsZSsweDQwNi8weDQ0 MApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8ZDE4NzcyNjA+XSBicHV0X29u ZSsweDAvMHgxMCBbZXh0M10KT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGQx ODQzYzE3Pl0gam91cm5hbF9zdG9wKzB4MWY3LzB4MmUwIFtqYmRdCk9jdCAgMiAxNTowOTo0 MiAobm9uZSkga2VybmVsOiAgWzxkMTg0MjU0OT5dIGpvdXJuYWxfc3RhcnQrMHhhOS8weGQw IFtqYmRdCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxkMTg0M2QzMj5dIGpv dXJuYWxfZm9yY2VfY29tbWl0KzB4MzIvMHg0MCBbamJkXQpPY3QgIDIgMTU6MDk6NDIgKG5v bmUpIGtlcm5lbDogIFs8ZDE4ODBjMzk+XSBleHQzX2ZvcmNlX2NvbW1pdCsweDI5LzB4MzAg W2V4dDNdCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE3YmUwMz5dIHdy aXRlX2lub2RlKzB4NDMvMHg1MApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8 YzAxN2JmNjA+XSBfX3N5bmNfc2luZ2xlX2lub2RlKzB4MTUwLzB4MjQwCk9jdCAgMiAxNTow OTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE3YzI4ZT5dIHN5bmNfc2JfaW5vZGVzKzB4MTdl LzB4MmEwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE3YzRlND5dIHN5 bmNfaW5vZGVzX3NiKzB4ODQvMHhhMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDog IFs8ZDE4ODBjNzA+XSBleHQzX3N5bmNfZnMrMHgwLzB4NzAgW2V4dDNdCk9jdCAgMiAxNTow OTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE1YjhhYT5dIGZzeW5jX3N1cGVyKzB4N2EvMHhi MApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNjE0ODc+XSBkb19yZW1v dW50X3NiKzB4MzcvMHhmMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAx NjE1ZTc+XSBkb19lbWVyZ2VuY3lfcmVtb3VudCsweGE3LzB4MTYwCk9jdCAgMiAxNTowOTo0 MiAobm9uZSkga2VybmVsOiAgWzxjMDE0MjRkYT5dIF9fcGRmbHVzaCsweGRhLzB4MWYwCk9j dCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE0MjVmMD5dIHBkZmx1c2grMHgw LzB4MjAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTQyNWZmPl0gcGRm bHVzaCsweGYvMHgyMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNjE1 NDA+XSBkb19lbWVyZ2VuY3lfcmVtb3VudCsweDAvMHgxNjAKT2N0ICAyIDE1OjA5OjQyIChu b25lKSBrZXJuZWw6ICBbPGMwMTA3MjUwPl0ga2VybmVsX3RocmVhZF9oZWxwZXIrMHgwLzB4 MTAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTA3MjU1Pl0ga2VybmVs X3RocmVhZF9oZWxwZXIrMHg1LzB4MTAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6 IApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogYmFkOiBzY2hlZHVsaW5nIHdoaWxl IGF0b21pYyEKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6IENhbGwgVHJhY2U6Ck9j dCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDExZTZlNj5dIHNjaGVkdWxlKzB4 NDA2LzB4NDQwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxkMTg3NzI2MD5d IGJwdXRfb25lKzB4MC8weDEwIFtleHQzXQpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5l bDogIFs8ZDE4NDNjMTc+XSBqb3VybmFsX3N0b3ArMHgxZjcvMHgyZTAgW2piZF0KT2N0ICAy IDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGQxODQyNTQ5Pl0gam91cm5hbF9zdGFydCsw eGE5LzB4ZDAgW2piZF0KT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGQxODQz ZDMyPl0gam91cm5hbF9mb3JjZV9jb21taXQrMHgzMi8weDQwIFtqYmRdCk9jdCAgMiAxNTow OTo0MiAobm9uZSkga2VybmVsOiAgWzxkMTg4MGMzOT5dIGV4dDNfZm9yY2VfY29tbWl0KzB4 MjkvMHgzMCBbZXh0M10KT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTdi ZTAzPl0gd3JpdGVfaW5vZGUrMHg0My8weDUwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2Vy bmVsOiAgWzxjMDE3YmY2MD5dIF9fc3luY19zaW5nbGVfaW5vZGUrMHgxNTAvMHgyNDAKT2N0 ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTdjMjhlPl0gc3luY19zYl9pbm9k ZXMrMHgxN2UvMHgyYTAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTdj NGU0Pl0gc3luY19pbm9kZXNfc2IrMHg4NC8weGEwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkg a2VybmVsOiAgWzxkMTg4MGM3MD5dIGV4dDNfc3luY19mcysweDAvMHg3MCBbZXh0M10KT2N0 ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTViOGFhPl0gZnN5bmNfc3VwZXIr MHg3YS8weGIwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE2MTQ4Nz5d IGRvX3JlbW91bnRfc2IrMHgzNy8weGYwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVs OiAgWzxjMDE2MTVlNz5dIGRvX2VtZXJnZW5jeV9yZW1vdW50KzB4YTcvMHgxNjAKT2N0ICAy IDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTQyNGRhPl0gX19wZGZsdXNoKzB4ZGEv MHgxZjAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTQyNWYwPl0gcGRm bHVzaCsweDAvMHgyMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNDI1 ZmY+XSBwZGZsdXNoKzB4Zi8weDIwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAg WzxjMDE2MTU0MD5dIGRvX2VtZXJnZW5jeV9yZW1vdW50KzB4MC8weDE2MApPY3QgIDIgMTU6 MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxMDcyNTA+XSBrZXJuZWxfdGhyZWFkX2hlbHBl cisweDAvMHgxMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxMDcyNTU+ XSBrZXJuZWxfdGhyZWFkX2hlbHBlcisweDUvMHgxMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUp IGtlcm5lbDogCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiBiYWQ6IHNjaGVkdWxp bmcgd2hpbGUgYXRvbWljIQpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogQ2FsbCBU cmFjZToKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTFlNmU2Pl0gc2No ZWR1bGUrMHg0MDYvMHg0NDAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGQx ODc3MjYwPl0gYnB1dF9vbmUrMHgwLzB4MTAgW2V4dDNdCk9jdCAgMiAxNTowOTo0MiAobm9u ZSkga2VybmVsOiAgWzxkMTg0M2MxNz5dIGpvdXJuYWxfc3RvcCsweDFmNy8weDJlMCBbamJk XQpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8ZDE4NDI1NDk+XSBqb3VybmFs X3N0YXJ0KzB4YTkvMHhkMCBbamJkXQpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDog IFs8ZDE4NDNkMzI+XSBqb3VybmFsX2ZvcmNlX2NvbW1pdCsweDMyLzB4NDAgW2piZF0KT2N0 ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGQxODgwYzM5Pl0gZXh0M19mb3JjZV9j b21taXQrMHgyOS8weDMwIFtleHQzXQpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDog IFs8YzAxN2JlMDM+XSB3cml0ZV9pbm9kZSsweDQzLzB4NTAKT2N0ICAyIDE1OjA5OjQyIChu b25lKSBrZXJuZWw6ICBbPGMwMTdiZjYwPl0gX19zeW5jX3NpbmdsZV9pbm9kZSsweDE1MC8w eDI0MApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxN2MyOGU+XSBzeW5j X3NiX2lub2RlcysweDE3ZS8weDJhMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDog IFs8YzAxN2M0ZTQ+XSBzeW5jX2lub2Rlc19zYisweDg0LzB4YTAKT2N0ICAyIDE1OjA5OjQy IChub25lKSBrZXJuZWw6ICBbPGQxODgwYzcwPl0gZXh0M19zeW5jX2ZzKzB4MC8weDcwIFtl eHQzXQpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNWI4YWE+XSBmc3lu Y19zdXBlcisweDdhLzB4YjAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMw MTYxNDg3Pl0gZG9fcmVtb3VudF9zYisweDM3LzB4ZjAKT2N0ICAyIDE1OjA5OjQyIChub25l KSBrZXJuZWw6ICBbPGMwMTYxNWU3Pl0gZG9fZW1lcmdlbmN5X3JlbW91bnQrMHhhNy8weDE2 MApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNDI0ZGE+XSBfX3BkZmx1 c2grMHhkYS8weDFmMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNDI1 ZjA+XSBwZGZsdXNoKzB4MC8weDIwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAg WzxjMDE0MjVmZj5dIHBkZmx1c2grMHhmLzB4MjAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBr ZXJuZWw6ICBbPGMwMTYxNTQwPl0gZG9fZW1lcmdlbmN5X3JlbW91bnQrMHgwLzB4MTYwCk9j dCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDEwNzI1MD5dIGtlcm5lbF90aHJl YWRfaGVscGVyKzB4MC8weDEwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxj MDEwNzI1NT5dIGtlcm5lbF90aHJlYWRfaGVscGVyKzB4NS8weDEwCk9jdCAgMiAxNTowOTo0 MiAobm9uZSkga2VybmVsOiAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6IGJhZDog c2NoZWR1bGluZyB3aGlsZSBhdG9taWMhCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVs OiBDYWxsIFRyYWNlOgpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxMWU2 ZTY+XSBzY2hlZHVsZSsweDQwNi8weDQ0MApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5l bDogIFs8ZDE4NzcyNjA+XSBicHV0X29uZSsweDAvMHgxMCBbZXh0M10KT2N0ICAyIDE1OjA5 OjQyIChub25lKSBrZXJuZWw6ICBbPGQxODQzYzE3Pl0gam91cm5hbF9zdG9wKzB4MWY3LzB4 MmUwIFtqYmRdCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxkMTg0MjU0OT5d IGpvdXJuYWxfc3RhcnQrMHhhOS8weGQwIFtqYmRdCk9jdCAgMiAxNTowOTo0MiAobm9uZSkg a2VybmVsOiAgWzxkMTg0M2QzMj5dIGpvdXJuYWxfZm9yY2VfY29tbWl0KzB4MzIvMHg0MCBb amJkXQpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8ZDE4ODBjMzk+XSBleHQz X2ZvcmNlX2NvbW1pdCsweDI5LzB4MzAgW2V4dDNdCk9jdCAgMiAxNTowOTo0MiAobm9uZSkg a2VybmVsOiAgWzxjMDE3YmUwMz5dIHdyaXRlX2lub2RlKzB4NDMvMHg1MApPY3QgIDIgMTU6 MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxN2JmNjA+XSBfX3N5bmNfc2luZ2xlX2lub2Rl KzB4MTUwLzB4MjQwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE3YzI4 ZT5dIHN5bmNfc2JfaW5vZGVzKzB4MTdlLzB4MmEwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkg a2VybmVsOiAgWzxjMDE3YzRlND5dIHN5bmNfaW5vZGVzX3NiKzB4ODQvMHhhMApPY3QgIDIg MTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8ZDE4ODBjNzA+XSBleHQzX3N5bmNfZnMrMHgw LzB4NzAgW2V4dDNdCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE1Yjhh YT5dIGZzeW5jX3N1cGVyKzB4N2EvMHhiMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5l bDogIFs8YzAxNjE0ODc+XSBkb19yZW1vdW50X3NiKzB4MzcvMHhmMApPY3QgIDIgMTU6MDk6 NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNjE1ZTc+XSBkb19lbWVyZ2VuY3lfcmVtb3VudCsw eGE3LzB4MTYwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE0MjRkYT5d IF9fcGRmbHVzaCsweGRhLzB4MWYwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAg WzxjMDE0MjVmMD5dIHBkZmx1c2grMHgwLzB4MjAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBr ZXJuZWw6ICBbPGMwMTQyNWZmPl0gcGRmbHVzaCsweGYvMHgyMApPY3QgIDIgMTU6MDk6NDIg KG5vbmUpIGtlcm5lbDogIFs8YzAxNjE1NDA+XSBkb19lbWVyZ2VuY3lfcmVtb3VudCsweDAv MHgxNjAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTA3MjUwPl0ga2Vy bmVsX3RocmVhZF9oZWxwZXIrMHgwLzB4MTAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJu ZWw6ICBbPGMwMTA3MjU1Pl0ga2VybmVsX3RocmVhZF9oZWxwZXIrMHg1LzB4MTAKT2N0ICAy IDE1OjA5OjQyIChub25lKSBrZXJuZWw6IApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5l bDogYmFkOiBzY2hlZHVsaW5nIHdoaWxlIGF0b21pYyEKT2N0ICAyIDE1OjA5OjQyIChub25l KSBrZXJuZWw6IENhbGwgVHJhY2U6Ck9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAg WzxjMDExZTZlNj5dIHNjaGVkdWxlKzB4NDA2LzB4NDQwCk9jdCAgMiAxNTowOTo0MiAobm9u ZSkga2VybmVsOiAgWzxkMTg3NzI2MD5dIGJwdXRfb25lKzB4MC8weDEwIFtleHQzXQpPY3Qg IDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8ZDE4NDNjMTc+XSBqb3VybmFsX3N0b3Ar MHgxZjcvMHgyZTAgW2piZF0KT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGQx ODQyNTQ5Pl0gam91cm5hbF9zdGFydCsweGE5LzB4ZDAgW2piZF0KT2N0ICAyIDE1OjA5OjQy IChub25lKSBrZXJuZWw6ICBbPGQxODQzZDMyPl0gam91cm5hbF9mb3JjZV9jb21taXQrMHgz Mi8weDQwIFtqYmRdCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxkMTg4MGMz OT5dIGV4dDNfZm9yY2VfY29tbWl0KzB4MjkvMHgzMCBbZXh0M10KT2N0ICAyIDE1OjA5OjQy IChub25lKSBrZXJuZWw6ICBbPGMwMTdiZTAzPl0gd3JpdGVfaW5vZGUrMHg0My8weDUwCk9j dCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE3YmY2MD5dIF9fc3luY19zaW5n bGVfaW5vZGUrMHgxNTAvMHgyNDAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBb PGMwMTdjMjhlPl0gc3luY19zYl9pbm9kZXMrMHgxN2UvMHgyYTAKT2N0ICAyIDE1OjA5OjQy IChub25lKSBrZXJuZWw6ICBbPGMwMTdjNGU0Pl0gc3luY19pbm9kZXNfc2IrMHg4NC8weGEw Ck9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxkMTg4MGM3MD5dIGV4dDNfc3lu Y19mcysweDAvMHg3MCBbZXh0M10KT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBb PGMwMTViOGFhPl0gZnN5bmNfc3VwZXIrMHg3YS8weGIwCk9jdCAgMiAxNTowOTo0MiAobm9u ZSkga2VybmVsOiAgWzxjMDE2MTQ4Nz5dIGRvX3JlbW91bnRfc2IrMHgzNy8weGYwCk9jdCAg MiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE2MTVlNz5dIGRvX2VtZXJnZW5jeV9y ZW1vdW50KzB4YTcvMHgxNjAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMw MTQyNGRhPl0gX19wZGZsdXNoKzB4ZGEvMHgxZjAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBr ZXJuZWw6ICBbPGMwMTQyNWYwPl0gcGRmbHVzaCsweDAvMHgyMApPY3QgIDIgMTU6MDk6NDIg KG5vbmUpIGtlcm5lbDogIFs8YzAxNDI1ZmY+XSBwZGZsdXNoKzB4Zi8weDIwCk9jdCAgMiAx NTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE2MTU0MD5dIGRvX2VtZXJnZW5jeV9yZW1v dW50KzB4MC8weDE2MApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxMDcy NTA+XSBrZXJuZWxfdGhyZWFkX2hlbHBlcisweDAvMHgxMApPY3QgIDIgMTU6MDk6NDIgKG5v bmUpIGtlcm5lbDogIFs8YzAxMDcyNTU+XSBrZXJuZWxfdGhyZWFkX2hlbHBlcisweDUvMHgx MApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogCk9jdCAgMiAxNTowOTo0MiAobm9u ZSkga2VybmVsOiBiYWQ6IHNjaGVkdWxpbmcgd2hpbGUgYXRvbWljIQpPY3QgIDIgMTU6MDk6 NDIgKG5vbmUpIGtlcm5lbDogQ2FsbCBUcmFjZToKT2N0ICAyIDE1OjA5OjQyIChub25lKSBr ZXJuZWw6ICBbPGMwMTFlNmU2Pl0gc2NoZWR1bGUrMHg0MDYvMHg0NDAKT2N0ICAyIDE1OjA5 OjQyIChub25lKSBrZXJuZWw6ICBbPGQxODc3MjYwPl0gYnB1dF9vbmUrMHgwLzB4MTAgW2V4 dDNdCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxkMTg0M2MxNz5dIGpvdXJu YWxfc3RvcCsweDFmNy8weDJlMCBbamJkXQpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5l bDogIFs8ZDE4NDI1NDk+XSBqb3VybmFsX3N0YXJ0KzB4YTkvMHhkMCBbamJkXQpPY3QgIDIg MTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8ZDE4NDNkMzI+XSBqb3VybmFsX2ZvcmNlX2Nv bW1pdCsweDMyLzB4NDAgW2piZF0KT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBb PGQxODgwYzM5Pl0gZXh0M19mb3JjZV9jb21taXQrMHgyOS8weDMwIFtleHQzXQpPY3QgIDIg MTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxN2JlMDM+XSB3cml0ZV9pbm9kZSsweDQz LzB4NTAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTdiZjYwPl0gX19z eW5jX3NpbmdsZV9pbm9kZSsweDE1MC8weDI0MApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtl cm5lbDogIFs8YzAxN2MyOGU+XSBzeW5jX3NiX2lub2RlcysweDE3ZS8weDJhMApPY3QgIDIg MTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxN2M0ZTQ+XSBzeW5jX2lub2Rlc19zYisw eDg0LzB4YTAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGQxODgwYzcwPl0g ZXh0M19zeW5jX2ZzKzB4MC8weDcwIFtleHQzXQpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtl cm5lbDogIFs8YzAxNWI4YWE+XSBmc3luY19zdXBlcisweDdhLzB4YjAKT2N0ICAyIDE1OjA5 OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTYxNDg3Pl0gZG9fcmVtb3VudF9zYisweDM3LzB4 ZjAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTYxNWU3Pl0gZG9fZW1l cmdlbmN5X3JlbW91bnQrMHhhNy8weDE2MApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5l bDogIFs8YzAxNDI0ZGE+XSBfX3BkZmx1c2grMHhkYS8weDFmMApPY3QgIDIgMTU6MDk6NDIg KG5vbmUpIGtlcm5lbDogIFs8YzAxNDI1ZjA+XSBwZGZsdXNoKzB4MC8weDIwCk9jdCAgMiAx NTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE0MjVmZj5dIHBkZmx1c2grMHhmLzB4MjAK T2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTYxNTQwPl0gZG9fZW1lcmdl bmN5X3JlbW91bnQrMHgwLzB4MTYwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAg WzxjMDEwNzI1MD5dIGtlcm5lbF90aHJlYWRfaGVscGVyKzB4MC8weDEwCk9jdCAgMiAxNTow OTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDEwNzI1NT5dIGtlcm5lbF90aHJlYWRfaGVscGVy KzB4NS8weDEwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAKT2N0ICAyIDE1OjA5 OjQyIChub25lKSBrZXJuZWw6IGJhZDogc2NoZWR1bGluZyB3aGlsZSBhdG9taWMhCk9jdCAg MiAxNTowOTo0MiAobm9uZSkga2VybmVsOiBDYWxsIFRyYWNlOgpPY3QgIDIgMTU6MDk6NDIg KG5vbmUpIGtlcm5lbDogIFs8YzAxMWU2ZTY+XSBzY2hlZHVsZSsweDQwNi8weDQ0MApPY3Qg IDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8ZDE4NzcyNjA+XSBicHV0X29uZSsweDAv MHgxMCBbZXh0M10KT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGQxODQzYzE3 Pl0gam91cm5hbF9zdG9wKzB4MWY3LzB4MmUwIFtqYmRdCk9jdCAgMiAxNTowOTo0MiAobm9u ZSkga2VybmVsOiAgWzxkMTg0MjU0OT5dIGpvdXJuYWxfc3RhcnQrMHhhOS8weGQwIFtqYmRd Ck9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxkMTg0M2QzMj5dIGpvdXJuYWxf Zm9yY2VfY29tbWl0KzB4MzIvMHg0MCBbamJkXQpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtl cm5lbDogIFs8ZDE4ODBjMzk+XSBleHQzX2ZvcmNlX2NvbW1pdCsweDI5LzB4MzAgW2V4dDNd Ck9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE3YmUwMz5dIHdyaXRlX2lu b2RlKzB4NDMvMHg1MApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxN2Jm NjA+XSBfX3N5bmNfc2luZ2xlX2lub2RlKzB4MTUwLzB4MjQwCk9jdCAgMiAxNTowOTo0MiAo bm9uZSkga2VybmVsOiAgWzxjMDE3YzI4ZT5dIHN5bmNfc2JfaW5vZGVzKzB4MTdlLzB4MmEw Ck9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE3YzRlND5dIHN5bmNfaW5v ZGVzX3NiKzB4ODQvMHhhMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8ZDE4 ODBjNzA+XSBleHQzX3N5bmNfZnMrMHgwLzB4NzAgW2V4dDNdCk9jdCAgMiAxNTowOTo0MiAo bm9uZSkga2VybmVsOiAgWzxjMDE1YjhhYT5dIGZzeW5jX3N1cGVyKzB4N2EvMHhiMApPY3Qg IDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNjE0ODc+XSBkb19yZW1vdW50X3Ni KzB4MzcvMHhmMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNjE1ZTc+ XSBkb19lbWVyZ2VuY3lfcmVtb3VudCsweGE3LzB4MTYwCk9jdCAgMiAxNTowOTo0MiAobm9u ZSkga2VybmVsOiAgWzxjMDE0MjRkYT5dIF9fcGRmbHVzaCsweGRhLzB4MWYwCk9jdCAgMiAx NTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE0MjVmMD5dIHBkZmx1c2grMHgwLzB4MjAK T2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTQyNWZmPl0gcGRmbHVzaCsw eGYvMHgyMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNjE1NDA+XSBk b19lbWVyZ2VuY3lfcmVtb3VudCsweDAvMHgxNjAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBr ZXJuZWw6ICBbPGMwMTA3MjUwPl0ga2VybmVsX3RocmVhZF9oZWxwZXIrMHgwLzB4MTAKT2N0 ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTA3MjU1Pl0ga2VybmVsX3RocmVh ZF9oZWxwZXIrMHg1LzB4MTAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6IApPY3Qg IDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogYmFkOiBzY2hlZHVsaW5nIHdoaWxlIGF0b21p YyEKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6IENhbGwgVHJhY2U6Ck9jdCAgMiAx NTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDExZTZlNj5dIHNjaGVkdWxlKzB4NDA2LzB4 NDQwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxkMTg3NzI2MD5dIGJwdXRf b25lKzB4MC8weDEwIFtleHQzXQpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8 ZDE4NDNjMTc+XSBqb3VybmFsX3N0b3ArMHgxZjcvMHgyZTAgW2piZF0KT2N0ICAyIDE1OjA5 OjQyIChub25lKSBrZXJuZWw6ICBbPGQxODQyNTQ5Pl0gam91cm5hbF9zdGFydCsweGE5LzB4 ZDAgW2piZF0KT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGQxODQzZDMyPl0g am91cm5hbF9mb3JjZV9jb21taXQrMHgzMi8weDQwIFtqYmRdCk9jdCAgMiAxNTowOTo0MiAo bm9uZSkga2VybmVsOiAgWzxkMTg4MGMzOT5dIGV4dDNfZm9yY2VfY29tbWl0KzB4MjkvMHgz MCBbZXh0M10KT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTdiZTAzPl0g d3JpdGVfaW5vZGUrMHg0My8weDUwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAg WzxjMDE3YmY2MD5dIF9fc3luY19zaW5nbGVfaW5vZGUrMHgxNTAvMHgyNDAKT2N0ICAyIDE1 OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTdjMjhlPl0gc3luY19zYl9pbm9kZXMrMHgx N2UvMHgyYTAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTdjNGU0Pl0g c3luY19pbm9kZXNfc2IrMHg4NC8weGEwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVs OiAgWzxkMTg4MGM3MD5dIGV4dDNfc3luY19mcysweDAvMHg3MCBbZXh0M10KT2N0ICAyIDE1 OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTViOGFhPl0gZnN5bmNfc3VwZXIrMHg3YS8w eGIwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE2MTQ4Nz5dIGRvX3Jl bW91bnRfc2IrMHgzNy8weGYwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxj MDE2MTVlNz5dIGRvX2VtZXJnZW5jeV9yZW1vdW50KzB4YTcvMHgxNjAKT2N0ICAyIDE1OjA5 OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTQyNGRhPl0gX19wZGZsdXNoKzB4ZGEvMHgxZjAK T2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTQyNWYwPl0gcGRmbHVzaCsw eDAvMHgyMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNDI1ZmY+XSBw ZGZsdXNoKzB4Zi8weDIwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE2 MTU0MD5dIGRvX2VtZXJnZW5jeV9yZW1vdW50KzB4MC8weDE2MApPY3QgIDIgMTU6MDk6NDIg KG5vbmUpIGtlcm5lbDogIFs8YzAxMDcyNTA+XSBrZXJuZWxfdGhyZWFkX2hlbHBlcisweDAv MHgxMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxMDcyNTU+XSBrZXJu ZWxfdGhyZWFkX2hlbHBlcisweDUvMHgxMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5l bDogCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiBiYWQ6IHNjaGVkdWxpbmcgd2hp bGUgYXRvbWljIQpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogQ2FsbCBUcmFjZToK T2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTFlNmU2Pl0gc2NoZWR1bGUr MHg0MDYvMHg0NDAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGQxODc3MjYw Pl0gYnB1dF9vbmUrMHgwLzB4MTAgW2V4dDNdCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2Vy bmVsOiAgWzxkMTg0M2MxNz5dIGpvdXJuYWxfc3RvcCsweDFmNy8weDJlMCBbamJkXQpPY3Qg IDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8ZDE4NDI1NDk+XSBqb3VybmFsX3N0YXJ0 KzB4YTkvMHhkMCBbamJkXQpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8ZDE4 NDNkMzI+XSBqb3VybmFsX2ZvcmNlX2NvbW1pdCsweDMyLzB4NDAgW2piZF0KT2N0ICAyIDE1 OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGQxODgwYzM5Pl0gZXh0M19mb3JjZV9jb21taXQr MHgyOS8weDMwIFtleHQzXQpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAx N2JlMDM+XSB3cml0ZV9pbm9kZSsweDQzLzB4NTAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBr ZXJuZWw6ICBbPGMwMTdiZjYwPl0gX19zeW5jX3NpbmdsZV9pbm9kZSsweDE1MC8weDI0MApP Y3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxN2MyOGU+XSBzeW5jX3NiX2lu b2RlcysweDE3ZS8weDJhMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAx N2M0ZTQ+XSBzeW5jX2lub2Rlc19zYisweDg0LzB4YTAKT2N0ICAyIDE1OjA5OjQyIChub25l KSBrZXJuZWw6ICBbPGQxODgwYzcwPl0gZXh0M19zeW5jX2ZzKzB4MC8weDcwIFtleHQzXQpP Y3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNWI4YWE+XSBmc3luY19zdXBl cisweDdhLzB4YjAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTYxNDg3 Pl0gZG9fcmVtb3VudF9zYisweDM3LzB4ZjAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJu ZWw6ICBbPGMwMTYxNWU3Pl0gZG9fZW1lcmdlbmN5X3JlbW91bnQrMHhhNy8weDE2MApPY3Qg IDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNDI0ZGE+XSBfX3BkZmx1c2grMHhk YS8weDFmMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNDI1ZjA+XSBw ZGZsdXNoKzB4MC8weDIwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE0 MjVmZj5dIHBkZmx1c2grMHhmLzB4MjAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6 ICBbPGMwMTYxNTQwPl0gZG9fZW1lcmdlbmN5X3JlbW91bnQrMHgwLzB4MTYwCk9jdCAgMiAx NTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDEwNzI1MD5dIGtlcm5lbF90aHJlYWRfaGVs cGVyKzB4MC8weDEwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDEwNzI1 NT5dIGtlcm5lbF90aHJlYWRfaGVscGVyKzB4NS8weDEwCk9jdCAgMiAxNTowOTo0MiAobm9u ZSkga2VybmVsOiAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6IGJhZDogc2NoZWR1 bGluZyB3aGlsZSBhdG9taWMhCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiBDYWxs IFRyYWNlOgpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxMWU2ZTY+XSBz Y2hlZHVsZSsweDQwNi8weDQ0MApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8 ZDE4NzcyNjA+XSBicHV0X29uZSsweDAvMHgxMCBbZXh0M10KT2N0ICAyIDE1OjA5OjQyIChu b25lKSBrZXJuZWw6ICBbPGQxODQzYzE3Pl0gam91cm5hbF9zdG9wKzB4MWY3LzB4MmUwIFtq YmRdCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxkMTg0MjU0OT5dIGpvdXJu YWxfc3RhcnQrMHhhOS8weGQwIFtqYmRdCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVs OiAgWzxkMTg0M2QzMj5dIGpvdXJuYWxfZm9yY2VfY29tbWl0KzB4MzIvMHg0MCBbamJkXQpP Y3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8ZDE4ODBjMzk+XSBleHQzX2ZvcmNl X2NvbW1pdCsweDI5LzB4MzAgW2V4dDNdCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVs OiAgWzxjMDE3YmUwMz5dIHdyaXRlX2lub2RlKzB4NDMvMHg1MApPY3QgIDIgMTU6MDk6NDIg KG5vbmUpIGtlcm5lbDogIFs8YzAxN2JmNjA+XSBfX3N5bmNfc2luZ2xlX2lub2RlKzB4MTUw LzB4MjQwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE3YzI4ZT5dIHN5 bmNfc2JfaW5vZGVzKzB4MTdlLzB4MmEwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVs OiAgWzxjMDE3YzRlND5dIHN5bmNfaW5vZGVzX3NiKzB4ODQvMHhhMApPY3QgIDIgMTU6MDk6 NDIgKG5vbmUpIGtlcm5lbDogIFs8ZDE4ODBjNzA+XSBleHQzX3N5bmNfZnMrMHgwLzB4NzAg W2V4dDNdCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE1YjhhYT5dIGZz eW5jX3N1cGVyKzB4N2EvMHhiMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8 YzAxNjE0ODc+XSBkb19yZW1vdW50X3NiKzB4MzcvMHhmMApPY3QgIDIgMTU6MDk6NDIgKG5v bmUpIGtlcm5lbDogIFs8YzAxNjE1ZTc+XSBkb19lbWVyZ2VuY3lfcmVtb3VudCsweGE3LzB4 MTYwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE0MjRkYT5dIF9fcGRm bHVzaCsweGRhLzB4MWYwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE0 MjVmMD5dIHBkZmx1c2grMHgwLzB4MjAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6 ICBbPGMwMTQyNWZmPl0gcGRmbHVzaCsweGYvMHgyMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUp IGtlcm5lbDogIFs8YzAxNjE1NDA+XSBkb19lbWVyZ2VuY3lfcmVtb3VudCsweDAvMHgxNjAK T2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTA3MjUwPl0ga2VybmVsX3Ro cmVhZF9oZWxwZXIrMHgwLzB4MTAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBb PGMwMTA3MjU1Pl0ga2VybmVsX3RocmVhZF9oZWxwZXIrMHg1LzB4MTAKT2N0ICAyIDE1OjA5 OjQyIChub25lKSBrZXJuZWw6IApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogYmFk OiBzY2hlZHVsaW5nIHdoaWxlIGF0b21pYyEKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJu ZWw6IENhbGwgVHJhY2U6Ck9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDEx ZTZlNj5dIHNjaGVkdWxlKzB4NDA2LzB4NDQwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2Vy bmVsOiAgWzxkMTg3NzI2MD5dIGJwdXRfb25lKzB4MC8weDEwIFtleHQzXQpPY3QgIDIgMTU6 MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8ZDE4NDNjMTc+XSBqb3VybmFsX3N0b3ArMHgxZjcv MHgyZTAgW2piZF0KT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGQxODQyNTQ5 Pl0gam91cm5hbF9zdGFydCsweGE5LzB4ZDAgW2piZF0KT2N0ICAyIDE1OjA5OjQyIChub25l KSBrZXJuZWw6ICBbPGQxODQzZDMyPl0gam91cm5hbF9mb3JjZV9jb21taXQrMHgzMi8weDQw IFtqYmRdCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxkMTg4MGMzOT5dIGV4 dDNfZm9yY2VfY29tbWl0KzB4MjkvMHgzMCBbZXh0M10KT2N0ICAyIDE1OjA5OjQyIChub25l KSBrZXJuZWw6ICBbPGMwMTdiZTAzPl0gd3JpdGVfaW5vZGUrMHg0My8weDUwCk9jdCAgMiAx NTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE3YmY2MD5dIF9fc3luY19zaW5nbGVfaW5v ZGUrMHgxNTAvMHgyNDAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTdj MjhlPl0gc3luY19zYl9pbm9kZXMrMHgxN2UvMHgyYTAKT2N0ICAyIDE1OjA5OjQyIChub25l KSBrZXJuZWw6ICBbPGMwMTdjNGU0Pl0gc3luY19pbm9kZXNfc2IrMHg4NC8weGEwCk9jdCAg MiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxkMTg4MGM3MD5dIGV4dDNfc3luY19mcysw eDAvMHg3MCBbZXh0M10KT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTVi OGFhPl0gZnN5bmNfc3VwZXIrMHg3YS8weGIwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2Vy bmVsOiAgWzxjMDE2MTQ4Nz5dIGRvX3JlbW91bnRfc2IrMHgzNy8weGYwCk9jdCAgMiAxNTow OTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE2MTVlNz5dIGRvX2VtZXJnZW5jeV9yZW1vdW50 KzB4YTcvMHgxNjAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTQyNGRh Pl0gX19wZGZsdXNoKzB4ZGEvMHgxZjAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6 ICBbPGMwMTQyNWYwPl0gcGRmbHVzaCsweDAvMHgyMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUp IGtlcm5lbDogIFs8YzAxNDI1ZmY+XSBwZGZsdXNoKzB4Zi8weDIwCk9jdCAgMiAxNTowOTo0 MiAobm9uZSkga2VybmVsOiAgWzxjMDE2MTU0MD5dIGRvX2VtZXJnZW5jeV9yZW1vdW50KzB4 MC8weDE2MApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxMDcyNTA+XSBr ZXJuZWxfdGhyZWFkX2hlbHBlcisweDAvMHgxMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtl cm5lbDogIFs8YzAxMDcyNTU+XSBrZXJuZWxfdGhyZWFkX2hlbHBlcisweDUvMHgxMApPY3Qg IDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2Vy bmVsOiBiYWQ6IHNjaGVkdWxpbmcgd2hpbGUgYXRvbWljIQpPY3QgIDIgMTU6MDk6NDIgKG5v bmUpIGtlcm5lbDogQ2FsbCBUcmFjZToKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6 ICBbPGMwMTFlNmU2Pl0gc2NoZWR1bGUrMHg0MDYvMHg0NDAKT2N0ICAyIDE1OjA5OjQyIChu b25lKSBrZXJuZWw6ICBbPGQxODc3MjYwPl0gYnB1dF9vbmUrMHgwLzB4MTAgW2V4dDNdCk9j dCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxkMTg0M2MxNz5dIGpvdXJuYWxfc3Rv cCsweDFmNy8weDJlMCBbamJkXQpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8 ZDE4NDI1NDk+XSBqb3VybmFsX3N0YXJ0KzB4YTkvMHhkMCBbamJkXQpPY3QgIDIgMTU6MDk6 NDIgKG5vbmUpIGtlcm5lbDogIFs8ZDE4NDNkMzI+XSBqb3VybmFsX2ZvcmNlX2NvbW1pdCsw eDMyLzB4NDAgW2piZF0KT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGQxODgw YzM5Pl0gZXh0M19mb3JjZV9jb21taXQrMHgyOS8weDMwIFtleHQzXQpPY3QgIDIgMTU6MDk6 NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxN2JlMDM+XSB3cml0ZV9pbm9kZSsweDQzLzB4NTAK T2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTdiZjYwPl0gX19zeW5jX3Np bmdsZV9pbm9kZSsweDE1MC8weDI0MApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDog IFs8YzAxN2MyOGU+XSBzeW5jX3NiX2lub2RlcysweDE3ZS8weDJhMApPY3QgIDIgMTU6MDk6 NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxN2M0ZTQ+XSBzeW5jX2lub2Rlc19zYisweDg0LzB4 YTAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGQxODgwYzcwPl0gZXh0M19z eW5jX2ZzKzB4MC8weDcwIFtleHQzXQpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDog IFs8YzAxNWI4YWE+XSBmc3luY19zdXBlcisweDdhLzB4YjAKT2N0ICAyIDE1OjA5OjQyIChu b25lKSBrZXJuZWw6ICBbPGMwMTYxNDg3Pl0gZG9fcmVtb3VudF9zYisweDM3LzB4ZjAKT2N0 ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTYxNWU3Pl0gZG9fZW1lcmdlbmN5 X3JlbW91bnQrMHhhNy8weDE2MApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8 YzAxNDI0ZGE+XSBfX3BkZmx1c2grMHhkYS8weDFmMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUp IGtlcm5lbDogIFs8YzAxNDI1ZjA+XSBwZGZsdXNoKzB4MC8weDIwCk9jdCAgMiAxNTowOTo0 MiAobm9uZSkga2VybmVsOiAgWzxjMDE0MjVmZj5dIHBkZmx1c2grMHhmLzB4MjAKT2N0ICAy IDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTYxNTQwPl0gZG9fZW1lcmdlbmN5X3Jl bW91bnQrMHgwLzB4MTYwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDEw NzI1MD5dIGtlcm5lbF90aHJlYWRfaGVscGVyKzB4MC8weDEwCk9jdCAgMiAxNTowOTo0MiAo bm9uZSkga2VybmVsOiAgWzxjMDEwNzI1NT5dIGtlcm5lbF90aHJlYWRfaGVscGVyKzB4NS8w eDEwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAKT2N0ICAyIDE1OjA5OjQyIChu b25lKSBrZXJuZWw6IGJhZDogc2NoZWR1bGluZyB3aGlsZSBhdG9taWMhCk9jdCAgMiAxNTow OTo0MiAobm9uZSkga2VybmVsOiBDYWxsIFRyYWNlOgpPY3QgIDIgMTU6MDk6NDIgKG5vbmUp IGtlcm5lbDogIFs8YzAxMWU2ZTY+XSBzY2hlZHVsZSsweDQwNi8weDQ0MApPY3QgIDIgMTU6 MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8ZDE4NzcyNjA+XSBicHV0X29uZSsweDAvMHgxMCBb ZXh0M10KT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGQxODQzYzE3Pl0gam91 cm5hbF9zdG9wKzB4MWY3LzB4MmUwIFtqYmRdCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2Vy bmVsOiAgWzxkMTg0MjU0OT5dIGpvdXJuYWxfc3RhcnQrMHhhOS8weGQwIFtqYmRdCk9jdCAg MiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxkMTg0M2QzMj5dIGpvdXJuYWxfZm9yY2Vf Y29tbWl0KzB4MzIvMHg0MCBbamJkXQpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDog IFs8ZDE4ODBjMzk+XSBleHQzX2ZvcmNlX2NvbW1pdCsweDI5LzB4MzAgW2V4dDNdCk9jdCAg MiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE3YmUwMz5dIHdyaXRlX2lub2RlKzB4 NDMvMHg1MApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxN2JmNjA+XSBf X3N5bmNfc2luZ2xlX2lub2RlKzB4MTUwLzB4MjQwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkg a2VybmVsOiAgWzxjMDE3YzI4ZT5dIHN5bmNfc2JfaW5vZGVzKzB4MTdlLzB4MmEwCk9jdCAg MiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE3YzRlND5dIHN5bmNfaW5vZGVzX3Ni KzB4ODQvMHhhMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8ZDE4ODBjNzA+ XSBleHQzX3N5bmNfZnMrMHgwLzB4NzAgW2V4dDNdCk9jdCAgMiAxNTowOTo0MiAobm9uZSkg a2VybmVsOiAgWzxjMDE1YjhhYT5dIGZzeW5jX3N1cGVyKzB4N2EvMHhiMApPY3QgIDIgMTU6 MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNjE0ODc+XSBkb19yZW1vdW50X3NiKzB4Mzcv MHhmMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNjE1ZTc+XSBkb19l bWVyZ2VuY3lfcmVtb3VudCsweGE3LzB4MTYwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2Vy bmVsOiAgWzxjMDE0MjRkYT5dIF9fcGRmbHVzaCsweGRhLzB4MWYwCk9jdCAgMiAxNTowOTo0 MiAobm9uZSkga2VybmVsOiAgWzxjMDE0MjVmMD5dIHBkZmx1c2grMHgwLzB4MjAKT2N0ICAy IDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTQyNWZmPl0gcGRmbHVzaCsweGYvMHgy MApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNjE1NDA+XSBkb19lbWVy Z2VuY3lfcmVtb3VudCsweDAvMHgxNjAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6 ICBbPGMwMTA3MjUwPl0ga2VybmVsX3RocmVhZF9oZWxwZXIrMHgwLzB4MTAKT2N0ICAyIDE1 OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTA3MjU1Pl0ga2VybmVsX3RocmVhZF9oZWxw ZXIrMHg1LzB4MTAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6IApPY3QgIDIgMTU6 MDk6NDIgKG5vbmUpIGtlcm5lbDogYmFkOiBzY2hlZHVsaW5nIHdoaWxlIGF0b21pYyEKT2N0 ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6IENhbGwgVHJhY2U6Ck9jdCAgMiAxNTowOTo0 MiAobm9uZSkga2VybmVsOiAgWzxjMDExZTZlNj5dIHNjaGVkdWxlKzB4NDA2LzB4NDQwCk9j dCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxkMTg3NzI2MD5dIGJwdXRfb25lKzB4 MC8weDEwIFtleHQzXQpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8ZDE4NDNj MTc+XSBqb3VybmFsX3N0b3ArMHgxZjcvMHgyZTAgW2piZF0KT2N0ICAyIDE1OjA5OjQyIChu b25lKSBrZXJuZWw6ICBbPGQxODQyNTQ5Pl0gam91cm5hbF9zdGFydCsweGE5LzB4ZDAgW2pi ZF0KT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGQxODQzZDMyPl0gam91cm5h bF9mb3JjZV9jb21taXQrMHgzMi8weDQwIFtqYmRdCk9jdCAgMiAxNTowOTo0MiAobm9uZSkg a2VybmVsOiAgWzxkMTg4MGMzOT5dIGV4dDNfZm9yY2VfY29tbWl0KzB4MjkvMHgzMCBbZXh0 M10KT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTdiZTAzPl0gd3JpdGVf aW5vZGUrMHg0My8weDUwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE3 YmY2MD5dIF9fc3luY19zaW5nbGVfaW5vZGUrMHgxNTAvMHgyNDAKT2N0ICAyIDE1OjA5OjQy IChub25lKSBrZXJuZWw6ICBbPGMwMTdjMjhlPl0gc3luY19zYl9pbm9kZXMrMHgxN2UvMHgy YTAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTdjNGU0Pl0gc3luY19p bm9kZXNfc2IrMHg4NC8weGEwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxk MTg4MGM3MD5dIGV4dDNfc3luY19mcysweDAvMHg3MCBbZXh0M10KT2N0ICAyIDE1OjA5OjQy IChub25lKSBrZXJuZWw6ICBbPGMwMTViOGFhPl0gZnN5bmNfc3VwZXIrMHg3YS8weGIwCk9j dCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE2MTQ4Nz5dIGRvX3JlbW91bnRf c2IrMHgzNy8weGYwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE2MTVl Nz5dIGRvX2VtZXJnZW5jeV9yZW1vdW50KzB4YTcvMHgxNjAKT2N0ICAyIDE1OjA5OjQyIChu b25lKSBrZXJuZWw6ICBbPGMwMTQyNGRhPl0gX19wZGZsdXNoKzB4ZGEvMHgxZjAKT2N0ICAy IDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTQyNWYwPl0gcGRmbHVzaCsweDAvMHgy MApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNDI1ZmY+XSBwZGZsdXNo KzB4Zi8weDIwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE2MTU0MD5d IGRvX2VtZXJnZW5jeV9yZW1vdW50KzB4MC8weDE2MApPY3QgIDIgMTU6MDk6NDIgKG5vbmUp IGtlcm5lbDogIFs8YzAxMDcyNTA+XSBrZXJuZWxfdGhyZWFkX2hlbHBlcisweDAvMHgxMApP Y3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxMDcyNTU+XSBrZXJuZWxfdGhy ZWFkX2hlbHBlcisweDUvMHgxMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogCk9j dCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiBiYWQ6IHNjaGVkdWxpbmcgd2hpbGUgYXRv bWljIQpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogQ2FsbCBUcmFjZToKT2N0ICAy IDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTFlNmU2Pl0gc2NoZWR1bGUrMHg0MDYv MHg0NDAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGQxODc3MjYwPl0gYnB1 dF9vbmUrMHgwLzB4MTAgW2V4dDNdCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAg WzxkMTg0M2MxNz5dIGpvdXJuYWxfc3RvcCsweDFmNy8weDJlMCBbamJkXQpPY3QgIDIgMTU6 MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8ZDE4NDI1NDk+XSBqb3VybmFsX3N0YXJ0KzB4YTkv MHhkMCBbamJkXQpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8ZDE4NDNkMzI+ XSBqb3VybmFsX2ZvcmNlX2NvbW1pdCsweDMyLzB4NDAgW2piZF0KT2N0ICAyIDE1OjA5OjQy IChub25lKSBrZXJuZWw6ICBbPGQxODgwYzM5Pl0gZXh0M19mb3JjZV9jb21taXQrMHgyOS8w eDMwIFtleHQzXQpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxN2JlMDM+ XSB3cml0ZV9pbm9kZSsweDQzLzB4NTAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6 ICBbPGMwMTdiZjYwPl0gX19zeW5jX3NpbmdsZV9pbm9kZSsweDE1MC8weDI0MApPY3QgIDIg MTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxN2MyOGU+XSBzeW5jX3NiX2lub2Rlcysw eDE3ZS8weDJhMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxN2M0ZTQ+ XSBzeW5jX2lub2Rlc19zYisweDg0LzB4YTAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJu ZWw6ICBbPGQxODgwYzcwPl0gZXh0M19zeW5jX2ZzKzB4MC8weDcwIFtleHQzXQpPY3QgIDIg MTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNWI4YWE+XSBmc3luY19zdXBlcisweDdh LzB4YjAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTYxNDg3Pl0gZG9f cmVtb3VudF9zYisweDM3LzB4ZjAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBb PGMwMTYxNWU3Pl0gZG9fZW1lcmdlbmN5X3JlbW91bnQrMHhhNy8weDE2MApPY3QgIDIgMTU6 MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNDI0ZGE+XSBfX3BkZmx1c2grMHhkYS8weDFm MApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNDI1ZjA+XSBwZGZsdXNo KzB4MC8weDIwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE0MjVmZj5d IHBkZmx1c2grMHhmLzB4MjAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMw MTYxNTQwPl0gZG9fZW1lcmdlbmN5X3JlbW91bnQrMHgwLzB4MTYwCk9jdCAgMiAxNTowOTo0 MiAobm9uZSkga2VybmVsOiAgWzxjMDEwNzI1MD5dIGtlcm5lbF90aHJlYWRfaGVscGVyKzB4 MC8weDEwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDEwNzI1NT5dIGtl cm5lbF90aHJlYWRfaGVscGVyKzB4NS8weDEwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2Vy bmVsOiAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6IGJhZDogc2NoZWR1bGluZyB3 aGlsZSBhdG9taWMhCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiBDYWxsIFRyYWNl OgpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxMWU2ZTY+XSBzY2hlZHVs ZSsweDQwNi8weDQ0MApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8ZDE4Nzcy NjA+XSBicHV0X29uZSsweDAvMHgxMCBbZXh0M10KT2N0ICAyIDE1OjA5OjQyIChub25lKSBr ZXJuZWw6ICBbPGQxODQzYzE3Pl0gam91cm5hbF9zdG9wKzB4MWY3LzB4MmUwIFtqYmRdCk9j dCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxkMTg0MjU0OT5dIGpvdXJuYWxfc3Rh cnQrMHhhOS8weGQwIFtqYmRdCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxk MTg0M2QzMj5dIGpvdXJuYWxfZm9yY2VfY29tbWl0KzB4MzIvMHg0MCBbamJkXQpPY3QgIDIg MTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8ZDE4ODBjMzk+XSBleHQzX2ZvcmNlX2NvbW1p dCsweDI5LzB4MzAgW2V4dDNdCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxj MDE3YmUwMz5dIHdyaXRlX2lub2RlKzB4NDMvMHg1MApPY3QgIDIgMTU6MDk6NDIgKG5vbmUp IGtlcm5lbDogIFs8YzAxN2JmNjA+XSBfX3N5bmNfc2luZ2xlX2lub2RlKzB4MTUwLzB4MjQw Ck9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE3YzI4ZT5dIHN5bmNfc2Jf aW5vZGVzKzB4MTdlLzB4MmEwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxj MDE3YzRlND5dIHN5bmNfaW5vZGVzX3NiKzB4ODQvMHhhMApPY3QgIDIgMTU6MDk6NDIgKG5v bmUpIGtlcm5lbDogIFs8ZDE4ODBjNzA+XSBleHQzX3N5bmNfZnMrMHgwLzB4NzAgW2V4dDNd Ck9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE1YjhhYT5dIGZzeW5jX3N1 cGVyKzB4N2EvMHhiMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNjE0 ODc+XSBkb19yZW1vdW50X3NiKzB4MzcvMHhmMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtl cm5lbDogIFs8YzAxNjE1ZTc+XSBkb19lbWVyZ2VuY3lfcmVtb3VudCsweGE3LzB4MTYwCk9j dCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE0MjRkYT5dIF9fcGRmbHVzaCsw eGRhLzB4MWYwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE0MjVmMD5d IHBkZmx1c2grMHgwLzB4MjAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMw MTQyNWZmPl0gcGRmbHVzaCsweGYvMHgyMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5l bDogIFs8YzAxNjE1NDA+XSBkb19lbWVyZ2VuY3lfcmVtb3VudCsweDAvMHgxNjAKT2N0ICAy IDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTA3MjUwPl0ga2VybmVsX3RocmVhZF9o ZWxwZXIrMHgwLzB4MTAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTA3 MjU1Pl0ga2VybmVsX3RocmVhZF9oZWxwZXIrMHg1LzB4MTAKT2N0ICAyIDE1OjA5OjQyIChu b25lKSBrZXJuZWw6IApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogYmFkOiBzY2hl ZHVsaW5nIHdoaWxlIGF0b21pYyEKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6IENh bGwgVHJhY2U6Ck9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDExZTZlNj5d IHNjaGVkdWxlKzB4NDA2LzB4NDQwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAg WzxkMTg3NzI2MD5dIGJwdXRfb25lKzB4MC8weDEwIFtleHQzXQpPY3QgIDIgMTU6MDk6NDIg KG5vbmUpIGtlcm5lbDogIFs8ZDE4NDNjMTc+XSBqb3VybmFsX3N0b3ArMHgxZjcvMHgyZTAg W2piZF0KT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGQxODQyNTQ5Pl0gam91 cm5hbF9zdGFydCsweGE5LzB4ZDAgW2piZF0KT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJu ZWw6ICBbPGQxODQzZDMyPl0gam91cm5hbF9mb3JjZV9jb21taXQrMHgzMi8weDQwIFtqYmRd Ck9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxkMTg4MGMzOT5dIGV4dDNfZm9y Y2VfY29tbWl0KzB4MjkvMHgzMCBbZXh0M10KT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJu ZWw6ICBbPGMwMTdiZTAzPl0gd3JpdGVfaW5vZGUrMHg0My8weDUwCk9jdCAgMiAxNTowOTo0 MiAobm9uZSkga2VybmVsOiAgWzxjMDE3YmY2MD5dIF9fc3luY19zaW5nbGVfaW5vZGUrMHgx NTAvMHgyNDAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTdjMjhlPl0g c3luY19zYl9pbm9kZXMrMHgxN2UvMHgyYTAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJu ZWw6ICBbPGMwMTdjNGU0Pl0gc3luY19pbm9kZXNfc2IrMHg4NC8weGEwCk9jdCAgMiAxNTow OTo0MiAobm9uZSkga2VybmVsOiAgWzxkMTg4MGM3MD5dIGV4dDNfc3luY19mcysweDAvMHg3 MCBbZXh0M10KT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTViOGFhPl0g ZnN5bmNfc3VwZXIrMHg3YS8weGIwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAg WzxjMDE2MTQ4Nz5dIGRvX3JlbW91bnRfc2IrMHgzNy8weGYwCk9jdCAgMiAxNTowOTo0MiAo bm9uZSkga2VybmVsOiAgWzxjMDE2MTVlNz5dIGRvX2VtZXJnZW5jeV9yZW1vdW50KzB4YTcv MHgxNjAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTQyNGRhPl0gX19w ZGZsdXNoKzB4ZGEvMHgxZjAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMw MTQyNWYwPl0gcGRmbHVzaCsweDAvMHgyMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5l bDogIFs8YzAxNDI1ZmY+XSBwZGZsdXNoKzB4Zi8weDIwCk9jdCAgMiAxNTowOTo0MiAobm9u ZSkga2VybmVsOiAgWzxjMDE2MTU0MD5dIGRvX2VtZXJnZW5jeV9yZW1vdW50KzB4MC8weDE2 MApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxMDcyNTA+XSBrZXJuZWxf dGhyZWFkX2hlbHBlcisweDAvMHgxMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDog IFs8YzAxMDcyNTU+XSBrZXJuZWxfdGhyZWFkX2hlbHBlcisweDUvMHgxMApPY3QgIDIgMTU6 MDk6NDIgKG5vbmUpIGtlcm5lbDogCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiBi YWQ6IHNjaGVkdWxpbmcgd2hpbGUgYXRvbWljIQpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtl cm5lbDogQ2FsbCBUcmFjZToKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMw MTFlNmU2Pl0gc2NoZWR1bGUrMHg0MDYvMHg0NDAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBr ZXJuZWw6ICBbPGQxODQ4YTc4Pl0gbG9nX3dhaXRfY29tbWl0KzB4YjgvMHgxNDAgW2piZF0K T2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTFlNzcwPl0gZGVmYXVsdF93 YWtlX2Z1bmN0aW9uKzB4MC8weDMwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAg WzxkMTg0M2NkMD5dIGpvdXJuYWxfc3RvcCsweDJiMC8weDJlMCBbamJkXQpPY3QgIDIgMTU6 MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8ZDE4NDI1NDk+XSBqb3VybmFsX3N0YXJ0KzB4YTkv MHhkMCBbamJkXQpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8ZDE4NDNkMzI+ XSBqb3VybmFsX2ZvcmNlX2NvbW1pdCsweDMyLzB4NDAgW2piZF0KT2N0ICAyIDE1OjA5OjQy IChub25lKSBrZXJuZWw6ICBbPGQxODgwYzM5Pl0gZXh0M19mb3JjZV9jb21taXQrMHgyOS8w eDMwIFtleHQzXQpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxN2JlMDM+ XSB3cml0ZV9pbm9kZSsweDQzLzB4NTAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6 ICBbPGMwMTdiZjYwPl0gX19zeW5jX3NpbmdsZV9pbm9kZSsweDE1MC8weDI0MApPY3QgIDIg MTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxN2MyOGU+XSBzeW5jX3NiX2lub2Rlcysw eDE3ZS8weDJhMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxN2M0ZTQ+ XSBzeW5jX2lub2Rlc19zYisweDg0LzB4YTAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJu ZWw6ICBbPGQxODgwYzcwPl0gZXh0M19zeW5jX2ZzKzB4MC8weDcwIFtleHQzXQpPY3QgIDIg MTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNWI4YWE+XSBmc3luY19zdXBlcisweDdh LzB4YjAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTYxNDg3Pl0gZG9f cmVtb3VudF9zYisweDM3LzB4ZjAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBb PGMwMTYxNWU3Pl0gZG9fZW1lcmdlbmN5X3JlbW91bnQrMHhhNy8weDE2MApPY3QgIDIgMTU6 MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNDI0ZGE+XSBfX3BkZmx1c2grMHhkYS8weDFm MApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNDI1ZjA+XSBwZGZsdXNo KzB4MC8weDIwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE0MjVmZj5d IHBkZmx1c2grMHhmLzB4MjAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMw MTYxNTQwPl0gZG9fZW1lcmdlbmN5X3JlbW91bnQrMHgwLzB4MTYwCk9jdCAgMiAxNTowOTo0 MiAobm9uZSkga2VybmVsOiAgWzxjMDEwNzI1MD5dIGtlcm5lbF90aHJlYWRfaGVscGVyKzB4 MC8weDEwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDEwNzI1NT5dIGtl cm5lbF90aHJlYWRfaGVscGVyKzB4NS8weDEwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2Vy bmVsOiAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6IGJhZDogc2NoZWR1bGluZyB3 aGlsZSBhdG9taWMhCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiBDYWxsIFRyYWNl OgpPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxMWU2ZTY+XSBzY2hlZHVs ZSsweDQwNi8weDQ0MApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8ZDE4Nzcy NjA+XSBicHV0X29uZSsweDAvMHgxMCBbZXh0M10KT2N0ICAyIDE1OjA5OjQyIChub25lKSBr ZXJuZWw6ICBbPGQxODQzYzE3Pl0gam91cm5hbF9zdG9wKzB4MWY3LzB4MmUwIFtqYmRdCk9j dCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxkMTg0MjU0OT5dIGpvdXJuYWxfc3Rh cnQrMHhhOS8weGQwIFtqYmRdCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxk MTg0M2QzMj5dIGpvdXJuYWxfZm9yY2VfY29tbWl0KzB4MzIvMHg0MCBbamJkXQpPY3QgIDIg MTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8ZDE4ODBjMzk+XSBleHQzX2ZvcmNlX2NvbW1p dCsweDI5LzB4MzAgW2V4dDNdCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxj MDE3YmUwMz5dIHdyaXRlX2lub2RlKzB4NDMvMHg1MApPY3QgIDIgMTU6MDk6NDIgKG5vbmUp IGtlcm5lbDogIFs8YzAxN2JmNjA+XSBfX3N5bmNfc2luZ2xlX2lub2RlKzB4MTUwLzB4MjQw Ck9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE3YzI4ZT5dIHN5bmNfc2Jf aW5vZGVzKzB4MTdlLzB4MmEwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxj MDE3YzRlND5dIHN5bmNfaW5vZGVzX3NiKzB4ODQvMHhhMApPY3QgIDIgMTU6MDk6NDIgKG5v bmUpIGtlcm5lbDogIFs8ZDE4ODBjNzA+XSBleHQzX3N5bmNfZnMrMHgwLzB4NzAgW2V4dDNd Ck9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE1YjhhYT5dIGZzeW5jX3N1 cGVyKzB4N2EvMHhiMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNjE0 ODc+XSBkb19yZW1vdW50X3NiKzB4MzcvMHhmMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtl cm5lbDogIFs8YzAxNjE1ZTc+XSBkb19lbWVyZ2VuY3lfcmVtb3VudCsweGE3LzB4MTYwCk9j dCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE0MjRkYT5dIF9fcGRmbHVzaCsw eGRhLzB4MWYwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE0MjVmMD5d IHBkZmx1c2grMHgwLzB4MjAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMw MTQyNWZmPl0gcGRmbHVzaCsweGYvMHgyMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5l bDogIFs8YzAxNjE1NDA+XSBkb19lbWVyZ2VuY3lfcmVtb3VudCsweDAvMHgxNjAKT2N0ICAy IDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTA3MjUwPl0ga2VybmVsX3RocmVhZF9o ZWxwZXIrMHgwLzB4MTAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTA3 MjU1Pl0ga2VybmVsX3RocmVhZF9oZWxwZXIrMHg1LzB4MTAKT2N0ICAyIDE1OjA5OjQyIChu b25lKSBrZXJuZWw6IApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogYmFkOiBzY2hl ZHVsaW5nIHdoaWxlIGF0b21pYyEKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6IENh bGwgVHJhY2U6Ck9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDExZTZlNj5d IHNjaGVkdWxlKzB4NDA2LzB4NDQwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAg WzxkMTg0OGE3OD5dIGxvZ193YWl0X2NvbW1pdCsweGI4LzB4MTQwIFtqYmRdCk9jdCAgMiAx NTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDExZTc3MD5dIGRlZmF1bHRfd2FrZV9mdW5j dGlvbisweDAvMHgzMApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8ZDE4NDNj ZDA+XSBqb3VybmFsX3N0b3ArMHgyYjAvMHgyZTAgW2piZF0KT2N0ICAyIDE1OjA5OjQyIChu b25lKSBrZXJuZWw6ICBbPGQxODQyNTQ5Pl0gam91cm5hbF9zdGFydCsweGE5LzB4ZDAgW2pi ZF0KT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGQxODQzZDMyPl0gam91cm5h bF9mb3JjZV9jb21taXQrMHgzMi8weDQwIFtqYmRdCk9jdCAgMiAxNTowOTo0MiAobm9uZSkg a2VybmVsOiAgWzxkMTg4MGMzOT5dIGV4dDNfZm9yY2VfY29tbWl0KzB4MjkvMHgzMCBbZXh0 M10KT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTdiZTAzPl0gd3JpdGVf aW5vZGUrMHg0My8weDUwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE3 YmY2MD5dIF9fc3luY19zaW5nbGVfaW5vZGUrMHgxNTAvMHgyNDAKT2N0ICAyIDE1OjA5OjQy IChub25lKSBrZXJuZWw6ICBbPGMwMTdjMjhlPl0gc3luY19zYl9pbm9kZXMrMHgxN2UvMHgy YTAKT2N0ICAyIDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTdjNGU0Pl0gc3luY19p bm9kZXNfc2IrMHg4NC8weGEwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxk MTg4MGM3MD5dIGV4dDNfc3luY19mcysweDAvMHg3MCBbZXh0M10KT2N0ICAyIDE1OjA5OjQy IChub25lKSBrZXJuZWw6ICBbPGMwMTViOGFhPl0gZnN5bmNfc3VwZXIrMHg3YS8weGIwCk9j dCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE2MTQ4Nz5dIGRvX3JlbW91bnRf c2IrMHgzNy8weGYwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE2MTVl Nz5dIGRvX2VtZXJnZW5jeV9yZW1vdW50KzB4YTcvMHgxNjAKT2N0ICAyIDE1OjA5OjQyIChu b25lKSBrZXJuZWw6ICBbPGMwMTQyNGRhPl0gX19wZGZsdXNoKzB4ZGEvMHgxZjAKT2N0ICAy IDE1OjA5OjQyIChub25lKSBrZXJuZWw6ICBbPGMwMTQyNWYwPl0gcGRmbHVzaCsweDAvMHgy MApPY3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxNDI1ZmY+XSBwZGZsdXNo KzB4Zi8weDIwCk9jdCAgMiAxNTowOTo0MiAobm9uZSkga2VybmVsOiAgWzxjMDE2MTU0MD5d IGRvX2VtZXJnZW5jeV9yZW1vdW50KzB4MC8weDE2MApPY3QgIDIgMTU6MDk6NDIgKG5vbmUp IGtlcm5lbDogIFs8YzAxMDcyNTA+XSBrZXJuZWxfdGhyZWFkX2hlbHBlcisweDAvMHgxMApP Y3QgIDIgMTU6MDk6NDIgKG5vbmUpIGtlcm5lbDogIFs8YzAxMDcyNTU+XSBrZXJuZWxfdGhy ZWFkX2hlbHBlcisweDUvMHgxMAo= --------------060309090903090100000100-- From owner-linux-xfs@oss.sgi.com Thu Oct 2 06:07:20 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 02 Oct 2003 06:08:05 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h92D7K25011827 for ; Thu, 2 Oct 2003 06:07:20 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h92D7Eq0016471 for ; Thu, 2 Oct 2003 06:07:15 -0700 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h92D7Ecc11884131; Thu, 2 Oct 2003 08:07:14 -0500 (CDT) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-41.corp.sgi.com [134.15.64.41]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h92D7CRn310966354; Thu, 2 Oct 2003 08:07:13 -0500 (CDT) Subject: Re: Hang on mount with 2.6 From: Steve Lord To: Klaus Strebel Cc: linux-xfs@oss.sgi.com In-Reply-To: <3F7C16EA.9060701@agile.com> References: <3F7C16EA.9060701@agile.com> Content-Type: text/plain Organization: Message-Id: <1065100031.1510.110.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 02 Oct 2003 08:07:12 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 611 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 450 Lines: 18 On Thu, 2003-10-02 at 07:15, Klaus Strebel wrote: > Hi all, > > the latest CVS from linux-2.5-xfs gives me the attached messages on > mount of an xfs filesystem (/home), all preceding mounts are ext3/ext2 > filesystems. I compiled with GCC-3.3 on SuSE-8.2. Any hints, ideas, patches? > > Ciao > Klaus I have been looking at this, no answer yet, time to look at recent diffs and see what we broke I think. Steve -- Steve Lord From owner-linux-xfs@oss.sgi.com Thu Oct 2 06:10:54 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 02 Oct 2003 06:11:27 -0700 (PDT) Received: from goliath.sylaba.poznan.pl (goliath.sylaba.poznan.pl [195.216.104.3]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h92DAh25012285 for ; Thu, 2 Oct 2003 06:10:44 -0700 Received: by goliath.sylaba.poznan.pl (Postfix, from userid 1003) id DD765943F7; Thu, 2 Oct 2003 14:28:49 +0200 (CEST) Received: from venus.local.navi.pl (ps103.poznan.sdi.tpnet.pl [217.97.72.103]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by goliath.sylaba.poznan.pl (Postfix) with ESMTP id 73B70943CB; Thu, 2 Oct 2003 14:28:49 +0200 (CEST) Received: from venus.local.navi.pl (venus.local.navi.pl [127.0.0.1]) by venus.local.navi.pl (8.12.5/8.12.5) with ESMTP id h92CTHsc011081; Thu, 2 Oct 2003 14:29:17 +0200 Subject: Re: could not open default font fixed From: Olaf Fraczyk To: deny Cc: linux-xfs@oss.sgi.com In-Reply-To: <3F7C0D52.6070403@monaco.net> References: <3F7C0D52.6070403@monaco.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 02 Oct 2003 14:29:17 +0200 Message-Id: <1065097757.9635.1.camel@venus> Mime-Version: 1.0 X-archive-position: 612 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: olaf@navi.pl Precedence: bulk X-list: linux-xfs Content-Length: 667 Lines: 43 Hi, This list for XFS filesystem, not for font server. Bye, Olaf On Thu, 2003-10-02 at 13:34, deny wrote: > hi > > i ve this message on my mandrake 9.0 > when i am booting > > what i do before ? > i stop abruptely after a froze when try to ending mandrake > > > i try to stop my xfs server > i do init 3 > and try to launch xfs > but i dont know the exact command > > (xfs start or stop dont work > i ve the message : > usage xfs -config config-file -port etc..... > > > i try to update the system > but i am blocked just after reconfiguring the rpm base > (from the cd rom install n 1 ) > > > i don't know what else to do > > thanks > > > > > > From owner-linux-xfs@oss.sgi.com Thu Oct 2 06:29:17 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 02 Oct 2003 06:29:56 -0700 (PDT) Received: from nexus.siana.ch (nexus.siana.ch [62.65.147.218]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h92DTE25012895 for ; Thu, 2 Oct 2003 06:29:15 -0700 Received: from GVACONTPC00089 (lhr254b.dhl.com [198.141.198.254]) by nexus.siana.ch (Postfix) with SMTP id 5DA6FACF6 for ; Thu, 2 Oct 2003 15:29:07 +0200 (CEST) Message-ID: <002a01c388e9$275b7ad0$f5025a0a@gvaco.ch.dhl.com> From: "Marc Beuchat" To: Subject: linux 2.4.20 + xfs 1.3 crashes at boot Date: Thu, 2 Oct 2003 15:29:05 +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 X-archive-position: 613 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: marc@siana.ch Precedence: bulk X-list: linux-xfs Content-Length: 4556 Lines: 126 I have compiled a stock kernel 2.4.20 patched with linux-2.4.20-core-xfs-1.3.0.patch, linux-xfs-1.3.0.patch and linux-2.4.20-xfs-1.3.0fixup.patch. Booting on a dual pentium III system, the kernel oops just after initializing the first CPU: ============================================================ Linux version 2.4.20-horizon (root@nexus) (gcc version 2.95.3 20010315 (release) ) #1 SMP Mon Sep 29 19:36:44 CEST 2003 BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 00000000000a0000 (usable) BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 000000000bff0000 (usable) BIOS-e820: 000000000bff0000 - 000000000bff3000 (ACPI NVS) BIOS-e820: 000000000bff3000 - 000000000c000000 (ACPI data) BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved) BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved) 191MB LOWMEM available. found SMP MP-table at 000f5a40 hm, page 000f5000 reserved twice. hm, page 000f6000 reserved twice. hm, page 000f1000 reserved twice. hm, page 000f2000 reserved twice. On node 0 totalpages: 49136 zone(0): 4096 pages. zone(1): 45040 pages. zone(2): 0 pages. Intel MultiProcessor Specification v1.1 Virtual Wire compatibility mode. OEM ID: OEM00000 Product ID: PROD00000000 APIC at: 0xFEE00000 Processor #0 Pentium(tm) Pro APIC version 17 Processor #1 Pentium(tm) Pro APIC version 17 I/O APIC #2 Version 17 at 0xFEC00000. Processors: 2 Kernel command line: BOOT_IMAGE=2.4.20-horizon ro root=305 console=ttyS0,38400 i debus=66 ide_setup: idebus=66 Initializing CPU#0 Detected 548.542 MHz processor. Calibrating delay loop... 1094.45 BogoMIPS Memory: 191924k/196544k available (1217k kernel code, 4236k reserved, 249k data, 240k init, 0k highmem) Dentry cache hash table entries: 32768 (order: 6, 262144 bytes) Inode cache hash table entries: 16384 (order: 5, 131072 bytes) Mount-cache hash table entries: 4096 (order: 3, 32768 bytes) invalid operand: 0000 CPU: 0 EIP: 0010:[<00000007>] Not tainted EFLAGS: 00010206 eax: 00000001 ebx: 00000001 ecx: c0262b00 edx: c0262bec esi: cbfee400 edi: c0262aec ebp: c023a014 esp: c0271f44 ds: 0018 es: 0018 ss: 0018 Process swapper (pid: 0, stackpage=c0271000) Stack: c01486fd cbfee400 cbfee400 cbfee400 c0262aec c023a014 c013a174 c0149872 cbfee400 c013ad80 cbfee400 cbfee400 00000000 c013a42f cbfee400 00000000 00000000 fffffff4 c1214160 c0262aec c013a59d c0262aec 00000000 c023a014 Call Trace: [] [] [] [] [] [] [] [] Code: Bad EIP value. <0>Kernel panic: Attempted to kill the idle task! In idle task - not syncing ============================================================ Passing this through ksymoops, I get the following: ============================================================ invalid operand: 0000 CPU: 0 EIP: 0010:[<00000007>] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010206 eax: 00000001 ebx: 00000001 ecx: c0262b00 edx: c0262bec esi: cbfee400 edi: c0262aec ebp: c023a014 esp: c0271f44 ds: 0018 es: 0018 ss: 0018 Process swapper (pid: 0, stackpage=c0271000) Stack: c01486fd cbfee400 cbfee400 cbfee400 c0262aec c023a014 c013a174 c0149872 cbfee400 c013ad80 cbfee400 cbfee400 00000000 c013a42f cbfee400 00000000 00000000 fffffff4 c1214160 c0262aec c013a59d c0262aec 00000000 c023a014 Call Trace: [] [] [] [] [] [] [] [] Code: Bad EIP value. >>EIP; 00000007 Before first symbol <===== >>ecx; c0262b00 >>edx; c0262bec >>edi; c0262aec >>ebp; c023a014 >>esp; c0271f44 Trace; c01486fd Trace; c013a174 Trace; c0149872 Trace; c013ad80 Trace; c013a42f Trace; c013a59d Trace; c0105000 <_stext+0/0> Trace; c013a765 <0>Kernel panic: Attempted to kill the idle task! ============================================================ I have tried compiling with egcs-1.1.2 (gcc 2.91.66) and gcc-2.95.3 with the same results. I have even tried compiling the kernel with the xfs patches but no xfs configuration options selected - the system still crashes in the same place. What could be wrong? Thanks for any ideas, Marc From owner-linux-xfs@oss.sgi.com Thu Oct 2 06:43:12 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 02 Oct 2003 06:43:50 -0700 (PDT) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h92DhA25013382 for ; Thu, 2 Oct 2003 06:43:10 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h92BkcOO002769 for ; Thu, 2 Oct 2003 04:46:38 -0700 Received: from tulip-e236.americas.sgi.com (tulip-e236.americas.sgi.com [128.162.236.208]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h92Dh3cc11880862; Thu, 2 Oct 2003 08:43:04 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by tulip-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h92Dh4Sn30417153; Thu, 2 Oct 2003 08:43:04 -0500 (CDT) Received: from jen.americas.sgi.com (localhost.localdomain [127.0.0.1]) by jen.americas.sgi.com (8.12.8/8.12.8) with ESMTP id h92Dh3KZ005052; Thu, 2 Oct 2003 08:43:03 -0500 Received: (from lord@localhost) by jen.americas.sgi.com (8.12.8/8.12.8/Submit) id h92Dh2U2005050; Thu, 2 Oct 2003 08:43:03 -0500 X-Authentication-Warning: jen.americas.sgi.com: lord set sender to lord@sgi.com using -f Subject: Re: linux 2.4.20 + xfs 1.3 crashes at boot From: Steve Lord To: Marc Beuchat Cc: linux-xfs@oss.sgi.com In-Reply-To: <002a01c388e9$275b7ad0$f5025a0a@gvaco.ch.dhl.com> References: <002a01c388e9$275b7ad0$f5025a0a@gvaco.ch.dhl.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1065102182.26609.490.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 02 Oct 2003 08:43:02 -0500 X-archive-position: 614 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 902 Lines: 22 On Thu, 2003-10-02 at 08:29, Marc Beuchat wrote: > I have compiled a stock kernel 2.4.20 patched with > linux-2.4.20-core-xfs-1.3.0.patch, linux-xfs-1.3.0.patch and > linux-2.4.20-xfs-1.3.0fixup.patch. Booting on a dual pentium III system, the > kernel oops just after initializing the first CPU: This looks rather like you missed something in backporting the patch, the alloc_inode code is different between the kernel the patch was intended for, and the one you used it one. You have to look at what the patch does to the kernel, and what the base kernel looks like, then make your kernel do the same thing. Some of the changes needed by xfs have been incorporated into the base code since 2.4.20 and hence are not present in the patch anymore. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Oct 2 07:02:58 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 02 Oct 2003 07:03:37 -0700 (PDT) Received: from rrzd2.rz.uni-regensburg.de (root@rrzd2.rz.uni-regensburg.de [132.199.1.12]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h92E2a25014312 for ; Thu, 2 Oct 2003 07:02:57 -0700 Received: from rss1.rz.uni-regensburg.de (rss1.rz.uni-regensburg.de [132.199.1.200]) by rrzd2.rz.uni-regensburg.de (8.12.3/8.12.3/Debian -4) with SMTP id h92E2Zqu001014 for ; Thu, 2 Oct 2003 16:02:35 +0200 Received: (qmail 2836 invoked from network); 2 Oct 2003 16:02:35 +0200 Received: from pc9391.physik.uni-regensburg.de (HELO pc9391) (guc28561@132.199.98.219) by rss1.rz.uni-regensburg.de with SMTP; 2 Oct 2003 16:02:35 +0200 Date: Thu, 2 Oct 2003 16:02:34 +0200 From: Christian Guggenberger To: Steve Lord Cc: Marc Beuchat , linux-xfs@oss.sgi.com Subject: Re: linux 2.4.20 + xfs 1.3 crashes at boot Message-ID: <20031002160234.A3833@pc9391.uni-regensburg.de> References: <002a01c388e9$275b7ad0$f5025a0a@gvaco.ch.dhl.com> <1065102182.26609.490.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In-Reply-To: <1065102182.26609.490.camel@jen.americas.sgi.com>; from lord@sgi.com on Thu, Oct 02, 2003 at 15:43:02 +0200 X-Mailer: Balsa 1.2.4 X-archive-position: 615 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Christian.Guggenberger@physik.uni-regensburg.de Precedence: bulk X-list: linux-xfs Content-Length: 1149 Lines: 28 On 02.10.2003 15:43 Steve Lord wrote: > On Thu, 2003-10-02 at 08:29, Marc Beuchat wrote: > > I have compiled a stock kernel 2.4.20 patched with > > linux-2.4.20-core-xfs-1.3.0.patch, linux-xfs-1.3.0.patch and > > linux-2.4.20-xfs-1.3.0fixup.patch. Booting on a dual pentium III system, > the > > kernel oops just after initializing the first CPU: > > > This looks rather like you missed something in backporting the > patch, the alloc_inode code is different between the kernel the > patch was intended for, and the one you used it one. You have to > look at what the patch does to the kernel, and what the base kernel > looks like, then make your kernel do the same thing. Some of the > changes needed by xfs have been incorporated into the base code > since 2.4.20 and hence are not present in the patch anymore. > ?? Hmm, I thought Release-1.3.0 was released for both 2.4.20 and 2.4.21 ? Thus, I don't understand your comment here. IMHO there would have been no need for any "backports" ... btw. ftp://oss.sgi.com seems to be alive, but i get "permission denied", when trying to access projects/xfs Thanks for clarification. Christian From owner-linux-xfs@oss.sgi.com Thu Oct 2 07:10:32 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 02 Oct 2003 07:11:09 -0700 (PDT) Received: from nexus.siana.ch (nexus.siana.ch [62.65.147.218]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h92EAU25015160 for ; Thu, 2 Oct 2003 07:10:31 -0700 Received: from GVACONTPC00089 (lhr254b.dhl.com [198.141.198.254]) by nexus.siana.ch (Postfix) with SMTP id 79462ACF6; Thu, 2 Oct 2003 16:10:23 +0200 (CEST) Message-ID: <003601c388ee$eb5f2120$f5025a0a@gvaco.ch.dhl.com> From: "Marc Beuchat" To: "Steve Lord" Cc: References: <002a01c388e9$275b7ad0$f5025a0a@gvaco.ch.dhl.com> <1065102182.26609.490.camel@jen.americas.sgi.com> Subject: Re: linux 2.4.20 + xfs 1.3 crashes at boot Date: Thu, 2 Oct 2003 16:10:21 +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 X-archive-position: 616 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: marc@siana.ch Precedence: bulk X-list: linux-xfs Content-Length: 1458 Lines: 43 Steve, I was under the impression that the patches I applied were already back-ported to linux-2.4.20. In fact, I get no errors when applying the three xfs patches (as listed below). I guess this can have nothing to do with the fact that I am running the kernel on a dual process system? Marc ----- Original Message ----- From: "Steve Lord" To: "Marc Beuchat" Cc: Sent: Thursday, October 02, 2003 3:43 PM Subject: Re: linux 2.4.20 + xfs 1.3 crashes at boot > On Thu, 2003-10-02 at 08:29, Marc Beuchat wrote: > > I have compiled a stock kernel 2.4.20 patched with > > linux-2.4.20-core-xfs-1.3.0.patch, linux-xfs-1.3.0.patch and > > linux-2.4.20-xfs-1.3.0fixup.patch. Booting on a dual pentium III system, the > > kernel oops just after initializing the first CPU: > > > This looks rather like you missed something in backporting the > patch, the alloc_inode code is different between the kernel the > patch was intended for, and the one you used it one. You have to > look at what the patch does to the kernel, and what the base kernel > looks like, then make your kernel do the same thing. Some of the > changes needed by xfs have been incorporated into the base code > since 2.4.20 and hence are not present in the patch anymore. > > Steve > > -- > > Steve Lord voice: +1-651-683-3511 > Principal Engineer, Filesystem Software email: lord@sgi.com > From owner-linux-xfs@oss.sgi.com Thu Oct 2 08:43:18 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 02 Oct 2003 08:43:58 -0700 (PDT) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h92FhH25021617 for ; Thu, 2 Oct 2003 08:43:18 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h92G0cHc017707 for ; Thu, 2 Oct 2003 11:00:38 -0500 Received: from tulip-e236.americas.sgi.com (tulip-e236.americas.sgi.com [128.162.236.208]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h92FhCcc11913805; Thu, 2 Oct 2003 10:43:12 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by tulip-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h92FhCSn30763332; Thu, 2 Oct 2003 10:43:12 -0500 (CDT) Received: from jen.americas.sgi.com (localhost.localdomain [127.0.0.1]) by jen.americas.sgi.com (8.12.8/8.12.8) with ESMTP id h92FhBKZ007093; Thu, 2 Oct 2003 10:43:11 -0500 Received: (from lord@localhost) by jen.americas.sgi.com (8.12.8/8.12.8/Submit) id h92FhBsv007091; Thu, 2 Oct 2003 10:43:11 -0500 X-Authentication-Warning: jen.americas.sgi.com: lord set sender to lord@sgi.com using -f Subject: Re: Hang on mount with 2.6 From: Steve Lord To: Klaus Strebel Cc: linux-xfs@oss.sgi.com In-Reply-To: <3F7C16EA.9060701@agile.com> References: <3F7C16EA.9060701@agile.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1065109390.7060.0.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 02 Oct 2003 10:43:11 -0500 X-archive-position: 617 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 630 Lines: 21 On Thu, 2003-10-02 at 07:15, Klaus Strebel wrote: > Hi all, > > the latest CVS from linux-2.5-xfs gives me the attached messages on > mount of an xfs filesystem (/home), all preceding mounts are ext3/ext2 > filesystems. I compiled with GCC-3.3 on SuSE-8.2. Any hints, ideas, patches? > > Ciao > Klaus Try turning off preempt, Linus's kernel also works OK, there is a mod in our tree which uses per-cpu variables for some stats, it appears to interact badly with preempt. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Oct 2 08:44:18 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 02 Oct 2003 08:44:51 -0700 (PDT) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h92FiI25021686 for ; Thu, 2 Oct 2003 08:44:18 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h92G1dHc018043 for ; Thu, 2 Oct 2003 11:01:39 -0500 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h92FiCcc11892002; Thu, 2 Oct 2003 10:44:12 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h92FiCK11940486; Thu, 2 Oct 2003 10:44:12 -0500 (CDT) Subject: Re: Hang on mount with 2.6 From: Eric Sandeen To: Steve Lord Cc: Klaus Strebel , linux-xfs@oss.sgi.com In-Reply-To: <1065100031.1510.110.camel@laptop.americas.sgi.com> References: <3F7C16EA.9060701@agile.com> <1065100031.1510.110.camel@laptop.americas.sgi.com> Content-Type: text/plain Organization: Message-Id: <1065109451.23210.3.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 02 Oct 2003 10:44:12 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 618 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 917 Lines: 27 Do you have preemption enabled? Can you try without? I put per-cpu variables into xfs for xfs statistics, and I think it might be the problem. I ran changes through our qa suite and it looked fine, but I did not think to turn on preemption - and preempt changes the way per-cpu vars work. -Eric On Thu, 2003-10-02 at 08:07, Steve Lord wrote: > On Thu, 2003-10-02 at 07:15, Klaus Strebel wrote: > > Hi all, > > > > the latest CVS from linux-2.5-xfs gives me the attached messages on > > mount of an xfs filesystem (/home), all preceding mounts are ext3/ext2 > > filesystems. I compiled with GCC-3.3 on SuSE-8.2. Any hints, ideas, patches? > > > > Ciao > > Klaus > > I have been looking at this, no answer yet, time to look at recent diffs > and see what we broke I think. > > Steve -- Eric Sandeen [C]XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Thu Oct 2 09:42:13 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 02 Oct 2003 09:42:53 -0700 (PDT) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h92GgC25025981 for ; Thu, 2 Oct 2003 09:42:12 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h92EjfOO017553 for ; Thu, 2 Oct 2003 07:45:41 -0700 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h92Gg6cc11929946; Thu, 2 Oct 2003 11:42:06 -0500 (CDT) Received: from naboo (naboo.americas.sgi.com [128.162.233.73]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h92Gg6Rn310134792; Thu, 2 Oct 2003 11:42:06 -0500 (CDT) Subject: Re: linux 2.4.20 + xfs 1.3 crashes at boot From: Russell Cattelan To: Marc Beuchat Cc: Steve Lord , linux-xfs@oss.sgi.com In-Reply-To: <003601c388ee$eb5f2120$f5025a0a@gvaco.ch.dhl.com> References: <002a01c388e9$275b7ad0$f5025a0a@gvaco.ch.dhl.com> <1065102182.26609.490.camel@jen.americas.sgi.com> <003601c388ee$eb5f2120$f5025a0a@gvaco.ch.dhl.com> Content-Type: text/plain Message-Id: <1065112613.11286.12.camel@naboo> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4-8mdk Date: Thu, 02 Oct 2003 11:36:53 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 619 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cattelan@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 1896 Lines: 58 Yes you're correct those three patches will give you 1.3 on 2.4.20. Why it's crashing on boot is another question. That backtrace seem a bit suspicious. Any chance you can grab the kdb patches and boot up with kdb enabled? Note 2.4.20 did not get a lot of 1.3 testing but it should at least boot. On Thu, 2003-10-02 at 09:10, Marc Beuchat wrote: > Steve, > > I was under the impression that the patches I applied were already > back-ported to linux-2.4.20. In fact, I get no errors when applying the > three xfs patches (as listed below). > > I guess this can have nothing to do with the fact that I am running the > kernel on a dual process system? > > Marc > > ----- Original Message ----- > From: "Steve Lord" > To: "Marc Beuchat" > Cc: > Sent: Thursday, October 02, 2003 3:43 PM > Subject: Re: linux 2.4.20 + xfs 1.3 crashes at boot > > > > On Thu, 2003-10-02 at 08:29, Marc Beuchat wrote: > > > I have compiled a stock kernel 2.4.20 patched with > > > linux-2.4.20-core-xfs-1.3.0.patch, linux-xfs-1.3.0.patch and > > > linux-2.4.20-xfs-1.3.0fixup.patch. Booting on a dual pentium III system, > the > > > kernel oops just after initializing the first CPU: > > > > > > This looks rather like you missed something in backporting the > > patch, the alloc_inode code is different between the kernel the > > patch was intended for, and the one you used it one. You have to > > look at what the patch does to the kernel, and what the base kernel > > looks like, then make your kernel do the same thing. Some of the > > changes needed by xfs have been incorporated into the base code > > since 2.4.20 and hence are not present in the patch anymore. > > > > Steve > > > > -- > > > > Steve Lord voice: +1-651-683-3511 > > Principal Engineer, Filesystem Software email: lord@sgi.com > > > From owner-linux-xfs@oss.sgi.com Thu Oct 2 10:26:12 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 02 Oct 2003 10:26:47 -0700 (PDT) Received: from nexus.siana.ch (nexus.siana.ch [62.65.147.218]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h92HQB25030168 for ; Thu, 2 Oct 2003 10:26:12 -0700 Received: from anais (dhcp64.siana.ch [192.168.2.63]) by nexus.siana.ch (Postfix) with SMTP id 013FEACF6; Thu, 2 Oct 2003 19:26:02 +0200 (CEST) Date: Thu, 2 Oct 2003 19:26:04 +0200 From: Marc Beuchat To: Russell Cattelan Cc: lord@sgi.com, linux-xfs@oss.sgi.com Subject: Re: linux 2.4.20 + xfs 1.3 crashes at boot Message-Id: <20031002192604.5775f935.marc@siana.ch> In-Reply-To: <1065112613.11286.12.camel@naboo> References: <002a01c388e9$275b7ad0$f5025a0a@gvaco.ch.dhl.com> <1065102182.26609.490.camel@jen.americas.sgi.com> <003601c388ee$eb5f2120$f5025a0a@gvaco.ch.dhl.com> <1065112613.11286.12.camel@naboo> X-Mailer: Sylpheed version 0.9.5 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 620 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: marc@siana.ch Precedence: bulk X-list: linux-xfs Content-Length: 624 Lines: 22 On Thu, 02 Oct 2003 11:36:53 -0500 Russell Cattelan wrote: > Yes you're correct those three patches will give you > 1.3 on 2.4.20. > > Why it's crashing on boot is another question. > That backtrace seem a bit suspicious. > > Any chance you can grab the kdb patches and boot > up with kdb enabled? > > > Note 2.4.20 did not get a lot of 1.3 testing but > it should at least boot. I just compiled 2.4.21 with the 1.3 patches and the same compiler/environment and that boots without a problem. If I find the time, I can include the kdb patches and send the results for the 2.4.20 compilation. Marc From owner-linux-xfs@oss.sgi.com Thu Oct 2 10:58:02 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 02 Oct 2003 10:58:37 -0700 (PDT) Received: from khe-mailhub1.eigner.com (khe-mailhub1.eigner.com [194.120.231.246]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h92Hw125001245 for ; Thu, 2 Oct 2003 10:58:02 -0700 Received: from agile.com (unknown [194.120.231.18]) by khe-mailhub1.eigner.com (Postfix) with ESMTP id 83C613A6; Thu, 2 Oct 2003 19:57:39 +0200 (CEST) Message-ID: <3F7C6718.4070208@agile.com> Date: Thu, 02 Oct 2003 19:57:44 +0200 From: Klaus Strebel Organization: Agile Software Corp. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: de, en, de-de, en-us MIME-Version: 1.0 To: Eric Sandeen Cc: Steve Lord , linux-xfs@oss.sgi.com Subject: Re: Hang on mount with 2.6 References: <3F7C16EA.9060701@agile.com> <1065100031.1510.110.camel@laptop.americas.sgi.com> <1065109451.23210.3.camel@stout.americas.sgi.com> In-Reply-To: <1065109451.23210.3.camel@stout.americas.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-agile-MailScanner-Information: Please contact the ISP for more information X-agile-MailScanner: Found to be clean X-agile-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=-2.6, required 5, EMAIL_ATTRIBUTION -0.50, IN_REP_TO -0.50, QUOTED_EMAIL_TEXT -0.48, REFERENCES -0.50, REPLY_WITH_QUOTES -0.50, USER_AGENT_MOZILLA_UA 0.00, X_ACCEPT_LANG -0.10) X-archive-position: 621 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: klaus.strebel@agile.com Precedence: bulk X-list: linux-xfs Content-Length: 1077 Lines: 40 Eric Sandeen wrote: > Do you have preemption enabled? Can you try without? I put per-cpu > variables into xfs for xfs statistics, and I think it might be the > problem. I ran changes through our qa suite and it looked fine, but I > did not think to turn on preemption - and preempt changes the way > per-cpu vars work. > > -Eric > > On Thu, 2003-10-02 at 08:07, Steve Lord wrote: > >>On Thu, 2003-10-02 at 07:15, Klaus Strebel wrote: >> >>>Hi all, >>> >>>the latest CVS from linux-2.5-xfs gives me the attached messages on >>>mount of an xfs filesystem (/home), all preceding mounts are ext3/ext2 >>>filesystems. I compiled with GCC-3.3 on SuSE-8.2. Any hints, ideas, patches? >>> >>>Ciao >>>Klaus >> >>I have been looking at this, no answer yet, time to look at recent diffs >>and see what we broke I think. >> >>Steve Yep, that made the trick. I don't need preempt, just looks like a interesting new feature ;-). Ciao Klaus -- Klaus Strebel UNIX-Engineer klaus.strebel@agile.com Agile Software Corporation How Product Become Profits (TM) From owner-linux-xfs@oss.sgi.com Thu Oct 2 11:07:52 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 02 Oct 2003 11:08:26 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h92I7q25002333 for ; Thu, 2 Oct 2003 11:07:52 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h92I7kq0014125 for ; Thu, 2 Oct 2003 11:07:47 -0700 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h92I7kcc11884637; Thu, 2 Oct 2003 13:07:46 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h92I7kK11947406; Thu, 2 Oct 2003 13:07:46 -0500 (CDT) Subject: Re: Hang on mount with 2.6 From: Eric Sandeen To: Klaus Strebel Cc: Steve Lord , linux-xfs@oss.sgi.com In-Reply-To: <3F7C6718.4070208@agile.com> References: <3F7C16EA.9060701@agile.com> <1065100031.1510.110.camel@laptop.americas.sgi.com> <1065109451.23210.3.camel@stout.americas.sgi.com> <3F7C6718.4070208@agile.com> Content-Type: text/plain Organization: Message-Id: <1065118065.23210.17.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 02 Oct 2003 13:07:45 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 622 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2110 Lines: 53 This patch should fix it up to work with preempt, as well. Earlier code was braindead on my part... This doesn't protect the stats vars from preemption; I don't think we care much, in any case it shouldn't harm anything but the accuracy of the stats. -Eric =========================================================================== linux/fs/xfs/linux/xfs_stats.h =========================================================================== --- /usr/tmp/TmpDir.27349-0/linux/fs/xfs/linux/xfs_stats.h_1.9 2003-10-02 13:06:14.000000000 -0500 +++ linux/fs/xfs/linux/xfs_stats.h 2003-10-02 12:37:24.000000000 -0500 @@ -130,9 +130,11 @@ DECLARE_PER_CPU(struct xfsstats, xfsstats); -# define XFS_STATS_INC(count) ( get_cpu_var(xfsstats).count++ ) -# define XFS_STATS_DEC(count) ( get_cpu_var(xfsstats).count-- ) -# define XFS_STATS_ADD(count, inc) ( get_cpu_var(xfsstats).count += (inc) ) +/* We don't disable preempt, not too worried about poking the + * wrong cpu's stat */ +#define XFS_STATS_INC(count) (__get_cpu_var(xfsstats).count++) +#define XFS_STATS_DEC(count) (__get_cpu_var(xfsstats).count--) +#define XFS_STATS_ADD(count, inc) (__get_cpu_var(xfsstats).count += (inc)) extern void xfs_init_procfs(void); extern void xfs_cleanup_procfs(void); =========================================================================== linux/fs/xfs/pagebuf/page_buf_internal.h =========================================================================== --- /usr/tmp/TmpDir.27349-0/linux/fs/xfs/pagebuf/page_buf_internal.h_1.27 2003-10-02 13:06:14.000000000 -0500 +++ linux/fs/xfs/pagebuf/page_buf_internal.h 2003-10-02 12:37:43.000000000 -0500 @@ -123,7 +123,12 @@ DECLARE_PER_CPU(struct pbstats, pbstats); -#define PB_STATS_INC(count) ( get_cpu_var(pbstats).count++ ) +/* We don't disable preempt, not too worried about poking the + * wrong cpu's stat */ +#define PB_STATS_INC(count) do { \ + get_cpu_var(pbstats).count++; \ + put_cpu_var(pbstats); \ +} while (0) #ifndef STATIC # define STATIC static From owner-linux-xfs@oss.sgi.com Thu Oct 2 12:45:56 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 02 Oct 2003 12:46:30 -0700 (PDT) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h92Jjt25013731 for ; Thu, 2 Oct 2003 12:45:55 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h92K3GHc008353 for ; Thu, 2 Oct 2003 15:03:17 -0500 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h92Jjncc11891287; Thu, 2 Oct 2003 14:45:49 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h92JjnK11962492; Thu, 2 Oct 2003 14:45:49 -0500 (CDT) Subject: Re: Hang on mount with 2.6 From: Eric Sandeen To: Klaus Strebel Cc: Steve Lord , linux-xfs@oss.sgi.com In-Reply-To: <1065118065.23210.17.camel@stout.americas.sgi.com> References: <3F7C16EA.9060701@agile.com> <1065100031.1510.110.camel@laptop.americas.sgi.com> <1065109451.23210.3.camel@stout.americas.sgi.com> <3F7C6718.4070208@agile.com> <1065118065.23210.17.camel@stout.americas.sgi.com> Content-Type: text/plain Organization: Message-Id: <1065123948.23210.22.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 02 Oct 2003 14:45:48 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 623 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1970 Lines: 46 This is not my day. The previous pagebuf patch is not harmful, but isn't what I meant to send... here's the correct patch. =========================================================================== linux/fs/xfs/linux/xfs_stats.h =========================================================================== --- /usr/tmp/TmpDir.13414-0/linux/fs/xfs/linux/xfs_stats.h_1.9 2003-10-02 14:45:08.000000000 -0500 +++ linux/fs/xfs/linux/xfs_stats.h 2003-10-02 12:37:24.000000000 -0500 @@ -130,9 +130,11 @@ DECLARE_PER_CPU(struct xfsstats, xfsstats); -# define XFS_STATS_INC(count) ( get_cpu_var(xfsstats).count++ ) -# define XFS_STATS_DEC(count) ( get_cpu_var(xfsstats).count-- ) -# define XFS_STATS_ADD(count, inc) ( get_cpu_var(xfsstats).count += (inc) ) +/* We don't disable preempt, not too worried about poking the + * wrong cpu's stat, we only care about aggregate anyway */ +#define XFS_STATS_INC(count) (__get_cpu_var(xfsstats).count++) +#define XFS_STATS_DEC(count) (__get_cpu_var(xfsstats).count--) +#define XFS_STATS_ADD(count, inc) (__get_cpu_var(xfsstats).count += (inc)) extern void xfs_init_procfs(void); extern void xfs_cleanup_procfs(void); =========================================================================== linux/fs/xfs/pagebuf/page_buf_internal.h =========================================================================== --- /usr/tmp/TmpDir.13414-0/linux/fs/xfs/pagebuf/page_buf_internal.h_1.27 2003-10-02 14:45:08.000000000 -0500 +++ linux/fs/xfs/pagebuf/page_buf_internal.h 2003-10-02 14:42:58.000000000 -0500 @@ -123,7 +123,9 @@ DECLARE_PER_CPU(struct pbstats, pbstats); -#define PB_STATS_INC(count) ( get_cpu_var(pbstats).count++ ) +/* We don't disable preempt, not too worried about poking the + * wrong cpu's stat, we only care about aggregate anyway */ +#define PB_STATS_INC(count) (__get_cpu_var(pbstats).count++) #ifndef STATIC # define STATIC static From owner-linux-xfs@oss.sgi.com Thu Oct 2 12:55:14 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 02 Oct 2003 12:55:46 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h92JtD25015164 for ; Thu, 2 Oct 2003 12:55:13 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h92Jt7q0025063 for ; Thu, 2 Oct 2003 12:55:08 -0700 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h92Jt6cc11946496 for ; Thu, 2 Oct 2003 14:55:07 -0500 (CDT) Received: from sgi.com (penguin.americas.sgi.com [128.162.240.135]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h92Jt6Rn308055825; Thu, 2 Oct 2003 14:55:06 -0500 (CDT) Received: from penguin.americas.sgi.com (localhost.localdomain [127.0.0.1]) by sgi.com (8.12.8/8.12.8) with ESMTP id h92JqxGf014238; Thu, 2 Oct 2003 14:52:59 -0500 Received: (from sandeen@localhost) by penguin.americas.sgi.com (8.12.8/8.12.8/Submit) id h92JqxgO014236; Thu, 2 Oct 2003 14:52:59 -0500 Date: Thu, 2 Oct 2003 14:52:59 -0500 From: Eric Sandeen Message-Id: <200310021952.h92JqxgO014236@penguin.americas.sgi.com> Subject: PARTIAL TAKE 899288 - Rework linux-xfs to use per-cpu vars for xfsstats X-archive-position: 624 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@penguin.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 479 Lines: 17 Either handle preemption with get/put or not, but don't get without a put! Fix code for preemptable kernels. Date: Thu Oct 2 12:54:29 PDT 2003 Workarea: penguin.americas.sgi.com:/src/sandeen/2.5.x-xfs/workarea The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:159379a linux/fs/xfs/linux/xfs_stats.h - 1.10 linux/fs/xfs/pagebuf/page_buf_internal.h - 1.28 - use __get_cpu_var, no preemption protection for now From owner-linux-xfs@oss.sgi.com Thu Oct 2 17:07:27 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 02 Oct 2003 17:07:39 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10) with ESMTP id h9307R25003427 for ; Thu, 2 Oct 2003 17:07:27 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id h9307RP4003426 for linux-xfs@oss.sgi.com; Thu, 2 Oct 2003 17:07:27 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10) with ESMTP id h9307P29003410 for ; Thu, 2 Oct 2003 17:07:25 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id h92NQ150001287; Thu, 2 Oct 2003 16:26:01 -0700 Date: Thu, 2 Oct 2003 16:26:01 -0700 Message-Id: <200310022326.h92NQ150001287@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 267] pwrite64 failed on 1.2 TB evms volume X-Bugzilla-Reason: AssignedTo X-archive-position: 626 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 795 Lines: 26 http://oss.sgi.com/bugzilla/show_bug.cgi?id=267 nathans@sgi.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID ------- Additional Comments From nathans@sgi.com 2003-02-10 16:26 PDT ------- Daniel, this is not an XFS problem - it's a device driver bug (EVMS/DM). You should report the problem to those folks, we can't help you with it. We are actively testing XFS filesystems in the 100's of terabytes range on non-EVMS/DM devices with no problems. cheers. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Fri Oct 3 02:20:57 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 03 Oct 2003 02:21:36 -0700 (PDT) Received: from kerberos.suse.cz (kerberos.suse.cz [195.47.106.10]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h939Ku25008599 for ; Fri, 3 Oct 2003 02:20:57 -0700 Received: from chimera.suse.cz (chimera.suse.cz [10.20.0.2]) by kerberos.suse.cz (****** SuSE CR *******) with ESMTP id 642014FB88 for ; Fri, 3 Oct 2003 11:20:50 +0200 (MEST) Received: from alienAngel.upjs.sk (test12.suse.cz [10.20.3.140]) by chimera.suse.cz (Postfix) with ESMTP id 08B624FAA for ; Fri, 3 Oct 2003 11:20:50 +0200 (CEST) Received: from localhost (ja@localhost) by alienAngel.upjs.sk (8.12.7/8.12.6/Submit) with ESMTP id h939MIEK008000 for ; Fri, 3 Oct 2003 11:22:18 +0200 X-Authentication-Warning: alienAngel.home.sk: ja owned process doing -bs Date: Fri, 3 Oct 2003 11:22:18 +0200 (CEST) From: Jan Derfinak X-X-Sender: ja@alienAngel.home.sk To: linux-xfs@oss.sgi.com Subject: cvs error Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 627 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ja@mail.upjs.sk Precedence: bulk X-list: linux-xfs Content-Length: 280 Lines: 17 Hi. It seems that public cvs access is broken. Command line: > cvs update -dP cvs server: Updating . cvs server: cannot open directory /cvs/xfs-cmds: No such file or directory cvs server: skipping directory Web access: Error: xfs-cmds: no such file or directory jan -- From owner-linux-xfs@oss.sgi.com Fri Oct 3 02:34:25 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 03 Oct 2003 02:34:59 -0700 (PDT) Received: from gusi.leathercollection.ph (gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h939YO25010455 for ; Fri, 3 Oct 2003 02:34:25 -0700 Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 81902EB4A1F for ; Fri, 3 Oct 2003 17:34:17 +0800 (PHT) Received: from lawin.alabang.leathercollection.ph (lawin.alabang.leathercollection.ph [192.168.0.2]) by gusi.leathercollection.ph (Postfix) with ESMTP id 50610EB4A13 for ; Fri, 3 Oct 2003 17:34:09 +0800 (PHT) Received: by lawin.alabang.leathercollection.ph (Postfix, from userid 1000) id 5946D1A4039; Fri, 3 Oct 2003 17:34:06 +0800 (PHT) Date: Fri, 3 Oct 2003 17:34:06 +0800 From: Federico Sevilla III To: linux-xfs@oss.sgi.com Subject: Re: cvs error Message-ID: <20031003093406.GB7005@leathercollection.ph> 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: X-Organization: The Leather Collection, Inc. X-Organization-URL: http://www.leathercollection.ph X-Personal-URL: http://jijo.free.net.ph User-Agent: Mutt/1.5.4i X-archive-position: 628 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jijo@free.net.ph Precedence: bulk X-list: linux-xfs Content-Length: 524 Lines: 14 On Fri, Oct 03, 2003 at 11:22:18AM +0200, Jan Derfinak wrote: > It seems that public cvs access is broken. Public FTP access is broken, too. is a symlink to , but access to is denied. :( --> Jijo -- Federico Sevilla III : http://jijo.free.net.ph : When we speak of free Network Administrator : The Leather Collection, Inc. : software we refer to GnuPG Key ID : 0x93B746BE : freedom, not price. From owner-linux-xfs@oss.sgi.com Fri Oct 3 08:43:26 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 03 Oct 2003 08:44:07 -0700 (PDT) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h93FhP25031404 for ; Fri, 3 Oct 2003 08:43:26 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h93DkwOO027075 for ; Fri, 3 Oct 2003 06:46:58 -0700 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h93FhJcc11922167 for ; Fri, 3 Oct 2003 10:43:19 -0500 (CDT) Received: from naboo.americas.sgi.com (naboo.americas.sgi.com [128.162.233.73]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h93FgvRn270998782; Fri, 3 Oct 2003 10:42:57 -0500 (CDT) Received: by naboo.americas.sgi.com (Postfix, from userid 29039) id D3A75186C78D; Fri, 3 Oct 2003 10:37:30 -0500 (CDT) Subject: PARTIAL TAKE 901236 - Fix remount,ro path Message-Id: <20031003153730.D3A75186C78D@naboo.americas.sgi.com> Date: Fri, 3 Oct 2003 10:37:30 -0500 (CDT) From: cattelan@naboo.americas.sgi.com (Russell Cattelan) To: undisclosed-recipients:;;;;@sgi.com;;; X-archive-position: 629 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cattelan@naboo.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 339 Lines: 13 Date: Fri Oct 3 08:41:56 PDT 2003 Workarea: naboo.americas.sgi.com:/go/xfs2/XFS/x2.4-xfs-clean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:159444a linux/fs/xfs/xfs_vfsops.c - 1.433 - Add back in the loop counter that does at least 2 flushes for the remout,ro path From owner-linux-xfs@oss.sgi.com Fri Oct 3 13:28:06 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 03 Oct 2003 13:28:45 -0700 (PDT) Received: from mail.ii.uib.no (eik.ii.uib.no [129.177.16.3]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h93KS525028629 for ; Fri, 3 Oct 2003 13:28:06 -0700 Received: from lapprose.ii.uib.no ([129.177.20.37]) by mail.ii.uib.no with esmtp (TLSv1:AES256-SHA:256) (Exim 4.12) id 1A5WWv-0000N6-00 for linux-xfs@oss.sgi.com; Fri, 03 Oct 2003 22:28:01 +0200 Received: (from jfm@localhost) by lapprose.ii.uib.no (8.12.8/8.12.8/Submit) id h93KS1nt024873 for linux-xfs@oss.sgi.com; Fri, 3 Oct 2003 22:28:01 +0200 Date: Fri, 3 Oct 2003 22:28:01 +0200 From: Jan-Frode Myklebust To: linux-xfs@oss.sgi.com Subject: ftp://oss.sgi.com/projects/xfs Message-ID: <20031003202801.GB24696@ii.uib.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scanner: exiscan for exim4 (http://duncanthrax.net/exiscan/) *1A5WWv-0000N6-00*AFmZSO6dUOw* X-archive-position: 631 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: janfrode@parallab.no Precedence: bulk X-list: linux-xfs Content-Length: 464 Lines: 17 Somethings broken with the ftp-site: ncftp /projects > pwd ftp://oss.sgi.com/projects/ ncftp /projects > ls -ld xfs lrwxrwxr-x 1 0 0 12 Oct 4 2002 xfs -> ../.pub0/xfs ncftp /projects > cd xfs Could not chdir to xfs: server said: Can't change directory to xfs: Permission denied ncftp /projects > cd /.pub0 Could not chdir to /.pub0: server said: Prohibited file name: .pub0 Hope this doesn't have anything to do with SCO... -jf From owner-linux-xfs@oss.sgi.com Fri Oct 3 13:57:05 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 03 Oct 2003 13:57:38 -0700 (PDT) Received: from linux-sxs.org (d60-65-142-166.col.wideopenwest.com [65.60.166.142]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h93Kv425000578 for ; Fri, 3 Oct 2003 13:57:05 -0700 Received: from linux-sxs.org (localhost [127.0.0.1]) by linux-sxs.org (8.12.10/8.12.10) with ESMTP id h93KR1vd015005; Fri, 3 Oct 2003 16:27:02 -0400 Received: from localhost (netllama@localhost) by linux-sxs.org (8.12.10/8.12.10/Submit) with ESMTP id h93KR19O019684; Fri, 3 Oct 2003 16:27:01 -0400 Date: Fri, 3 Oct 2003 16:27:01 -0400 (EDT) From: Net Llama! To: Jan-Frode Myklebust cc: linux-xfs@oss.sgi.com Subject: Re: ftp://oss.sgi.com/projects/xfs In-Reply-To: <20031003202801.GB24696@ii.uib.no> Message-ID: References: <20031003202801.GB24696@ii.uib.no> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: OK, scanned by File::Scan,ClamAV X-Scanned-By: MIMEDefang 2.37 X-archive-position: 632 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: netllama@linux-sxs.org Precedence: bulk X-list: linux-xfs Content-Length: 796 Lines: 28 Its prolly the load on the server again. This happened abou 3 weeks ago. On Fri, 3 Oct 2003, Jan-Frode Myklebust wrote: > Somethings broken with the ftp-site: > > ncftp /projects > pwd > ftp://oss.sgi.com/projects/ > ncftp /projects > ls -ld xfs > lrwxrwxr-x 1 0 0 12 Oct 4 2002 xfs -> ../.pub0/xfs > ncftp /projects > cd xfs > Could not chdir to xfs: server said: Can't change directory to xfs: Permission denied > ncftp /projects > cd /.pub0 > Could not chdir to /.pub0: server said: Prohibited file name: .pub0 > > > Hope this doesn't have anything to do with SCO... > > > -jf > > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lonni J Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo http://netllama.ipfox.com From owner-linux-xfs@oss.sgi.com Sat Oct 4 09:52:01 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 04 Oct 2003 09:52:47 -0700 (PDT) Received: from smtp.nofida.ch ([62.2.181.77]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h94Gpt25032277 for ; Sat, 4 Oct 2003 09:51:56 -0700 Received: by smtp.nofida.ch (Postfix, from userid 101) id 4668FAD; Sat, 4 Oct 2003 18:51:53 +0200 (CEST) Received: from [192.168.74.20] (unknown [192.168.74.20]) by smtp.nofida.ch (Postfix) with ESMTP id 88D2A33; Sat, 4 Oct 2003 18:51:42 +0200 (CEST) Subject: unable to mount filesystem From: Marcel de Riedmatten To: Linux xfs list Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-SnKinJMn7KfAzVUZ68ve" Organization: Message-Id: <1065286302.20458.44.camel@galadriel> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 04 Oct 2003 18:51:42 +0200 X-Virus-Scanned: by AMaViS perl-11 X-archive-position: 634 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mdr@dotforge.ch Precedence: bulk X-list: linux-xfs Content-Length: 63659 Lines: 1413 --=-SnKinJMn7KfAzVUZ68ve Content-Type: multipart/mixed; boundary="=-zva6SAgwqdr3C7TScaN5" --=-zva6SAgwqdr3C7TScaN5 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi all I was making write tests on a 1.5TB xfs filesystem and after unmounting it i can't mount it again. It looks like a log corruption or something. This is what i found in syslog: i try to mount multiple times Oct 4 17:15:35 grobelix kernel: XFS mounting filesystem sd(8,1) Oct 4 17:15:36 grobelix kernel: Starting XFS recovery on filesystem: sd(8,1) (dev: 8/1) Oct 4 17:15:36 grobelix kernel: XFS: log mount/recovery failed Oct 4 17:15:36 grobelix kernel: XFS: log mount failed Oct 4 17:15:50 grobelix kernel: XFS mounting filesystem sd(8,1) Oct 4 17:15:50 grobelix kernel: Filesystem "sd(8,1)": XFS internal error xlog_clear_stale_blocks(2) at line 1253 of file xfs_log_recover.c.=20 Caller 0xf898e900 Oct 4 17:15:50 grobelix kernel: e8539c40 f898ef6c f89b6bc5 00000001 e2e39c00 f89b6ae1 000004e5 f898e900=20 Oct 4 17:15:50 grobelix kernel: 00000006 00000007 0000ec00 00000007 00000007 00000801 c44b0380 e21dde80=20 Oct 4 17:15:50 grobelix kernel: f898e900 e21dde80 0000ec00 00000007 000001f0 e2e39c00 0000feff 0000ec00=20 Oct 4 17:15:50 grobelix kernel: Call Trace: [] xlog_clear_stale_blocks [xfs] 0xbc (0xe8539c44)) Oct 4 17:15:50 grobelix kernel: [] .rodata.str1.1 [xfs] 0x838 (0xe8539c48)) Oct 4 17:15:50 grobelix kernel: [] .rodata.str1.1 [xfs] 0x754 (0xe8539c54)) Oct 4 17:15:50 grobelix kernel: [] xlog_find_tail [xfs] 0x3c0 (0xe8539c5c)) Oct 4 17:15:50 grobelix kernel: [] xlog_find_tail [xfs] 0x3c0 (0xe8539c80)) Oct 4 17:15:50 grobelix kernel: [] xlog_recover [xfs] 0x20 (0xe8539ccc)) Oct 4 17:15:50 grobelix kernel: [] xfs_log_mount [xfs] 0x84 (0xe8539d00)) Oct 4 17:15:50 grobelix kernel: [] xfs_mountfs [xfs] 0x9e3 (0xe8539d1c)) Oct 4 17:15:50 grobelix kernel: [] xfs_readsb [xfs] 0x190 (0xe8539d8c)) Oct 4 17:15:50 grobelix kernel: [] xfs_setsize_buftarg [xfs] 0x2f (0xe8539db8)) Oct 4 17:15:50 grobelix kernel: [] xfs_mount [xfs] 0x2fc (0xe8539dcc)) Oct 4 17:15:50 grobelix kernel: [] vfs_mount [xfs] 0x21 (0xe8539dfc)) Oct 4 17:15:50 grobelix kernel: [] linvfs_read_super [xfs] 0x85 (0xe8539e0c)) Oct 4 17:15:50 grobelix kernel: [get_sb_bdev+530/656] get_sb_bdev [kernel] 0x212 (0xe8539e74)) Oct 4 17:15:50 grobelix kernel: [__generic_copy_from_user+50/96] __generic_copy_from_user [kernel] 0x32 (0xe8539e8c)) Oct 4 17:15:50 grobelix kernel: [] xfs_fs_type [xfs] 0x0 (0xe8539ed4)) Oct 4 17:15:50 grobelix kernel: [do_kern_mount+92/272] do_kern_mount [kernel] 0x5c (0xe8539edc)) Oct 4 17:15:50 grobelix kernel: [] xfs_fs_type [xfs] 0x0 (0xe8539ee0)) Oct 4 17:15:50 grobelix kernel: [do_add_mount+118/320] do_add_mount [kernel] 0x76 (0xe8539f10)) Oct 4 17:15:50 grobelix kernel: [do_mount+331/368] do_mount [kernel] 0x14b (0xe8539f40)) Oct 4 17:15:50 grobelix kernel: [copy_mount_options+76/160] copy_mount_options [kernel] 0x4c (0xe8539f7c)) Oct 4 17:15:50 grobelix kernel: [sys_mount+164/256] sys_mount [kernel] 0xa4 (0xe8539f90)) Oct 4 17:15:50 grobelix kernel: [system_call+51/56] system_call [kernel] 0x33 (0xe8539fc0)) Oct 4 17:15:50 grobelix kernel:=20 Oct 4 17:15:50 grobelix kernel: XFS: failed to locate log tail Oct 4 17:15:50 grobelix kernel: XFS: log mount/recovery failed Oct 4 17:15:50 grobelix kernel: XFS: log mount failed This is xfs-1.3 whith Axel Thimm smp i686 package at=20 http://atrpms.physik.fu-berlin.de/dist/rh73/kernel/ Hardware is supermicro dual xeon board (x5dp8-g2) with 2 GB of ram and a 3ware 8506-8 with 7 disks raid5.=20 Then try xfs_logprint (whithout -t ) but it segfault: ./xfs_logprint /dev/sda1=20 xfs_logprint: data device: 0x801 log device: 0x801 daddr: 1468006656 length: 261888 cycle: 7 version: 2 lsn: 7,65536 tail_lsn: 7,65024 length of Log Record: 258048 prev offset: 65024 num ops: 3689 uuid: 8c709d84-99db-4623-bc6a-70c61ec21c53 format: little endian linux ---------------------------------------------------------------------------- Oper (0): tid: c45c8ec4 len: 0 clientid: ERROR flags: none ---------------------------------------------------------------------------- Oper (1): tid: c45c83cc len: 0 clientid: ERROR flags: none ---------------------------------------------------------------------------- Oper (2): tid: 69000000 len: 0 clientid: ERROR flags: none ---------------------------------------------------------------------------- Oper (3): tid: 0 len: 0 clientid: ERROR flags: none ---------------------------------------------------------------------------- Oper (4): tid: c0ee1b00 len: 266480 clientid: ERROR flags: none xfs_logprint: unknown log operation type (0) ---------------------------------------------------------------------------- Segmentation fault (core dumped) here is the backtrace : gdb -c core xfs_logprint=20 GNU gdb 2002-04-01-cvs Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-linux"... Core was generated by ./xfs_logprint /dev/sda1'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libuuid.so.1...done. Loaded symbols for /lib/libuuid.so.1 Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 #0 0x4008edcd in bcopy () from /lib/libc.so.6 (gdb) bt #0 0x4008edcd in bcopy () from /lib/libc.so.6 #1 0x0804b054 in xlog_print_op_header (op_head=3D0x40179134, i=3D5, ptr=3D0xbfffec88) at log_misc.c:131 #2 0x0804d57d in xlog_print_record (fd=3D3, num_ops=3D3689, len=3D258048, read_type=3D0xbfffece8, partial_buf=3D0xbfffecec, rhead=3D0xbfffecfc) at log_misc.c:962 #3 0x0804e118 in xfs_log_print (log=3D0xbfffef30, fd=3D3, print_block_start=3D-1) at log_misc.c:1216 #4 0x0804eb71 in main (argc=3D2, argv=3D0xbfffeff4) at logprint.c:256 then i try xfs_logprint -t and is works. Ii have joined the output file. xfs_check show no output. xfs_repair complain for the un replayed log. So i xfs_repair -L /dev/sda1 and after that i could remount the filesystem.=20=20 # xfs_info data meta-data=3D/exports/data isize=3D256 agcount=3D351, agsize=3D1048576 blks =3D sectsz=3D512=20=20 data =3D bsize=3D4096 blocks=3D367671614, imaxpct=3D25 =3D sunit=3D16 swidth=3D96 blks, unwritten=3D1 naming =3Dversion 2 bsize=3D4096=20=20 log =3Dinternal bsize=3D4096 blocks=3D32736, version= =3D2 =3D sectsz=3D512 sunit=3D48 blks realtime =3Dnone extsz=3D65536 blocks=3D0, rtextents=3D0 I hope this will bring some useful information to the developpers. Best Regards --=20 Marcel de Riedmatten pgp key: CFE703CA http://ftp.dotforge.ch/pub/users/mdr/mdr.gpg.asc Empreinte: 4687 F9CB D8E2 AC1A B806 F812 C048 0875 CFE7 03CA --=-zva6SAgwqdr3C7TScaN5 Content-Disposition: attachment; filename=log.text Content-Type: text/plain; name=log.text; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable xfs_logprint: data device: 0x801 log device: 0x801 daddr: 1468006656 length: 261888 log tail: 60416 head: 65279 state: LOG REC AT LSN cycle 7 block 60416 (0x7, 0xec00) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D TRANS: tid:0xc45c87bc type:DIOSTRAT #items:5 trans:0x0 q:0x808cf70 INO: cnt:3 total:3 a:0x808cf90 len:52 a:0x808cfe8 len:96 a:0x808d050 len:32= =20 INODE: #regs:3 ino:0x104 flags:0x5 dsize:32 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x808d078 len:24 a:0x808d0d0 len:128=20 BUF: #regs:2 start blkno:0x8b800001 len:1 bmap size:1 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x808d158 len:28 a:0x808d1b0 len:128=20 BUF: #regs:2 start blkno:0x8b800010 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d238 len:28 a:0x808d290 len:128=20 BUF: #regs:2 start blkno:0x8b800018 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d318 len:24 a:0x808d370 len:128=20 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 SUPER Block Buffer: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D TRANS: tid:0xc45c87e0 type:DIOSTRAT #items:5 trans:0x0 q:0x808cf70 INO: cnt:3 total:3 a:0x808cf90 len:52 a:0x808cfe8 len:96 a:0x808d050 len:32= =20 INODE: #regs:3 ino:0x104 flags:0x5 dsize:32 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x808d078 len:24 a:0x808d0d0 len:128=20 BUF: #regs:2 start blkno:0x8b800001 len:1 bmap size:1 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x808d158 len:28 a:0x808d1b0 len:128=20 BUF: #regs:2 start blkno:0x8b800010 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d238 len:28 a:0x808d290 len:128=20 BUF: #regs:2 start blkno:0x8b800018 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d318 len:24 a:0x808d370 len:128=20 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 SUPER Block Buffer: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D TRANS: tid:0xc45c8804 type:DIOSTRAT #items:5 trans:0x0 q:0x808cf70 INO: cnt:3 total:3 a:0x808cf90 len:52 a:0x808cfe8 len:96 a:0x808d050 len:32= =20 INODE: #regs:3 ino:0x104 flags:0x5 dsize:32 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x808d078 len:24 a:0x808d0d0 len:128=20 BUF: #regs:2 start blkno:0x8b800001 len:1 bmap size:1 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x808d158 len:28 a:0x808d1b0 len:128=20 BUF: #regs:2 start blkno:0x8b800010 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d238 len:28 a:0x808d290 len:128=20 BUF: #regs:2 start blkno:0x8b800018 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d318 len:24 a:0x808d370 len:128=20 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 SUPER Block Buffer: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D TRANS: tid:0xc45c884c type:DIOSTRAT #items:5 trans:0x0 q:0x808cf70 INO: cnt:3 total:3 a:0x808cf90 len:52 a:0x808cfe8 len:96 a:0x808d050 len:32= =20 INODE: #regs:3 ino:0x104 flags:0x5 dsize:32 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x808d078 len:24 a:0x808d0d0 len:128=20 BUF: #regs:2 start blkno:0x8b800001 len:1 bmap size:1 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x808d158 len:28 a:0x808d1b0 len:128=20 BUF: #regs:2 start blkno:0x8b800010 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d238 len:28 a:0x808d290 len:128=20 BUF: #regs:2 start blkno:0x8b800018 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d318 len:24 a:0x808d370 len:128=20 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 SUPER Block Buffer: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D TRANS: tid:0xc45c8828 type:DIOSTRAT #items:5 trans:0x0 q:0x808cf70 INO: cnt:3 total:3 a:0x808cf90 len:52 a:0x808cfe8 len:96 a:0x808d050 len:32= =20 INODE: #regs:3 ino:0x104 flags:0x5 dsize:32 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x808d078 len:24 a:0x808d0d0 len:128=20 BUF: #regs:2 start blkno:0x8b800001 len:1 bmap size:1 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x808d158 len:28 a:0x808d1b0 len:128=20 BUF: #regs:2 start blkno:0x8b800010 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d238 len:28 a:0x808d290 len:128=20 BUF: #regs:2 start blkno:0x8b800018 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d318 len:24 a:0x808d370 len:128=20 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 SUPER Block Buffer: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D TRANS: tid:0xc45c8870 type:DIOSTRAT #items:5 trans:0x0 q:0x808cf70 INO: cnt:3 total:3 a:0x808cf90 len:52 a:0x808cfe8 len:96 a:0x808d050 len:32= =20 INODE: #regs:3 ino:0x104 flags:0x5 dsize:32 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x808d078 len:24 a:0x808d0d0 len:128=20 BUF: #regs:2 start blkno:0x8b800001 len:1 bmap size:1 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x808d158 len:28 a:0x808d1b0 len:128=20 BUF: #regs:2 start blkno:0x8b800010 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d238 len:28 a:0x808d290 len:128=20 BUF: #regs:2 start blkno:0x8b800018 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d318 len:24 a:0x808d370 len:128=20 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 SUPER Block Buffer: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D TRANS: tid:0xc45c8894 type:DIOSTRAT #items:5 trans:0x0 q:0x808cf70 INO: cnt:3 total:3 a:0x808cf90 len:52 a:0x808cfe8 len:96 a:0x808d050 len:32= =20 INODE: #regs:3 ino:0x104 flags:0x5 dsize:32 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x808d078 len:24 a:0x808d0d0 len:128=20 BUF: #regs:2 start blkno:0x8b800001 len:1 bmap size:1 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x808d158 len:28 a:0x808d1b0 len:128=20 BUF: #regs:2 start blkno:0x8b800010 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d238 len:28 a:0x808d290 len:128=20 BUF: #regs:2 start blkno:0x8b800018 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d318 len:24 a:0x808d370 len:128=20 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 SUPER Block Buffer: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D TRANS: tid:0xc45c88b8 type:DIOSTRAT #items:5 trans:0x0 q:0x808cf70 INO: cnt:3 total:3 a:0x808cf90 len:52 a:0x808cfe8 len:96 a:0x808d050 len:32= =20 INODE: #regs:3 ino:0x104 flags:0x5 dsize:32 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x808d078 len:24 a:0x808d0d0 len:128=20 BUF: #regs:2 start blkno:0x8b800001 len:1 bmap size:1 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x808d158 len:28 a:0x808d1b0 len:128=20 BUF: #regs:2 start blkno:0x8b800010 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d238 len:28 a:0x808d290 len:128=20 BUF: #regs:2 start blkno:0x8b800018 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d318 len:24 a:0x808d370 len:128=20 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 SUPER Block Buffer: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D TRANS: tid:0xc45c88dc type:DIOSTRAT #items:5 trans:0x0 q:0x808cf70 INO: cnt:3 total:3 a:0x808cf90 len:52 a:0x808cfe8 len:96 a:0x808d050 len:32= =20 INODE: #regs:3 ino:0x104 flags:0x5 dsize:32 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x808d078 len:24 a:0x808d0d0 len:128=20 BUF: #regs:2 start blkno:0x8b800001 len:1 bmap size:1 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x808d158 len:28 a:0x808d1b0 len:128=20 BUF: #regs:2 start blkno:0x8b800010 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d238 len:28 a:0x808d290 len:128=20 BUF: #regs:2 start blkno:0x8b800018 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d318 len:24 a:0x808d370 len:128=20 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 SUPER Block Buffer: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D TRANS: tid:0xc45c8900 type:DIOSTRAT #items:5 trans:0x0 q:0x808cf70 INO: cnt:3 total:3 a:0x808cf90 len:52 a:0x808cfe8 len:96 a:0x808d050 len:32= =20 INODE: #regs:3 ino:0x104 flags:0x5 dsize:32 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x808d078 len:24 a:0x808d0d0 len:128=20 BUF: #regs:2 start blkno:0x8b800001 len:1 bmap size:1 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x808d158 len:28 a:0x808d1b0 len:128=20 BUF: #regs:2 start blkno:0x8b800010 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d238 len:28 a:0x808d290 len:128=20 BUF: #regs:2 start blkno:0x8b800018 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d318 len:24 a:0x808d370 len:128=20 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 SUPER Block Buffer: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D TRANS: tid:0xc45c8948 type:DIOSTRAT #items:5 trans:0x0 q:0x808cf70 INO: cnt:3 total:3 a:0x808cf90 len:52 a:0x808cfe8 len:96 a:0x808d050 len:32= =20 INODE: #regs:3 ino:0x104 flags:0x5 dsize:32 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x808d078 len:24 a:0x808d0d0 len:128=20 BUF: #regs:2 start blkno:0x8b800001 len:1 bmap size:1 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x808d158 len:28 a:0x808d1b0 len:128=20 BUF: #regs:2 start blkno:0x8b800010 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d238 len:28 a:0x808d290 len:128=20 BUF: #regs:2 start blkno:0x8b800018 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d318 len:24 a:0x808d370 len:128=20 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 SUPER Block Buffer: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D TRANS: tid:0xc45c8924 type:DIOSTRAT #items:5 trans:0x0 q:0x808cf70 INO: cnt:3 total:3 a:0x808cf90 len:52 a:0x808cfe8 len:96 a:0x808d050 len:32= =20 INODE: #regs:3 ino:0x104 flags:0x5 dsize:32 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x808d078 len:24 a:0x808d0d0 len:128=20 BUF: #regs:2 start blkno:0x8b800001 len:1 bmap size:1 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x808d158 len:28 a:0x808d1b0 len:128=20 BUF: #regs:2 start blkno:0x8b800010 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d238 len:28 a:0x808d290 len:128=20 BUF: #regs:2 start blkno:0x8b800018 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d318 len:24 a:0x808d370 len:128=20 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 SUPER Block Buffer: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D TRANS: tid:0xc45c896c type:DIOSTRAT #items:5 trans:0x0 q:0x808cf70 INO: cnt:3 total:3 a:0x808cf90 len:52 a:0x808cfe8 len:96 a:0x808d050 len:32= =20 INODE: #regs:3 ino:0x104 flags:0x5 dsize:32 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x808d078 len:24 a:0x808d0d0 len:128=20 BUF: #regs:2 start blkno:0x8b800001 len:1 bmap size:1 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x808d158 len:28 a:0x808d1b0 len:128=20 BUF: #regs:2 start blkno:0x8b800010 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d238 len:28 a:0x808d290 len:128=20 BUF: #regs:2 start blkno:0x8b800018 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d318 len:24 a:0x808d370 len:128=20 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 SUPER Block Buffer: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D TRANS: tid:0xc45c8990 type:DIOSTRAT #items:5 trans:0x0 q:0x808cf70 INO: cnt:3 total:3 a:0x808cf90 len:52 a:0x808cfe8 len:96 a:0x808d050 len:32= =20 INODE: #regs:3 ino:0x104 flags:0x5 dsize:32 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x808d078 len:24 a:0x808d0d0 len:128=20 BUF: #regs:2 start blkno:0x8b800001 len:1 bmap size:1 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x808d158 len:28 a:0x808d1b0 len:128=20 BUF: #regs:2 start blkno:0x8b800010 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d238 len:28 a:0x808d290 len:128=20 BUF: #regs:2 start blkno:0x8b800018 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d318 len:24 a:0x808d370 len:128=20 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 SUPER Block Buffer: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D TRANS: tid:0xc45c89b4 type:DIOSTRAT #items:5 trans:0x0 q:0x808cf70 INO: cnt:3 total:3 a:0x808cf90 len:52 a:0x808cfe8 len:96 a:0x808d050 len:32= =20 INODE: #regs:3 ino:0x104 flags:0x5 dsize:32 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x808d078 len:24 a:0x808d0d0 len:128=20 BUF: #regs:2 start blkno:0x8b800001 len:1 bmap size:1 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x808d158 len:28 a:0x808d1b0 len:128=20 BUF: #regs:2 start blkno:0x8b800010 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d238 len:28 a:0x808d290 len:128=20 BUF: #regs:2 start blkno:0x8b800018 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d318 len:24 a:0x808d370 len:128=20 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 SUPER Block Buffer: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D TRANS: tid:0xc45c89d8 type:DIOSTRAT #items:5 trans:0x0 q:0x808cf70 INO: cnt:3 total:3 a:0x808cf90 len:52 a:0x808cfe8 len:96 a:0x808d050 len:32= =20 INODE: #regs:3 ino:0x104 flags:0x5 dsize:32 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x808d078 len:24 a:0x808d0d0 len:128=20 BUF: #regs:2 start blkno:0x8b800001 len:1 bmap size:1 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x808d158 len:28 a:0x808d1b0 len:128=20 BUF: #regs:2 start blkno:0x8b800010 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d238 len:28 a:0x808d290 len:128=20 BUF: #regs:2 start blkno:0x8b800018 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d318 len:24 a:0x808d370 len:128=20 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 SUPER Block Buffer: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D TRANS: tid:0xc45c89fc type:DIOSTRAT #items:5 trans:0x0 q:0x808cf70 INO: cnt:3 total:3 a:0x808cf90 len:52 a:0x808cfe8 len:96 a:0x808d050 len:32= =20 INODE: #regs:3 ino:0x104 flags:0x5 dsize:32 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x808d078 len:24 a:0x808d0d0 len:128=20 BUF: #regs:2 start blkno:0x8b800001 len:1 bmap size:1 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x808d158 len:28 a:0x808d1b0 len:128=20 BUF: #regs:2 start blkno:0x8b800010 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d238 len:28 a:0x808d290 len:128=20 BUF: #regs:2 start blkno:0x8b800018 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d318 len:24 a:0x808d370 len:128=20 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 SUPER Block Buffer: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D TRANS: tid:0xc45c8a20 type:DIOSTRAT #items:5 trans:0x0 q:0x808cf70 INO: cnt:3 total:3 a:0x808cf90 len:52 a:0x808cfe8 len:96 a:0x808d050 len:32= =20 INODE: #regs:3 ino:0x104 flags:0x5 dsize:32 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x808d078 len:24 a:0x808d0d0 len:128=20 BUF: #regs:2 start blkno:0x8b800001 len:1 bmap size:1 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x808d158 len:28 a:0x808d1b0 len:128=20 BUF: #regs:2 start blkno:0x8b800010 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d238 len:28 a:0x808d290 len:128=20 BUF: #regs:2 start blkno:0x8b800018 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d318 len:24 a:0x808d370 len:128=20 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 SUPER Block Buffer: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D TRANS: tid:0xc45c8a44 type:DIOSTRAT #items:5 trans:0x0 q:0x808cf70 INO: cnt:3 total:3 a:0x808cf90 len:52 a:0x808cfe8 len:96 a:0x808d050 len:32= =20 INODE: #regs:3 ino:0x104 flags:0x5 dsize:32 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x808d078 len:24 a:0x808d0d0 len:128=20 BUF: #regs:2 start blkno:0x8b800001 len:1 bmap size:1 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x808d158 len:28 a:0x808d1b0 len:128=20 BUF: #regs:2 start blkno:0x8b800010 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d238 len:28 a:0x808d290 len:128=20 BUF: #regs:2 start blkno:0x8b800018 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d318 len:24 a:0x808d370 len:128=20 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 SUPER Block Buffer: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D TRANS: tid:0xc45c8a68 type:DIOSTRAT #items:5 trans:0x0 q:0x808cf70 INO: cnt:3 total:3 a:0x808cf90 len:52 a:0x808cfe8 len:96 a:0x808d050 len:32= =20 INODE: #regs:3 ino:0x104 flags:0x5 dsize:32 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x808d078 len:24 a:0x808d0d0 len:128=20 BUF: #regs:2 start blkno:0x8b800001 len:1 bmap size:1 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x808d158 len:28 a:0x808d1b0 len:128=20 BUF: #regs:2 start blkno:0x8b800010 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d238 len:28 a:0x808d290 len:128=20 BUF: #regs:2 start blkno:0x8b800018 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d318 len:24 a:0x808d370 len:128=20 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 SUPER Block Buffer: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D TRANS: tid:0xc45c8a8c type:DIOSTRAT #items:5 trans:0x0 q:0x808cf70 INO: cnt:3 total:3 a:0x808cf90 len:52 a:0x808cfe8 len:96 a:0x808d050 len:32= =20 INODE: #regs:3 ino:0x104 flags:0x5 dsize:32 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x808d078 len:24 a:0x808d0d0 len:128=20 BUF: #regs:2 start blkno:0x8b800001 len:1 bmap size:1 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x808d158 len:28 a:0x808d1b0 len:128=20 BUF: #regs:2 start blkno:0x8b800010 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d238 len:28 a:0x808d290 len:128=20 BUF: #regs:2 start blkno:0x8b800018 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d318 len:24 a:0x808d370 len:128=20 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 SUPER Block Buffer: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D TRANS: tid:0xc45c8ab0 type:DIOSTRAT #items:5 trans:0x0 q:0x808cf70 INO: cnt:3 total:3 a:0x808cf90 len:52 a:0x808cfe8 len:96 a:0x808d050 len:32= =20 INODE: #regs:3 ino:0x104 flags:0x5 dsize:32 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x808d078 len:24 a:0x808d0d0 len:128=20 BUF: #regs:2 start blkno:0x8b800001 len:1 bmap size:1 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x808d158 len:28 a:0x808d1b0 len:128=20 BUF: #regs:2 start blkno:0x8b800010 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d238 len:28 a:0x808d290 len:128=20 BUF: #regs:2 start blkno:0x8b800018 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d318 len:24 a:0x808d370 len:128=20 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 SUPER Block Buffer: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D TRANS: tid:0xc45c8ad4 type:DIOSTRAT #items:5 trans:0x0 q:0x808cf70 INO: cnt:3 total:3 a:0x808cf90 len:52 a:0x808cfe8 len:96 a:0x808d050 len:32= =20 INODE: #regs:3 ino:0x104 flags:0x5 dsize:32 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x808d078 len:24 a:0x808d0d0 len:128=20 BUF: #regs:2 start blkno:0x8b800001 len:1 bmap size:1 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x808d158 len:28 a:0x808d1b0 len:128=20 BUF: #regs:2 start blkno:0x8b800010 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d238 len:28 a:0x808d290 len:128=20 BUF: #regs:2 start blkno:0x8b800018 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d318 len:24 a:0x808d370 len:128=20 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 SUPER Block Buffer: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D TRANS: tid:0xc45c8af8 type:DIOSTRAT #items:5 trans:0x0 q:0x808cf70 INO: cnt:3 total:3 a:0x808cf90 len:52 a:0x808cfe8 len:96 a:0x808d050 len:32= =20 INODE: #regs:3 ino:0x104 flags:0x5 dsize:32 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x808d078 len:24 a:0x808d0d0 len:128=20 BUF: #regs:2 start blkno:0x8b800001 len:1 bmap size:1 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x808d158 len:28 a:0x808d1b0 len:128=20 BUF: #regs:2 start blkno:0x8b800010 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d238 len:28 a:0x808d290 len:128=20 BUF: #regs:2 start blkno:0x8b800018 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d318 len:24 a:0x808d370 len:128=20 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 SUPER Block Buffer: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D TRANS: tid:0xc45c8b1c type:DIOSTRAT #items:5 trans:0x0 q:0x808cf70 INO: cnt:3 total:3 a:0x808cf90 len:52 a:0x808cfe8 len:96 a:0x808d050 len:32= =20 INODE: #regs:3 ino:0x104 flags:0x5 dsize:32 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x808d078 len:24 a:0x808d0d0 len:128=20 BUF: #regs:2 start blkno:0x8b800001 len:1 bmap size:1 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x808d158 len:28 a:0x808d1b0 len:128=20 BUF: #regs:2 start blkno:0x8b800010 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d238 len:28 a:0x808d290 len:128=20 BUF: #regs:2 start blkno:0x8b800018 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d318 len:24 a:0x808d370 len:128=20 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 SUPER Block Buffer: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D TRANS: tid:0xc45c8b40 type:DIOSTRAT #items:5 trans:0x0 q:0x808cf70 INO: cnt:3 total:3 a:0x808cf90 len:52 a:0x808cfe8 len:96 a:0x808d050 len:32= =20 INODE: #regs:3 ino:0x104 flags:0x5 dsize:32 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x808d078 len:24 a:0x808d0d0 len:128=20 BUF: #regs:2 start blkno:0x8b800001 len:1 bmap size:1 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x808d158 len:28 a:0x808d1b0 len:128=20 BUF: #regs:2 start blkno:0x8b800010 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d238 len:28 a:0x808d290 len:128=20 BUF: #regs:2 start blkno:0x8b800018 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d318 len:24 a:0x808d370 len:128=20 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 SUPER Block Buffer: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D TRANS: tid:0xc45c8b64 type:DIOSTRAT #items:5 trans:0x0 q:0x808cf70 INO: cnt:3 total:3 a:0x808cf90 len:52 a:0x808cfe8 len:96 a:0x808d050 len:32= =20 INODE: #regs:3 ino:0x104 flags:0x5 dsize:32 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x808d078 len:24 a:0x808d0d0 len:128=20 BUF: #regs:2 start blkno:0x8b800001 len:1 bmap size:1 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x808d158 len:28 a:0x808d1b0 len:128=20 BUF: #regs:2 start blkno:0x8b800010 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d238 len:28 a:0x808d290 len:128=20 BUF: #regs:2 start blkno:0x8b800018 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d318 len:24 a:0x808d370 len:128=20 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 SUPER Block Buffer: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D TRANS: tid:0xc45c8b88 type:DIOSTRAT #items:5 trans:0x0 q:0x808cf70 INO: cnt:3 total:3 a:0x808cf90 len:52 a:0x808cfe8 len:96 a:0x808d050 len:32= =20 INODE: #regs:3 ino:0x104 flags:0x5 dsize:32 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x808d078 len:24 a:0x808d0d0 len:128=20 BUF: #regs:2 start blkno:0x8b800001 len:1 bmap size:1 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x808d158 len:28 a:0x808d1b0 len:128=20 BUF: #regs:2 start blkno:0x8b800010 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d238 len:28 a:0x808d290 len:128=20 BUF: #regs:2 start blkno:0x8b800018 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d318 len:24 a:0x808d370 len:128=20 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 SUPER Block Buffer: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D TRANS: tid:0xc45c8bac type:DIOSTRAT #items:5 trans:0x0 q:0x808cf70 INO: cnt:3 total:3 a:0x808cf90 len:52 a:0x808cfe8 len:96 a:0x808d050 len:32= =20 INODE: #regs:3 ino:0x104 flags:0x5 dsize:32 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x808d078 len:24 a:0x808d0d0 len:128=20 BUF: #regs:2 start blkno:0x8b800001 len:1 bmap size:1 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x808d158 len:28 a:0x808d1b0 len:128=20 BUF: #regs:2 start blkno:0x8b800010 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d238 len:28 a:0x808d290 len:128=20 BUF: #regs:2 start blkno:0x8b800018 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d318 len:24 a:0x808d370 len:128=20 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 SUPER Block Buffer: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D TRANS: tid:0xc45c8bd0 type:DIOSTRAT #items:5 trans:0x0 q:0x808cf70 INO: cnt:3 total:3 a:0x808cf90 len:52 a:0x808cfe8 len:96 a:0x808d050 len:32= =20 INODE: #regs:3 ino:0x104 flags:0x5 dsize:32 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x808d078 len:24 a:0x808d0d0 len:128=20 BUF: #regs:2 start blkno:0x8b800001 len:1 bmap size:1 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x808d158 len:28 a:0x808d1b0 len:128=20 BUF: #regs:2 start blkno:0x8b800010 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d238 len:28 a:0x808d290 len:128=20 BUF: #regs:2 start blkno:0x8b800018 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d318 len:24 a:0x808d370 len:128=20 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 SUPER Block Buffer: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D TRANS: tid:0xc45c8c18 type:DIOSTRAT #items:5 trans:0x0 q:0x808cf70 INO: cnt:3 total:3 a:0x808cf90 len:52 a:0x808cfe8 len:96 a:0x808d050 len:32= =20 INODE: #regs:3 ino:0x104 flags:0x5 dsize:32 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x808d078 len:24 a:0x808d0d0 len:128=20 BUF: #regs:2 start blkno:0x8b800001 len:1 bmap size:1 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x808d158 len:28 a:0x808d1b0 len:128=20 BUF: #regs:2 start blkno:0x8b800010 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d238 len:28 a:0x808d290 len:128=20 BUF: #regs:2 start blkno:0x8b800018 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d318 len:24 a:0x808d370 len:128=20 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 SUPER Block Buffer: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D TRANS: tid:0xc45c8bf4 type:DIOSTRAT #items:5 trans:0x0 q:0x808cf70 INO: cnt:3 total:3 a:0x808cf90 len:52 a:0x808cfe8 len:96 a:0x808d050 len:32= =20 INODE: #regs:3 ino:0x104 flags:0x5 dsize:32 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x808d078 len:24 a:0x808d0d0 len:128=20 BUF: #regs:2 start blkno:0x8b800001 len:1 bmap size:1 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x808d158 len:28 a:0x808d1b0 len:128=20 BUF: #regs:2 start blkno:0x8b800010 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d238 len:28 a:0x808d290 len:128=20 BUF: #regs:2 start blkno:0x8b800018 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d318 len:24 a:0x808d370 len:128=20 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 SUPER Block Buffer: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D TRANS: tid:0xc45c8c3c type:DIOSTRAT #items:5 trans:0x0 q:0x808cf70 INO: cnt:3 total:3 a:0x808cf90 len:52 a:0x808cfe8 len:96 a:0x808d050 len:32= =20 INODE: #regs:3 ino:0x104 flags:0x5 dsize:32 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x808d078 len:24 a:0x808d0d0 len:128=20 BUF: #regs:2 start blkno:0x8b800001 len:1 bmap size:1 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x808d158 len:28 a:0x808d1b0 len:128=20 BUF: #regs:2 start blkno:0x8b800010 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d238 len:28 a:0x808d290 len:128=20 BUF: #regs:2 start blkno:0x8b800018 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d318 len:24 a:0x808d370 len:128=20 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 SUPER Block Buffer: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D TRANS: tid:0xc45c8c60 type:DIOSTRAT #items:5 trans:0x0 q:0x808cf70 INO: cnt:3 total:3 a:0x808cf90 len:52 a:0x808cfe8 len:96 a:0x808d050 len:32= =20 INODE: #regs:3 ino:0x104 flags:0x5 dsize:32 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x808d078 len:24 a:0x808d0d0 len:128=20 BUF: #regs:2 start blkno:0x8b800001 len:1 bmap size:1 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x808d158 len:28 a:0x808d1b0 len:128=20 BUF: #regs:2 start blkno:0x8b800010 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d238 len:28 a:0x808d290 len:128=20 BUF: #regs:2 start blkno:0x8b800018 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d318 len:24 a:0x808d370 len:128=20 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 SUPER Block Buffer: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D TRANS: tid:0xc45c8c84 type:DIOSTRAT #items:5 trans:0x0 q:0x808cf70 INO: cnt:3 total:3 a:0x808cf90 len:52 a:0x808cfe8 len:96 a:0x808d050 len:32= =20 INODE: #regs:3 ino:0x104 flags:0x5 dsize:32 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x808d078 len:24 a:0x808d0d0 len:128=20 BUF: #regs:2 start blkno:0x8b800001 len:1 bmap size:1 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x808d158 len:28 a:0x808d1b0 len:128=20 BUF: #regs:2 start blkno:0x8b800010 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d238 len:28 a:0x808d290 len:128=20 BUF: #regs:2 start blkno:0x8b800018 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d318 len:24 a:0x808d370 len:128=20 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 SUPER Block Buffer: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D TRANS: tid:0xc45c8ca8 type:DIOSTRAT #items:5 trans:0x0 q:0x808cf70 INO: cnt:3 total:3 a:0x808cf90 len:52 a:0x808cfe8 len:96 a:0x808d050 len:32= =20 INODE: #regs:3 ino:0x104 flags:0x5 dsize:32 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x808d078 len:24 a:0x808d0d0 len:128=20 BUF: #regs:2 start blkno:0x8b800001 len:1 bmap size:1 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x808d158 len:28 a:0x808d1b0 len:128=20 BUF: #regs:2 start blkno:0x8b800010 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d238 len:28 a:0x808d290 len:128=20 BUF: #regs:2 start blkno:0x8b800018 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d318 len:24 a:0x808d370 len:128=20 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 SUPER Block Buffer: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D TRANS: tid:0xc45c8ccc type:DIOSTRAT #items:5 trans:0x0 q:0x808cf70 INO: cnt:3 total:3 a:0x808cf90 len:52 a:0x808cfe8 len:96 a:0x808d050 len:32= =20 INODE: #regs:3 ino:0x104 flags:0x5 dsize:32 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x808d078 len:24 a:0x808d0d0 len:128=20 BUF: #regs:2 start blkno:0x8b800001 len:1 bmap size:1 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x808d158 len:28 a:0x808d1b0 len:128=20 BUF: #regs:2 start blkno:0x8b800010 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d238 len:28 a:0x808d290 len:128=20 BUF: #regs:2 start blkno:0x8b800018 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d318 len:24 a:0x808d370 len:128=20 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 SUPER Block Buffer: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D TRANS: tid:0xc45c8cf0 type:DIOSTRAT #items:5 trans:0x0 q:0x808cf70 INO: cnt:3 total:3 a:0x808cf90 len:52 a:0x808cfe8 len:96 a:0x808d050 len:32= =20 INODE: #regs:3 ino:0x104 flags:0x5 dsize:32 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x808d078 len:24 a:0x808d0d0 len:128=20 BUF: #regs:2 start blkno:0x8b800001 len:1 bmap size:1 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x808d158 len:28 a:0x808d1b0 len:128=20 BUF: #regs:2 start blkno:0x8b800010 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d238 len:28 a:0x808d290 len:128=20 BUF: #regs:2 start blkno:0x8b800018 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d318 len:24 a:0x808d370 len:128=20 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 SUPER Block Buffer: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D TRANS: tid:0xc45c8d14 type:DIOSTRAT #items:5 trans:0x0 q:0x808cf70 INO: cnt:3 total:3 a:0x808cf90 len:52 a:0x808cfe8 len:96 a:0x808d050 len:32= =20 INODE: #regs:3 ino:0x104 flags:0x5 dsize:32 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x808d078 len:24 a:0x808d0d0 len:128=20 BUF: #regs:2 start blkno:0x8b800001 len:1 bmap size:1 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x808d158 len:28 a:0x808d1b0 len:128=20 BUF: #regs:2 start blkno:0x8b800010 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d238 len:28 a:0x808d290 len:128=20 BUF: #regs:2 start blkno:0x8b800018 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d318 len:24 a:0x808d370 len:128=20 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 SUPER Block Buffer: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D TRANS: tid:0xc45c8d38 type:DIOSTRAT #items:5 trans:0x0 q:0x808cf70 INO: cnt:3 total:3 a:0x808cf90 len:52 a:0x808cfe8 len:96 a:0x808d050 len:32= =20 INODE: #regs:3 ino:0x104 flags:0x5 dsize:32 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x808d078 len:24 a:0x808d0d0 len:128=20 BUF: #regs:2 start blkno:0x8b800001 len:1 bmap size:1 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x808d158 len:28 a:0x808d1b0 len:128=20 BUF: #regs:2 start blkno:0x8b800010 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d238 len:28 a:0x808d290 len:128=20 BUF: #regs:2 start blkno:0x8b800018 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d318 len:24 a:0x808d370 len:128=20 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 SUPER Block Buffer: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D TRANS: tid:0xc45c8d5c type:DIOSTRAT #items:5 trans:0x0 q:0x808cf70 INO: cnt:3 total:3 a:0x808cf90 len:52 a:0x808cfe8 len:96 a:0x808d050 len:32= =20 INODE: #regs:3 ino:0x104 flags:0x5 dsize:32 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x808d078 len:24 a:0x808d0d0 len:128=20 BUF: #regs:2 start blkno:0x8b800001 len:1 bmap size:1 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x808d158 len:28 a:0x808d1b0 len:128=20 BUF: #regs:2 start blkno:0x8b800010 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d238 len:28 a:0x808d290 len:128=20 BUF: #regs:2 start blkno:0x8b800018 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d318 len:24 a:0x808d370 len:128=20 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 SUPER Block Buffer: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D TRANS: tid:0xc45c8d80 type:DIOSTRAT #items:5 trans:0x0 q:0x808cf70 INO: cnt:3 total:3 a:0x808cf90 len:52 a:0x808cfe8 len:96 a:0x808d050 len:32= =20 INODE: #regs:3 ino:0x104 flags:0x5 dsize:32 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x808d078 len:24 a:0x808d0d0 len:128=20 BUF: #regs:2 start blkno:0x8b800001 len:1 bmap size:1 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x808d158 len:28 a:0x808d1b0 len:128=20 BUF: #regs:2 start blkno:0x8b800010 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d238 len:28 a:0x808d290 len:128=20 BUF: #regs:2 start blkno:0x8b800018 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d318 len:24 a:0x808d370 len:128=20 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 SUPER Block Buffer: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D TRANS: tid:0xc45c8da4 type:DIOSTRAT #items:5 trans:0x0 q:0x808cf70 INO: cnt:3 total:3 a:0x808cf90 len:52 a:0x808cfe8 len:96 a:0x808d050 len:32= =20 INODE: #regs:3 ino:0x104 flags:0x5 dsize:32 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x808d078 len:24 a:0x808d0d0 len:128=20 BUF: #regs:2 start blkno:0x8b800001 len:1 bmap size:1 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x808d158 len:28 a:0x808d1b0 len:128=20 BUF: #regs:2 start blkno:0x8b800010 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d238 len:28 a:0x808d290 len:128=20 BUF: #regs:2 start blkno:0x8b800018 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d318 len:24 a:0x808d370 len:128=20 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 SUPER Block Buffer: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D TRANS: tid:0xc45c8dc8 type:DIOSTRAT #items:5 trans:0x0 q:0x808cf70 INO: cnt:3 total:3 a:0x808cf90 len:52 a:0x808cfe8 len:96 a:0x808d050 len:32= =20 INODE: #regs:3 ino:0x104 flags:0x5 dsize:32 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x808d078 len:24 a:0x808d0d0 len:128=20 BUF: #regs:2 start blkno:0x8b800001 len:1 bmap size:1 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x808d158 len:28 a:0x808d1b0 len:128=20 BUF: #regs:2 start blkno:0x8b800010 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d238 len:28 a:0x808d290 len:128=20 BUF: #regs:2 start blkno:0x8b800018 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d318 len:24 a:0x808d370 len:128=20 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 SUPER Block Buffer: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D TRANS: tid:0xc45c8dec type:DIOSTRAT #items:5 trans:0x0 q:0x808cf70 INO: cnt:3 total:3 a:0x808cf90 len:52 a:0x808cfe8 len:96 a:0x808d050 len:32= =20 INODE: #regs:3 ino:0x104 flags:0x5 dsize:32 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x808d078 len:24 a:0x808d0d0 len:128=20 BUF: #regs:2 start blkno:0x8b800001 len:1 bmap size:1 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x808d158 len:28 a:0x808d1b0 len:128=20 BUF: #regs:2 start blkno:0x8b800010 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d238 len:28 a:0x808d290 len:128=20 BUF: #regs:2 start blkno:0x8b800018 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d318 len:24 a:0x808d370 len:128=20 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 SUPER Block Buffer: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D TRANS: tid:0xc45c8e10 type:DIOSTRAT #items:5 trans:0x0 q:0x808cf70 INO: cnt:3 total:3 a:0x808cf90 len:52 a:0x808cfe8 len:96 a:0x808d050 len:32= =20 INODE: #regs:3 ino:0x104 flags:0x5 dsize:32 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x808d078 len:24 a:0x808d0d0 len:128=20 BUF: #regs:2 start blkno:0x8b800001 len:1 bmap size:1 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x808d158 len:28 a:0x808d1b0 len:128=20 BUF: #regs:2 start blkno:0x8b800010 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d238 len:28 a:0x808d290 len:128=20 BUF: #regs:2 start blkno:0x8b800018 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d318 len:24 a:0x808d370 len:128=20 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 SUPER Block Buffer: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D TRANS: tid:0xc45c8e34 type:DIOSTRAT #items:5 trans:0x0 q:0x808cf70 INO: cnt:3 total:3 a:0x808cf90 len:52 a:0x808cfe8 len:96 a:0x808d050 len:32= =20 INODE: #regs:3 ino:0x104 flags:0x5 dsize:32 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x808d078 len:24 a:0x808d0d0 len:128=20 BUF: #regs:2 start blkno:0x8b800001 len:1 bmap size:1 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x808d158 len:28 a:0x808d1b0 len:128=20 BUF: #regs:2 start blkno:0x8b800010 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d238 len:28 a:0x808d290 len:128=20 BUF: #regs:2 start blkno:0x8b800018 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d318 len:24 a:0x808d370 len:128=20 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 SUPER Block Buffer: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D TRANS: tid:0xc45c8e58 type:DIOSTRAT #items:5 trans:0x0 q:0x808cf70 INO: cnt:3 total:3 a:0x808cf90 len:52 a:0x808cfe8 len:96 a:0x808d050 len:32= =20 INODE: #regs:3 ino:0x104 flags:0x5 dsize:32 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x808d078 len:24 a:0x808d0d0 len:128=20 BUF: #regs:2 start blkno:0x8b800001 len:1 bmap size:1 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x808d158 len:28 a:0x808d1b0 len:128=20 BUF: #regs:2 start blkno:0x8b800010 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d238 len:28 a:0x808d290 len:128=20 BUF: #regs:2 start blkno:0x8b800018 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d318 len:24 a:0x808d370 len:128=20 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 SUPER Block Buffer: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D TRANS: tid:0xc45c8e7c type:DIOSTRAT #items:5 trans:0x0 q:0x808cf70 INO: cnt:3 total:3 a:0x808cf90 len:52 a:0x808cfe8 len:96 a:0x808d050 len:32= =20 INODE: #regs:3 ino:0x104 flags:0x5 dsize:32 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x808d078 len:24 a:0x808d0d0 len:128=20 BUF: #regs:2 start blkno:0x8b800001 len:1 bmap size:1 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x808d158 len:28 a:0x808d1b0 len:128=20 BUF: #regs:2 start blkno:0x8b800010 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d238 len:28 a:0x808d290 len:128=20 BUF: #regs:2 start blkno:0x8b800018 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d318 len:24 a:0x808d370 len:128=20 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 SUPER Block Buffer: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D TRANS: tid:0xc45c8ea0 type:DIOSTRAT #items:5 trans:0x0 q:0x808cf70 INO: cnt:3 total:3 a:0x808cf90 len:52 a:0x808cfe8 len:96 a:0x808d050 len:32= =20 INODE: #regs:3 ino:0x104 flags:0x5 dsize:32 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x808d078 len:24 a:0x808d0d0 len:128=20 BUF: #regs:2 start blkno:0x8b800001 len:1 bmap size:1 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x808d158 len:28 a:0x808d1b0 len:128=20 BUF: #regs:2 start blkno:0x8b800010 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d238 len:28 a:0x808d290 len:128=20 BUF: #regs:2 start blkno:0x8b800018 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d318 len:24 a:0x808d370 len:128=20 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 SUPER Block Buffer: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D TRANS: tid:0xc45c8ec4 type:DIOSTRAT #items:5 trans:0x0 q:0x808cf70 INO: cnt:3 total:3 a:0x808cf90 len:52 a:0x808cfe8 len:96 a:0x808d050 len:32= =20 INODE: #regs:3 ino:0x104 flags:0x5 dsize:32 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x808d078 len:24 a:0x808d0d0 len:128=20 BUF: #regs:2 start blkno:0x8b800001 len:1 bmap size:1 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x808d158 len:28 a:0x808d1b0 len:128=20 BUF: #regs:2 start blkno:0x8b800010 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d238 len:28 a:0x808d290 len:128=20 BUF: #regs:2 start blkno:0x8b800018 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d318 len:24 a:0x808d370 len:128=20 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 SUPER Block Buffer: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D TRANS: tid:0xc45c8ee8 type:DIOSTRAT #items:5 trans:0x0 q:0x808cf70 INO: cnt:3 total:3 a:0x808cf90 len:52 a:0x808cfe8 len:96 a:0x808d050 len:32= =20 INODE: #regs:3 ino:0x104 flags:0x5 dsize:32 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x808d078 len:24 a:0x808d0d0 len:128=20 BUF: #regs:2 start blkno:0x8b800001 len:1 bmap size:1 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x808d158 len:28 a:0x808d1b0 len:128=20 BUF: #regs:2 start blkno:0x8b800010 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d238 len:28 a:0x808d290 len:128=20 BUF: #regs:2 start blkno:0x8b800018 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d318 len:24 a:0x808d370 len:128=20 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 SUPER Block Buffer: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D TRANS: tid:0xc45c8f30 type:DIOSTRAT #items:5 trans:0x0 q:0x808cf70 INO: cnt:3 total:3 a:0x808cf90 len:52 a:0x808cfe8 len:96 a:0x808d050 len:32= =20 INODE: #regs:3 ino:0x104 flags:0x5 dsize:32 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x808d078 len:24 a:0x808d0d0 len:128=20 BUF: #regs:2 start blkno:0x8b800001 len:1 bmap size:1 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x808d158 len:28 a:0x808d1b0 len:128=20 BUF: #regs:2 start blkno:0x8b800010 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d238 len:28 a:0x808d290 len:128=20 BUF: #regs:2 start blkno:0x8b800018 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d318 len:24 a:0x808d370 len:128=20 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 SUPER Block Buffer: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D TRANS: tid:0xc45c8f0c type:DIOSTRAT #items:5 trans:0x0 q:0x808cf70 INO: cnt:3 total:3 a:0x808cf90 len:52 a:0x808cfe8 len:96 a:0x808d050 len:32= =20 INODE: #regs:3 ino:0x104 flags:0x5 dsize:32 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x808d078 len:24 a:0x808d0d0 len:128=20 BUF: #regs:2 start blkno:0x8b800001 len:1 bmap size:1 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x808d158 len:28 a:0x808d1b0 len:128=20 BUF: #regs:2 start blkno:0x8b800010 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d238 len:28 a:0x808d290 len:128=20 BUF: #regs:2 start blkno:0x8b800018 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x808d318 len:24 a:0x808d370 len:128=20 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 SUPER Block Buffer: --=-zva6SAgwqdr3C7TScaN5-- --=-SnKinJMn7KfAzVUZ68ve Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQA/fvqdwEgIdc/nA8oRAtHDAJ4yQvoIzN8ZeI0qCz443MAG2b8ZPgCgjEID tc9NDDwslt6cW1tAjk8/1VY= =oRoz -----END PGP SIGNATURE----- --=-SnKinJMn7KfAzVUZ68ve-- From owner-linux-xfs@oss.sgi.com Sat Oct 4 12:10:38 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 04 Oct 2003 12:11:21 -0700 (PDT) Received: from elrond.render-it.com (mail.illuvatar.net [205.147.19.123]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h94JAb25011005 for ; Sat, 4 Oct 2003 12:10:38 -0700 Received: from illuvatar.com (elrond [193.168.254.200]) by elrond.render-it.com (SGI-8.9.3/8.9.3) with ESMTP id MAA70766 for ; Sat, 4 Oct 2003 12:00:31 -0700 (PDT) Message-ID: <3F7F18CF.FF45C438@illuvatar.com> Date: Sat, 04 Oct 2003 12:00:31 -0700 From: "William C. Shortell" Organization: ILLUVATAR, LLC X-Mailer: Mozilla 4.79C-SGI [en] (X11; I; IRIX64 6.5 IP28) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Linux XFS Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 635 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bill@illuvatar.com Precedence: bulk X-list: linux-xfs Content-Length: 1289 Lines: 33 Tech support, I installed xfs on my linux box using your iso (forRH-9.0-SGI-XFS-1.3.0.v1.iso). I ran into a number of problems. 1) Can't boot from iso because it doesn't recognize SCSI system disks. Looking back, I might have been able to accomplish this if I had created a block driver disk. However, I just mounted the iso image and did an rpm install. 2) Once installed, I converted all but my / partition to xfs. Everything went absolutely fine. However, once I tried to convert the / partition to xfs I was unable to boot. Luckily, I was able to go back to my ext3 filesystem and get my machine up. 3) I downloaded the linux-2.4.22 kernel and the xfs-2.4.22-all-i386.bz2 file. Compiled and installed the kernel, modified my /etc/fstab file, and still couldn't boot. Linux kept trying to mount my / partition as ext3. When I listed the modules that were loaded, xfs was not one of them. 4) Finally, after compiling xfs into the kernel and creating a new initrd image, I was able to boot. My question is if you can tell me what entry to add to /etc/modules.conf to get the xfs module to load on boot up. -- William C. Shortell ILLUVATAR,LLC Phone/Fax (714) 965-5918 PO Box 8506 Cell (310) 753-1774 Fountain Valley, CA 92728-8506 E-mail bill@illuvatar.com From owner-linux-xfs@oss.sgi.com Sat Oct 4 13:14:43 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 04 Oct 2003 13:15:29 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h94KEg25018818 for ; Sat, 4 Oct 2003 13:14:43 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h94KEbq0032641 for ; Sat, 4 Oct 2003 13:14:37 -0700 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h94KEacc11903042; Sat, 4 Oct 2003 15:14:36 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h94KEaK22149837; Sat, 4 Oct 2003 15:14:36 -0500 (CDT) Date: Sat, 4 Oct 2003 15:14:35 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: "William C. Shortell" cc: linux-xfs@oss.sgi.com Subject: Re: Linux XFS In-Reply-To: <3F7F18CF.FF45C438@illuvatar.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 636 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1583 Lines: 41 On Sat, 4 Oct 2003, William C. Shortell wrote: > Tech support, Where? :) > 1) Can't boot from iso because it doesn't recognize SCSI system disks. > Looking back, I might have been able to accomplish this if I had created > a block driver disk. However, I just mounted the iso image and did an > rpm install. Does the stock RH driver work? What scsi card do you have? I'd be surprised if the problem is specifically related to our installer, but perhaps. > 2) Once installed, I converted all but my / partition to xfs. > Everything went absolutely fine. However, once I tried to convert the / > partition to xfs I was unable to boot. Luckily, I was able to go back > to my ext3 filesystem and get my machine up. "unable to boot" isn't enough info to go on, what errors did you encounter? I take it that you did not go through the full installer, since you could not boot the iso, did you simply install the kernel, or? > 3) I downloaded the linux-2.4.22 kernel and the xfs-2.4.22-all-i386.bz2 > file. Compiled and installed the kernel, modified my /etc/fstab file, > and still couldn't boot. Linux kept trying to mount my / partition as > ext3. When I listed the modules that were loaded, xfs was not one of > them. mkinitrd looks at fstab and modules.conf when deciding which modules to include - try "-v" to see what it's adding. You can also specifically include modules, try --with=xfs > 4) Finally, after compiling xfs into the kernel and creating a new > initrd image, I was able to boot. Sounds like it all boils down to a bad initrd image. -Eric From owner-linux-xfs@oss.sgi.com Sun Oct 5 11:37:06 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 05 Oct 2003 11:37:44 -0700 (PDT) Received: from linux-sxs.org (d60-65-142-166.col.wideopenwest.com [65.60.166.142]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h95Ib525028942 for ; Sun, 5 Oct 2003 11:37:06 -0700 Received: from linux-sxs.org (localhost [127.0.0.1]) by linux-sxs.org (8.12.10/8.12.10) with ESMTP id h95I72vd026783 for ; Sun, 5 Oct 2003 14:07:02 -0400 Received: from localhost (netllama@localhost) by linux-sxs.org (8.12.10/8.12.10/Submit) with ESMTP id h95I7261032732 for ; Sun, 5 Oct 2003 14:07:02 -0400 Date: Sun, 5 Oct 2003 14:07:02 -0400 (EDT) From: Net Llama! To: linux-xfs@oss.sgi.com Subject: oss.sgi.com ftp server tanked? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: OK, scanned by File::Scan,ClamAV X-Scanned-By: MIMEDefang 2.37 X-archive-position: 637 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: netllama@linux-sxs.org Precedence: bulk X-list: linux-xfs Content-Length: 360 Lines: 9 Can someone in authority check the status of the oss.sgi.com ftp server? Looks like ftp://oss.sgi.com/projects/xfs is currently set to 700 perms. Is this intentional? If so, why? -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lonni J Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo http://netllama.ipfox.com From owner-linux-xfs@oss.sgi.com Sun Oct 5 12:42:33 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 05 Oct 2003 12:42:55 -0700 (PDT) Received: from blake.timetraveller.org (blake.timetraveller.org [203.23.43.10]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h95JgV25004157 for ; Sun, 5 Oct 2003 12:42:32 -0700 Received: from zen.canint.timetraveller.org (CPE00105ae6b1e1-CM000039aeec61.cpe.net.cable.rogers.com [63.139.6.84]) by blake.timetraveller.org (8.12.3/8.12.3) with ESMTP id h95JgJIa019861 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Mon, 6 Oct 2003 05:42:21 +1000 Received: from zen.canint.timetraveller.org (zen.canint.timetraveller.org [192.168.120.1]) by zen.canint.timetraveller.org (8.12.10/8.12.10) with ESMTP id h95Jg5R7020611; Sun, 5 Oct 2003 15:42:05 -0400 Date: Sun, 5 Oct 2003 15:42:05 -0400 (EDT) From: Robert Brockway X-X-Sender: robert@zen.canint.timetraveller.org To: Net Llama! cc: linux-xfs@oss.sgi.com Subject: Re: oss.sgi.com ftp server tanked? In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 639 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: robert@timetraveller.org Precedence: bulk X-list: linux-xfs Content-Length: 485 Lines: 22 On Sun, 5 Oct 2003, Robert Brockway wrote: > zen:~$date > Sun Oct 5 15:39:26 EDT 2003 > (About 1.5 hrs after your post) > > So whatever it was has gone away. Oh no it hasn't :( ncftp /projects > ls -l drwx------ Sep 6 16:39 xfs Sorry for the noise. Rob -- Robert Brockway B.Sc. email: robert@timetraveller.org, zzbrock@uqconnect.net Linux counter project ID #16440 (http://counter.li.org) "The earth is but one country and mankind its citizens" -Baha'u'llah From owner-linux-xfs@oss.sgi.com Sun Oct 5 12:41:18 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 05 Oct 2003 12:41:57 -0700 (PDT) Received: from blake.timetraveller.org (blake.timetraveller.org [203.23.43.10]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h95JfG25003954 for ; Sun, 5 Oct 2003 12:41:17 -0700 Received: from zen.canint.timetraveller.org (CPE00105ae6b1e1-CM000039aeec61.cpe.net.cable.rogers.com [63.139.6.84]) by blake.timetraveller.org (8.12.3/8.12.3) with ESMTP id h95JevIa019832 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Mon, 6 Oct 2003 05:41:00 +1000 Received: from zen.canint.timetraveller.org (zen.canint.timetraveller.org [192.168.120.1]) by zen.canint.timetraveller.org (8.12.10/8.12.10) with ESMTP id h95JehR7020607; Sun, 5 Oct 2003 15:40:43 -0400 Date: Sun, 5 Oct 2003 15:40:43 -0400 (EDT) From: Robert Brockway X-X-Sender: robert@zen.canint.timetraveller.org To: Net Llama! cc: linux-xfs@oss.sgi.com Subject: Re: oss.sgi.com ftp server tanked? In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 638 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: robert@timetraveller.org Precedence: bulk X-list: linux-xfs Content-Length: 579 Lines: 21 On Sun, 5 Oct 2003, Net Llama! wrote: > Can someone in authority check the status of the oss.sgi.com ftp server? > Looks like ftp://oss.sgi.com/projects/xfs is currently set to 700 perms. > Is this intentional? If so, why? It's absolutely fine right now. zen:~$date Sun Oct 5 15:39:26 EDT 2003 (About 1.5 hrs after your post) So whatever it was has gone away. Rob -- Robert Brockway B.Sc. email: robert@timetraveller.org, zzbrock@uqconnect.net Linux counter project ID #16440 (http://counter.li.org) "The earth is but one country and mankind its citizens" -Baha'u'llah From owner-linux-xfs@oss.sgi.com Sun Oct 5 12:59:17 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 05 Oct 2003 12:59:51 -0700 (PDT) Received: from linux-sxs.org (d60-65-142-166.col.wideopenwest.com [65.60.166.142]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h95JxE25005959 for ; Sun, 5 Oct 2003 12:59:17 -0700 Received: from linux-sxs.org (localhost [127.0.0.1]) by linux-sxs.org (8.12.10/8.12.10) with ESMTP id h95JTCvd001081; Sun, 5 Oct 2003 15:29:12 -0400 Received: from localhost (netllama@localhost) by linux-sxs.org (8.12.10/8.12.10/Submit) with ESMTP id h95JTC15011577; Sun, 5 Oct 2003 15:29:12 -0400 Date: Sun, 5 Oct 2003 15:29:12 -0400 (EDT) From: Net Llama! To: Robert Brockway cc: linux-xfs@oss.sgi.com Subject: Re: oss.sgi.com ftp server tanked? In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: OK, scanned by File::Scan,ClamAV X-Scanned-By: MIMEDefang 2.37 X-archive-position: 640 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: netllama@linux-sxs.org Precedence: bulk X-list: linux-xfs Content-Length: 807 Lines: 27 On Sun, 5 Oct 2003, Robert Brockway wrote: > On Sun, 5 Oct 2003, Net Llama! wrote: > > > Can someone in authority check the status of the oss.sgi.com ftp server? > > Looks like ftp://oss.sgi.com/projects/xfs is currently set to 700 perms. > > Is this intentional? If so, why? > > It's absolutely fine right now. > > zen:~$date > Sun Oct 5 15:39:26 EDT 2003 > (About 1.5 hrs after your post) > > So whatever it was has gone away. 550 Can't change directory to /projects/xfs: Permission denied Its not fine. I just tried from 3 different boxes in geographically separate parts of the internet. Sun Oct 5 12:58:41 PDT 2003 -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lonni J Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo http://netllama.ipfox.com From owner-linux-xfs@oss.sgi.com Sun Oct 5 22:46:13 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 05 Oct 2003 22:46:46 -0700 (PDT) Received: from kerberos.suse.cz (kerberos.suse.cz [195.47.106.10]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h965kB25002675 for ; Sun, 5 Oct 2003 22:46:12 -0700 Received: from chimera.suse.cz (chimera.suse.cz [10.20.0.2]) by kerberos.suse.cz (****** SuSE CR *******) with ESMTP id A9C724FB89 for ; Mon, 6 Oct 2003 07:46:05 +0200 (MEST) Received: from alienAngel.upjs.sk (test12.suse.cz [10.20.3.140]) by chimera.suse.cz (Postfix) with ESMTP id 23A434FAA for ; Mon, 6 Oct 2003 07:46:05 +0200 (CEST) Received: from localhost (ja@localhost) by alienAngel.upjs.sk (8.12.7/8.12.6/Submit) with ESMTP id h965mBCm016938 for ; Mon, 6 Oct 2003 07:48:12 +0200 X-Authentication-Warning: alienAngel.home.sk: ja owned process doing -bs Date: Mon, 6 Oct 2003 07:48:11 +0200 (CEST) From: Jan Derfinak X-X-Sender: ja@alienAngel.home.sk To: linux-xfs@oss.sgi.com Subject: BLKGETSIZE64, BLKBSZSET, BLKSSZGET definition in xfsprogs. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 641 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ja@mail.upjs.sk Precedence: bulk X-list: linux-xfs Content-Length: 316 Lines: 11 Hi. While looking to xfsprogs source I found that xfsprogs defines BLKGETSIZE64, BLKBSZSET and BLKSSZGET in libxfs/linux.c. These macros are also defined in /usr/include/linux/fs.h. I'm curious why xfsprogs doesn't include linux/fs.h and doesn't use system defaults instead of own definition? Thanks. jan -- From owner-linux-xfs@oss.sgi.com Sun Oct 5 23:02:55 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 05 Oct 2003 23:03:28 -0700 (PDT) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9662t25003249 for ; Sun, 5 Oct 2003 23:02:55 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id h9646YOO007001 for ; Sun, 5 Oct 2003 21:06:35 -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 QAA25584; Mon, 6 Oct 2003 16:02:31 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h9662UYN311132; Mon, 6 Oct 2003 16:02:30 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id h965xwjn001927; Mon, 6 Oct 2003 15:59:58 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id h965xwYw001925; Mon, 6 Oct 2003 15:59:58 +1000 Date: Mon, 6 Oct 2003 15:59:58 +1000 From: Nathan Scott To: Jan Derfinak Cc: linux-xfs@oss.sgi.com Subject: Re: BLKGETSIZE64, BLKBSZSET, BLKSSZGET definition in xfsprogs. Message-ID: <20031006055957.GC1001@frodo> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i X-archive-position: 642 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 844 Lines: 25 On Mon, Oct 06, 2003 at 07:48:11AM +0200, Jan Derfinak wrote: > Hi. > > While looking to xfsprogs source I found that xfsprogs defines BLKGETSIZE64, > BLKBSZSET and BLKSSZGET in libxfs/linux.c. These macros are also defined in > /usr/include/linux/fs.h. I'm curious why xfsprogs doesn't include ^^^^^^^ There is no guarantee that the installed kernel headers will have these defined. xfsprogs doesn't directly use any kernel headers, for this reason. See the Linux ABI thread on LKML at the moment. > linux/fs.h and doesn't use system defaults instead of own definition? Actually, IIRC these are all conditionally compiled (so if they are already defined via system headers, we use the already-set values). Not that it matters, they should never have any value different to what we define them to here. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Oct 5 23:54:36 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 05 Oct 2003 23:55:38 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h966sX25005651 for ; Sun, 5 Oct 2003 23:54:33 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h966sRq0029717 for ; Sun, 5 Oct 2003 23:54:27 -0700 Received: from boing.melbourne.sgi.com (localhost [127.0.0.1]) by boing.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h966sPBY1911122; Mon, 6 Oct 2003 16:54:25 +1000 (AEST) Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h966sND21918284; Mon, 6 Oct 2003 16:54:23 +1000 (AEST) Date: Mon, 6 Oct 2003 16:54:23 +1000 From: Tim Shimmin To: Marcel de Riedmatten Cc: Linux xfs list Subject: Re: unable to mount filesystem Message-ID: <20031006165423.Q1716630@boing.melbourne.sgi.com> References: <1065286302.20458.44.camel@galadriel> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <1065286302.20458.44.camel@galadriel>; from mdr@dotforge.ch on Sat, Oct 04, 2003 at 06:51:42PM +0200 X-archive-position: 643 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 3496 Lines: 92 Hi Marcel, On Sat, Oct 04, 2003 at 06:51:42PM +0200, Marcel de Riedmatten wrote: > > I was making write tests on a 1.5TB xfs filesystem and after unmounting > it i can't mount it again. It looks like a log corruption or something. > This is what i found in syslog: i try to mount multiple times > > > > Oct 4 17:15:35 grobelix kernel: XFS mounting filesystem sd(8,1) > Oct 4 17:15:36 grobelix kernel: Starting XFS recovery on filesystem: > sd(8,1) (dev: 8/1) > Oct 4 17:15:36 grobelix kernel: XFS: log mount/recovery failed > Oct 4 17:15:36 grobelix kernel: XFS: log mount failed > Oct 4 17:15:50 grobelix kernel: XFS mounting filesystem sd(8,1) > Oct 4 17:15:50 grobelix kernel: Filesystem "sd(8,1)": XFS internal > error > xlog_clear_stale_blocks(2) at line 1253 of file xfs_log_recover.c. > Caller ... > (0xe8539c54)) > Oct 4 17:15:50 grobelix kernel: [] xlog_find_tail [xfs] 0x3c0 > (0xe8539c5c)) ... > This is xfs-1.3 whith Axel Thimm smp i686 package at > http://atrpms.physik.fu-berlin.de/dist/rh73/kernel/ > > > Hardware is supermicro dual xeon board (x5dp8-g2) with 2 GB of ram and a > 3ware 8506-8 with 7 disks raid5. > > > Then try xfs_logprint (without -t ) but it segfault: > xfs_logprint without -t prior to xfsprogs-2.5.10 couldn't handle v2 logs. From xfsprogs/doc/CHANGES: xfsprogs-2.5.10 (30 September 2003) - Fix up xfs_logprint to handle version 2 logs for its operation output (previously core dumped on it). > # xfs_info data > meta-data=/exports/data isize=256 agcount=351, > agsize=1048576 blks > = sectsz=512 > data = bsize=4096 blocks=367671614, > imaxpct=25 > = sunit=16 swidth=96 blks, > unwritten=1 > naming =version 2 bsize=4096 > log =internal bsize=4096 blocks=32736, version=2 > = sectsz=512 sunit=48 blks > realtime =none extsz=65536 blocks=0, rtextents=0 > I noticed that you are using version 2 logs with a striped size of 48 4K-blocks or 8*48=384 BBs (512 byte blocks). I believe there is a bug in the code for log sunit which is not a power of 2 in BBs. xfs_log.c: log->l_stripemask = 1 << xfs_highbit32(mp->m_sb.sb_logsunit >> BBSHIFT); I have a fix in my own code but it is mixed with some other v2 log changes. I'm currently writing v2 log QA to test this stuff out. I'll let you know when I check this stuff in. > xlog_clear_stale_blocks(2) at line 1253 of file xfs_log_recover.c. This error happens (great msg I think not:) if the tail of the log is greater than the head. By greater I mean in terms of . (So if the cycle #s of the head/tail are the same then the tail blk < head blk otherwise the tail cycle# should be one less than the head cycle# since the tail must be on the previous cycle. And the tail should never be greater than the head. > xfs_logprint: > data device: 0x801 > log device: 0x801 daddr: 1468006656 length: 261888 > > log tail: 60416 head: 65279 state: > > > LOG REC AT LSN cycle 7 block 60416 (0x7, 0xec00) > ============================================================================ > TRANS: tid:0xc45c87bc type:DIOSTRAT #items:5 trans:0x0 q:0x808cf70 > It looks like the tail blk# (60416) is less than the head blk# (65279). In which case it is likely that the cycle numbers are not the same like they should be. --Tim From owner-linux-xfs@oss.sgi.com Mon Oct 6 00:48:05 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 06 Oct 2003 00:48:49 -0700 (PDT) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h967m425013222 for ; Mon, 6 Oct 2003 00:48:04 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id h965piOO016414 for ; Sun, 5 Oct 2003 22:51:45 -0700 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.54.232]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA26785 for ; Mon, 6 Oct 2003 17:47:56 +1000 Received: from sherman.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by sherman.melbourne.sgi.com (8.12.8/8.12.8) with ESMTP id h967lu2i028716 for ; Mon, 6 Oct 2003 17:47:56 +1000 Received: (from tes@localhost) by sherman.melbourne.sgi.com (8.12.8/8.12.8/Submit) id h967lutU028714 for linux-xfs@oss.sgi.com; Mon, 6 Oct 2003 17:47:56 +1000 Date: Mon, 6 Oct 2003 17:47:56 +1000 From: Tim Shimmin Message-Id: <200310060747.h967lutU028714@sherman.melbourne.sgi.com> Subject: TAKE - v2 log testing Apparently-To: X-archive-position: 644 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tes@sherman.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1375 Lines: 59 add couple of v2 su cases Date: Wed Oct 1 00:49:36 PDT 2003 Workarea: sherman.melbourne.sgi.com:/build/tes/isms/xfs-cmds The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:159275a xfstests/018 - 1.25 xfstests/018.out - 1.4 Subject: TAKE - Add some error msgs instead of silence on error. Date: Wed Oct 1 01:03:06 PDT 2003 Workarea: sherman.melbourne.sgi.com:/build/tes/isms/xfs-cmds The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:159277a xfsprogs/logprint/log_print_trans.c - 1.10 - Add some error msgs instead of silence on error. xfsprogs/include/libxlog.h - 1.11 - Allow error msg in library to come out on debug. Subject: TAKE - Split up v2 log testing Date: Mon Oct 6 00:46:19 PDT 2003 Workarea: sherman.melbourne.sgi.com:/build/tes/isms/xfs-cmds The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:159500a xfstests/082 - 1.1 xfstests/common.log - 1.1 xfstests/082.out - 1.1 xfstests/081 - 1.1 xfstests/081.out - 1.1 xfstests/081.ugquota.trans_inode - 1.1 xfstests/082.noquota.trans_inode - 1.1 xfstests/082.noquota.op - 1.1 xfstests/082.noquota.trans_buf - 1.1 xfstests/018 - 1.26 xfstests/group - 1.44 xfstests/018.out - 1.5 xfstests/018.ugquota.trans_inode - 1.3 From owner-linux-xfs@oss.sgi.com Mon Oct 6 08:45:22 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 06 Oct 2003 08:46:02 -0700 (PDT) Received: from mail.automatix.de (237.230.131.213.rev.inetbone.net [213.131.230.237]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h96FjG25029195 for ; Mon, 6 Oct 2003 08:45:21 -0700 Received: from uucp by mail.automatix.de with local-bsmtp (Exim 3.35 #1) id 1A6THJ-0003Aq-00 for linux-xfs@oss.sgi.com; Mon, 06 Oct 2003 13:11:49 +0200 Received: from pc2.s.automatix.de ([192.168.11.12] ident=jojo) by s.automatix.de with esmtp (Exim 3.36 #1) id 1A6TB7-0003Kk-00 for linux-xfs@oss.sgi.com; Mon, 06 Oct 2003 13:05:25 +0200 From: Juergen Sauer Reply-To: juergen.sauer@automatix.de Organization: AutomatiX GmbH To: linux-xfs@oss.sgi.com Subject: NFS broken again in 2.4.22 ? Date: Mon, 6 Oct 2003 13:05:22 +0200 User-Agent: KMail/1.5.4 MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Description: clearsigned data Content-Disposition: inline Message-Id: <200310061305.22456.juergen.sauer@automatix.de> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h96FjM25029197 X-archive-position: 646 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: juergen.sauer@automatix.de Precedence: bulk X-list: linux-xfs Content-Length: 665 Lines: 24 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! Since the usage of Kernal 2.4.22-xfs (CVS) on Server and Client Side The NFS Link throws up a "NFS Server not responding" Error, which dissapears at once: "NFS Server OK". mfG Jürgen automatiX Linux Support Crew - -- Jürgen Sauer - AutomatiX GmbH, +49-4209-4699, jojo@automatix.de ** ** Das Linux Systemhaus - Service - Support - Server - Lösungen ** ** http://www.automatix.de ICQ: #344389676 ** -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/gUxyW7UKI9EqarERAt9wAJ958SQgN5vJrdrNmeB9EuI5CU2HQACgj8TR sFGg89SIteJZ4UIdUQ+hVcU= =/PX8 -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Mon Oct 6 08:54:26 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 06 Oct 2003 08:55:07 -0700 (PDT) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h96FsQ25029740 for ; Mon, 6 Oct 2003 08:54:26 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h96Dw8OO025373 for ; Mon, 6 Oct 2003 06:58:09 -0700 Received: from tulip-e236.americas.sgi.com (tulip-e236.americas.sgi.com [128.162.236.208]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h96FsKcc11948411; Mon, 6 Oct 2003 10:54:20 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by tulip-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h96FsKSn31181602; Mon, 6 Oct 2003 10:54:20 -0500 (CDT) Received: from jen.americas.sgi.com (localhost.localdomain [127.0.0.1]) by jen.americas.sgi.com (8.12.8/8.12.8) with ESMTP id h96FsKKZ032623; Mon, 6 Oct 2003 10:54:20 -0500 Received: (from lord@localhost) by jen.americas.sgi.com (8.12.8/8.12.8/Submit) id h96FsJI4032621; Mon, 6 Oct 2003 10:54:19 -0500 X-Authentication-Warning: jen.americas.sgi.com: lord set sender to lord@sgi.com using -f Subject: Re: NFS broken again in 2.4.22 ? From: Steve Lord To: juergen.sauer@automatix.de Cc: linux-xfs@oss.sgi.com In-Reply-To: <200310061305.22456.juergen.sauer@automatix.de> References: <200310061305.22456.juergen.sauer@automatix.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1065455659.7063.1956.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 06 Oct 2003 10:54:19 -0500 X-archive-position: 647 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 568 Lines: 20 On Mon, 2003-10-06 at 06:05, Juergen Sauer wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi! > Since the usage of Kernal 2.4.22-xfs (CVS) on Server and Client Side > The NFS Link throws up a "NFS Server not responding" Error, which > dissapears at once: "NFS Server OK". First question is, is that specific to XFS filesystems or not? It is quite possibly a linux NFS issue rather than an XFS one. 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 6 09:47:26 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 06 Oct 2003 09:48:07 -0700 (PDT) Received: from smtp.nofida.ch ([62.2.181.77]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h96Gl325000679 for ; Mon, 6 Oct 2003 09:47:24 -0700 Received: by smtp.nofida.ch (Postfix, from userid 101) id 8371D904; Mon, 6 Oct 2003 18:47:01 +0200 (CEST) Received: from [192.168.74.20] (unknown [192.168.74.20]) by smtp.nofida.ch (Postfix) with ESMTP id 8CBAB259; Mon, 6 Oct 2003 18:46:53 +0200 (CEST) Subject: Re: unable to mount filesystem From: Marcel de Riedmatten To: Linux xfs list In-Reply-To: <20031006165423.Q1716630@boing.melbourne.sgi.com> References: <1065286302.20458.44.camel@galadriel> <20031006165423.Q1716630@boing.melbourne.sgi.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-bXrR1Hgbhy50AwYYPxyW" Organization: Message-Id: <1065458813.6238.273.camel@galadriel> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 06 Oct 2003 18:46:53 +0200 X-Virus-Scanned: by AMaViS perl-11 X-archive-position: 648 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mdr@dotforge.ch Precedence: bulk X-list: linux-xfs Content-Length: 3187 Lines: 102 --=-bXrR1Hgbhy50AwYYPxyW Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Le lun 06/10/2003 =E0 08:54, Tim Shimmin a =E9crit : > Hi Marcel, >=20 > On Sat, Oct 04, 2003 at 06:51:42PM +0200, Marcel de Riedmatten wrote: > >=20 > > Then try xfs_logprint (without -t ) but it segfault: > >=20 >=20 > xfs_logprint without -t prior to xfsprogs-2.5.10 couldn't handle v2 logs. > >From xfsprogs/doc/CHANGES: > xfsprogs-2.5.10 (30 September 2003) > - Fix up xfs_logprint to handle version 2 logs for its > operation output (previously core dumped on it). >=20 Thanks, i thought i was uptodate but $ xfs_logprint -V xfs_logprint version 2.5.6 > >=20 > I noticed that you are using version 2 logs with a striped size of 48 4K-= blocks > or 8*48=3D384 BBs (512 byte blocks). > I believe there is a bug in the code for log sunit which is not > a power of 2 in BBs. > xfs_log.c: log->l_stripemask =3D 1 << xfs_highbit32(mp->m_sb.sb_logsunit = >> BBSHIFT);=20 ok i'll use 64k (128BBs) which is my stripsize. I am going to add lvm to the thing and alignement outside power of 2 will be hard if even possible anyway.=20=20 >=20 > I have a fix in my own code but it is mixed with some other v2 log change= s.=20 > I'm currently writing v2 log QA to test this stuff out. > I'll let you know when I check this stuff in. ok >=20 > > xlog_clear_stale_blocks(2) at line 1253 of file xfs_log_recover.c.=20 > This error happens (great msg I think not:) if the tail of the log > is greater than the head. By greater I mean in terms of . > (So if the cycle #s of the head/tail are the same then=20 > the tail blk < head blk otherwise > the tail cycle# should be one less than the head cycle# since > the tail must be on the previous cycle. > And the tail should never be greater than the head. >=20 > > xfs_logprint: > > data device: 0x801 > > log device: 0x801 daddr: 1468006656 length: 261888 > >=20 > > log tail: 60416 head: 65279 state: > >=20 > >=20 > > LOG REC AT LSN cycle 7 block 60416 (0x7, 0xec00) > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > > TRANS: tid:0xc45c87bc type:DIOSTRAT #items:5 trans:0x0 q:0x808cf70 > > > It looks like the tail blk# (60416) is less than the head blk# (65279). > In which case it is likely that the cycle numbers are not the same like > they should be. I am not sure if this can be seen as consequence of the log alignment. Anyway i 'll try with 64k log alignement and see if i can repeat it.=20 Thanks --=20 Marcel de Riedmatten pgp key: CFE703CA http://ftp.dotforge.ch/pub/users/mdr/mdr.gpg.asc Empreinte: 4687 F9CB D8E2 AC1A B806 F812 C048 0875 CFE7 03CA --=-bXrR1Hgbhy50AwYYPxyW Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQA/gZx9wEgIdc/nA8oRArkRAJ0UM9bU06u9VYdLlZSXHR1RO1R5xwCfSHzg vUeWM9UOwSLKO7h0cniu4Bo= =0Yzx -----END PGP SIGNATURE----- --=-bXrR1Hgbhy50AwYYPxyW-- From owner-linux-xfs@oss.sgi.com Mon Oct 6 13:39:50 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 06 Oct 2003 13:40:30 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h96Kdo25019570 for ; Mon, 6 Oct 2003 13:39:50 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h96IIeq0032113 for ; Mon, 6 Oct 2003 11:18:41 -0700 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h96IIecc11953771 for ; Mon, 6 Oct 2003 13:18:40 -0500 (CDT) Received: from sgi.com (penguin.americas.sgi.com [128.162.240.135]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h96IIeRn318609586 for ; Mon, 6 Oct 2003 13:18:40 -0500 (CDT) Received: from penguin.americas.sgi.com (localhost.localdomain [127.0.0.1]) by sgi.com (8.12.8/8.12.8) with ESMTP id h96IDCGf012056 for ; Mon, 6 Oct 2003 13:13:12 -0500 Received: (from lord@localhost) by penguin.americas.sgi.com (8.12.8/8.12.8/Submit) id h96IDCA2012054 for linux-xfs@oss.sgi.com; Mon, 6 Oct 2003 13:13:12 -0500 Date: Mon, 6 Oct 2003 13:13:12 -0500 From: Steve Lord Message-Id: <200310061813.h96IDCA2012054@penguin.americas.sgi.com> Subject: TAKE Implement deletion of inode clusters in XFS. To: linux-xfs@oss.sgi.com X-archive-position: 649 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@penguin.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 3442 Lines: 105 XFS dynamically allocates space for inodes as they are created, this is different from many other filesystems where inode space is statically allocated at mkfs time. While inode space is dynamically allocated, it is never freed - up until now that is. This non-freeing of space tends to lead to fragmentation on filesystems where lots of files come and go. It can also lead to inodes and their parent directories being scattered around the disk more. With this change, the default behavior is changed to free a cluster of inodes once the last entry in the cluster is freed. The old behavior is still available with the -o ikeep mount option. Date: Mon Oct 6 11:11:55 PDT 2003 Workarea: jen.americas.sgi.com:/src/lord/xfs-idelete The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:159536a linux/fs/xfs/xfsidbg.c - 1.239 - add tracing flags for stale inode clusters. linux/fs/xfs/xfs_ialloc.h - 1.44 - changed prototype for xfs_difree linux/fs/xfs/xfs_ialloc.c - 1.175 - When freeing an inode, check to see if this is the last in use inode in the cluster. If it is, then remove the inode cluster from the inode btree and fix up the super block and agi inode counters. linux/fs/xfs/xfs_buf_item.h - 1.40 - Add XFS_BLI_STALE_INODE definition linux/fs/xfs/xfs_buf_item.c - 1.143 - when unpinning a stale buffer after a log write, add code to deal with it being an inode cluster, we execute the callbacks on the buffer directly, rather than just removing it from the AIL. linux/fs/xfs/xfs_vnodeops.c - 1.613 - extend the inactive path logic to deal with freeing the space which could be removed with an inode cluster. linux/fs/xfs/xfs_ialloc_btree.h - 1.25 - turn on prototype for xfs_inobt_delete linux/fs/xfs/xfs_ialloc_btree.c - 1.76 - Turn on the inode btree free path and fix up several bugs in the implementation. linux/fs/xfs/xfs_inode_item.c - 1.116 - add logic for dealing with stale inode log items linux/fs/xfs/xfs_inode_item.h - 1.45 - prototype for xfs_istale_done linux/fs/xfs/xfs_log_recover.c - 1.279 - During log recovery, take into acount the fact that an inode write in the log may be cancelled by a subsequent stale of the inode buffer. We need to prevent the inode log record from being replayed to disk in this case. linux/fs/xfs/xfs_vfsops.c - 1.434 - mount option parsing for freeing inode clusters linux/fs/xfs/xfs_iget.c - 1.193 - clear inode stale flag when reusing an inode linux/fs/xfs/xfs_clnt.h - 1.41 - add mount option to control freeing of inode clusters linux/fs/xfs/xfs_mount.h - 1.183 - define for mount option control of inode cluster freeing linux/fs/xfs/xfs_inode.c - 1.389 - Add xfs_ifree_cluster to free up an inode cluster. This has to synchronize with sync activity and make sure we have cleaned out the sync path on all the inodes in the cluster before we free the space. linux/fs/xfs/xfs_inode.h - 1.186 - Add XFS_ISTALE and change some prototypes for inode cluster freeing linux/fs/xfs/xfs_trans.c - 1.153 - remove assert that the inode count always increments linux/fs/xfs/xfs_trans.h - 1.123 - Change log reservation for deallocating an inode linux/fs/xfs/xfs_trans_buf.c - 1.115 - Add special handler for staling an inode buffer Modid: 2.4.x-xfs:slinx:159536b linux/Documentation/filesystems/xfs.txt - 1.15 - Describe new ikeep mount option. From owner-linux-xfs@oss.sgi.com Mon Oct 6 13:44:40 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 06 Oct 2003 13:45:12 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h96Kid25020219 for ; Mon, 6 Oct 2003 13:44:40 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h96KiYq0017657 for ; Mon, 6 Oct 2003 13:44:34 -0700 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h96KiWcc11950952 for ; Mon, 6 Oct 2003 15:44:33 -0500 (CDT) Received: from sgi.com (penguin.americas.sgi.com [128.162.240.135]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h96KiXRn306943013 for ; Mon, 6 Oct 2003 15:44:33 -0500 (CDT) Received: from penguin.americas.sgi.com (localhost.localdomain [127.0.0.1]) by sgi.com (8.12.8/8.12.8) with ESMTP id h96KbwGf014088 for ; Mon, 6 Oct 2003 15:37:59 -0500 Received: (from lord@localhost) by penguin.americas.sgi.com (8.12.8/8.12.8/Submit) id h96KbwjD014086 for linux-xfs@oss.sgi.com; Mon, 6 Oct 2003 15:37:58 -0500 Date: Mon, 6 Oct 2003 15:37:58 -0500 From: Steve Lord Message-Id: <200310062037.h96KbwjD014086@penguin.americas.sgi.com> Subject: TAKE - merge up to 2.6.0-test6 To: linux-xfs@oss.sgi.com X-archive-position: 650 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@penguin.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 88649 Lines: 2299 Date: Mon Oct 6 13:20:41 PDT 2003 Workarea: penguin.americas.sgi.com:/src/lord/xfs-linux.2.5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:159553a linux/kernel/power/pmdisk.c - 1.1 linux/include/asm-x86_64/dwarf2.h - 1.1 linux/drivers/serial/serial_cs.c - 1.1 linux/sound/oss/dmasound/trans_16.c - 1.1 linux/drivers/serial/serial_core.c - 1.1 linux/arch/i386/kernel/timers/common.c - 1.1 linux/kernel/power/disk.c - 1.1 linux/sound/oss/dmasound/tas_ioctl.h - 1.1 linux/Documentation/as-iosched.txt - 1.1 linux/sound/oss/dmasound/tas_eq_prefs.h - 1.1 linux/kernel/power/Kconfig - 1.1 linux/sound/oss/dmasound/tas_common.h - 1.1 linux/arch/i386/kernel/cpu/cpufreq/speedstep-smi.c - 1.1 linux/fs/afs/cache.h - 1.1 linux/Documentation/kbuild/modules.txt - 1.1 linux/drivers/i2c/algos/Kconfig - 1.1 linux/drivers/i2c/algos/Makefile - 1.1 linux/sound/oss/dmasound/tas_common.c - 1.1 linux/sound/oss/dmasound/tas3004_tables.c - 1.1 linux/drivers/i2c/algos/i2c-algo-bit.c - 1.1 linux/sound/oss/dmasound/tas3004.h - 1.1 linux/sound/oss/dmasound/tas3004.c - 1.1 linux/sound/oss/dmasound/tas3001c_tables.c - 1.1 linux/drivers/i2c/algos/i2c-algo-ite.c - 1.1 linux/sound/oss/dmasound/tas3001c.h - 1.1 linux/sound/oss/dmasound/tas3001c.c - 1.1 linux/sound/oss/dmasound/dac3550a.c - 1.1 linux/drivers/i2c/algos/i2c-algo-ite.h - 1.1 linux/include/asm-ppc/reg.h - 1.1 linux/include/asm-ppc/reg_booke.h - 1.1 linux/security/commoncap.c - 1.1 linux/scripts/mkuboot.sh - 1.1 linux/scripts/bin2c.c - 1.1 linux/drivers/i2c/algos/i2c-algo-pcf.c - 1.1 linux/drivers/i2c/algos/i2c-algo-pcf.h - 1.1 linux/arch/ia64/oprofile/init.c - 1.1 linux/arch/ia64/oprofile/Makefile - 1.1 linux/drivers/i2c/busses/scx200_i2c.c - 1.1 linux/drivers/i2c/busses/i2c-prosavage.c - 1.1 linux/arch/arm/configs/a5k_defconfig - 1.1 linux/arch/arm/configs/adi_evb_defconfig - 1.1 linux/arch/arm/configs/adsbitsy_defconfig - 1.1 linux/arch/arm/configs/anakin_defconfig - 1.1 linux/arch/arm/configs/assabet_defconfig - 1.1 linux/arch/arm/configs/badge4_defconfig - 1.1 linux/arch/arm/configs/brutus_defconfig - 1.1 linux/arch/arm/configs/cerfcube_defconfig - 1.1 linux/arch/arm/configs/cerfpda_defconfig - 1.1 linux/arch/arm/configs/cerfpod_defconfig - 1.1 linux/arch/arm/configs/clps7500_defconfig - 1.1 linux/arch/arm/configs/ebsa110_defconfig - 1.1 linux/arch/arm/configs/edb7211_defconfig - 1.1 linux/arch/arm/configs/empeg_defconfig - 1.1 linux/arch/arm/configs/epxa10db_defconfig - 1.1 linux/arch/arm/configs/flexanet_defconfig - 1.1 linux/arch/arm/configs/footbridge_defconfig - 1.1 linux/arch/arm/configs/fortunet_defconfig - 1.1 linux/arch/arm/configs/freebird_defconfig - 1.1 linux/arch/arm/configs/freebird_new_defconfig - 1.1 linux/arch/arm/configs/graphicsclient_defconfig - 1.1 linux/arch/arm/configs/graphicsmaster_defconfig - 1.1 linux/arch/arm/configs/h3600_defconfig - 1.1 linux/arch/arm/configs/hackkit_defconfig - 1.1 linux/arch/arm/configs/huw_webpanel_defconfig - 1.1 linux/arch/arm/configs/integrator_defconfig - 1.1 linux/arch/arm/configs/iq80310_defconfig - 1.1 linux/arch/arm/configs/iq80321_defconfig - 1.1 linux/arch/arm/configs/jornada720_defconfig - 1.1 linux/arch/arm/configs/lart_defconfig - 1.1 linux/arch/arm/configs/lubbock_defconfig - 1.1 linux/arch/arm/configs/lusl7200_defconfig - 1.1 linux/arch/arm/configs/neponset_defconfig - 1.1 linux/arch/arm/configs/omnimeter_defconfig - 1.1 linux/arch/arm/configs/pangolin_defconfig - 1.1 linux/arch/arm/configs/pfs168_mqtft_defconfig - 1.1 linux/arch/arm/configs/pfs168_mqvga_defconfig - 1.1 linux/arch/arm/configs/pfs168_sastn_defconfig - 1.1 linux/arch/arm/configs/pfs168_satft_defconfig - 1.1 linux/arch/arm/configs/pleb_defconfig - 1.1 linux/arch/arm/configs/rpc_defconfig - 1.1 linux/arch/arm/configs/shannon_defconfig - 1.1 linux/arch/arm/configs/shark_defconfig - 1.1 linux/arch/arm/configs/sherman_defconfig - 1.1 linux/arch/arm/configs/stork_defconfig - 1.1 linux/arch/arm/configs/system3_defconfig - 1.1 linux/arch/arm/configs/trizeps_defconfig - 1.1 linux/arch/ia64/oprofile/Kconfig - 1.1 linux/arch/i386/power/swsusp.S - 1.1 linux/drivers/i2c/busses/i2c-sis5595.c - 1.1 linux/drivers/i2c/busses/scx200_acb.c - 1.1 linux/net/atm/ioctl.c - 1.1 linux/arch/ia64/mm/contig.c - 1.1 linux/arch/parisc/kernel/vmlinux.lds.S - 1.1 linux/arch/arm/mm/abort-ev5tj.S - 1.1 linux/drivers/i2c/busses/i2c-voodoo3.c - 1.1 linux/arch/arm/mm/abort-ev5t.S - 1.1 linux/arch/parisc/nm - 1.1 linux/arch/ppc/boot/simple/clear.S - 1.1 linux/drivers/i2c/busses/i2c-philips-par.c - 1.1 linux/arch/ia64/kernel/perfmon_hpsim.h - 1.1 linux/arch/arm/mm/Kconfig - 1.1 linux/drivers/i2c/busses/i2c-via.c - 1.1 linux/include/linux/compiler-intel.h - 1.1 linux/drivers/i2c/busses/i2c-velleman.c - 1.1 linux/drivers/i2c/busses/i2c-sis630.c - 1.1 linux/arch/ppc64/mm/hugetlbpage.c - 1.1 linux/include/linux/compiler-gcc3.h - 1.1 linux/arch/ppc64/boot/install.sh - 1.1 linux/arch/arm/mm/proc-arm1020e.S - 1.1 linux/arch/arm/mm/proc-arm1022.S - 1.1 linux/net/llc/llc_station.c - 1.1 linux/include/asm-ppc64/local.h - 1.1 linux/net/llc/llc_output.h - 1.1 linux/net/llc/llc_output.c - 1.1 linux/net/llc/llc_input.c - 1.1 linux/drivers/net/wan/wanxl.c - 1.1 linux/net/llc/llc_core.c - 1.1 linux/drivers/net/wan/wanxl.h - 1.1 linux/drivers/net/wan/wanxlfw.S - 1.1 linux/net/llc/Kconfig - 1.1 linux/drivers/net/wan/wanxlfw.inc - 1.1 linux/arch/arm/mm/proc-arm1026.S - 1.1 linux/include/linux/compiler-gcc2.h - 1.1 linux/arch/arm/mach-integrator/lm.c - 1.1 linux/drivers/i2c/busses/i2c-savage4.c - 1.1 linux/drivers/i2c/busses/i2c-rpx.c - 1.1 linux/drivers/net/wireless/arlan-main.c - 1.1 linux/arch/i386/power/Makefile - 1.1 linux/drivers/s390/block/Kconfig - 1.1 linux/drivers/s390/char/sclp_vt220.c - 1.1 linux/drivers/i2c/busses/i2c-elektor.c - 1.1 linux/drivers/i2c/busses/i2c-elv.c - 1.1 linux/drivers/i2c/busses/i2c-frodo.c - 1.1 linux/arch/i386/power/cpu.c - 1.1 linux/include/linux/compiler-gcc.h - 1.1 linux/include/asm-parisc/sections.h - 1.1 linux/include/asm-parisc/local.h - 1.1 linux/include/asm-s390/local.h - 1.1 linux/include/linux/compiler-gcc+.h - 1.1 linux/drivers/i2c/busses/i2c-i810.c - 1.1 linux/drivers/i2c/busses/i2c-ibm_iic.c - 1.1 linux/include/asm-ia64/meminit.h - 1.1 linux/include/asm-ia64/intel_intrin.h - 1.1 linux/include/asm-i386/ist.h - 1.1 linux/include/asm-s390/sections.h - 1.1 linux/include/asm-arm/arch-integrator/lm.h - 1.1 linux/arch/ppc/kernel/idle_power4.S - 1.1 linux/drivers/i2c/busses/i2c-ibm_iic.h - 1.1 linux/drivers/i2c/busses/i2c-iop3xx.c - 1.1 linux/drivers/i2c/busses/i2c-iop3xx.h - 1.1 linux/arch/i386/power/pmdisk.S - 1.1 linux/drivers/i2c/chips/eeprom.c - 1.1 linux/drivers/i2c/busses/i2c-ite.c - 1.1 linux/drivers/i2c/busses/i2c-keywest.c - 1.1 linux/drivers/i2c/busses/i2c-keywest.h - 1.1 linux/scripts/Makefile - 1.20 linux/net/wanrouter/wanproc.c - 1.27 linux/net/wanrouter/wanmain.c - 1.22 linux/net/sunrpc/svcsock.c - 1.38 linux/net/sched/sch_generic.c - 1.16 linux/net/sched/sch_api.c - 1.18 linux/net/sched/police.c - 1.5 linux/net/sched/estimator.c - 1.4 linux/net/rose/rose_route.c - 1.14 linux/net/rose/af_rose.c - 1.37 linux/net/packet/af_packet.c - 1.48 linux/net/netsyms.c - 1.78 linux/net/netrom/nr_timer.c - 1.11 linux/net/netrom/nr_route.c - 1.11 linux/net/netrom/nr_loopback.c - 1.10 linux/net/netrom/af_netrom.c - 1.34 linux/net/netlink/af_netlink.c - 1.35 linux/net/irda/irttp.c - 1.27 linux/net/irda/irproc.c - 1.15 linux/net/irda/irlmp.c - 1.29 linux/net/irda/irlap_frame.c - 1.21 linux/net/irda/irlap.c - 1.27 linux/net/irda/irlan/irlan_common.c - 1.26 linux/net/irda/iriap.c - 1.25 linux/net/irda/discovery.c - 1.12 linux/net/ipx/af_ipx.c - 1.42 linux/net/ipv6/udp.c - 1.48 linux/net/ipv6/tcp_ipv6.c - 1.60 linux/net/ipv6/raw.c - 1.42 linux/net/ipv6/proc.c - 1.19 linux/net/ipv6/ndisc.c - 1.42 linux/net/ipv6/mcast.c - 1.33 linux/net/ipv6/ipv6_sockglue.c - 1.26 linux/net/ipv6/ip6_flowlabel.c - 1.10 linux/net/ipv6/addrconf.c - 1.44 linux/net/ipv4/udp.c - 1.50 linux/net/ipv4/tcp_ipv4.c - 1.67 linux/net/ipv4/route.c - 1.54 linux/net/ipv4/raw.c - 1.40 linux/net/ipv4/proc.c - 1.20 linux/net/ipv4/ipmr.c - 1.34 linux/net/ipv4/ipconfig.c - 1.41 linux/net/ipv4/ip_output.c - 1.53 linux/net/ipv4/ip_input.c - 1.26 linux/net/ipv4/ip_gre.c - 1.36 linux/net/ipv4/igmp.c - 1.33 linux/net/ipv4/icmp.c - 1.44 linux/net/ipv4/fib_hash.c - 1.14 linux/net/ipv4/arp.c - 1.33 linux/net/core/dev.c - 1.84 linux/net/ax25/ax25_uid.c - 1.9 linux/net/ax25/ax25_route.c - 1.13 linux/net/ax25/af_ax25.c - 1.38 linux/net/appletalk/ddp.c - 1.32 linux/net/appletalk/aarp.c - 1.19 linux/net/802/tr.c - 1.16 linux/net/802/psnap.c - 1.13 linux/net/802/p8022.c - 1.12 linux/mm/slab.c - 1.66 linux/mm/page_alloc.c - 1.115 linux/mm/mprotect.c - 1.40 linux/mm/mmap.c - 1.83 linux/mm/mlock.c - 1.18 linux/mm/memory.c - 1.112 linux/mm/filemap.c - 1.163 linux/lib/inflate.c - 1.7 linux/lib/Makefile - 1.25 linux/kernel/sysctl.c - 1.74 linux/kernel/sys.c - 1.59 linux/kernel/softirq.c - 1.40 linux/kernel/signal.c - 1.61 linux/kernel/sched.c - 1.111 linux/kernel/resource.c - 1.24 linux/kernel/ksyms.c - 1.200 linux/kernel/fork.c - 1.100 linux/kernel/exit.c - 1.74 linux/kernel/acct.c - 1.29 linux/kernel/Makefile - 1.48 linux/ipc/sem.c - 1.32 linux/init/main.c - 1.113 linux/include/scsi/scsi.h - 1.13 linux/include/net/rose.h - 1.9 linux/include/net/llc.h - 1.5 linux/include/net/if_inet6.h - 1.13 linux/include/linux/types.h - 1.14 linux/include/linux/tty.h - 1.26 linux/include/linux/swap.h - 1.77 linux/include/linux/smb_mount.h - 1.6 linux/include/linux/skbuff.h - 1.38 linux/include/linux/sched.h - 1.112 linux/include/linux/rtnetlink.h - 1.22 linux/include/linux/random.h - 1.7 linux/include/linux/proc_fs.h - 1.44 linux/include/linux/nls.h - 1.8 linux/include/linux/nfsd/nfsfh.h - 1.20 linux/include/linux/nfsd/nfsd.h - 1.24 linux/include/linux/nfsd/export.h - 1.20 linux/include/linux/netdevice.h - 1.55 linux/include/linux/mm.h - 1.124 linux/include/linux/miscdevice.h - 1.16 linux/include/linux/major.h - 1.33 linux/include/linux/kernel.h - 1.49 linux/include/linux/kdev_t.h - 1.14 linux/include/linux/ipv6.h - 1.12 linux/include/linux/interrupt.h - 1.31 linux/include/linux/init.h - 1.28 linux/include/linux/if_frad.h - 1.8 linux/include/linux/i2c.h - 1.28 linux/include/linux/hdlcdrv.h - 1.11 linux/include/linux/ftape.h - 1.6 linux/include/linux/fs.h - 1.224 linux/include/linux/elf.h - 1.29 linux/include/linux/console.h - 1.13 linux/include/linux/coda_psdev.h - 1.12 linux/include/linux/coda_linux.h - 1.19 linux/include/linux/coda_fs_i.h - 1.10 linux/include/linux/coda_cache.h - 1.6 linux/include/linux/coda.h - 1.11 linux/include/linux/blkdev.h - 1.92 linux/include/asm-sparc64/vga.h - 1.4 linux/include/asm-sparc64/stat.h - 1.8 linux/include/asm-sparc64/signal.h - 1.11 linux/include/asm-sparc64/processor.h - 1.33 linux/include/asm-sparc64/posix_types.h - 1.11 linux/include/asm-sparc64/mman.h - 1.7 linux/include/asm-sparc64/delay.h - 1.12 linux/include/asm-sparc64/bugs.h - 1.3 linux/include/asm-sparc/signal.h - 1.9 linux/include/asm-sparc/processor.h - 1.24 linux/include/asm-sparc/posix_types.h - 1.6 linux/include/asm-sparc/mman.h - 1.7 linux/include/asm-sparc/atomic.h - 1.10 linux/include/asm-ppc/unaligned.h - 1.6 linux/include/asm-ppc/ucontext.h - 1.7 linux/include/asm-ppc/uaccess.h - 1.17 linux/include/asm-ppc/termios.h - 1.12 linux/include/asm-ppc/system.h - 1.31 linux/include/asm-ppc/stat.h - 1.10 linux/include/asm-ppc/spinlock.h - 1.20 linux/include/asm-ppc/signal.h - 1.10 linux/include/asm-ppc/serial.h - 1.16 linux/include/asm-ppc/prom.h - 1.18 linux/include/asm-ppc/processor.h - 1.46 linux/include/asm-ppc/posix_types.h - 1.12 linux/include/asm-ppc/pgtable.h - 1.46 linux/include/asm-ppc/pci-bridge.h - 1.15 linux/include/asm-ppc/page.h - 1.24 linux/include/asm-ppc/ohare.h - 1.8 linux/include/asm-ppc/mmu.h - 1.13 linux/include/asm-ppc/mman.h - 1.10 linux/include/asm-ppc/md.h - 1.6 linux/include/asm-ppc/irq.h - 1.21 linux/include/asm-ppc/ipc.h - 1.7 linux/include/asm-ppc/ioctl.h - 1.5 linux/include/asm-ppc/ide.h - 1.25 linux/include/asm-ppc/hardirq.h - 1.28 linux/include/asm-ppc/checksum.h - 1.7 linux/include/asm-ppc/cache.h - 1.15 linux/include/asm-ppc/bootx.h - 1.7 linux/include/asm-ppc/bitops.h - 1.20 linux/include/asm-ppc/atomic.h - 1.14 linux/include/asm-ppc/a.out.h - 1.5 linux/include/asm-mips/stat.h - 1.9 linux/include/asm-mips/softirq.h - 1.9 linux/include/asm-mips/signal.h - 1.10 linux/include/asm-mips/processor.h - 1.25 linux/include/asm-mips/posix_types.h - 1.9 linux/include/asm-mips/mman.h - 1.6 linux/include/asm-m68k/signal.h - 1.7 linux/include/asm-m68k/processor.h - 1.19 linux/include/asm-m68k/posix_types.h - 1.7 linux/include/asm-m68k/mman.h - 1.6 linux/include/asm-i386/uaccess.h - 1.27 linux/include/asm-i386/signal.h - 1.12 linux/include/asm-i386/processor.h - 1.58 linux/include/asm-i386/posix_types.h - 1.7 linux/include/asm-i386/mman.h - 1.6 linux/include/asm-arm/system.h - 1.30 linux/include/asm-arm/string.h - 1.8 linux/include/asm-arm/signal.h - 1.9 linux/include/asm-arm/processor.h - 1.30 linux/include/asm-arm/proc-fns.h - 1.16 linux/include/asm-arm/posix_types.h - 1.8 linux/include/asm-arm/pgtable.h - 1.32 linux/include/asm-arm/page.h - 1.22 linux/include/asm-arm/mman.h - 1.6 linux/include/asm-arm/bugs.h - 1.7 linux/include/asm-alpha/smp.h - 1.24 linux/include/asm-alpha/signal.h - 1.8 linux/include/asm-alpha/processor.h - 1.20 linux/include/asm-alpha/posix_types.h - 1.9 linux/include/asm-alpha/mman.h - 1.7 linux/fs/ufs/namei.c - 1.23 linux/fs/super.c - 1.104 linux/fs/stat.c - 1.37 linux/fs/smbfs/sock.c - 1.20 linux/fs/smbfs/proc.c - 1.31 linux/fs/smbfs/inode.c - 1.50 linux/fs/smbfs/dir.c - 1.30 linux/fs/smbfs/Makefile - 1.12 linux/fs/proc/kmsg.c - 1.10 linux/fs/proc/inode.c - 1.34 linux/fs/proc/generic.c - 1.39 linux/fs/proc/base.c - 1.57 linux/fs/proc/array.c - 1.61 linux/fs/proc/Makefile - 1.16 linux/fs/open.c - 1.56 linux/fs/nls/nls_koi8-r.c - 1.9 linux/fs/nls/nls_iso8859-9.c - 1.10 linux/fs/nls/nls_iso8859-8.c - 1.10 linux/fs/nls/nls_iso8859-7.c - 1.10 linux/fs/nls/nls_iso8859-6.c - 1.10 linux/fs/nls/nls_iso8859-5.c - 1.10 linux/fs/nls/nls_iso8859-4.c - 1.10 linux/fs/nls/nls_iso8859-3.c - 1.10 linux/fs/nls/nls_iso8859-2.c - 1.10 linux/fs/nls/nls_iso8859-15.c - 1.10 linux/fs/nls/nls_iso8859-1.c - 1.10 linux/fs/nls/nls_cp874.c - 1.10 linux/fs/nls/nls_cp869.c - 1.10 linux/fs/nls/nls_cp866.c - 1.10 linux/fs/nls/nls_cp865.c - 1.10 linux/fs/nls/nls_cp864.c - 1.10 linux/fs/nls/nls_cp863.c - 1.10 linux/fs/nls/nls_cp862.c - 1.10 linux/fs/nls/nls_cp861.c - 1.10 linux/fs/nls/nls_cp860.c - 1.10 linux/fs/nls/nls_cp857.c - 1.10 linux/fs/nls/nls_cp855.c - 1.10 linux/fs/nls/nls_cp852.c - 1.10 linux/fs/nls/nls_cp850.c - 1.10 linux/fs/nls/nls_cp775.c - 1.10 linux/fs/nls/nls_cp737.c - 1.10 linux/fs/nls/nls_cp437.c - 1.10 linux/fs/nls/nls_base.c - 1.17 linux/fs/nls/Makefile - 1.14 linux/fs/nfsd/nfsxdr.c - 1.25 linux/fs/nfsd/nfsproc.c - 1.35 linux/fs/nfsd/nfsfh.c - 1.52 linux/fs/nfsd/nfs3xdr.c - 1.42 linux/fs/nfsd/export.c - 1.57 linux/fs/nfs/proc.c - 1.23 linux/fs/nfs/nfs3xdr.c - 1.23 linux/fs/nfs/nfs2xdr.c - 1.27 linux/fs/nfs/dir.c - 1.56 linux/fs/ncpfs/inode.c - 1.47 linux/fs/ncpfs/dir.c - 1.37 linux/fs/namei.c - 1.77 linux/fs/locks.c - 1.42 linux/fs/fat/file.c - 1.31 linux/fs/ext2/symlink.c - 1.13 linux/fs/ext2/namei.c - 1.32 linux/fs/ext2/inode.c - 1.70 linux/fs/exec.c - 1.89 linux/fs/dcache.c - 1.57 linux/fs/coda/upcall.c - 1.23 linux/fs/coda/psdev.c - 1.29 linux/fs/coda/inode.c - 1.34 linux/fs/coda/file.c - 1.23 linux/fs/coda/dir.c - 1.32 linux/fs/coda/coda_linux.c - 1.14 linux/fs/coda/cnode.c - 1.17 linux/fs/coda/cache.c - 1.14 linux/fs/binfmt_elf.c - 1.63 linux/fs/binfmt_aout.c - 1.32 linux/fs/autofs/root.c - 1.23 linux/fs/autofs/inode.c - 1.18 linux/fs/autofs/autofs_i.h - 1.15 linux/drivers/usb/Makefile - 1.63 linux/drivers/scsi/sym53c8xx_defs.h - 1.17 linux/drivers/scsi/sym53c8xx.h - 1.16 linux/drivers/scsi/sym53c8xx.c - 1.51 linux/drivers/scsi/sym53c416.c - 1.22 linux/drivers/scsi/sr.c - 1.74 linux/drivers/scsi/sg.c - 1.59 linux/drivers/scsi/sd.c - 1.94 linux/drivers/scsi/scsi_proc.c - 1.24 linux/drivers/scsi/scsi_error.c - 1.49 linux/drivers/scsi/scsi_debug.c - 1.39 linux/drivers/scsi/scsi.h - 1.56 linux/drivers/scsi/scsi.c - 1.83 linux/drivers/scsi/ncr53c8xx.h - 1.14 linux/drivers/scsi/ncr53c8xx.c - 1.41 linux/drivers/scsi/megaraid.h - 1.23 linux/drivers/scsi/in2000.h - 1.16 linux/drivers/scsi/in2000.c - 1.21 linux/drivers/scsi/imm.h - 1.17 linux/drivers/scsi/ide-scsi.c - 1.59 linux/drivers/scsi/i60uscsi.c - 1.10 linux/drivers/scsi/hosts.c - 1.52 linux/drivers/scsi/gdth.c - 1.36 linux/drivers/scsi/g_NCR5380.c - 1.28 linux/drivers/scsi/fcal.c - 1.18 linux/drivers/scsi/aha152x.c - 1.46 linux/drivers/scsi/a3000.c - 1.17 linux/drivers/scsi/NCR5380.c - 1.24 linux/drivers/scsi/Makefile - 1.56 linux/drivers/scsi/BusLogic.c - 1.28 linux/drivers/sbus/char/bpp.c - 1.28 linux/drivers/net/wd.c - 1.21 linux/drivers/net/tlan.c - 1.39 linux/drivers/net/sunhme.c - 1.51 linux/drivers/net/smc9194.c - 1.26 linux/drivers/net/smc-ultra32.c - 1.18 linux/drivers/net/smc-ultra.c - 1.28 linux/drivers/net/smc-mca.c - 1.20 linux/drivers/net/slip.c - 1.30 linux/drivers/net/rrunner.h - 1.7 linux/drivers/net/rrunner.c - 1.31 linux/drivers/net/rcpci45.c - 1.33 linux/drivers/net/ni65.c - 1.22 linux/drivers/net/ni52.c - 1.21 linux/drivers/net/ni5010.c - 1.20 linux/drivers/net/net_init.c - 1.24 linux/drivers/net/ne3210.c - 1.18 linux/drivers/net/ne2k-pci.c - 1.32 linux/drivers/net/ne2.c - 1.19 linux/drivers/net/ne.c - 1.26 linux/drivers/net/mace.c - 1.23 linux/drivers/net/lne390.c - 1.19 linux/drivers/net/lance.c - 1.30 linux/drivers/net/irda/w83977af_ir.c - 1.32 linux/drivers/net/irda/Makefile - 1.28 linux/drivers/net/hp100.c - 1.32 linux/drivers/net/hp.c - 1.17 linux/drivers/net/hp-plus.c - 1.20 linux/drivers/net/hamradio/scc.c - 1.34 linux/drivers/net/hamradio/hdlcdrv.c - 1.17 linux/drivers/net/hamradio/bpqether.c - 1.25 linux/drivers/net/hamradio/baycom_ser_hdx.c - 1.20 linux/drivers/net/hamradio/baycom_ser_fdx.c - 1.20 linux/drivers/net/hamradio/baycom_par.c - 1.18 linux/drivers/net/hamradio/baycom_epp.c - 1.28 linux/drivers/net/ewrk3.c - 1.30 linux/drivers/net/es3210.c - 1.19 linux/drivers/net/eepro.c - 1.33 linux/drivers/net/e2100.c - 1.20 linux/drivers/net/dgrs.c - 1.30 linux/drivers/net/depca.c - 1.28 linux/drivers/net/cs89x0.c - 1.31 linux/drivers/net/acenic.c - 1.52 linux/drivers/net/ac3200.c - 1.23 linux/drivers/net/Space.c - 1.48 linux/drivers/net/Makefile - 1.77 linux/drivers/net/8390.c - 1.31 linux/drivers/net/3c515.c - 1.32 linux/drivers/net/3c509.c - 1.50 linux/drivers/net/3c505.c - 1.38 linux/drivers/net/3c503.c - 1.27 linux/drivers/net/3c501.c - 1.29 linux/drivers/macintosh/mediabay.c - 1.18 linux/drivers/macintosh/macserial.c - 1.32 linux/drivers/macintosh/adb.c - 1.29 linux/drivers/isdn/hisax/config.c - 1.40 linux/drivers/char/tty_io.c - 1.74 linux/drivers/char/sysrq.c - 1.37 linux/drivers/char/specialix.c - 1.23 linux/drivers/char/serial167.c - 1.23 linux/drivers/char/rocket.c - 1.27 linux/drivers/char/random.c - 1.44 linux/drivers/char/pty.c - 1.22 linux/drivers/char/pcxx.c - 1.24 linux/drivers/char/n_tty.c - 1.24 linux/drivers/char/misc.c - 1.39 linux/drivers/char/mem.c - 1.56 linux/drivers/char/lp.c - 1.41 linux/drivers/char/keyboard.c - 1.39 linux/drivers/char/istallion.c - 1.33 linux/drivers/char/ftape/lowlevel/ftape-init.c - 1.8 linux/drivers/char/epca.c - 1.33 linux/drivers/char/cyclades.c - 1.35 linux/drivers/char/Makefile - 1.86 linux/drivers/cdrom/sonycd535.c - 1.41 linux/drivers/cdrom/gscd.c - 1.36 linux/drivers/cdrom/cdrom.c - 1.57 linux/drivers/block/z2ram.c - 1.34 linux/drivers/block/xd.c - 1.59 linux/drivers/block/ps2esdi.c - 1.61 linux/drivers/block/loop.c - 1.90 linux/drivers/block/ll_rw_blk.c - 1.142 linux/drivers/block/floppy.c - 1.73 linux/drivers/block/acsi.c - 1.52 linux/arch/sparc64/solaris/misc.c - 1.32 linux/arch/sparc64/solaris/fs.c - 1.24 linux/arch/sparc64/mm/init.c - 1.60 linux/arch/sparc64/kernel/time.c - 1.39 linux/arch/sparc64/kernel/sys_sparc32.c - 1.80 linux/arch/sparc64/kernel/setup.c - 1.43 linux/arch/sparc64/defconfig - 1.101 linux/arch/sparc/mm/srmmu.c - 1.49 linux/arch/sparc/lib/memset.S - 1.5 linux/arch/sparc/lib/copy_user.S - 1.5 linux/arch/sparc/lib/checksum.S - 1.4 linux/arch/sparc/kernel/sun4d_smp.c - 1.26 linux/arch/sparc/kernel/setup.c - 1.30 linux/arch/sparc/boot/btfixupprep.c - 1.5 linux/arch/ppc/mm/init.c - 1.53 linux/arch/ppc/mm/fault.c - 1.26 linux/arch/ppc/lib/locks.c - 1.14 linux/arch/ppc/kernel/traps.c - 1.33 linux/arch/ppc/kernel/time.c - 1.29 linux/arch/ppc/kernel/syscalls.c - 1.19 linux/arch/ppc/kernel/softemu8xx.c - 1.9 linux/arch/ppc/kernel/smp.c - 1.53 linux/arch/ppc/kernel/signal.c - 1.25 linux/arch/ppc/kernel/setup.c - 1.63 linux/arch/ppc/kernel/ptrace.c - 1.20 linux/arch/ppc/kernel/process.c - 1.53 linux/arch/ppc/kernel/ppc_htab.c - 1.22 linux/arch/ppc/kernel/pci.c - 1.37 linux/arch/ppc/kernel/misc.S - 1.61 linux/arch/ppc/kernel/irq.c - 1.49 linux/arch/ppc/kernel/idle.c - 1.28 linux/arch/ppc/kernel/head.S - 1.46 linux/arch/ppc/kernel/align.c - 1.13 linux/arch/ppc/kernel/Makefile - 1.44 linux/arch/ppc/amiga/ints.c - 1.10 linux/arch/ppc/amiga/config.c - 1.22 linux/arch/ppc/Makefile - 1.43 linux/arch/ppc/8xx_io/uart.c - 1.30 linux/arch/ppc/8xx_io/enet.c - 1.20 linux/arch/mips/sni/setup.c - 1.11 linux/arch/mips/kernel/sysirix.c - 1.25 linux/arch/mips/kernel/setup.c - 1.20 linux/arch/mips/kernel/mips_ksyms.c - 1.17 linux/arch/mips/kernel/irixsig.c - 1.16 linux/arch/mips/kernel/irixelf.c - 1.19 linux/arch/mips/jazz/setup.c - 1.9 linux/arch/mips/Makefile - 1.20 linux/arch/m68k/kernel/signal.c - 1.23 linux/arch/i386/kernel/traps.c - 1.84 linux/arch/i386/kernel/setup.c - 1.99 linux/arch/i386/kernel/process.c - 1.76 linux/arch/i386/kernel/io_apic.c - 1.69 linux/arch/i386/kernel/i386_ksyms.c - 1.73 linux/arch/i386/kernel/apm.c - 1.66 linux/arch/i386/kernel/Makefile - 1.55 linux/arch/i386/boot/setup.S - 1.35 linux/arch/i386/boot/compressed/misc.c - 1.20 linux/arch/i386/boot/Makefile - 1.24 linux/arch/i386/Makefile - 1.57 linux/arch/arm/mm/proc-sa110.S - 1.33 linux/arch/arm/mm/mm-armv.c - 1.37 linux/arch/arm/mm/fault-armv.c - 1.32 linux/arch/arm/mm/Makefile - 1.27 linux/arch/arm/kernel/time.c - 1.28 linux/arch/arm/kernel/setup.c - 1.45 linux/arch/arm/kernel/ptrace.c - 1.28 linux/arch/arm/kernel/process.c - 1.39 linux/arch/arm/kernel/fiq.c - 1.16 linux/arch/arm/kernel/entry-common.S - 1.27 linux/arch/arm/kernel/entry-armv.S - 1.46 linux/arch/arm/kernel/ecard.c - 1.33 linux/arch/arm/boot/compressed/misc.c - 1.8 linux/arch/arm/Makefile - 1.50 linux/README - 1.17 linux/Makefile - 1.259 linux/MAINTAINERS - 1.150 linux/Documentation/smp.tex - 1.3 linux/Documentation/modules.txt - 1.9 linux/Documentation/kbuild/00-INDEX - 1.7 linux/Documentation/filesystems/ntfs.txt - 1.23 linux/Documentation/Changes - 1.70 linux/Documentation/00-INDEX - 1.19 linux/CREDITS - 1.108 linux/net/decnet/dn_neigh.c - 1.15 linux/net/decnet/dn_dev.c - 1.23 linux/net/decnet/af_decnet.c - 1.46 linux/fs/hpfs/namei.c - 1.23 linux/fs/hpfs/inode.c - 1.26 linux/fs/efs/inode.c - 1.16 linux/drivers/net/sk_mca.h - 1.6 linux/drivers/net/irda/toshoboe.c - 1.36 linux/drivers/net/irda/smc-ircc.c - 1.31 linux/drivers/isdn/hisax/isar.c - 1.24 linux/arch/sparc/math-emu/sfp-util.h - 1.2 linux/arch/ppc/xmon/start.c - 1.25 linux/arch/ppc/xmon/ppc-opc.c - 1.6 linux/arch/arm/nwfpe/softfloat.h - 1.4 linux/arch/arm/nwfpe/fpopcode.h - 1.6 linux/arch/arm/nwfpe/fpopcode.c - 1.7 linux/arch/arm/nwfpe/fpa11_cprt.c - 1.9 linux/arch/arm/nwfpe/fpa11_cpdt.c - 1.9 linux/arch/arm/nwfpe/fpa11_cpdo.c - 1.8 linux/arch/arm/nwfpe/fpa11.h - 1.8 linux/arch/arm/nwfpe/fpa11.c - 1.13 linux/Documentation/kernel-parameters.txt - 1.31 linux/drivers/tc/zs.c - 1.17 linux/include/asm-i386/setup.h - 1.6 linux/arch/arm/def-configs/rpc - 1.13 linux/arch/arm/def-configs/footbridge - 1.17 linux/arch/arm/def-configs/ebsa110 - 1.13 linux/arch/arm/def-configs/a5k - 1.10 linux/drivers/net/ppp_generic.c - 1.44 linux/drivers/net/hamradio/yam.c - 1.28 linux/drivers/char/sx.c - 1.38 linux/fs/nls/nls_iso8859-14.c - 1.9 linux/drivers/net/sis900.c - 1.51 linux/drivers/net/sb1000.c - 1.27 linux/drivers/net/fc/iph5526.c - 1.31 linux/drivers/char/ip2.c - 1.10 linux/drivers/atm/zatm.c - 1.22 linux/drivers/atm/uPD98402.c - 1.10 linux/drivers/atm/eni.c - 1.26 linux/drivers/atm/atmtcp.c - 1.17 linux/net/sched/sch_atm.c - 1.17 linux/net/atm/resources.h - 1.8 linux/net/atm/resources.c - 1.16 linux/net/atm/protocols.h - 1.2 linux/net/atm/proc.c - 1.25 linux/net/atm/mpc.h - 1.4 linux/net/atm/mpc.c - 1.20 linux/net/atm/lec.h - 1.10 linux/net/atm/lec.c - 1.27 linux/net/atm/ipcommon.c - 1.5 linux/net/atm/common.c - 1.30 linux/net/atm/clip.c - 1.23 linux/net/atm/Makefile - 1.16 linux/include/net/atmclip.h - 1.7 linux/include/linux/atmdev.h - 1.21 linux/include/linux/atmclip.h - 1.2 linux/arch/ppc/math-emu/fcmpo.c - 1.4 linux/arch/ppc/kernel/head_8xx.S - 1.20 linux/arch/ppc/kernel/entry.S - 1.38 linux/arch/arm/kernel/semaphore.c - 1.14 linux/arch/arm/kernel/bios32.c - 1.40 linux/drivers/block/DAC960.h - 1.28 linux/drivers/block/DAC960.c - 1.75 linux/arch/sh/kernel/setup.c - 1.24 linux/arch/ppc/math-emu/stfd.c - 1.4 linux/arch/ppc/math-emu/sfp-machine.h - 1.5 linux/arch/ppc/math-emu/op-common.h - 1.4 linux/arch/ppc/math-emu/op-4.h - 1.5 linux/arch/ppc/math-emu/op-2.h - 1.4 linux/arch/ppc/math-emu/op-1.h - 1.4 linux/arch/ppc/math-emu/math.c - 1.5 linux/drivers/char/n_r3964.c - 1.19 linux/net/irda/ircomm/ircomm_core.c - 1.21 linux/include/asm-sh/signal.h - 1.8 linux/include/asm-sh/processor.h - 1.23 linux/include/asm-sh/posix_types.h - 1.5 linux/include/asm-sh/mman.h - 1.4 linux/include/asm-ppc/m48t35.h - 1.6 linux/drivers/pcmcia/tcic.c - 1.32 linux/drivers/pcmcia/rsrc_mgr.c - 1.26 linux/drivers/pcmcia/ricoh.h - 1.13 linux/drivers/pcmcia/i82365.c - 1.47 linux/drivers/pcmcia/cs_internal.h - 1.22 linux/drivers/pcmcia/cs.c - 1.46 linux/include/pcmcia/ss.h - 1.19 linux/drivers/pcmcia/cardbus.c - 1.34 linux/include/asm-ppc/pci.h - 1.25 linux/drivers/net/pcmcia/pcnet_cs.c - 1.30 linux/drivers/net/pcmcia/3c589_cs.c - 1.33 linux/drivers/char/drm/gamma_dma.c - 1.18 linux/drivers/char/drm/drmP.h - 1.28 linux/drivers/net/wan/cosa.h - 1.3 linux/drivers/net/wan/cosa.c - 1.36 linux/drivers/net/wan/Makefile - 1.23 linux/drivers/net/tokenring/olympic.c - 1.30 linux/arch/i386/kernel/smpboot.c - 1.66 linux/drivers/net/wan/z85230.c - 1.17 linux/drivers/net/wan/syncppp.c - 1.20 linux/drivers/net/wan/sealevel.c - 1.14 linux/drivers/net/wan/sdlamain.c - 1.20 linux/drivers/net/wan/sdladrv.c - 1.14 linux/drivers/net/wan/sdla_x25.c - 1.20 linux/drivers/net/wan/sdla_ppp.c - 1.25 linux/drivers/net/wan/sdla_fr.c - 1.25 linux/drivers/net/wan/sdla.c - 1.20 linux/drivers/net/wan/sbni.c - 1.26 linux/drivers/net/wan/dlci.c - 1.15 linux/drivers/net/wan/cycx_x25.c - 1.19 linux/include/asm-ppc/mpc8xx.h - 1.10 linux/include/linux/pmu.h - 1.9 linux/drivers/net/tokenring/tms380tr.c - 1.22 linux/drivers/net/pcmcia/xirc2ps_cs.c - 1.30 linux/drivers/net/pcmcia/3c574_cs.c - 1.32 linux/drivers/net/pcmcia/nmclan_cs.c - 1.25 linux/drivers/net/pcmcia/fmvj18x_cs.c - 1.29 linux/arch/arm/def-configs/empeg - 1.4 linux/drivers/net/pcmcia/smc91c92_cs.c - 1.26 linux/arch/arm/def-configs/brutus - 1.14 linux/include/asm-arm/arch-sa1100/serial.h - 1.6 linux/fs/proc/proc_misc.c - 1.69 linux/fs/bfs/inode.c - 1.33 linux/fs/proc/kcore.c - 1.18 linux/drivers/net/sk98lin/h/skgeinit.h - 1.6 linux/Documentation/networking/sk98lin.txt - 1.9 linux/drivers/net/sk98lin/h/skdrv1st.h - 1.10 linux/drivers/net/sk98lin/h/skdrv2nd.h - 1.8 linux/drivers/net/sk98lin/skge.c - 1.30 linux/drivers/net/sk98lin/h/sktypes.h - 1.4 linux/include/asm-ppc/pgalloc.h - 1.16 linux/arch/ppc/mm/mem_pieces.c - 1.11 linux/arch/ppc/kernel/head_4xx.S - 1.15 linux/include/asm-sparc/sfp-machine.h - 1.4 linux/drivers/scsi/scsi_lib.c - 1.72 linux/include/linux/i2c-id.h - 1.20 linux/drivers/i2c/i2c-velleman.c - 1.12 linux/drivers/i2c/i2c-elv.c - 1.13 linux/drivers/i2c/i2c-philips-par.c - 1.13 linux/drivers/i2c/i2c-pcf8584.h - 1.5 linux/drivers/i2c/i2c-elektor.c - 1.19 linux/drivers/i2c/i2c-algo-pcf.c - 1.17 linux/drivers/i2c/i2c-dev.c - 1.34 linux/drivers/i2c/i2c-core.c - 1.31 linux/drivers/i2c/i2c-algo-bit.c - 1.19 linux/drivers/i2c/Makefile - 1.16 linux/include/asm-ppc/hw_irq.h - 1.11 linux/include/linux/input.h - 1.29 linux/drivers/net/pcmcia/com20020_cs.c - 1.14 linux/drivers/net/tokenring/smctr.c - 1.23 linux/drivers/pnp/quirks.c - 1.16 linux/arch/arm/boot/compressed/head-sa1100.S - 1.12 linux/arch/i386/kernel/mpparse.c - 1.43 linux/drivers/char/moxa.c - 1.22 linux/include/asm-ppc/shmbuf.h - 1.5 linux/include/asm-ppc/sembuf.h - 1.5 linux/include/asm-ppc/msgbuf.h - 1.5 linux/drivers/scsi/scsi_scan.c - 1.56 linux/drivers/scsi/3w-xxxx.h - 1.22 linux/drivers/scsi/3w-xxxx.c - 1.36 linux/drivers/net/wan/sdla_chdlc.c - 1.28 linux/drivers/net/tokenring/tmspci.c - 1.14 linux/drivers/net/tokenring/abyss.c - 1.13 linux/fs/autofs4/autofs_i.h - 1.12 linux/fs/autofs4/root.c - 1.21 linux/fs/autofs4/inode.c - 1.18 linux/drivers/net/irda/nsc-ircc.c - 1.31 linux/drivers/char/vme_scc.c - 1.19 linux/arch/ia64/kernel/entry.S - 1.43 linux/arch/ia64/kernel/efi.c - 1.25 linux/arch/ia64/kernel/acpi.c - 1.28 linux/arch/ia64/kernel/Makefile - 1.24 linux/arch/ia64/ia32/sys_ia32.c - 1.51 linux/arch/ia64/Makefile - 1.34 linux/arch/ia64/kernel/init_task.c - 1.12 linux/arch/ia64/kernel/setup.c - 1.31 linux/arch/ia64/kernel/time.c - 1.28 linux/arch/ia64/kernel/traps.c - 1.25 linux/arch/ia64/kernel/unwind.c - 1.19 linux/arch/ia64/kernel/perfmon.c - 1.31 linux/arch/ia64/kernel/mca.c - 1.26 linux/arch/ia64/mm/init.c - 1.32 linux/arch/ia64/mm/Makefile - 1.7 linux/drivers/scsi/qla1280.h - 1.15 linux/drivers/scsi/qla1280.c - 1.32 linux/include/linux/raid/md_k.h - 1.35 linux/include/asm-ia64/mman.h - 1.7 linux/include/asm-ia64/processor.h - 1.38 linux/include/asm-ia64/posix_types.h - 1.4 linux/include/asm-ia64/param.h - 1.6 linux/include/asm-ia64/ptrace.h - 1.16 linux/include/asm-ia64/spinlock.h - 1.18 linux/include/asm-ia64/unistd.h - 1.35 linux/include/asm-ia64/signal.h - 1.10 linux/include/asm-ia64/uaccess.h - 1.13 linux/arch/arm/mm/consistent.c - 1.18 linux/include/linux/devfs_fs_kernel.h - 1.23 linux/drivers/isdn/hysdn/hysdn_init.c - 1.10 linux/fs/devfs/base.c - 1.65 linux/drivers/net/skfp/h/targetos.h - 1.3 linux/drivers/net/skfp/skfddi.c - 1.21 linux/net/bridge/br_forward.c - 1.12 linux/drivers/video/matrox/i2c-matroxfb.c - 1.12 linux/drivers/video/riva/fbdev.c - 1.30 linux/include/linux/usb.h - 1.67 linux/include/asm-ia64/hw_irq.h - 1.13 linux/drivers/usb/serial/usb-serial.c - 1.24 linux/drivers/usb/serial/ftdi_sio.h - 1.11 linux/drivers/ide/ide-cd.c - 1.71 linux/include/linux/elevator.h - 1.22 linux/drivers/scsi/sym53c8xx_comm.h - 1.18 linux/drivers/net/wan/comx.c - 1.23 linux/drivers/net/wan/comx-proto-ppp.c - 1.7 linux/drivers/net/wan/comx-proto-lapb.c - 1.11 linux/drivers/net/wan/comx-proto-fr.c - 1.15 linux/drivers/net/wan/comx-hw-mixcom.c - 1.15 linux/drivers/net/wan/comx-hw-locomx.c - 1.11 linux/drivers/net/wan/comx-hw-comx.c - 1.14 linux/drivers/net/tokenring/lanstreamer.h - 1.5 linux/Documentation/DocBook/kernel-api.tmpl - 1.31 linux/net/ipv4/netfilter/ipt_REJECT.c - 1.25 linux/net/ipv4/netfilter/ipt_MASQUERADE.c - 1.14 linux/include/linux/netfilter_ipv4/ip_nat.h - 1.5 linux/drivers/scsi/dmx3191d.c - 1.17 linux/drivers/net/pcmcia/ibmtr_cs.c - 1.20 linux/fs/nfs/nfs3proc.c - 1.23 linux/drivers/usb/serial/ftdi_sio.c - 1.54 linux/arch/ia64/kernel/smpboot.c - 1.25 linux/drivers/net/wan/lmc/lmc_ver.h - 1.5 linux/fs/partitions/ibm.c - 1.16 linux/drivers/usb/serial/digi_acceleport.c - 1.40 linux/drivers/net/pppoe.c - 1.32 linux/arch/ppc/xmon/start_8xx.c - 1.5 linux/arch/ppc/8260_io/uart.c - 1.20 linux/arch/ppc/8260_io/enet.c - 1.13 linux/drivers/char/rio/rio_linux.c - 1.27 linux/arch/s390/kernel/process.c - 1.20 linux/arch/arm/def-configs/lart - 1.12 linux/arch/s390/boot/Makefile - 1.14 linux/arch/s390/Makefile - 1.20 linux/arch/s390/boot/ipldump.S - 1.3 linux/include/asm-s390/uaccess.h - 1.12 linux/arch/s390/boot/ipleckd.S - 1.3 linux/arch/s390/defconfig - 1.22 linux/arch/s390/boot/iplfba.S - 1.2 linux/include/asm-s390/lowcore.h - 1.11 linux/include/asm-s390/system.h - 1.14 linux/include/asm-s390/hardirq.h - 1.10 linux/include/asm-s390/spinlock.h - 1.9 linux/include/asm-s390/smp.h - 1.11 linux/include/asm-s390/signal.h - 1.8 linux/arch/s390/kernel/entry.S - 1.27 linux/arch/s390/kernel/head.S - 1.13 linux/include/asm-s390/atomic.h - 1.8 linux/drivers/s390/net/iucv.c - 1.15 linux/drivers/s390/net/iucv.h - 1.7 linux/drivers/s390/char/Makefile - 1.11 linux/drivers/s390/block/dasd_eckd.c - 1.18 linux/drivers/s390/block/dasd.c - 1.47 linux/include/asm-s390/ptrace.h - 1.10 linux/include/asm-s390/processor.h - 1.16 linux/include/asm-s390/posix_types.h - 1.5 linux/arch/arm/def-configs/assabet - 1.14 linux/arch/arm/def-configs/graphicsclient - 1.13 linux/arch/arm/def-configs/lusl7200 - 1.8 linux/include/asm-s390/mman.h - 1.4 linux/include/asm-s390/current.h - 1.7 linux/drivers/s390/block/dasd_proc.c - 1.11 linux/arch/s390/kernel/time.c - 1.15 linux/arch/s390/kernel/traps.c - 1.20 linux/arch/s390/kernel/ptrace.c - 1.14 linux/arch/s390/kernel/setup.c - 1.18 linux/arch/s390/kernel/signal.c - 1.19 linux/arch/s390/kernel/smp.c - 1.24 linux/arch/s390/lib/delay.c - 1.3 linux/arch/s390/mm/fault.c - 1.14 linux/Documentation/DocBook/kernel-hacking.tmpl - 1.15 linux/Documentation/DocBook/kernel-locking.tmpl - 1.10 linux/fs/xfs/xfs_ialloc.c - 1.170 linux/fs/xfs/xfs_types.h - 1.72 linux/fs/xfs/linux/xfs_super.c - 1.287 linux/fs/xfs/linux/xfs_iops.c - 1.210 linux/include/asm-ppc/backlight.h - 1.6 linux/drivers/char/drm/i810_dma.c - 1.26 linux/include/asm-ppc/time.h - 1.13 linux/drivers/usb/storage/transport.c - 1.48 linux/fs/jffs/inode-v23.c - 1.40 linux/fs/jffs/intrep.c - 1.24 linux/arch/arm/mm/proc-arm720.S - 1.20 linux/fs/nls/nls_big5.c - 1.6 linux/arch/sh/boot/compressed/misc.c - 1.2 linux/drivers/net/ibmlana.c - 1.11 linux/include/linux/serio.h - 1.12 linux/fs/nls/nls_cp932.c - 1.6 linux/fs/nls/nls_cp936.c - 1.5 linux/fs/nls/nls_cp949.c - 1.5 linux/fs/nls/nls_cp950.c - 1.5 linux/fs/nls/nls_euc-jp.c - 1.7 linux/fs/nls/nls_euc-kr.c - 1.6 linux/fs/nls/nls_gb2312.c - 1.6 linux/fs/nls/nls_sjis.c - 1.6 linux/drivers/sbus/char/display7seg.c - 1.10 linux/drivers/media/video/tuner.c - 1.20 linux/drivers/media/video/saa5249.c - 1.18 linux/drivers/media/video/msp3400.c - 1.21 linux/arch/arm/boot/bootp/init.S - 1.7 linux/drivers/input/mousedev.c - 1.22 linux/drivers/input/input.c - 1.24 linux/drivers/input/evdev.c - 1.22 linux/arch/arm/tools/mach-types - 1.29 linux/drivers/md/raid1.c - 1.39 linux/drivers/md/raid5.c - 1.47 linux/Documentation/kbuild/makefiles.txt - 1.12 linux/arch/arm/def-configs/clps7500 - 1.5 linux/arch/arm/def-configs/shark - 1.14 linux/arch/arm/mm/proc-arm920.S - 1.18 linux/arch/ppc/8260_io/fcc_enet.c - 1.10 linux/drivers/block/cciss.c - 1.63 linux/drivers/md/linear.c - 1.26 linux/drivers/md/md.c - 1.80 linux/drivers/md/raid0.c - 1.23 linux/drivers/net/hamachi.c - 1.28 linux/include/asm-ppc/highmem.h - 1.14 linux/include/asm-ppc/uninorth.h - 1.9 linux/net/irda/irsyms.c - 1.15 linux/include/asm-i386/cpufeature.h - 1.9 linux/arch/parisc/kernel/drivers.c - 1.7 linux/include/asm-parisc/atomic.h - 1.3 linux/include/asm-parisc/hil.h - 1.3 linux/include/asm-parisc/uaccess.h - 1.4 linux/include/asm-parisc/mman.h - 1.5 linux/arch/arm/def-configs/integrator - 1.8 linux/arch/arm/def-configs/neponset - 1.13 linux/arch/arm/def-configs/pangolin - 1.11 linux/arch/arm/def-configs/sherman - 1.6 linux/include/asm-parisc/posix_types.h - 1.6 linux/arch/arm/lib/io-readsb.S - 1.4 linux/arch/arm/lib/io-writesb.S - 1.4 linux/arch/arm/lib/io-writesl.S - 1.5 linux/include/asm-parisc/processor.h - 1.13 linux/arch/parisc/kernel/traps.c - 1.11 linux/arch/parisc/kernel/syscall.S - 1.13 linux/arch/parisc/kernel/sys_parisc.c - 1.9 linux/arch/parisc/kernel/signal.c - 1.11 linux/arch/parisc/kernel/setup.c - 1.8 linux/arch/parisc/kernel/real2.S - 1.3 linux/arch/i386/kernel/dmi_scan.c - 1.34 linux/arch/parisc/kernel/process.c - 1.11 linux/arch/parisc/kernel/pci.c - 1.10 linux/arch/parisc/kernel/parisc_ksyms.c - 1.10 linux/include/asm-parisc/bitops.h - 1.5 linux/include/asm-parisc/signal.h - 1.4 linux/include/asm-parisc/byteorder.h - 1.3 linux/include/asm-parisc/elf.h - 1.6 linux/arch/parisc/kernel/irq.c - 1.13 linux/include/asm-parisc/io.h - 1.5 linux/arch/parisc/kernel/cache.c - 1.5 linux/arch/parisc/hpux/wrappers.S - 1.4 linux/arch/parisc/hpux/sys_hpux.c - 1.7 linux/arch/parisc/hpux/fs.c - 1.7 linux/arch/parisc/defconfig - 1.11 linux/arch/parisc/Makefile - 1.17 linux/include/asm-parisc/stat.h - 1.5 linux/include/asm-arm/mmu.h - 1.4 linux/mm/shmem.c - 1.67 linux/drivers/atm/firestream.c - 1.20 linux/drivers/scsi/osst.c - 1.31 linux/include/asm-ia64/sn/hcl.h - 1.6 linux/include/asm-ia64/sn/hcl_util.h - 1.4 linux/include/asm-ia64/sn/invent.h - 1.5 linux/include/asm-ia64/sn/ioc3.h - 1.4 linux/include/asm-ia64/sn/ioerror_handling.h - 1.5 linux/drivers/char/drm/r128_cce.c - 1.12 linux/include/asm-ia64/sn/ksys/elsc.h - 1.6 linux/include/asm-ia64/sn/ksys/l1.h - 1.7 linux/include/asm-ia64/sn/labelcl.h - 1.4 linux/include/asm-ia64/sn/xtalk/xtalk_private.h - 1.6 linux/include/asm-ia64/sn/xtalk/xswitch.h - 1.4 linux/include/asm-ia64/sn/xtalk/xbow_info.h - 1.4 linux/include/asm-ia64/sn/nodepda.h - 1.8 linux/include/asm-ia64/sn/sgi.h - 1.6 linux/include/asm-ia64/sn/router.h - 1.6 linux/include/asm-ia64/sn/pci/pciio.h - 1.7 linux/include/asm-ia64/sn/pci/pcibr_private.h - 1.9 linux/include/asm-ia64/sn/pci/pci_bus_cvlink.h - 1.6 linux/fs/reiserfs/super.c - 1.38 linux/fs/reiserfs/tail_conversion.c - 1.22 linux/drivers/char/drm/radeon_cp.c - 1.15 linux/drivers/char/drm/radeon_drm.h - 1.14 linux/drivers/char/drm/radeon_drv.h - 1.15 linux/drivers/char/drm/radeon_state.c - 1.14 linux/fs/reiserfs/namei.c - 1.31 linux/fs/reiserfs/journal.c - 1.47 linux/fs/reiserfs/inode.c - 1.45 linux/fs/reiserfs/file.c - 1.19 linux/include/linux/reiserfs_fs.h - 1.40 linux/include/linux/reiserfs_fs_sb.h - 1.20 linux/drivers/usb/storage/unusual_devs.h - 1.29 linux/drivers/sbus/char/cpwatchdog.c - 1.11 linux/drivers/s390/net/netiucv.c - 1.21 linux/drivers/s390/net/ctcmain.c - 1.19 linux/drivers/s390/char/tape.h - 1.9 linux/drivers/s390/block/xpram.c - 1.38 linux/drivers/s390/block/dasd_diag.c - 1.13 linux/include/asm-cris/signal.h - 1.5 linux/drivers/pcmcia/hd64465_ss.c - 1.14 linux/include/asm-cris/posix_types.h - 1.4 linux/arch/s390/kernel/s390_ext.c - 1.6 linux/include/asm-cris/mman.h - 1.3 linux/include/net/syncppp.h - 1.4 linux/arch/arm/mach-integrator/Makefile - 1.10 linux/drivers/net/wan/dscc4.c - 1.23 linux/drivers/isdn/hisax/sedlbauer_cs.c - 1.10 linux/drivers/net/wan/sdla_ft1.c - 1.8 linux/drivers/net/wan/wanpipe_multppp.c - 1.12 linux/drivers/s390/char/tuball.c - 1.13 linux/net/wanrouter/af_wanpipe.c - 1.22 linux/drivers/net/saa9730.h - 1.2 linux/drivers/net/saa9730.c - 1.8 linux/drivers/s390/net/ctctty.h - 1.4 linux/drivers/isdn/hisax/elsa_cs.c - 1.7 linux/fs/nls/nls_cp1251.c - 1.6 linux/fs/nls/nls_cp1255.c - 1.7 linux/fs/nls/nls_iso8859-13.c - 1.7 linux/fs/nls/nls_koi8-u.c - 1.6 linux/fs/nls/nls_tis-620.c - 1.5 linux/include/linux/compiler.h - 1.13 linux/fs/nls/nls_koi8-ru.c - 1.6 linux/drivers/net/irda/irda-usb.c - 1.36 linux/drivers/net/wireless/Makefile - 1.12 linux/drivers/net/wireless/orinoco.c - 1.19 linux/drivers/net/wireless/orinoco_cs.c - 1.20 linux/fs/char_dev.c - 1.14 linux/arch/ppc/boot/utils/mkprep.c - 1.3 linux/arch/ppc/boot/prep/head.S - 1.5 linux/arch/ppc/boot/prep/Makefile - 1.16 linux/arch/ppc/boot/lib/zlib.c - 1.5 linux/arch/ppc/boot/include/zlib.h - 1.3 linux/arch/ppc/boot/include/rs6000.h - 1.3 linux/arch/ppc/boot/images/Makefile - 1.9 linux/arch/ppc/boot/common/misc-common.c - 1.11 linux/arch/ppc/boot/common/crt0.S - 1.6 linux/include/net/bluetooth/bluetooth.h - 1.11 linux/include/net/bluetooth/hci.h - 1.9 linux/include/net/bluetooth/l2cap.h - 1.9 linux/drivers/bluetooth/hci_usb.c - 1.26 linux/net/bluetooth/af_bluetooth.c - 1.20 linux/net/bluetooth/hci_core.c - 1.14 linux/net/bluetooth/hci_sock.c - 1.18 linux/net/bluetooth/syms.c - 1.8 linux/drivers/mtd/maps/sa1100-flash.c - 1.11 linux/drivers/net/wireless/airo_cs.c - 1.9 linux/drivers/net/wireless/airo.c - 1.36 linux/arch/ppc/mm/hashtable.S - 1.9 linux/drivers/net/irda/ali-ircc.c - 1.19 linux/drivers/net/sk98lin/h/skversion.h - 1.4 linux/drivers/net/sk98lin/skproc.c - 1.11 linux/include/asm-s390/pci.h - 1.3 linux/Documentation/video4linux/Zoran - 1.4 linux/drivers/char/ser_a2232.c - 1.12 linux/drivers/message/fusion/mptctl.c - 1.17 linux/drivers/ieee1394/nodemgr.c - 1.23 linux/Documentation/s390/CommonIO - 1.5 linux/drivers/s390/block/dasd_int.h - 1.14 linux/drivers/char/drm/radeon.h - 1.12 linux/drivers/char/drm/drm_proc.h - 1.10 linux/drivers/char/drm/drm_memory.h - 1.7 linux/drivers/char/drm/drm_fops.h - 1.9 linux/drivers/char/drm/drm_drv.h - 1.18 linux/drivers/char/drm/drm_agpsupport.h - 1.17 linux/arch/arm/def-configs/anakin - 1.7 linux/arch/arm/def-configs/flexanet - 1.10 linux/arch/arm/def-configs/freebird - 1.8 linux/arch/arm/def-configs/freebird_new - 1.8 linux/arch/arm/def-configs/h3600 - 1.9 linux/arch/arm/def-configs/huw_webpanel - 1.6 linux/arch/arm/def-configs/jornada720 - 1.10 linux/arch/arm/def-configs/omnimeter - 1.7 linux/arch/arm/def-configs/pfs168_mqtft - 1.8 linux/arch/arm/def-configs/pfs168_mqvga - 1.8 linux/arch/arm/def-configs/pfs168_sastn - 1.8 linux/arch/arm/def-configs/pfs168_satft - 1.8 linux/arch/arm/def-configs/pleb - 1.8 linux/arch/arm/mach-sa1100/simpad.c - 1.12 linux/arch/arm/mach-sa1100/pfs168.c - 1.14 linux/arch/arm/mach-anakin/arch.c - 1.5 linux/arch/arm/mach-integrator/cpu.c - 1.16 linux/arch/ppc/mm/4xx_mmu.c - 1.7 linux/arch/ppc/mm/mmu_context.c - 1.6 linux/arch/ppc/kernel/temp.c - 1.5 linux/arch/ppc/mm/mmu_decl.h - 1.10 linux/arch/ppc/mm/pgtable.c - 1.14 linux/arch/ppc/mm/ppc_mmu.c - 1.9 linux/arch/ppc/mm/tlb.c - 1.9 linux/arch/ppc/kernel/l2cr.S - 1.9 linux/arch/ppc/kernel/cputable.c - 1.12 linux/drivers/telephony/ixj_pcmcia.c - 1.7 linux/drivers/scsi/dpt_i2o.c - 1.28 linux/drivers/scsi/dpt/dpti_i2o.h - 1.2 linux/drivers/char/serial_tx3912.c - 1.13 linux/drivers/net/ns83820.c - 1.24 linux/drivers/scsi/53c700.c - 1.24 linux/drivers/i2c/i2c-adap-ite.c - 1.10 linux/drivers/i2c/i2c-algo-ite.c - 1.6 linux/drivers/i2c/i2c-ite.h - 1.2 linux/drivers/scsi/lasi700.c - 1.13 linux/drivers/scsi/lasi700.h - 1.7 linux/fs/jffs2/file.c - 1.15 linux/fs/jffs2/super.c - 1.19 linux/drivers/md/multipath.c - 1.24 linux/scripts/mkspec - 1.5 linux/drivers/char/mwave/mwavedd.c - 1.10 linux/fs/smbfs/proto.h - 1.11 linux/include/asm-ppc/commproc.h - 1.5 linux/drivers/pcmcia/sa1100_generic.c - 1.19 linux/drivers/pcmcia/sa1100_assabet.c - 1.9 linux/drivers/pcmcia/sa1100_simpad.c - 1.7 linux/arch/arm/mach-sa1100/h3600.c - 1.14 linux/arch/arm/lib/lib1funcs.S - 1.4 linux/drivers/atm/lanai.c - 1.13 linux/drivers/pcmcia/i82092.c - 1.19 linux/arch/arm/def-configs/adsbitsy - 1.9 linux/arch/arm/def-configs/cerfcube - 1.9 linux/arch/arm/def-configs/cerfpda - 1.9 linux/arch/arm/def-configs/cerfpod - 1.9 linux/arch/arm/def-configs/edb7211 - 1.5 linux/arch/arm/def-configs/epxa10db - 1.9 linux/arch/arm/def-configs/graphicsmaster - 1.9 linux/net/ipv4/netfilter/ip_nat_snmp_basic.c - 1.12 linux/net/ipv4/netfilter/ip_nat_irc.c - 1.9 linux/net/8021q/vlanproc.c - 1.12 linux/net/8021q/vlan.c - 1.14 linux/Documentation/networking/ifenslave.c - 1.8 linux/Documentation/networking/bonding.txt - 1.11 linux/drivers/atm/idt77252.c - 1.16 linux/fs/jbd/journal.c - 1.28 linux/drivers/scsi/sym53c8xx_2/sym53c8xx.h - 1.9 linux/drivers/scsi/sym53c8xx_2/sym_conf.h - 1.4 linux/drivers/scsi/sym53c8xx_2/sym_glue.c - 1.21 linux/drivers/scsi/sym53c8xx_2/sym_glue.h - 1.13 linux/drivers/scsi/sym53c8xx_2/sym_hipd.c - 1.11 linux/drivers/scsi/sym53c8xx_2/sym_hipd.h - 1.3 linux/arch/arm/mm/proc-arm1020.S - 1.13 linux/arch/arm/mm/proc-arm926.S - 1.14 linux/net/atm/pppoatm.c - 1.11 linux/fs/ext3/inode.c - 1.45 linux/fs/ext3/namei.c - 1.26 linux/fs/ext3/super.c - 1.42 linux/fs/intermezzo/ext_attr.c - 1.7 linux/fs/intermezzo/file.c - 1.10 linux/fs/intermezzo/inode.c - 1.9 linux/fs/intermezzo/journal.c - 1.8 linux/fs/intermezzo/journal_ext3.c - 1.8 linux/fs/intermezzo/journal_reiserfs.c - 1.8 linux/include/linux/seq_file.h - 1.6 linux/fs/intermezzo/presto.c - 1.12 linux/fs/intermezzo/upcall.c - 1.7 linux/fs/jbd/transaction.c - 1.23 linux/fs/reiserfs/procfs.c - 1.15 linux/fs/intermezzo/dir.c - 1.15 linux/fs/intermezzo/dcache.c - 1.10 linux/drivers/net/pcmcia/axnet_cs.c - 1.14 linux/include/linux/bio.h - 1.24 linux/fs/bio.c - 1.34 linux/init/do_mounts.c - 1.31 linux/drivers/usb/serial/ipaq.c - 1.27 linux/arch/arm/mm/proc-xscale.S - 1.16 linux/arch/arm/mm/proc-arm922.S - 1.13 linux/arch/arm/mm/minicache.c - 1.8 linux/arch/arm/mach-tbox/core.c - 1.4 linux/arch/arm/def-configs/adi_evb - 1.8 linux/arch/arm/def-configs/iq80310 - 1.14 linux/arch/arm/def-configs/shannon - 1.8 linux/arch/arm/def-configs/system3 - 1.8 linux/include/asm-arm/hardware/sa1111.h - 1.11 linux/arch/arm/mach-clps711x/mm.c - 1.4 linux/arch/arm/mach-l7200/core.c - 1.7 linux/arch/arm/mach-rpc/riscpc.c - 1.7 linux/include/asm-arm/arch-clps711x/system.h - 1.3 linux/drivers/net/Makefile.lib - 1.11 linux/drivers/usb/Makefile.lib - 1.5 linux/fs/Makefile.lib - 1.3 linux/net/ipv4/tcp_diag.c - 1.9 linux/net/core/wireless.c - 1.9 linux/drivers/net/wireless/netwave_cs.c - 1.12 linux/drivers/net/wireless/wavelan_cs.c - 1.12 linux/drivers/net/wireless/wavelan_cs.p.h - 1.8 linux/Documentation/DocBook/writing_usb_driver.tmpl - 1.4 linux/drivers/base/core.c - 1.30 linux/drivers/pci/pci-driver.c - 1.19 linux/fs/xattr.c - 1.16 linux/include/linux/pnpbios.h - 1.11 linux/drivers/input/joystick/db9.c - 1.5 linux/drivers/input/serio/serio.c - 1.12 linux/sound/ppc/tumbler.c - 1.10 linux/sound/ppc/pmac.c - 1.12 linux/sound/ppc/daca.c - 1.5 linux/sound/pci/trident/trident_main.c - 1.17 linux/sound/pci/intel8x0.c - 1.22 linux/arch/ppc/4xx_io/Makefile - 1.5 linux/arch/ppc/4xx_io/serial_sicc.c - 1.7 linux/sound/pci/es1968.c - 1.19 linux/sound/pci/ens1370.c - 1.23 linux/arch/ppc/8xx_io/cs4218_tdm.c - 1.9 linux/sound/pci/emu10k1/emupcm.c - 1.12 linux/sound/pci/emu10k1/emufx.c - 1.19 linux/sound/pci/emu10k1/emu10k1.c - 1.11 linux/sound/pci/cs46xx/cs46xx_lib.c - 1.21 linux/arch/ppc/boot/common/util.S - 1.7 linux/sound/pci/ac97/ac97_codec.c - 1.20 linux/sound/oss/vwsnd.c - 1.9 linux/arch/ppc/boot/simple/Makefile - 1.17 linux/arch/ppc/boot/simple/gt64260_tty.c - 1.5 linux/arch/ppc/boot/simple/head.S - 1.6 linux/arch/ppc/boot/simple/misc-embedded.c - 1.8 linux/arch/ppc/boot/simple/misc-ev64260.S - 1.4 linux/arch/ppc/boot/simple/misc-spruce.c - 1.7 linux/arch/ppc/boot/utils/addRamDisk.c - 1.2 linux/arch/ppc/boot/utils/addSystemMap.c - 1.2 linux/arch/ppc/boot/utils/mkbugboot.c - 1.4 linux/arch/ppc/boot/utils/mkimage.wrapper - 1.2 linux/sound/oss/rme96xx.c - 1.13 linux/sound/oss/nec_vrc5477.c - 1.13 linux/sound/oss/i810_audio.c - 1.19 linux/sound/oss/dmasound/dmasound_awacs.c - 1.10 linux/sound/oss/dmasound/awacs_defs.h - 1.2 linux/sound/oss/dmasound/Makefile - 1.6 linux/arch/ppc/platforms/adir.h - 1.2 linux/arch/ppc/platforms/adir_pci.c - 1.3 linux/arch/ppc/platforms/adir_pic.c - 1.3 linux/arch/ppc/platforms/apus_pci.c - 1.4 linux/arch/ppc/platforms/ccm.h - 1.3 linux/arch/ppc/platforms/chrp_setup.c - 1.12 linux/arch/ppc/platforms/chrp_time.c - 1.4 linux/arch/ppc/platforms/error_log.c - 1.3 linux/arch/ppc/platforms/error_log.h - 1.3 linux/arch/ppc/platforms/ev64260.h - 1.4 linux/arch/ppc/platforms/ev64260_setup.c - 1.7 linux/arch/ppc/platforms/gemini.h - 1.3 linux/arch/ppc/platforms/gemini_prom.S - 1.3 linux/arch/ppc/platforms/hermes.h - 1.2 linux/arch/ppc/platforms/ip860.h - 1.2 linux/arch/ppc/platforms/k2.h - 1.4 linux/arch/ppc/platforms/k2_pci.c - 1.6 linux/arch/ppc/platforms/k2_setup.c - 1.10 linux/arch/ppc/platforms/lantec.h - 1.2 linux/arch/ppc/platforms/lopec_pci.c - 1.5 linux/arch/ppc/platforms/lopec_serial.h - 1.4 linux/arch/ppc/platforms/lopec_setup.c - 1.15 linux/arch/ppc/platforms/lwmon.h - 1.2 linux/arch/ppc/platforms/mcpn765.h - 1.4 linux/arch/ppc/platforms/mcpn765_pci.c - 1.4 linux/arch/ppc/platforms/mcpn765_serial.h - 1.5 linux/arch/ppc/platforms/mvme5100.h - 1.4 linux/arch/ppc/platforms/mvme5100_pci.c - 1.4 linux/arch/ppc/platforms/mvme5100_serial.h - 1.4 linux/arch/ppc/platforms/pcore.h - 1.4 linux/arch/ppc/platforms/pcore_pci.c - 1.4 linux/arch/ppc/platforms/pcu_e.h - 1.2 linux/arch/ppc/platforms/pmac_backlight.c - 1.3 linux/arch/ppc/platforms/pmac_feature.c - 1.9 linux/arch/ppc/platforms/pmac_nvram.c - 1.5 linux/arch/ppc/platforms/pmac_pci.c - 1.6 linux/arch/ppc/platforms/pmac_pic.c - 1.10 linux/arch/ppc/platforms/pmac_setup.c - 1.14 linux/arch/ppc/platforms/pmac_smp.c - 1.9 linux/arch/ppc/platforms/powerpmc250.c - 1.8 linux/arch/ppc/platforms/powerpmc250.h - 1.4 linux/arch/ppc/platforms/powerpmc250_serial.h - 1.4 linux/arch/ppc/platforms/pplus_pci.c - 1.4 linux/arch/ppc/platforms/pplus_setup.c - 1.14 linux/arch/ppc/platforms/prep_pci.c - 1.9 linux/arch/ppc/platforms/prep_setup.c - 1.15 linux/arch/ppc/platforms/prep_time.c - 1.4 linux/arch/ppc/platforms/proc_rtas.c - 1.4 linux/arch/ppc/platforms/prpmc750.h - 1.2 linux/arch/ppc/platforms/prpmc750_pci.c - 1.4 linux/arch/ppc/platforms/prpmc750_serial.h - 1.4 linux/arch/ppc/platforms/prpmc800.h - 1.4 linux/arch/ppc/platforms/prpmc800_pci.c - 1.4 linux/arch/ppc/platforms/prpmc800_serial.h - 1.4 linux/arch/ppc/platforms/residual.c - 1.7 linux/arch/ppc/platforms/sandpoint.h - 1.6 linux/arch/ppc/platforms/spd8xx.h - 1.4 linux/arch/ppc/platforms/spruce.h - 1.5 linux/arch/ppc/platforms/spruce_pci.c - 1.5 linux/arch/ppc/platforms/spruce_serial.h - 1.4 linux/arch/ppc/platforms/tqm8260.h - 1.3 linux/arch/ppc/platforms/tqm8xx.h - 1.5 linux/arch/x86_64/Makefile - 1.22 linux/arch/x86_64/boot/Makefile - 1.14 linux/arch/x86_64/boot/compressed/misc.c - 1.7 linux/arch/x86_64/defconfig - 1.22 linux/arch/x86_64/ia32/Makefile - 1.15 linux/arch/x86_64/ia32/ia32_ioctl.c - 1.23 linux/arch/x86_64/ia32/sys_ia32.c - 1.27 linux/arch/x86_64/kernel/Makefile - 1.21 linux/arch/x86_64/kernel/entry.S - 1.13 linux/arch/x86_64/kernel/io_apic.c - 1.13 linux/arch/x86_64/kernel/ioport.c - 1.10 linux/arch/x86_64/kernel/mpparse.c - 1.13 linux/arch/x86_64/kernel/nmi.c - 1.16 linux/arch/x86_64/kernel/setup.c - 1.18 linux/arch/x86_64/kernel/time.c - 1.18 linux/arch/x86_64/kernel/traps.c - 1.22 linux/arch/x86_64/mm/fault.c - 1.13 linux/sound/oss/ac97_codec.c - 1.10 linux/sound/isa/cs423x/cs4236.c - 1.17 linux/sound/drivers/dummy.c - 1.16 linux/sound/core/sound.c - 1.21 linux/sound/core/pcm_native.c - 1.21 linux/sound/core/oss/pcm_plugin.h - 1.5 linux/sound/core/oss/pcm_plugin.c - 1.8 linux/sound/core/oss/pcm_oss.c - 1.22 linux/sound/core/info.c - 1.18 linux/sound/core/hwdep.c - 1.11 linux/include/sound/pcm_oss.h - 1.4 linux/include/asm-x86_64/processor.h - 1.21 linux/include/asm-x86_64/posix_types.h - 1.4 linux/include/asm-x86_64/mman.h - 1.5 linux/include/asm-x86_64/kdebug.h - 1.4 linux/include/asm-x86_64/desc.h - 1.11 linux/include/sound/version.h - 1.21 linux/include/sound/emu10k1.h - 1.14 linux/include/sound/asound.h - 1.14 linux/include/sound/ac97_codec.h - 1.17 linux/include/asm-x86_64/siginfo.h - 1.5 linux/include/asm-x86_64/signal.h - 1.8 linux/include/asm-ppc/thread_info.h - 1.10 linux/include/asm-ppc/pplus.h - 1.4 linux/include/asm-ppc/ppc_asm.h - 1.7 linux/include/asm-ppc/ppc405_dma.h - 1.4 linux/include/asm-ppc/pmac_feature.h - 1.5 linux/include/asm-ppc/open_pic.h - 1.6 linux/include/asm-ppc/mpc10x.h - 1.6 linux/include/asm-ppc/ibm4xx.h - 1.6 linux/include/asm-x86_64/uaccess.h - 1.10 linux/include/asm-ppc/gt64260.h - 1.4 linux/include/asm-ppc/gt64260_defs.h - 1.4 linux/arch/ppc64/mm/fault.c - 1.10 linux/arch/ppc64/mm/init.c - 1.21 linux/include/asm-ppc64/ioctl.h - 1.2 linux/arch/ppc64/Makefile - 1.20 linux/arch/ppc64/boot/Makefile - 1.15 linux/arch/ppc64/defconfig - 1.19 linux/arch/ppc64/kernel/chrp_setup.c - 1.17 linux/arch/ppc64/kernel/eeh.c - 1.9 linux/arch/ppc64/kernel/head.S - 1.15 linux/arch/ppc64/kernel/htab.c - 1.15 linux/arch/ppc64/kernel/irq.c - 1.15 linux/arch/ppc64/kernel/pSeries_lpar.c - 1.13 linux/arch/ppc64/kernel/pSeries_pci.c - 1.15 linux/arch/ppc64/kernel/ppc_ksyms.c - 1.11 linux/arch/ppc64/kernel/process.c - 1.20 linux/arch/ppc64/kernel/rtas.c - 1.8 linux/arch/ppc64/kernel/rtc.c - 1.7 linux/arch/ppc64/kernel/semaphore.c - 1.3 linux/arch/ppc64/kernel/stab.c - 1.9 linux/arch/ppc64/kernel/sys_ppc32.c - 1.27 linux/arch/ppc64/kernel/syscalls.c - 1.11 linux/arch/ppc64/kernel/time.c - 1.18 linux/arch/ppc64/kernel/xics.c - 1.14 linux/arch/ppc64/mm/Makefile - 1.6 linux/arch/ppc64/xmon/xmon.c - 1.14 linux/include/asm-ppc64/mman.h - 1.5 linux/include/asm-ppc64/mmu.h - 1.7 linux/include/asm-ppc64/mmu_context.h - 1.7 linux/include/asm-ppc64/uaccess.h - 1.9 linux/include/asm-ppc64/rwsem.h - 1.3 linux/include/asm-ppc64/stat.h - 1.4 linux/include/asm-ppc64/signal.h - 1.7 linux/include/asm-ppc64/serial.h - 1.2 linux/include/asm-ppc64/semaphore.h - 1.6 linux/include/asm-ppc64/rtas.h - 1.7 linux/include/asm-ppc64/prom.h - 1.7 linux/include/asm-ppc64/processor.h - 1.18 linux/include/asm-ppc64/posix_types.h - 1.6 linux/include/asm-ppc64/pgtable.h - 1.14 linux/include/asm-ppc64/page.h - 1.14 linux/drivers/net/e1000/e1000_main.c - 1.26 linux/drivers/net/e1000/e1000_osdep.h - 1.10 linux/drivers/net/e1000/e1000.h - 1.15 linux/drivers/net/e1000/e1000_ethtool.c - 1.15 linux/drivers/net/e1000/e1000_param.c - 1.10 linux/arch/arm/def-configs/badge4 - 1.10 linux/arch/arm/def-configs/fortunet - 1.7 linux/arch/arm/mm/copypage-v4mc.S - 1.4 linux/arch/arm/def-configs/stork - 1.8 linux/arch/arm/mm/copypage-v3.S - 1.4 linux/fs/jfs/jfs_imap.c - 1.18 linux/fs/jfs/namei.c - 1.22 linux/arch/arm/mach-sa1100/stork.c - 1.7 linux/fs/jfs/super.c - 1.27 linux/include/asm-arm/glue.h - 1.6 linux/arch/arm/mm/tlb-v4wb.S - 1.7 linux/fs/jfs/jfs_mount.c - 1.16 linux/fs/jfs/jfs_txnmgr.c - 1.29 linux/arch/arm/mm/tlb-v4.S - 1.7 linux/arch/arm/mm/tlb-v3.S - 1.6 linux/drivers/pcmcia/sa1111_generic.c - 1.12 linux/drivers/net/tulip/de2104x.c - 1.14 linux/drivers/net/tulip/de4x5.c - 1.17 linux/sound/core/ioctl32/pcm32.c - 1.8 linux/sound/core/ioctl32/ioctl32.c - 1.11 linux/drivers/net/wan/hdlc_generic.c - 1.9 linux/drivers/net/e100/e100.h - 1.16 linux/drivers/net/e100/e100_config.c - 1.10 linux/drivers/net/e100/e100_config.h - 1.7 linux/drivers/net/e100/e100_main.c - 1.27 linux/arch/ia64/sn/kernel/sn_ksyms.c - 1.5 linux/arch/ia64/sn/kernel/irq.c - 1.7 linux/kernel/futex.c - 1.19 linux/include/asm-ia64/sn/uart16550.h - 1.3 linux/fs/jffs2/fs.c - 1.10 linux/include/asm-ia64/sn/sn2/sn_private.h - 1.5 linux/include/asm-ia64/sn/sn2/shub_mmr_t.h - 1.3 linux/include/asm-ia64/sn/sn2/shub.h - 1.3 linux/include/asm-ia64/sn/sn2/intr.h - 1.4 linux/include/asm-ia64/sn/mmtimer_private.h - 1.3 linux/include/asm-ia64/sn/klclock.h - 1.4 linux/arch/ia64/kernel/salinfo.c - 1.4 linux/arch/ia64/sn/kernel/Makefile - 1.12 linux/arch/ia64/sn/io/sn2/shuberror.c - 1.6 linux/arch/ia64/sn/io/sn2/shub_intr.c - 1.4 linux/arch/ia64/sn/io/sn2/pcibr/pcibr_slot.c - 1.7 linux/arch/ia64/sn/io/sn2/pcibr/pcibr_rrb.c - 1.6 linux/arch/ia64/sn/io/sn2/pcibr/pcibr_intr.c - 1.6 linux/arch/ia64/sn/io/sn2/pcibr/pcibr_hints.c - 1.4 linux/arch/ia64/sn/io/sn2/pcibr/pcibr_error.c - 1.6 linux/arch/ia64/sn/io/sn2/pcibr/pcibr_dvr.c - 1.10 linux/arch/ia64/sn/io/sn2/pcibr/pcibr_config.c - 1.4 linux/arch/ia64/sn/io/sn2/pcibr/pcibr_ate.c - 1.6 linux/arch/ia64/sn/io/sn2/ml_SN_intr.c - 1.4 linux/drivers/net/wan/comx-hw-munich.c - 1.14 linux/fs/libfs.c - 1.20 linux/include/asm-ppc/tlbflush.h - 1.8 linux/drivers/net/tc35815.c - 1.13 linux/drivers/ide/ide-tcq.c - 1.9 linux/drivers/net/e1000/e1000_hw.h - 1.9 linux/drivers/usb/core/hub.c - 1.30 linux/include/asm-arm/arch-pxa/pxa-regs.h - 1.8 linux/include/asm-arm/arch-pxa/keyboard.h - 1.2 linux/include/asm-arm/arch-pxa/irqs.h - 1.4 linux/include/asm-arm/arch-pxa/idp.h - 1.3 linux/include/asm-arm/arch-pxa/ide.h - 1.2 linux/include/asm-arm/arch-pxa/hardware.h - 1.4 linux/drivers/usb/core/usb.c - 1.41 linux/arch/arm/mach-pxa/generic.c - 1.8 linux/arch/arm/mach-pxa/leds.c - 1.3 linux/fs/partitions/efi.h - 1.6 linux/fs/partitions/efi.c - 1.5 linux/drivers/usb/media/usbvideo.c - 1.16 linux/drivers/net/e1000/e1000_hw.c - 1.9 linux/drivers/usb/image/scanner.c - 1.27 linux/drivers/usb/image/scanner.h - 1.20 linux/fs/nls/nls_cp1250.c - 1.4 linux/drivers/usb/input/hiddev.c - 1.19 linux/drivers/usb/media/dabusb.c - 1.18 linux/drivers/usb/net/usbnet.c - 1.29 linux/drivers/usb/media/vicam.c - 1.16 linux/drivers/usb/net/Makefile - 1.8 linux/drivers/isdn/i4l/isdn_tty.c - 1.14 linux/include/asm-ia64/acpi.h - 1.8 linux/drivers/isdn/i4l/isdn_common.c - 1.16 linux/include/asm-arm/tlbflush.h - 1.3 linux/include/asm-arm/cacheflush.h - 1.4 linux/arch/ia64/hp/common/sba_iommu.c - 1.16 linux/drivers/isdn/hardware/avm/avm_cs.c - 1.7 linux/fs/ntfs/layout.h - 1.6 linux/drivers/char/pcmcia/synclink_cs.c - 1.17 linux/scripts/mkcompile_h - 1.10 linux/drivers/block/umem.c - 1.24 linux/drivers/usb/host/uhci-hcd.c - 1.26 linux/drivers/net/wan/pc300_drv.c - 1.9 linux/drivers/net/wan/pc300_tty.c - 1.9 linux/net/bluetooth/sco.c - 1.14 linux/net/bluetooth/l2cap.c - 1.15 linux/net/bluetooth/hci_event.c - 1.6 linux/mm/page-writeback.c - 1.29 linux/arch/arm/mm/copypage-v4wt.S - 1.3 linux/arch/arm/mm/copypage-v4wb.S - 1.3 linux/include/asm-ppc64/paca.h - 1.5 linux/include/linux/writeback.h - 1.14 linux/include/asm-i386/suspend.h - 1.8 linux/Documentation/block/biodoc.txt - 1.6 linux/drivers/char/drm/sis_mm.c - 1.5 linux/drivers/char/drm/sis_ds.h - 1.2 linux/drivers/char/drm/sis_ds.c - 1.4 linux/drivers/char/drm/sis_drv.h - 1.2 linux/drivers/char/drm/sis_drm.h - 1.3 linux/drivers/char/drm/sis.h - 1.4 linux/include/linux/suspend.h - 1.12 linux/drivers/char/hvc_console.c - 1.13 linux/drivers/usb/core/message.c - 1.25 linux/drivers/usb/core/config.c - 1.6 linux/drivers/usb/class/usb-midi.c - 1.18 linux/drivers/s390/net/lcs.c - 1.16 linux/drivers/s390/cio/chsc.c - 1.11 linux/drivers/usb/core/hcd-pci.c - 1.16 linux/arch/i386/kernel/suspend.c - 1.15 linux/include/asm-s390/qdio.h - 1.6 linux/include/asm-s390/percpu.h - 1.2 linux/arch/i386/kernel/cpu/intel.c - 1.17 linux/drivers/s390/cio/cio.c - 1.9 linux/drivers/s390/block/dasd_devmap.c - 1.6 linux/drivers/s390/block/dasd_genhd.c - 1.17 linux/drivers/s390/block/dasd_ioctl.c - 1.14 linux/arch/i386/kernel/cpu/common.c - 1.16 linux/arch/x86_64/lib/csum-copy.S - 1.4 linux/arch/x86_64/lib/copy_page.S - 1.5 linux/arch/arm/mm/proc-arm6_7.S - 1.9 linux/net/llc/llc_if.c - 1.9 linux/include/net/llc_sap.h - 1.7 linux/include/net/llc_if.h - 1.4 linux/include/net/llc_s_st.h - 1.3 linux/include/asm-x86_64/suspend.h - 1.8 linux/include/net/llc_pdu.h - 1.6 linux/include/net/llc_main.h - 1.7 linux/include/linux/llc.h - 1.3 linux/arch/arm/kernel/asm-offsets.c - 1.5 linux/net/llc/llc_stat.c - 1.4 linux/net/llc/llc_sap.c - 1.12 linux/net/llc/llc_s_ac.c - 1.7 linux/net/llc/llc_evnt.c - 1.7 linux/net/llc/llc_mac.c - 1.12 linux/include/net/llc_mac.h - 1.6 linux/net/llc/Makefile - 1.8 linux/net/llc/llc_actn.c - 1.6 linux/net/llc/llc_pdu.c - 1.8 linux/include/net/llc_stat.h - 1.2 linux/net/llc/llc_c_ac.c - 1.12 linux/net/llc/llc_main.c - 1.14 linux/net/llc/llc_conn.c - 1.13 linux/include/net/llc_actn.h - 1.4 linux/include/net/llc_conn.h - 1.9 linux/include/net/llc_evnt.h - 1.5 linux/sound/pci/rme9652/hdsp.c - 1.16 linux/drivers/message/fusion/mptctl.h - 1.6 linux/drivers/isdn/hisax/avma1_cs.c - 1.8 linux/drivers/input/keyboard/atkbd.c - 1.13 linux/drivers/input/serio/i8042.c - 1.16 linux/drivers/input/joystick/iforce/iforce-packets.c - 1.5 linux/drivers/input/joystick/iforce/iforce-usb.c - 1.8 linux/arch/arm/mm/copypage-xscale.S - 1.4 linux/arch/arm/mm/abort-xscale.S - 1.2 linux/arch/arm/mm/abort-ev5tej.S - 1.2 linux/fs/smbfs/smbiod.c - 1.7 linux/security/security.c - 1.7 linux/security/capability.c - 1.13 linux/security/Makefile - 1.5 linux/drivers/serial/clps711x.c - 1.11 linux/drivers/serial/sa1100.c - 1.12 linux/drivers/serial/core.c - 1.17 linux/drivers/input/serio/ambakmi.c - 1.6 linux/drivers/char/agp/sis-agp.c - 1.13 linux/drivers/char/agp/hp-agp.c - 1.11 linux/drivers/serial/Makefile - 1.14 linux/drivers/serial/8250_pci.c - 1.13 linux/drivers/serial/8250.h - 1.4 linux/drivers/char/agp/via-agp.c - 1.14 linux/drivers/serial/8250_cs.c - 1.8 linux/include/asm-ppc64/mmzone.h - 1.10 linux/drivers/serial/8250.c - 1.19 linux/drivers/serial/21285.c - 1.12 linux/include/linux/serial_core.h - 1.18 linux/drivers/char/drm/drm_os_linux.h - 1.10 linux/arch/arm/mach-pxa/pm.c - 1.5 linux/arch/arm/def-configs/lubbock - 1.5 linux/net/sched/sch_htb.c - 1.12 linux/drivers/usb/class/usblp.c - 1.16 linux/fs/aio.c - 1.18 linux/drivers/i2c/i2c-rpx.c - 1.5 linux/drivers/i2c/i2c-frodo.c - 1.6 linux/drivers/i2c/i2c-algo-ibm_ocp.h - 1.3 linux/drivers/i2c/i2c-algo-ibm_ocp.c - 1.6 linux/include/asm-ppc/rtc.h - 1.5 linux/arch/i386/kernel/cpu/mtrr/if.c - 1.6 linux/arch/i386/mm/discontig.c - 1.10 linux/arch/i386/kernel/numaq.c - 1.7 linux/include/asm-i386/mmzone.h - 1.10 linux/include/asm-i386/numaq.h - 1.9 linux/include/asm-ppc64/hvcall.h - 1.3 linux/arch/parisc/vmlinux.lds.S - 1.10 linux/arch/i386/mm/hugetlbpage.c - 1.16 linux/include/asm-i386/numnodes.h - 1.4 linux/arch/ppc/boot/common/mpc10x_memory.c - 1.5 linux/kernel/pid.c - 1.6 linux/arch/i386/kernel/reboot.c - 1.8 linux/arch/ppc64/kernel/asm-offsets.c - 1.5 linux/arch/ppc/boot/of1275/ofinit.c - 1.3 linux/drivers/base/platform.c - 1.8 linux/arch/ppc64/mm/numa.c - 1.6 linux/arch/ppc/boot/openfirmware/newworldmain.c - 1.3 linux/arch/ppc/boot/of1275/ofstdio.c - 1.2 linux/arch/ppc/boot/openfirmware/coffmain.c - 1.4 linux/arch/ppc/boot/openfirmware/chrpmain.c - 1.3 linux/arch/ia64/mm/hugetlbpage.c - 1.10 linux/drivers/char/drm/radeon_mem.c - 1.5 linux/drivers/block/deadline-iosched.c - 1.13 linux/drivers/usb/core/driverfs.c - 1.7 linux/sound/pci/cs46xx/dsp_spos.c - 1.9 linux/include/asm-ppc64/topology.h - 1.8 linux/sound/pci/ac97/ac97_patch.c - 1.11 linux/net/llc/af_llc.c - 1.10 linux/include/linux/cpufreq.h - 1.18 linux/arch/i386/kernel/cpu/cpufreq/p4-clockmod.c - 1.14 linux/arch/i386/kernel/cpu/cpufreq/Makefile - 1.8 linux/sound/usb/usbquirks.h - 1.11 linux/sound/usb/usbmixer.c - 1.10 linux/sound/usb/usbaudio.c - 1.15 linux/sound/pci/via82xx.c - 1.14 linux/net/x25/x25_proc.c - 1.5 linux/net/llc/llc_proc.c - 1.10 linux/net/ipx/ipx_proc.c - 1.6 linux/drivers/usb/misc/usbtest.c - 1.17 linux/drivers/i2c/scx200_acb.c - 1.6 linux/drivers/i2c/scx200_i2c.c - 1.5 linux/drivers/scsi/aacraid/README - 1.3 linux/net/bluetooth/bnep/netdev.c - 1.4 linux/net/bluetooth/rfcomm/tty.c - 1.11 linux/net/bluetooth/rfcomm/sock.c - 1.14 linux/net/bluetooth/rfcomm/core.c - 1.13 linux/net/bluetooth/bnep/sock.c - 1.8 linux/net/bluetooth/bnep/core.c - 1.12 linux/net/bluetooth/bnep/bnep.h - 1.4 linux/include/sound/sscape_ioctl.h - 1.3 linux/net/appletalk/atalk_proc.c - 1.7 linux/drivers/net/irda/donauboe.c - 1.8 linux/fs/nfsd/nfs4xdr.c - 1.16 linux/fs/nfsd/nfs4proc.c - 1.11 linux/drivers/isdn/hardware/eicon/xdi_adapter.h - 1.3 linux/net/sunrpc/cache.c - 1.10 linux/include/asm-i386/timer.h - 1.7 linux/drivers/isdn/hardware/eicon/um_idi.c - 1.4 linux/drivers/isdn/hardware/eicon/s_pri.c - 1.3 linux/drivers/isdn/hardware/eicon/s_bri.c - 1.3 linux/arch/i386/kernel/timers/Makefile - 1.8 linux/arch/i386/kernel/timers/timer_cyclone.c - 1.7 linux/arch/i386/kernel/timers/timer_tsc.c - 1.17 linux/drivers/isdn/hardware/eicon/s_4bri.c - 1.3 linux/drivers/isdn/hardware/eicon/platform.h - 1.4 linux/drivers/isdn/hardware/eicon/os_pri.c - 1.3 linux/drivers/isdn/hardware/eicon/os_bri.c - 1.3 linux/drivers/isdn/hardware/eicon/Makefile - 1.5 linux/drivers/isdn/hardware/eicon/os_4bri.c - 1.3 linux/drivers/isdn/hardware/eicon/mntfunc.c - 1.3 linux/drivers/isdn/hardware/eicon/message.c - 1.3 linux/drivers/isdn/hardware/eicon/io.h - 1.3 linux/drivers/isdn/hardware/eicon/io.c - 1.3 linux/drivers/isdn/hardware/eicon/idifunc.c - 1.3 linux/drivers/isdn/hardware/eicon/i4lididrv.c - 1.8 linux/arch/ppc/kernel/asm-offsets.c - 1.5 linux/drivers/isdn/hardware/eicon/capifunc.c - 1.6 linux/drivers/isdn/hardware/eicon/capifunc.h - 1.3 linux/drivers/isdn/hardware/eicon/dlist.h - 1.3 linux/drivers/isdn/hardware/eicon/dlist.c - 1.3 linux/include/linux/nfs4.h - 1.6 linux/include/linux/nfsd/xdr4.h - 1.9 linux/arch/ppc/platforms/4xx/Makefile - 1.6 linux/arch/ppc/platforms/4xx/ash.c - 1.5 linux/arch/ppc/platforms/4xx/cedar.c - 1.5 linux/arch/ppc/platforms/4xx/cedar.h - 1.6 linux/arch/ppc/platforms/4xx/cpci405.c - 1.3 linux/arch/ppc/platforms/4xx/ep405.c - 1.6 linux/arch/ppc/platforms/4xx/ibmstb3.h - 1.6 linux/arch/ppc/platforms/4xx/redwood.h - 1.7 linux/arch/ppc/platforms/4xx/walnut.c - 1.7 linux/drivers/isdn/hardware/eicon/capimain.c - 1.6 linux/drivers/isdn/hardware/eicon/dadapter.c - 1.3 linux/drivers/isdn/hardware/eicon/debug.c - 1.2 linux/drivers/isdn/hardware/eicon/divasfunc.c - 1.4 linux/drivers/isdn/hardware/eicon/divasproc.c - 1.4 linux/drivers/isdn/hardware/eicon/divasmain.c - 1.10 linux/drivers/isdn/hardware/eicon/divasi.c - 1.7 linux/drivers/isdn/hardware/eicon/diva_didd.c - 1.5 linux/drivers/isdn/hardware/eicon/divamnt.c - 1.7 linux/drivers/isdn/hardware/eicon/divacapi.h - 1.2 linux/drivers/isdn/hardware/eicon/diva_pci.h - 1.3 linux/drivers/isdn/hardware/eicon/debuglib.c - 1.2 linux/drivers/isdn/hardware/eicon/debuglib.h - 1.2 linux/drivers/isdn/hardware/eicon/di.c - 1.3 linux/drivers/isdn/hardware/eicon/diddfunc.c - 1.3 linux/drivers/isdn/hardware/eicon/diva.c - 1.5 linux/fs/nfs/nfs4xdr.c - 1.9 linux/fs/afs/mount.h - 1.2 linux/net/rxrpc/transport.c - 1.4 linux/net/rxrpc/sysctl.c - 1.5 linux/net/rxrpc/proc.c - 1.4 linux/net/rxrpc/peer.c - 1.3 linux/net/rxrpc/main.c - 1.4 linux/net/rxrpc/krxtimod.c - 1.8 linux/net/rxrpc/krxsecd.c - 1.7 linux/net/rxrpc/krxiod.c - 1.6 linux/net/rxrpc/internal.h - 1.5 linux/fs/afs/Makefile - 1.4 linux/fs/afs/cache-layout.h - 1.2 linux/fs/afs/callback.c - 1.3 linux/net/rxrpc/connection.c - 1.4 linux/net/rxrpc/call.c - 1.4 linux/net/rxrpc/Makefile - 1.6 linux/fs/afs/cell.c - 1.2 linux/fs/afs/cell.h - 1.2 linux/fs/afs/cmservice.c - 1.6 linux/fs/afs/dir.c - 1.6 linux/fs/afs/file.c - 1.4 linux/fs/afs/inode.c - 1.5 linux/include/rxrpc/call.h - 1.3 linux/fs/afs/internal.h - 1.6 linux/include/rxrpc/connection.h - 1.2 linux/include/rxrpc/message.h - 1.2 linux/include/rxrpc/packet.h - 1.2 linux/include/rxrpc/peer.h - 1.3 linux/fs/afs/kafsasyncd.c - 1.6 linux/fs/afs/kafstimod.c - 1.8 linux/include/rxrpc/rxrpc.h - 1.2 linux/include/rxrpc/transport.h - 1.2 linux/fs/afs/main.c - 1.4 linux/fs/afs/mntpt.c - 1.4 linux/include/rxrpc/types.h - 1.2 linux/fs/afs/vnode.c - 1.3 linux/fs/afs/vnode.h - 1.4 linux/fs/afs/volume.c - 1.3 linux/arch/i386/oprofile/nmi_int.c - 1.14 linux/arch/x86_64/kernel/pci-gart.c - 1.15 linux/fs/afs/volume.h - 1.3 linux/fs/afs/super.c - 1.5 linux/fs/afs/vlclient.h - 1.2 linux/arch/x86_64/kernel/reboot.c - 1.7 linux/fs/afs/vlocation.c - 1.2 linux/fs/afs/server.c - 1.2 linux/fs/intermezzo/journal_tmpfs.c - 1.3 linux/fs/afs/super.h - 1.2 linux/fs/afs/types.h - 1.2 linux/fs/afs/vlclient.c - 1.4 linux/arch/ppc/boot/simple/misc.c - 1.8 linux/include/asm-i386/edd.h - 1.6 linux/arch/x86_64/mm/pageattr.c - 1.6 linux/drivers/pnp/pnpbios/core.c - 1.16 linux/scripts/Makefile.clean - 1.6 linux/arch/ppc/boot/simple/relocate.S - 1.5 linux/drivers/pnp/resource.c - 1.15 linux/net/bluetooth/bnep/Makefile.lib - 1.2 linux/arch/ppc/platforms/pal4.h - 1.4 linux/arch/i386/kernel/edd.c - 1.8 linux/drivers/pnp/isapnp/proc.c - 1.5 linux/arch/ppc/platforms/pal4_pci.c - 1.5 linux/arch/ppc/platforms/pal4_serial.h - 1.4 linux/arch/ppc/platforms/pal4_setup.c - 1.6 linux/drivers/pnp/isapnp/core.c - 1.17 linux/drivers/pnp/pnpbios/proc.c - 1.5 linux/drivers/net/Kconfig - 1.21 linux/drivers/net/appletalk/Kconfig - 1.4 linux/drivers/net/arcnet/Kconfig - 1.5 linux/drivers/net/hamradio/Kconfig - 1.6 linux/drivers/net/irda/Kconfig - 1.10 linux/drivers/message/i2o/Kconfig - 1.5 linux/drivers/net/pcmcia/Kconfig - 1.7 linux/drivers/net/tokenring/Kconfig - 1.8 linux/arch/alpha/Kconfig - 1.20 linux/drivers/message/fusion/Kconfig - 1.3 linux/arch/arm/Kconfig - 1.20 linux/drivers/net/tulip/Kconfig - 1.7 linux/drivers/md/dm-linear.c - 1.6 linux/arch/cris/Kconfig - 1.13 linux/include/linux/eventpoll.h - 1.10 linux/arch/i386/Kconfig - 1.29 linux/drivers/net/wan/Kconfig - 1.9 linux/net/bridge/netfilter/Kconfig - 1.6 linux/net/irda/irlan/Kconfig - 1.3 linux/drivers/media/video/Kconfig - 1.10 linux/drivers/net/wireless/Kconfig - 1.10 linux/drivers/media/radio/Kconfig - 1.3 linux/drivers/parport/Kconfig - 1.5 linux/scripts/kconfig/conf.c - 1.6 linux/arch/ia64/Kconfig - 1.19 linux/scripts/kconfig/Makefile - 1.8 linux/scripts/Makefile.lib - 1.8 linux/sound/oss/dmasound/Kconfig - 1.3 linux/scripts/Makefile.build - 1.13 linux/arch/ia64/mm/discontig.c - 1.5 linux/drivers/char/Kconfig - 1.13 linux/include/asm-parisc/cacheflush.h - 1.5 linux/arch/m68k/Kconfig - 1.18 linux/include/linux/netfilter_ipv4/ipt_physdev.h - 1.3 linux/arch/mips/Kconfig - 1.14 linux/include/asm-ia64/numa.h - 1.4 linux/arch/parisc/Kconfig - 1.16 linux/drivers/media/dvb/dvb-core/Kconfig - 1.3 linux/drivers/pcmcia/Kconfig - 1.6 linux/fs/partitions/Kconfig - 1.4 linux/drivers/media/Kconfig - 1.5 linux/drivers/pnp/isapnp/compat.c - 1.4 linux/drivers/s390/Kconfig - 1.6 linux/arch/parisc/kernel/sys_parisc32.c - 1.15 linux/drivers/sbus/char/Kconfig - 1.2 linux/drivers/md/dm.c - 1.12 linux/drivers/md/dm-table.c - 1.11 linux/drivers/md/dm-stripe.c - 1.7 linux/drivers/fc4/Kconfig - 1.3 linux/drivers/cdrom/Kconfig - 1.5 linux/drivers/scsi/Kconfig - 1.17 linux/drivers/isdn/sc/Kconfig - 1.3 linux/drivers/char/agp/Kconfig - 1.13 linux/arch/ppc/Kconfig - 1.19 linux/drivers/char/drm/Kconfig - 1.7 linux/arch/ppc64/Kconfig - 1.17 linux/arch/s390/Kconfig - 1.14 linux/arch/sh/Kconfig - 1.15 linux/arch/sparc/Kconfig - 1.17 linux/net/ipv4/netfilter/Kconfig - 1.7 linux/drivers/scsi/pcmcia/Kconfig - 1.7 linux/drivers/i2c/Kconfig - 1.10 linux/drivers/input/joystick/Kconfig - 1.3 linux/arch/sparc64/Kconfig - 1.22 linux/drivers/ide/Kconfig - 1.17 linux/drivers/block/Kconfig - 1.8 linux/drivers/input/joystick/iforce/Kconfig - 1.3 linux/drivers/input/gameport/Kconfig - 1.3 linux/drivers/usb/host/Kconfig - 1.4 linux/arch/x86_64/Kconfig - 1.22 linux/sound/pci/Kconfig - 1.6 linux/fs/Kconfig - 1.16 linux/drivers/input/Kconfig - 1.5 linux/drivers/input/keyboard/Kconfig - 1.6 linux/drivers/ieee1394/Kconfig - 1.4 linux/lib/Kconfig - 1.4 linux/crypto/Kconfig - 1.10 linux/drivers/usb/image/Kconfig - 1.4 linux/net/ipv4/netfilter/ipt_physdev.c - 1.8 linux/net/Kconfig - 1.12 linux/drivers/input/misc/Kconfig - 1.6 linux/net/ipv6/netfilter/Kconfig - 1.4 linux/drivers/input/mouse/Kconfig - 1.8 linux/net/bluetooth/bnep/Kconfig - 1.4 linux/drivers/serial/Kconfig - 1.14 linux/drivers/telephony/Kconfig - 1.4 linux/drivers/acpi/Kconfig - 1.11 linux/drivers/video/Kconfig - 1.13 linux/net/sched/Kconfig - 1.5 linux/drivers/isdn/hardware/eicon/Kconfig - 1.2 linux/drivers/usb/storage/Kconfig - 1.4 linux/drivers/atm/Kconfig - 1.6 linux/drivers/usb/serial/Kconfig - 1.8 linux/drivers/usb/misc/Kconfig - 1.6 linux/drivers/usb/Kconfig - 1.4 linux/sound/oss/Kconfig - 1.12 linux/drivers/usb/net/Kconfig - 1.7 linux/drivers/usb/class/Kconfig - 1.7 linux/net/ax25/Kconfig - 1.4 linux/drivers/char/ftape/Kconfig - 1.3 linux/drivers/usb/input/Kconfig - 1.7 linux/drivers/input/serio/Kconfig - 1.9 linux/init/Kconfig - 1.15 linux/drivers/usb/media/Kconfig - 1.4 linux/drivers/input/touchscreen/Kconfig - 1.3 linux/usr/gen_init_cpio.c - 1.5 linux/fs/hugetlbfs/inode.c - 1.16 linux/fs/eventpoll.c - 1.13 linux/mm/fremap.c - 1.10 linux/init/initramfs.c - 1.3 linux/drivers/parisc/wax.c - 1.4 linux/drivers/parisc/sba_iommu.c - 1.6 linux/drivers/parisc/led.c - 1.8 linux/drivers/parisc/lba_pci.c - 1.6 linux/drivers/parisc/lasi.c - 1.4 linux/drivers/parisc/iosapic.c - 1.5 linux/drivers/parisc/eisa.c - 1.9 linux/drivers/parisc/dino.c - 1.8 linux/drivers/parisc/ccio-dma.c - 1.8 linux/drivers/parisc/asp.c - 1.4 linux/include/linux/hugetlb.h - 1.11 linux/include/asm-v850/signal.h - 1.4 linux/include/asm-m68knommu/processor.h - 1.4 linux/include/asm-m68knommu/signal.h - 1.4 linux/arch/m68knommu/Kconfig - 1.17 linux/arch/m68knommu/kernel/signal.c - 1.8 linux/include/asm-v850/processor.h - 1.7 linux/include/asm-v850/posix_types.h - 1.3 linux/include/asm-v850/mman.h - 1.2 linux/arch/v850/Kconfig - 1.17 linux/arch/ppc/syslib/pplus_common.c - 1.4 linux/arch/ppc/syslib/prep_nvram.c - 1.2 linux/drivers/net/irda/sir_kthread.c - 1.8 linux/arch/ppc/syslib/todc_time.c - 1.6 linux/arch/ppc/syslib/prom_init.c - 1.6 linux/arch/ppc/syslib/prom.c - 1.5 linux/arch/ppc/syslib/ppc8xx_pic.c - 1.3 linux/arch/ppc/syslib/ppc4xx_serial.c - 1.4 linux/arch/ppc/syslib/ppc4xx_pic.c - 1.3 linux/arch/ppc/syslib/ppc405_pci.c - 1.5 linux/arch/ppc/syslib/pci_auto.c - 1.4 linux/arch/ppc/syslib/open_pic.c - 1.9 linux/arch/ppc/syslib/mpc10x_common.c - 1.6 linux/arch/ppc/syslib/m8xx_setup.c - 1.3 linux/arch/ppc/syslib/m8260_setup.c - 1.4 linux/arch/ppc/syslib/i8259.c - 1.3 linux/arch/ppc/syslib/harrier.c - 1.4 linux/arch/ppc/syslib/gt64260_pic.c - 1.4 linux/arch/ppc/syslib/gt64260_common.c - 1.4 linux/arch/ppc/syslib/cpc710.h - 1.5 linux/arch/ppc/syslib/cpc700_pic.c - 1.4 linux/arch/ppc/syslib/cpc700.h - 1.4 linux/arch/ppc/syslib/btext.c - 1.2 linux/drivers/s390/net/cu3088.c - 1.6 linux/drivers/scsi/scsi_sysfs.c - 1.15 linux/arch/i386/kernel/suspend_asm.S - 1.5 linux/drivers/pnp/card.c - 1.8 linux/drivers/s390/char/sclp.c - 1.6 linux/drivers/s390/char/sclp.h - 1.3 linux/drivers/s390/char/sclp_cpi.c - 1.3 linux/drivers/s390/char/sclp_tty.c - 1.9 linux/drivers/s390/char/tape_block.c - 1.8 linux/Documentation/s390/driver-model.txt - 1.4 linux/Documentation/scsi/scsi_mid_low_api.txt - 1.6 linux/drivers/s390/char/tape_char.c - 1.5 linux/arch/sparc64/kernel/module.c - 1.7 linux/drivers/video/console/Kconfig - 1.7 linux/drivers/char/agp/backend.c - 1.10 linux/crypto/proc.c - 1.4 linux/fs/compat.c - 1.11 linux/drivers/s390/cio/ccwgroup.c - 1.5 linux/drivers/s390/cio/css.c - 1.4 linux/drivers/s390/cio/css.h - 1.4 linux/drivers/s390/cio/device.c - 1.8 linux/drivers/s390/cio/device.h - 1.6 linux/drivers/s390/cio/device_fsm.c - 1.7 linux/drivers/s390/cio/device_id.c - 1.4 linux/drivers/char/agp/intel-agp.c - 1.13 linux/drivers/s390/cio/device_ops.c - 1.6 linux/drivers/s390/cio/device_status.c - 1.4 linux/drivers/s390/cio/qdio.c - 1.8 linux/arch/s390/kernel/module.c - 1.9 linux/drivers/s390/cio/qdio.h - 1.6 linux/drivers/char/watchdog/Kconfig - 1.8 linux/drivers/s390/net/lcs.h - 1.2 linux/arch/ppc/kernel/module.c - 1.7 linux/drivers/ieee1394/oui.db - 1.2 linux/drivers/char/watchdog/i810-tco.c - 1.7 linux/fs/intermezzo/intermezzo_psdev.h - 1.3 linux/drivers/ide/ide-io.c - 1.15 linux/drivers/char/watchdog/wdt_pci.c - 1.10 linux/arch/arm/mm/tlb-v4wbi.S - 1.2 linux/arch/x86_64/oprofile/Makefile - 1.4 linux/Documentation/sound/alsa/ALSA-Configuration.txt - 1.8 linux/drivers/i2c/busses/Kconfig - 1.10 linux/drivers/i2c/busses/Makefile - 1.8 linux/drivers/i2c/busses/i2c-amd756.c - 1.7 linux/drivers/i2c/busses/i2c-amd8111.c - 1.8 linux/drivers/i2c/chips/Kconfig - 1.8 linux/drivers/i2c/chips/Makefile - 1.7 linux/drivers/i2c/chips/adm1021.c - 1.11 linux/drivers/i2c/chips/lm75.c - 1.9 linux/drivers/scsi/aic7xxx/Kconfig.aic7xxx - 1.4 linux/include/asm-i386/mach-summit/mach_apic.h - 1.10 linux/include/asm-i386/mach-numaq/mach_apic.h - 1.9 linux/include/asm-i386/mach-default/mach_apic.h - 1.8 linux/drivers/video/i810/i810_main.c - 1.9 linux/drivers/video/i810/i810_main.h - 1.7 linux/include/asm-ppc/ocp_ids.h - 1.2 linux/drivers/scsi/zalon.h - 1.4 linux/drivers/scsi/zalon.c - 1.6 linux/arch/ppc/kernel/idle_6xx.S - 1.2 linux/arch/ppc/platforms/4xx/Kconfig - 1.4 linux/arch/ppc/platforms/4xx/beech.c - 1.3 linux/arch/ppc/platforms/4xx/beech.h - 1.2 linux/arch/ppc/platforms/4xx/ibm405lp.c - 1.2 linux/arch/ppc/platforms/4xx/ibm405lp.h - 1.2 linux/arch/ppc/syslib/ppc4xx_dma.c - 1.4 linux/arch/ppc/platforms/4xx/sycamore.c - 1.5 linux/arch/ppc/platforms/4xx/oak_setup.c - 1.3 linux/arch/ppc/platforms/4xx/redwood6.c - 1.4 linux/include/asm-i386/mach-bigsmp/mach_apic.h - 1.8 linux/drivers/parisc/hppb.c - 1.2 linux/arch/parisc/kernel/module.c - 1.7 linux/arch/ppc/ocp/ocp-probe.c - 1.3 linux/arch/ppc/ocp/ocp-driver.c - 1.2 linux/include/linux/eisa.h - 1.7 linux/drivers/eisa/eisa-bus.c - 1.9 linux/arch/ppc/ocp/ocp.c - 1.2 linux/include/asm-arm/arch-sa1100/trizeps.h - 1.2 linux/drivers/usb/net/Makefile.mii - 1.4 linux/mm/fadvise.c - 1.7 linux/Documentation/sound/alsa/OSS-Emulation.txt - 1.3 linux/arch/arm/mach-sa1100/trizeps.c - 1.2 linux/arch/i386/kernel/cpu/cpufreq/acpi.c - 1.8 linux/arch/ia64/kernel/fsys.S - 1.8 linux/arch/arm/mach-sa1100/hackkit.c - 1.3 linux/arch/arm/common/sa1111-pcipool.c - 1.4 linux/arch/arm/common/sa1111.c - 1.11 linux/arch/arm/def-configs/hackkit - 1.2 linux/arch/arm/def-configs/trizeps - 1.3 linux/scripts/modpost.c - 1.8 linux/scripts/Makefile.modpost - 1.5 linux/drivers/char/agp/alpha-agp.c - 1.4 linux/arch/i386/kernel/cpu/cpufreq/powernow-k7.c - 1.11 linux/drivers/acpi/sleep/sleep.h - 1.2 linux/drivers/acpi/sleep/proc.c - 1.4 linux/drivers/acpi/sleep/main.c - 1.7 linux/drivers/net/tokenring/proteon.c - 1.5 linux/drivers/net/tokenring/skisa.c - 1.5 linux/drivers/net/wireless/arlan.c - 1.5 linux/drivers/net/wireless/arlan-proc.c - 1.3 linux/drivers/net/wireless/arlan.h - 1.3 linux/drivers/net/wireless/ray_cs.c - 1.7 linux/drivers/net/wireless/strip.c - 1.6 linux/drivers/s390/net/Kconfig - 1.4 linux/arch/i386/kernel/cpu/cpufreq/Kconfig - 1.5 linux/kernel/posix-timers.c - 1.12 linux/include/asm-i386/mach-visws/mach_apic.h - 1.5 linux/drivers/char/watchdog/amd7xx_tco.c - 1.4 linux/fs/sysfs/dir.c - 1.6 linux/fs/sysfs/file.c - 1.8 linux/arch/i386/kernel/srat.c - 1.4 linux/init/do_mounts_md.c - 1.2 linux/init/do_mounts.h - 1.5 linux/init/do_mounts_devfs.c - 1.3 linux/init/do_mounts_rd.c - 1.6 linux/fs/sysfs/sysfs.h - 1.3 linux/include/asm-i386/srat.h - 1.3 linux/drivers/i2c/busses/i2c-ali15x3.c - 1.7 linux/arch/ia64/sn/io/sn2/ml_iograph.c - 1.3 linux/drivers/char/hw_random.c - 1.5 linux/arch/ia64/sn/io/sn2/pciio.c - 1.4 linux/arch/ia64/sn/io/sn2/pic.c - 1.3 linux/arch/ia64/sn/io/sn2/Makefile - 1.5 linux/arch/ia64/sn/io/sn2/shub.c - 1.6 linux/drivers/i2c/busses/i2c-piix4.c - 1.7 linux/drivers/i2c/busses/i2c-i801.c - 1.7 linux/arch/ia64/sn/io/sn2/xbow.c - 1.3 linux/sound/pci/ice1712/revo.c - 1.3 linux/sound/pci/ice1712/ice1724.c - 1.6 linux/sound/isa/cs423x/pc98.c - 1.3 linux/sound/core/memalloc.c - 1.6 linux/arch/ppc/platforms/tqm8260_setup.c - 1.2 linux/drivers/net/ne2k_cbus.c - 1.2 linux/arch/i386/boot98/compressed/misc.c - 1.2 linux/arch/ppc/platforms/mpc82xx.h - 1.2 linux/arch/ppc/platforms/est8260_setup.c - 1.2 linux/drivers/ide/ide-default.c - 1.3 linux/net/ipv6/anycast.c - 1.6 linux/drivers/i2c/busses/i2c-isa.c - 1.5 linux/drivers/usb/misc/speedtch.c - 1.7 linux/net/xfrm/xfrm_user.c - 1.10 linux/drivers/char/drm/i830_irq.c - 1.4 linux/Documentation/i2c/sysfs-interface - 1.2 linux/drivers/pcmcia/sa11xx_core.c - 1.7 linux/drivers/i2c/chips/via686a.c - 1.6 linux/drivers/i2c/chips/w83781d.c - 1.8 linux/drivers/i2c/i2c-sensor.c - 1.3 linux/net/ipv4/netfilter/ip_nat_amanda.c - 1.5 linux/net/ipv4/netfilter/ip_nat_tftp.c - 1.5 linux/arch/ppc/platforms/pmac_cpufreq.c - 1.7 linux/arch/ppc/platforms/pmac_sleep.S - 1.3 linux/arch/s390/kernel/compat_ioctl.c - 1.7 linux/arch/s390/kernel/compat_linux.c - 1.5 linux/drivers/media/dvb/dvb-core/Makefile.lib - 1.2 linux/include/sound/hdsp.h - 1.4 linux/drivers/media/dvb/ttpci/Kconfig - 1.2 linux/arch/arm/def-configs/iq80321 - 1.4 linux/include/linux/nfsd/state.h - 1.6 linux/drivers/i2c/i2c-keywest.h - 1.3 linux/drivers/i2c/i2c-keywest.c - 1.5 linux/include/asm-arm/arch-iop3xx/irqs.h - 1.2 linux/drivers/i2c/busses/i2c-viapro.c - 1.5 linux/arch/arm/mach-iop3xx/mm-321.c - 1.3 linux/arch/h8300/Kconfig - 1.8 linux/arch/h8300/kernel/h8300_ksyms.c - 1.2 linux/arch/h8300/kernel/ptrace.c - 1.3 linux/arch/h8300/kernel/signal.c - 1.4 linux/fs/nfsd/nfs4state.c - 1.7 linux/include/asm-arm/arch-iop3xx/iop321-irqs.h - 1.2 linux/include/asm-h8300/stat.h - 1.2 linux/include/asm-h8300/signal.h - 1.2 linux/arch/s390/kernel/compat_signal.c - 1.2 linux/arch/s390/kernel/entry64.S - 1.5 linux/arch/s390/kernel/head64.S - 1.4 linux/include/asm-h8300/processor.h - 1.5 linux/include/asm-h8300/posix_types.h - 1.2 linux/include/asm-h8300/mman.h - 1.2 linux/arch/arm/mm/proc-sa1100.S - 1.3 linux/include/linux/compat_ioctl.h - 1.7 linux/arch/arm/mm/cache-v4wt.S - 1.2 linux/drivers/i2c/chips/it87.c - 1.4 linux/init/do_mounts_initrd.c - 1.3 linux/arch/arm/mm/cache-v4wb.S - 1.2 linux/drivers/char/drm/drm_memory_debug.h - 1.4 linux/arch/arm/mm/cache-v3.S - 1.2 linux/arch/arm/mm/cache-v4.S - 1.2 linux/include/linux/usb_gadget.h - 1.5 linux/drivers/net/arm/Kconfig - 1.2 linux/drivers/char/agp/uninorth-agp.c - 1.3 linux/include/asm-i386/genapic.h - 1.4 linux/include/asm-i386/mach-generic/mach_apic.h - 1.4 linux/include/linux/pci-dynids.h - 1.2 linux/drivers/net/arm/ether00.c - 1.5 linux/drivers/net/bonding/bond_3ad.c - 1.3 linux/drivers/net/bonding/bond_3ad.h - 1.2 linux/drivers/net/bonding/bond_alb.c - 1.2 linux/drivers/net/bonding/bond_alb.h - 1.2 linux/dev/null - 1.9 linux/drivers/net/bonding/bond_main.c - 1.5 linux/drivers/net/bonding/bonding.h - 1.3 linux/drivers/usb/gadget/ether.c - 1.5 linux/drivers/usb/gadget/Kconfig - 1.3 linux/drivers/atm/he.c - 1.7 linux/drivers/i2c/busses/i2c-sis96x.c - 1.3 linux/drivers/scsi/scsi_priv.h - 1.7 linux/drivers/char/agp/nvidia-agp.c - 1.6 linux/drivers/scsi/arm/fas216.c - 1.6 linux/include/asm-ppc/agp.h - 1.2 linux/net/atm/br2684.c - 1.6 linux/net/core/net-sysfs.c - 1.7 linux/Documentation/DocBook/gadget.tmpl - 1.3 linux/sound/pcmcia/vx/vx_entry.c - 1.3 linux/drivers/mtd/mtd_blkdevs.c - 1.6 linux/arch/arm/mach-integrator/core.c - 1.3 linux/drivers/net/wireless/atmel.c - 1.4 linux/drivers/net/wireless/atmel_cs.c - 1.4 linux/drivers/pci/hotplug/Kconfig - 1.4 linux/drivers/pci/hotplug/acpiphp.h - 1.3 linux/drivers/pci/hotplug/acpiphp_core.c - 1.4 linux/drivers/pci/hotplug/acpiphp_glue.c - 1.5 linux/drivers/pci/hotplug/acpiphp_pci.c - 1.4 linux/drivers/pci/hotplug/acpiphp_res.c - 1.3 linux/drivers/pci/hotplug/cpci_hotplug.h - 1.3 linux/drivers/pci/hotplug/cpci_hotplug_core.c - 1.4 linux/drivers/pci/hotplug/cpci_hotplug_pci.c - 1.4 linux/arch/arm26/Kconfig - 1.8 linux/arch/arm26/boot/compressed/misc.c - 1.2 linux/arch/arm26/kernel/entry.S - 1.3 linux/arch/arm26/kernel/setup.c - 1.5 linux/include/asm-arm26/signal.h - 1.2 linux/drivers/pci/hotplug/cpqphp.h - 1.2 linux/drivers/pci/hotplug/cpqphp_core.c - 1.5 linux/drivers/pci/hotplug/cpqphp_ctrl.c - 1.2 linux/drivers/pci/hotplug/cpqphp_nvram.c - 1.3 linux/drivers/i2c/i2c-iop3xx.h - 1.2 linux/drivers/i2c/i2c-iop3xx.c - 1.2 linux/sound/pci/ice1712/aureon.c - 1.3 linux/drivers/pci/hotplug/cpqphp_nvram.h - 1.2 linux/drivers/pci/hotplug/cpqphp_pci.c - 1.3 linux/drivers/pci/hotplug/cpqphp_sysfs.c - 1.2 linux/drivers/i2c/chips/lm85.c - 1.4 linux/drivers/pci/hotplug/ibmphp.h - 1.3 linux/drivers/pci/hotplug/ibmphp_core.c - 1.4 linux/drivers/pci/hotplug/ibmphp_ebda.c - 1.4 linux/drivers/pci/hotplug/ibmphp_hpc.c - 1.3 linux/drivers/pci/hotplug/ibmphp_pci.c - 1.2 linux/drivers/pci/hotplug/ibmphp_res.c - 1.3 linux/drivers/pci/hotplug/pci_hotplug.h - 1.3 linux/drivers/pci/hotplug/pci_hotplug_core.c - 1.3 linux/drivers/pci/hotplug/pcihp_skeleton.c - 1.3 linux/sound/i2c/other/ak4xxx-adda.c - 1.3 linux/fs/compat_ioctl.c - 1.6 linux/include/asm-arm26/hardirq.h - 1.2 linux/include/asm-arm26/stat.h - 1.2 linux/include/asm-arm26/softirq.h - 1.2 linux/sound/isa/sscape.c - 1.3 linux/include/asm-arm26/processor.h - 1.4 linux/include/asm-arm26/posix_types.h - 1.2 linux/include/asm-arm26/mman.h - 1.2 linux/drivers/input/mouse/synaptics.h - 1.3 linux/drivers/input/mouse/synaptics.c - 1.3 linux/drivers/input/mouse/psmouse.h - 1.3 linux/drivers/input/mouse/psmouse-base.c - 1.3 linux/arch/ia64/sn/io/sn2/kdba_io.c - 1.2 linux/arch/ia64/sn/io/machvec/pci_dma.c - 1.4 linux/arch/ia64/sn/io/machvec/pci_bus_cvlink.c - 1.3 linux/arch/ia64/sn/io/machvec/pci.c - 1.4 linux/arch/ia64/sn/io/machvec/iomv.c - 1.4 linux/drivers/i2c/chips/lm78.c - 1.3 linux/drivers/pcmcia/yenta_socket.c - 1.8 linux/drivers/usb/net/ax8817x.c - 1.5 linux/fs/Kconfig.binfmt - 1.4 linux/arch/ia64/sn/io/hwgfs/invent_stub.c - 1.2 linux/arch/ia64/sn/io/hwgfs/hcl.c - 1.4 linux/arch/ia64/sn/io/hwgfs/Makefile - 1.2 linux/arch/ia64/sn/io/drivers/ioconfig_bus.c - 1.3 linux/arch/ia64/scripts/toolchain-flags - 1.4 linux/include/scsi/scsi_tcq.h - 1.2 linux/include/scsi/scsi_host.h - 1.4 linux/include/scsi/scsi_device.h - 1.6 linux/include/scsi/scsi_cmnd.h - 1.3 linux/arch/ia64/ia32/ia32priv.h - 1.4 linux/drivers/i2c/i2c-prosavage.c - 1.3 linux/drivers/i2c/busses/i2c-ali1535.c - 1.3 linux/drivers/pci/hotplug/fakephp.c - 1.2 linux/drivers/s390/net/qeth.c - 1.4 linux/drivers/s390/net/qeth.h - 1.3 linux/drivers/scsi/NCR_Q720.c - 1.4 linux/arch/mips/sgi-ip22/ip22-eisa.c - 1.2 linux/drivers/block/as-iosched.c - 1.7 linux/arch/ppc/syslib/gen550_kgdb.c - 1.2 linux/arch/cris/arch-v10/boot/compressed/misc.c - 1.2 linux/net/ipv4/ipvs/ip_vs_sched.c - 1.3 linux/net/ipv4/ipvs/ip_vs_ctl.c - 1.5 linux/net/ipv4/ipvs/ip_vs_conn.c - 1.4 linux/net/ipv4/ipvs/ip_vs_app.c - 1.2 linux/sound/oss/forte.c - 1.5 linux/net/ipv4/ipvs/Kconfig - 1.5 linux/net/ipv4/ipvs/ip_vs_proto_tcp.c - 1.2 linux/net/ipv4/ipvs/ip_vs_nq.c - 1.2 linux/net/ipv4/ipvs/ip_vs_lc.c - 1.2 linux/net/ipv4/ipvs/ip_vs_lblc.c - 1.3 linux/net/ipv4/ipvs/ip_vs_proto_udp.c - 1.2 linux/net/ipv4/ipvs/ip_vs_wrr.c - 1.2 linux/net/ipv4/ipvs/ip_vs_rr.c - 1.2 linux/net/ipv4/ipvs/ip_vs_wlc.c - 1.2 linux/net/ipv4/ipvs/ip_vs_lblcr.c - 1.3 linux/net/ipv4/ipvs/ip_vs_sync.c - 1.3 linux/net/ipv4/ipvs/ip_vs_sed.c - 1.2 linux/drivers/md/dm-ioctl-v1.c - 1.4 linux/drivers/net/wireless/wl3501_cs.c - 1.4 linux/drivers/md/dm-ioctl-v4.c - 1.4 linux/include/linux/dm-ioctl-v1.h - 1.2 linux/sound/pci/ac97/ac97_proc.c - 1.2 linux/sound/pci/ac97/ac97_local.h - 1.2 linux/security/selinux/ss/policydb.c - 1.4 linux/security/selinux/ss/mls.c - 1.2 linux/security/selinux/selinuxfs.c - 1.3 linux/drivers/i2c/busses/i2c-nforce2.c - 1.3 linux/security/selinux/include/security.h - 1.2 linux/security/selinux/hooks.c - 1.4 linux/security/selinux/Kconfig - 1.3 linux/drivers/net/irda/via-ircc.c - 1.3 linux/drivers/net/sk98lin/skdim.c - 1.2 linux/arch/alpha/boot/misc.c - 1.2 linux/arch/ia64/ia32/elfcore32.h - 1.2 linux/scripts/mkconfigs - 1.3 linux/drivers/pnp/pnpbios/bioscalls.c - 1.2 linux/drivers/pnp/pnpbios/pnpbios.h - 1.2 linux/kernel/power/swsusp.c - 1.3 linux/kernel/power/power.h - 1.3 linux/kernel/power/console.c - 1.3 linux/kernel/power/Makefile - 1.3 linux/kernel/configs.c - 1.4 linux/arch/mips/kernel/linux32.c - 1.2 linux/drivers/char/agp/ati-agp.c - 1.3 linux/kernel/power/main.c - 1.2 linux/drivers/base/power/suspend.c - 1.2 linux/drivers/base/power/resume.c - 1.2 linux/drivers/base/power/power.h - 1.2 linux/drivers/base/power/main.c - 1.3 linux/fs/sysfs/group.c - 1.2 linux/arch/s390/kernel/vmlinux.lds.S - 1.2 linux/arch/ppc64/kernel/vmlinux.lds.S - 1.2 linux/arch/ppc/syslib/of_device.c - 1.3 linux/arch/ppc/kernel/vmlinux.lds.S - 1.2 linux/include/asm-generic/cpumask_arith.h - 1.2 linux/include/asm-generic/cpumask_array.h - 1.2 linux/include/asm-ppc/macio.h - 1.3 linux/include/asm-generic/cpumask_up.h - 1.2 linux/arch/arm/mach-integrator/Kconfig - 1.2 linux/arch/arm/mach-integrator/impd1.c - 1.3 linux/include/asm-ppc/of_device.h - 1.3 linux/arch/ia64/hp/sim/boot/boot_head.S - 1.2 linux/arch/ia64/hp/sim/boot/bootloader.c - 1.2 linux/drivers/cpufreq/cpufreq_userspace.c - 1.2 linux/arch/ppc/syslib/ibm440gp_common.h - 1.2 linux/arch/ppc/syslib/ibm440gp_common.c - 1.2 linux/arch/ppc/platforms/4xx/ibm440gx.h - 1.2 linux/drivers/cpufreq/cpufreq.c - 1.2 linux/drivers/char/watchdog/alim1535_wdt.c - 1.2 linux/drivers/char/agp/amd64-agp.c - 1.2 linux/drivers/usb/gadget/inode.c - 1.2 linux/arch/ppc/boot/of1275/map.c - 1.2 linux/include/asm-ppc/ibm44x.h - 1.2 linux/arch/ppc/platforms/4xx/ocotea.c - 1.2 linux/arch/ppc/mm/44x_mmu.c - 1.2 linux/arch/ppc/platforms/4xx/ebony.c - 1.2 linux/arch/i386/kernel/timers/timer_hpet.c - 1.2 linux/arch/ppc/kernel/head_44x.S - 1.2 From owner-linux-xfs@oss.sgi.com Mon Oct 6 15:24:29 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 06 Oct 2003 15:25:09 -0700 (PDT) Received: from mail.automatix.de (237.230.131.213.rev.inetbone.net [213.131.230.237]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h96MOQ25028386 for ; Mon, 6 Oct 2003 15:24:29 -0700 Received: from uucp by mail.automatix.de with local-bsmtp (Exim 3.35 #1) id 1A6dm9-0005ln-00 for linux-xfs@oss.sgi.com; Tue, 07 Oct 2003 00:24:21 +0200 Received: from pc2.s.automatix.de ([192.168.11.12] ident=jojo) by s.automatix.de with esmtp (Exim 3.36 #1) id 1A6dSj-0004zQ-00; Tue, 07 Oct 2003 00:04:17 +0200 From: Juergen Sauer Reply-To: juergen.sauer@automatix.de To: Steve Lord Subject: Re: NFS broken again in 2.4.22 ? Date: Tue, 7 Oct 2003 00:04:14 +0200 User-Agent: KMail/1.5.4 Cc: linux-xfs@oss.sgi.com References: <200310061305.22456.juergen.sauer@automatix.de> <1065455659.7063.1956.camel@jen.americas.sgi.com> In-Reply-To: <1065455659.7063.1956.camel@jen.americas.sgi.com> Organization: AutomatiX GmbH MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Description: clearsigned data Content-Disposition: inline Message-Id: <200310070004.14283.juergen.sauer@automatix.de> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h96MOT25028389 X-archive-position: 651 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: juergen.sauer@automatix.de Precedence: bulk X-list: linux-xfs Content-Length: 1189 Lines: 37 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am Montag, 6. Oktober 2003 17:54 schrieb Steve Lord: > > Hi! > > Since the usage of Kernal 2.4.22-xfs (CVS) on Server and Client Side > > The NFS Link throws up a "NFS Server not responding" Error, which > > dissapears at once: "NFS Server OK". > > First question is, is that specific to XFS filesystems or not? > It is quite possibly a linux NFS issue rather than an XFS one. Complicated to test. Here at this side all server are running XFS, exclusively ;->> I have no spare partition left to test on ext2/ext3. But I did not heard from other admins that this would occour. It did not occour on 2.4.21, but current ACPI and IDE Changes in 22 fored the upgrade. How can I further help to debug ? mfG Jürgen automatiX Linux Support Crew - -- Jürgen Sauer - AutomatiX GmbH, +49-4209-4699, jojo@automatix.de ** ** Das Linux Systemhaus - Service - Support - Server - Lösungen ** ** http://www.automatix.de ICQ: #344389676 ** -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/gebeW7UKI9EqarERAk30AKC7+Imrvyli/dIrnWdMNvEg0ojWGwCgv0wl nmSWuHzNq+3ahVNBvHuikok= =Ov9D -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Mon Oct 6 17:45:16 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 06 Oct 2003 17:45:57 -0700 (PDT) Received: from mail.automatix.de (237.230.131.213.rev.inetbone.net [213.131.230.237]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h970jF25009192 for ; Mon, 6 Oct 2003 17:45:16 -0700 Received: from uucp by mail.automatix.de with local-bsmtp (Exim 3.35 #1) id 1A6dm9-0005lj-00 for linux-xfs@oss.sgi.com; Tue, 07 Oct 2003 00:24:21 +0200 Received: from pc2.s.automatix.de ([192.168.11.12] ident=jojo) by s.automatix.de with esmtp (Exim 3.36 #1) id 1A6dPt-0004zF-00; Tue, 07 Oct 2003 00:01:21 +0200 From: Juergen Sauer Organization: HB! Teutonia To: Steve Lord Subject: Re: NFS broken again in 2.4.22 ? Date: Tue, 7 Oct 2003 00:01:17 +0200 User-Agent: KMail/1.5.4 Cc: linux-xfs@oss.sgi.com References: <200310061305.22456.juergen.sauer@automatix.de> <1065455659.7063.1956.camel@jen.americas.sgi.com> In-Reply-To: <1065455659.7063.1956.camel@jen.americas.sgi.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Description: clearsigned data Content-Disposition: inline Message-Id: <200310070001.17682.jojo@teutonia.org> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h970jG25009193 X-archive-position: 652 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jojo@teutonia.org Precedence: bulk X-list: linux-xfs Content-Length: 1128 Lines: 38 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am Montag, 6. Oktober 2003 17:54 schrieb Steve Lord: > On Mon, 2003-10-06 at 06:05, Juergen Sauer wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Hi! > > Since the usage of Kernal 2.4.22-xfs (CVS) on Server and Client Side > > The NFS Link throws up a "NFS Server not responding" Error, which > > dissapears at once: "NFS Server OK". > > First question is, is that specific to XFS filesystems or not? > It is quite possibly a linux NFS issue rather than an XFS one. Complicated to test. Here at this side all server are running XFS, exclusively ;->> It did not occour on 2.4.21, but current ACPI and IDE Changes in 22 fored the upgrade. mbG Jürgen "Jojo" Sauer Z! - -- Jürgen "Jojo" Sauer Z! c/o HB! Teutonia, Ludwig-Barnay Str. 3, 30175 Hannover, Tel. 0511-817615 Privat: J. Sauer, Neue Str. 11, 28790 Schwanewede, Tel. 04209-4699 Web: http://www.teutonia.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/geYtW7UKI9EqarERApFQAKDJ6c33vMdM8KyFtZ1q65gSMV+gJwCbBQeW X1kjv4kjZv69T+HtpNRKbVI= =RUpM -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Tue Oct 7 01:29:24 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 07 Oct 2003 01:30:13 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h978Sx25031851 for ; Tue, 7 Oct 2003 01:29:21 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h978Srq0016334 for ; Tue, 7 Oct 2003 01:28:53 -0700 Received: from boing.melbourne.sgi.com (localhost [127.0.0.1]) by boing.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h978SnBY1735603; Tue, 7 Oct 2003 18:28:49 +1000 (AEST) Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h978Sj5i1952030; Tue, 7 Oct 2003 18:28:45 +1000 (AEST) Date: Tue, 7 Oct 2003 18:28:44 +1000 From: Tim Shimmin To: Marcel de Riedmatten Cc: Linux xfs list Subject: Re: unable to mount filesystem Message-ID: <20031007182844.D1716630@boing.melbourne.sgi.com> References: <1065286302.20458.44.camel@galadriel> <20031006165423.Q1716630@boing.melbourne.sgi.com> <1065458813.6238.273.camel@galadriel> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <1065458813.6238.273.camel@galadriel>; from mdr@dotforge.ch on Mon, Oct 06, 2003 at 06:46:53PM +0200 X-archive-position: 653 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2680 Lines: 66 Hi Marcel, > > > > > I noticed that you are using version 2 logs with a striped size of 48 4K-blocks > > or 8*48=384 BBs (512 byte blocks). > > I believe there is a bug in the code for log sunit which is not > > a power of 2 in BBs. > > xfs_log.c: log->l_stripemask = 1 << xfs_highbit32(mp->m_sb.sb_logsunit >> BBSHIFT); > > ok i'll use 64k (128BBs) which is my stripsize. I am going to add lvm to > the thing and alignement outside power of 2 will be hard if even > possible anyway. > > > > > I have a fix in my own code but it is mixed with some other v2 log changes. > > I'm currently writing v2 log QA to test this stuff out. > > I'll let you know when I check this stuff in. > > ok > > > > > > xlog_clear_stale_blocks(2) at line 1253 of file xfs_log_recover.c. > > This error happens (great msg I think not:) if the tail of the log > > is greater than the head. By greater I mean in terms of . > > (So if the cycle #s of the head/tail are the same then > > the tail blk < head blk otherwise > > the tail cycle# should be one less than the head cycle# since > > the tail must be on the previous cycle. > > And the tail should never be greater than the head. > > > > > xfs_logprint: > > > data device: 0x801 > > > log device: 0x801 daddr: 1468006656 length: 261888 > > > > > > log tail: 60416 head: 65279 state: > > > > > > > > > LOG REC AT LSN cycle 7 block 60416 (0x7, 0xec00) > > > ============================================================================ > > > TRANS: tid:0xc45c87bc type:DIOSTRAT #items:5 trans:0x0 q:0x808cf70 > > > > > It looks like the tail blk# (60416) is less than the head blk# (65279). > > In which case it is likely that the cycle numbers are not the same like > > they should be. > > > I am not sure if this can be seen as consequence of the log alignment. > Anyway i 'll try with 64k log alignement and see if i can repeat it. > I'm not certain either but it stood out to me. And it is possible. The use of l_stripemask is for setting log->l_curr_block with a roundup. And l_curr_block is used in iclog->ic_header.h_lsn[1] which is used to set the block# for where the next log record starts on disk on the next log record write. And the count for the size of the log record write is correctly rounded up to the sb_logsunit boundary (no l_stripemask used here). So this means, that in your case of logsunit of 384 BBs we would use: - block# start on 256BB boundary (384 --> 256 (power of 2) with mask from xfs_highbit32()) - block count in 384BB multiples (we use the right number here) This could corrupt the log AFAICT. Cheers, Tim. From owner-linux-xfs@oss.sgi.com Tue Oct 7 02:19:31 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 07 Oct 2003 02:20:12 -0700 (PDT) Received: from kerberos.suse.cz (kerberos.suse.cz [195.47.106.10]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h979JR25001249 for ; Tue, 7 Oct 2003 02:19:30 -0700 Received: from chimera.suse.cz (chimera.suse.cz [10.20.0.2]) by kerberos.suse.cz (****** SuSE CR *******) with ESMTP id A16B54FB82; Tue, 7 Oct 2003 11:19:21 +0200 (MEST) Received: from alienAngel.upjs.sk (test12.suse.cz [10.20.3.140]) by chimera.suse.cz (Postfix) with ESMTP id E6CCC5090; Tue, 7 Oct 2003 11:19:20 +0200 (CEST) Received: from localhost (ja@localhost) by alienAngel.upjs.sk (8.12.7/8.12.6/Submit) with ESMTP id h979L6iX002293; Tue, 7 Oct 2003 11:21:06 +0200 X-Authentication-Warning: alienAngel.home.sk: ja owned process doing -bs Date: Tue, 7 Oct 2003 11:21:06 +0200 (CEST) From: Jan Derfinak X-X-Sender: ja@alienAngel.home.sk To: Nathan Scott Cc: linux-xfs@oss.sgi.com Subject: Re: BLKGETSIZE64, BLKBSZSET, BLKSSZGET definition in xfsprogs. In-Reply-To: <20031006055957.GC1001@frodo> Message-ID: References: <20031006055957.GC1001@frodo> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 654 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ja@mail.upjs.sk Precedence: bulk X-list: linux-xfs Content-Length: 1090 Lines: 29 On Mon, 6 Oct 2003, Nathan Scott wrote: > On Mon, Oct 06, 2003 at 07:48:11AM +0200, Jan Derfinak wrote: > > Hi. > > > > While looking to xfsprogs source I found that xfsprogs defines BLKGETSIZE64, > > BLKBSZSET and BLKSSZGET in libxfs/linux.c. These macros are also defined in > > /usr/include/linux/fs.h. I'm curious why xfsprogs doesn't include > ^^^^^^^ ... > Actually, IIRC these are all conditionally compiled (so if they are > already defined via system headers, we use the already-set values). > Not that it matters, they should never have any value different to > what we define them to here. There was change in 2.6.0-test5 and linux/fs.h isn't included in xfsprogs so xfsprogs uses old definition. > bzcat patch-2.6.0-test5.bz2 | grep -e BLKBSZSET -e BLKGETSIZE64 -#define BLKBSZSET _IOW(0x12,113,sizeof(int)) -#define BLKGETSIZE64 _IOR(0x12,114,sizeof(u64)) /* return device size in bytes (u64 *arg) */ +#define BLKBSZSET _IOW(0x12,113,size_t) +#define BLKGETSIZE64 _IOR(0x12,114,size_t) /* return device size in bytes (u64 *arg) */ jan -- From owner-linux-xfs@oss.sgi.com Tue Oct 7 06:32:44 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 07 Oct 2003 06:33:18 -0700 (PDT) Received: from office.lsg.internal (wsip-68-14-236-254.ph.ph.cox.net [68.14.236.254]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h97DWh25015654 for ; Tue, 7 Oct 2003 06:32:43 -0700 Received: from [127.0.0.1] (helo=localhost) by office.lsg.internal with esmtp (Exim 4.23) id 1A6rx7-0003O3-ME for linux-xfs@oss.sgi.com; Tue, 07 Oct 2003 06:32:37 -0700 Received: from office.lsg.internal ([127.0.0.1]) by localhost (office.lsg.internal [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12858-05 for ; Tue, 7 Oct 2003 06:32:37 -0700 (MST) Received: from jeeves.kpf.internal ([192.168.170.1]) by office.lsg.internal with esmtp (Exim 4.23) id 1A6rx7-0003Ny-3M for linux-xfs@oss.sgi.com; Tue, 07 Oct 2003 06:32:37 -0700 Received: from [192.168.172.107] (helo=backtobasicsmgmt.com) by jeeves.kpf.internal with esmtp (Exim 4.05) id 1A6rww-0001ix-00 for linux-xfs@oss.sgi.com; Tue, 07 Oct 2003 06:32:26 -0700 Message-ID: <3F82C06A.1020808@backtobasicsmgmt.com> Date: Tue, 07 Oct 2003 06:32:26 -0700 From: "Kevin P. Fleming" Organization: Back to Basics Network Management User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: BLKGETSIZE64, BLKBSZSET, BLKSSZGET definition in xfsprogs. References: <20031006055957.GC1001@frodo> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at labsysgrp.com X-archive-position: 655 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kpfleming@backtobasicsmgmt.com Precedence: bulk X-list: linux-xfs Content-Length: 827 Lines: 20 Jan Derfinak wrote: > There was change in 2.6.0-test5 and linux/fs.h isn't included in > xfsprogs so xfsprogs uses old definition. > > >>bzcat patch-2.6.0-test5.bz2 | grep -e BLKBSZSET -e BLKGETSIZE64 > > -#define BLKBSZSET _IOW(0x12,113,sizeof(int)) > -#define BLKGETSIZE64 _IOR(0x12,114,sizeof(u64)) /* return device size in bytes (u64 *arg) */ > +#define BLKBSZSET _IOW(0x12,113,size_t) > +#define BLKGETSIZE64 _IOR(0x12,114,size_t) /* return device size in bytes (u64 *arg) */ > Actually, those definitions will produce the same ioctl number, so effectively there is no change. The kernel can't really change ioctl numbers once userspace begins using them, because that's an incompatible change, so it's fine if a userspace package copies the definition of some ioctls and then uses its own copies. From owner-linux-xfs@oss.sgi.com Tue Oct 7 07:03:01 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 07 Oct 2003 07:03:45 -0700 (PDT) Received: from kerberos.suse.cz (kerberos.suse.cz [195.47.106.10]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h97E2d25016811 for ; Tue, 7 Oct 2003 07:03:00 -0700 Received: from chimera.suse.cz (chimera.suse.cz [10.20.0.2]) by kerberos.suse.cz (****** SuSE CR *******) with ESMTP id 9147E4FB82; Tue, 7 Oct 2003 16:02:33 +0200 (MEST) Received: from alienAngel.upjs.sk (test12.suse.cz [10.20.3.140]) by chimera.suse.cz (Postfix) with ESMTP id 009D84276; Tue, 7 Oct 2003 16:02:32 +0200 (CEST) Received: from localhost (ja@localhost) by alienAngel.upjs.sk (8.12.7/8.12.6/Submit) with ESMTP id h97E2kIO004078; Tue, 7 Oct 2003 16:02:46 +0200 X-Authentication-Warning: alienAngel.home.sk: ja owned process doing -bs Date: Tue, 7 Oct 2003 16:02:46 +0200 (CEST) From: Jan Derfinak X-X-Sender: ja@alienAngel.home.sk To: "Kevin P. Fleming" Cc: linux-xfs@oss.sgi.com Subject: Re: BLKGETSIZE64, BLKBSZSET, BLKSSZGET definition in xfsprogs. In-Reply-To: <3F82C06A.1020808@backtobasicsmgmt.com> Message-ID: References: <20031006055957.GC1001@frodo> <3F82C06A.1020808@backtobasicsmgmt.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 656 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ja@mail.upjs.sk Precedence: bulk X-list: linux-xfs Content-Length: 1022 Lines: 30 On Tue, 7 Oct 2003, Kevin P. Fleming wrote: > Jan Derfinak wrote: > > > There was change in 2.6.0-test5 and linux/fs.h isn't included in > > xfsprogs so xfsprogs uses old definition. > > > > > >>bzcat patch-2.6.0-test5.bz2 | grep -e BLKBSZSET -e BLKGETSIZE64 > > > > -#define BLKBSZSET _IOW(0x12,113,sizeof(int)) > > -#define BLKGETSIZE64 _IOR(0x12,114,sizeof(u64)) /* return device size in bytes (u64 *arg) */ > > +#define BLKBSZSET _IOW(0x12,113,size_t) > > +#define BLKGETSIZE64 _IOR(0x12,114,size_t) /* return device size in bytes (u64 *arg) */ > > > > Actually, those definitions will produce the same ioctl number, so > effectively there is no change. The kernel can't really change ioctl > numbers once userspace begins using them, because that's an > incompatible change, so it's fine if a userspace package copies the > definition of some ioctls and then uses its own copies. > But there is difference in third parameter. And this cause error in _IOC_TYPECHECK macro in asm/ioctl.h. jan -- From owner-linux-xfs@oss.sgi.com Tue Oct 7 07:39:09 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 07 Oct 2003 07:39:50 -0700 (PDT) Received: from office.lsg.internal (wsip-68-14-236-254.ph.ph.cox.net [68.14.236.254]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h97Ed725018969 for ; Tue, 7 Oct 2003 07:39:08 -0700 Received: from [127.0.0.1] (helo=localhost) by office.lsg.internal with esmtp (Exim 4.23) id 1A6szO-0003QM-3h; Tue, 07 Oct 2003 07:39:02 -0700 Received: from office.lsg.internal ([127.0.0.1]) by localhost (office.lsg.internal [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12858-09; Tue, 7 Oct 2003 07:39:01 -0700 (MST) Received: from jeeves.kpf.internal ([192.168.170.1]) by office.lsg.internal with esmtp (Exim 4.23) id 1A6szN-0003QG-JS; Tue, 07 Oct 2003 07:39:01 -0700 Received: from [192.168.172.107] (helo=backtobasicsmgmt.com) by jeeves.kpf.internal with esmtp (Exim 4.05) id 1A6szC-0002Cf-00; Tue, 07 Oct 2003 07:38:50 -0700 Message-ID: <3F82CFFB.2000209@backtobasicsmgmt.com> Date: Tue, 07 Oct 2003 07:38:51 -0700 From: "Kevin P. Fleming" Organization: Back to Basics Network Management User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jan Derfinak CC: linux-xfs@oss.sgi.com Subject: Re: BLKGETSIZE64, BLKBSZSET, BLKSSZGET definition in xfsprogs. References: <20031006055957.GC1001@frodo> <3F82C06A.1020808@backtobasicsmgmt.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at labsysgrp.com X-archive-position: 657 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kpfleming@backtobasicsmgmt.com Precedence: bulk X-list: linux-xfs Content-Length: 335 Lines: 10 Jan Derfinak wrote: > But there is difference in third parameter. And this cause error in > _IOC_TYPECHECK macro in asm/ioctl.h. > And that error is caused by the header file, and will be fixed. The patch to fix it is already on the lkml list, but hasn't been accepted yet for some unknown reason. This is not xfsprogs' problem. From owner-linux-xfs@oss.sgi.com Tue Oct 7 08:18:24 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 07 Oct 2003 08:19:14 -0700 (PDT) Received: from moving-picture.com (mpc-26.sohonet.co.uk [193.203.82.251]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h97FIN25023418; Tue, 7 Oct 2003 08:18:24 -0700 Received: from darke.mpc.local ([172.16.11.6] helo=moving-picture.com) by moving-picture.com with esmtp (Exim 3.22 #1) id 1A6tbN-0007s2-00; Tue, 07 Oct 2003 16:18:17 +0100 Message-ID: <3F82D939.2622542E@moving-picture.com> Date: Tue, 07 Oct 2003 16:18:17 +0100 From: James Pearson Organization: Moving Picture Company X-Mailer: Mozilla 4.7 [en] (X11; I; IRIX64 6.5 IP30) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com CC: owner-projects@oss.sgi.com Subject: Re: ftp://oss.sgi.com/projects/xfs References: <20031003202801.GB24696@ii.uib.no> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Disclaimer: This email and any attachments are confidential, may be legally X-Disclaimer: privileged and intended solely for the use of addressee. If you X-Disclaimer: are not the intended recipient of this message, any disclosure, X-Disclaimer: copying, distribution or any action taken in reliance on it is X-Disclaimer: strictly prohibited and may be unlawful. If you have received X-Disclaimer: this message in error, please notify the sender and delete all X-Disclaimer: copies from your system. X-Disclaimer: X-Disclaimer: Email may be susceptible to data corruption, interception and X-Disclaimer: unauthorised amendment, and we do not accept liability for any X-Disclaimer: such corruption, interception or amendment or the consequences X-Disclaimer: thereof. X-archive-position: 658 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: james-p@moving-picture.com Precedence: bulk X-list: linux-xfs Content-Length: 1001 Lines: 35 Jan-Frode Myklebust wrote: > > Somethings broken with the ftp-site: > > ncftp /projects > pwd > ftp://oss.sgi.com/projects/ > ncftp /projects > ls -ld xfs > lrwxrwxr-x 1 0 0 12 Oct 4 2002 xfs -> ../.pub0/xfs > ncftp /projects > cd xfs > Could not chdir to xfs: server said: Can't change directory to xfs: Permission denied > ncftp /projects > cd /.pub0 > Could not chdir to /.pub0: server said: Prohibited file name: .pub0 > > Hope this doesn't have anything to do with SCO... > > > -jf According to the welcome banner on oss.sgi.com, it's using Pure-FTPd - the Pure-FTPd FAQ states: > Alternatively, you can use '-X' (--prohibitdotfilesread) to also prevent > users from READING these files and going into directories that begin with > "." . As /projects/xfs is a link to /.pub0/xfs and the error message is 'Prohibited file name' - then does oss.sgi.com run Pure-FTPd with the -X option? Could someone at SGI please have a look at this? Thanks James Pearson From owner-linux-xfs@oss.sgi.com Tue Oct 7 11:51:14 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 07 Oct 2003 11:51:53 -0700 (PDT) Received: from smtp-out3.iol.cz (smtp-out3.iol.cz [194.228.2.91]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h97Ip325003947 for ; Tue, 7 Oct 2003 11:51:04 -0700 Received: from alienAngel.upjs.sk (gprs150-94.eurotel.cz [160.218.150.94]) by smtp-out3.iol.cz (Internet on Line ESMP server) with ESMTP id 9FC4F34B4F; Tue, 7 Oct 2003 20:11:47 +0200 (CEST) Received: from localhost (ja@localhost) by alienAngel.upjs.sk (8.12.7/8.12.6/Submit) with ESMTP id h97ICcQ4004396; Tue, 7 Oct 2003 20:12:42 +0200 X-Authentication-Warning: alienAngel.home.sk: ja owned process doing -bs Date: Tue, 7 Oct 2003 20:12:38 +0200 (CEST) From: Jan Derfinak X-X-Sender: ja@alienAngel.home.sk To: "Kevin P. Fleming" Cc: linux-xfs@oss.sgi.com Subject: Re: BLKGETSIZE64, BLKBSZSET, BLKSSZGET definition in xfsprogs. In-Reply-To: <3F82CFFB.2000209@backtobasicsmgmt.com> Message-ID: References: <20031006055957.GC1001@frodo> <3F82C06A.1020808@backtobasicsmgmt.com> <3F82CFFB.2000209@backtobasicsmgmt.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 659 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ja@mail.upjs.sk Precedence: bulk X-list: linux-xfs Content-Length: 722 Lines: 25 On Tue, 7 Oct 2003, Kevin P. Fleming wrote: > Jan Derfinak wrote: > > > But there is difference in third parameter. And this cause error in > > _IOC_TYPECHECK macro in asm/ioctl.h. > > > > And that error is caused by the header file, and will be fixed. The > patch to fix it is already on the lkml list, but hasn't been accepted You are right that definition of _IOC_TYPECHECK is not absolutely right. But new definition of BLKGETSIZE64, BLKBSZSET is better that old one and remains in new kernel. > yet for some unknown reason. This is not xfsprogs' problem. Is there any reason to stay with old definition and have different definition of these macros in kernel and in xfsprogs? Did I miss something? jan -- From owner-linux-xfs@oss.sgi.com Tue Oct 7 14:25:14 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 07 Oct 2003 14:25:52 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h97LPD25014681 for ; Tue, 7 Oct 2003 14:25:14 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h97LP8q0032430 for ; Tue, 7 Oct 2003 14:25:08 -0700 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h97LP7cc11965297 for ; Tue, 7 Oct 2003 16:25:08 -0500 (CDT) Received: from sgi.com (penguin.americas.sgi.com [128.162.240.135]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h97LP8Rn304088835 for ; Tue, 7 Oct 2003 16:25:08 -0500 (CDT) Received: from penguin.americas.sgi.com (localhost.localdomain [127.0.0.1]) by sgi.com (8.12.8/8.12.8) with ESMTP id h97LErGf001658 for ; Tue, 7 Oct 2003 16:14:53 -0500 Received: (from lord@localhost) by penguin.americas.sgi.com (8.12.8/8.12.8/Submit) id h97LErbo001656 for linux-xfs@oss.sgi.com; Tue, 7 Oct 2003 16:14:53 -0500 Date: Tue, 7 Oct 2003 16:14:53 -0500 From: Steve Lord Message-Id: <200310072114.h97LErbo001656@penguin.americas.sgi.com> Subject: TAKE - switch xfs to use linux imode flags internally To: linux-xfs@oss.sgi.com X-archive-position: 660 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@penguin.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1386 Lines: 46 Date: Tue Oct 7 14:21:22 PDT 2003 Workarea: penguin.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:159631a linux/fs/xfs/xfsidbg.c - 1.240 linux/fs/xfs/xfs_rw.c - 1.384 linux/fs/xfs/xfs_vnodeops.c - 1.614 linux/fs/xfs/xfs_dir.c - 1.155 linux/fs/xfs/xfs_log_recover.c - 1.280 linux/fs/xfs/xfs_dfrag.c - 1.41 linux/fs/xfs/xfs_mount.c - 1.338 linux/fs/xfs/xfs_inode.c - 1.390 linux/fs/xfs/xfs_inode.h - 1.187 linux/fs/xfs/xfs_bmap.c - 1.312 linux/fs/xfs/xfs_rename.c - 1.55 linux/fs/xfs/xfs_attr.c - 1.110 linux/fs/xfs/xfs_dir2.c - 1.49 linux/fs/xfs/xfs_dinode.h - 1.70 linux/fs/xfs/quota/xfs_qm.c - 1.6 linux/fs/xfs/dmapi/dmapi_xfs.c - 1.19 linux/fs/xfs/linux/xfs_lrw.c - 1.200 linux/fs/xfs/linux/xfs_sysctl.h - 1.22 Modid: xfs-cmds:slinx:159631b cmd/xfsprogs/db/inode.c - 1.12 cmd/xfsprogs/db/frag.c - 1.14 cmd/xfsprogs/db/check.c - 1.19 cmd/xfsprogs/mkfs/proto.c - 1.13 cmd/xfsprogs/logprint/log_misc.c - 1.15 cmd/xfsprogs/include/xfs_inode.h - 1.36 cmd/xfsprogs/include/xfs_dinode.h - 1.13 cmd/xfsprogs/repair/phase6.c - 1.16 cmd/xfsprogs/repair/dinode.c - 1.17 cmd/xfsprogs/libxfs/xfs_dir.c - 1.15 cmd/xfsprogs/libxfs/xfs_inode.c - 1.26 cmd/xfsprogs/libxfs/util.c - 1.12 cmd/xfsprogs/libxfs/xfs_bmap.c - 1.23 cmd/xfsprogs/libxfs/xfs_dir2.c - 1.15 cmd/xfstests/013 - 1.13 From owner-linux-xfs@oss.sgi.com Tue Oct 7 16:28:24 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 07 Oct 2003 16:29:08 -0700 (PDT) Received: from universe.chowhouse.com (IDENT:0@stumpy.chowhouse.com [209.180.91.165] (may be forged)) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h97NSN25021165 for ; Tue, 7 Oct 2003 16:28:24 -0700 Received: from universe.chowhouse.com (IDENT:1000@localhost [127.0.0.1]) by universe.chowhouse.com (8.12.6/8.12.6) with ESMTP id h97NSMBI014748 for ; Tue, 7 Oct 2003 17:28:22 -0600 Received: from localhost (james@localhost) by universe.chowhouse.com (8.12.6/8.12.6/Submit) with ESMTP id h97NSM8n014745 for ; Tue, 7 Oct 2003 17:28:22 -0600 Date: Tue, 7 Oct 2003 17:28:22 -0600 (MDT) From: James Rich To: XFS mailing list Subject: chattr +A doesn't work Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 661 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: james@chowhouse.com Precedence: bulk X-list: linux-xfs Content-Length: 429 Lines: 15 Hey everyone, While testing some things for a friend I discovered that chattr +A doesn't work on XFS: root@stumpy:~# touch testatime root@stumpy:~# chattr +A testatime chattr: Inappropriate ioctl for device while reading flags on testatime This is with linux-2.6.0-test5. Is this specifically not supported? I realize there is a mount option for noatime - haven't tried that yet, but chattr should work, right? James Rich From owner-linux-xfs@oss.sgi.com Tue Oct 7 20:22:35 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 07 Oct 2003 20:23:20 -0700 (PDT) Received: from office.lsg.internal (wsip-68-14-236-254.ph.ph.cox.net [68.14.236.254]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h983MY25032735 for ; Tue, 7 Oct 2003 20:22:35 -0700 Received: from [127.0.0.1] (helo=localhost) by office.lsg.internal with esmtp (Exim 4.23) id 1A74uD-00042w-Cx for linux-xfs@oss.sgi.com; Tue, 07 Oct 2003 20:22:29 -0700 Received: from office.lsg.internal ([127.0.0.1]) by localhost (office.lsg.internal [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15040-10 for ; Tue, 7 Oct 2003 20:22:28 -0700 (MST) Received: from jeeves.kpf.internal ([192.168.170.1]) by office.lsg.internal with esmtp (Exim 4.23) id 1A74uC-00042p-R7 for linux-xfs@oss.sgi.com; Tue, 07 Oct 2003 20:22:28 -0700 Received: from [192.168.172.107] (helo=backtobasicsmgmt.com) by jeeves.kpf.internal with esmtp (Exim 4.05) id 1A74tf-0006eT-00 for linux-xfs@oss.sgi.com; Tue, 07 Oct 2003 20:21:55 -0700 Message-ID: <3F8382D3.5050703@backtobasicsmgmt.com> Date: Tue, 07 Oct 2003 20:21:55 -0700 From: "Kevin P. Fleming" Organization: Back to Basics Network Management User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: BLKGETSIZE64, BLKBSZSET, BLKSSZGET definition in xfsprogs. References: <20031006055957.GC1001@frodo> <3F82C06A.1020808@backtobasicsmgmt.com> <3F82CFFB.2000209@backtobasicsmgmt.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at labsysgrp.com X-archive-position: 662 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kpfleming@backtobasicsmgmt.com Precedence: bulk X-list: linux-xfs Content-Length: 643 Lines: 15 Jan Derfinak wrote: > Is there any reason to stay with old definition and have different > definition of these macros in kernel and in xfsprogs? > Did I miss something? > There is no particular reason to stay with the old definitions, but there's no particular reason (or rush) to change them either. The two definitions produce the same results, and are completely compatible. They're also both wrong, but they've been wrong since the beginning and can't be corrected now (other than by creating a new set of definitions with different names, the old ones will have to be supported at least through kernel 2.8 and probably longer). From owner-linux-xfs@oss.sgi.com Tue Oct 7 22:52:21 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 07 Oct 2003 22:52:59 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h985qK25004943 for ; Tue, 7 Oct 2003 22:52:21 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h985qAq0013958 for ; Tue, 7 Oct 2003 22:52:14 -0700 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h985q39c205196; Wed, 8 Oct 2003 15:52:03 +1000 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h985q2rQ214325; Wed, 8 Oct 2003 15:52:02 +1000 (EST) Date: Wed, 8 Oct 2003 15:52:02 +1000 (EST) From: Nathan Scott Message-Id: <200310080552.h985q2rQ214325@snort.melbourne.sgi.com> To: sgi.bugs.xfs@engr.sgi.com, linux-xfs@oss.sgi.com Subject: TAKE 902106 - fix incorrect diagnostics X-archive-position: 663 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 340 Lines: 13 Fix up pointers in diagnostics, print using %p not %x - for 64 bit platforms. Date: Tue Oct 7 22:50:22 PDT 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/clean-2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:159652a linux/fs/xfs/xfs_log_recover.c - 1.281 From owner-linux-xfs@oss.sgi.com Tue Oct 7 23:41:46 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 07 Oct 2003 23:42:20 -0700 (PDT) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h986fj25010594 for ; Tue, 7 Oct 2003 23:41:46 -0700 Received: from bruce.melbourne.sgi.com (bruce.melbourne.sgi.com [134.14.54.176]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h986xPHc017327 for ; Wed, 8 Oct 2003 01:59:26 -0500 Received: from bruce.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by bruce.melbourne.sgi.com (8.12.8/8.12.8) with ESMTP id h986fZLw007644 for ; Wed, 8 Oct 2003 16:41:35 +1000 Received: (from nathans@localhost) by bruce.melbourne.sgi.com (8.12.8/8.12.8/Submit) id h986fZpU007643 for linux-xfs@oss.sgi.com; Wed, 8 Oct 2003 16:41:35 +1000 Date: Wed, 8 Oct 2003 16:41:35 +1000 From: Nathan Scott Message-Id: <200310080641.h986fZpU007643@bruce.melbourne.sgi.com> Subject: TAKE - xfsidbg update X-archive-position: 664 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@bruce.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 295 Lines: 12 Merge in and update xfsidbg changes from the 2.4 tree. Date: Tue Oct 7 23:40:15 PDT 2003 Workarea: bruce.melbourne.sgi.com:/build2/devel26 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:159656a linux/fs/xfs/xfsidbg.c - 1.241 From owner-linux-xfs@oss.sgi.com Wed Oct 8 03:34:07 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 08 Oct 2003 03:34:47 -0700 (PDT) Received: from kerberos.suse.cz (kerberos.suse.cz [195.47.106.10]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h98AY525024770 for ; Wed, 8 Oct 2003 03:34:06 -0700 Received: from chimera.suse.cz (chimera.suse.cz [10.20.0.2]) by kerberos.suse.cz (****** SuSE CR *******) with ESMTP id 5245A4FB86; Wed, 8 Oct 2003 12:33:59 +0200 (MEST) Received: from alienAngel.upjs.sk (test12.suse.cz [10.20.3.140]) by chimera.suse.cz (Postfix) with ESMTP id 76A1E5090; Wed, 8 Oct 2003 12:33:58 +0200 (CEST) Received: from localhost (ja@localhost) by alienAngel.upjs.sk (8.12.7/8.12.6/Submit) with ESMTP id h98AZEKI007373; Wed, 8 Oct 2003 12:35:15 +0200 X-Authentication-Warning: alienAngel.home.sk: ja owned process doing -bs Date: Wed, 8 Oct 2003 12:35:14 +0200 (CEST) From: Jan Derfinak X-X-Sender: ja@alienAngel.home.sk To: "Kevin P. Fleming" Cc: linux-xfs@oss.sgi.com Subject: Re: BLKGETSIZE64, BLKBSZSET, BLKSSZGET definition in xfsprogs. In-Reply-To: <3F8382D3.5050703@backtobasicsmgmt.com> Message-ID: References: <20031006055957.GC1001@frodo> <3F82C06A.1020808@backtobasicsmgmt.com> <3F82CFFB.2000209@backtobasicsmgmt.com> <3F8382D3.5050703@backtobasicsmgmt.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 665 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ja@mail.upjs.sk Precedence: bulk X-list: linux-xfs Content-Length: 610 Lines: 20 On Tue, 7 Oct 2003, Kevin P. Fleming wrote: > Jan Derfinak wrote: > > > Is there any reason to stay with old definition and have different > > definition of these macros in kernel and in xfsprogs? > > Did I miss something? > > > > There is no particular reason to stay with the old definitions, but > there's no particular reason (or rush) to change them either. The two I disagree with you. The old definition isn't good and change in kernel is reasonable. Not syncing xfsprogs with kernel brings confusion to source code and in current status xfsprogs are not compilable with recent kernel. jan -- From owner-linux-xfs@oss.sgi.com Wed Oct 8 08:28:07 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 08 Oct 2003 08:28:53 -0700 (PDT) Received: from maeko.hayai.de (maeko.hayai.de [217.172.178.38]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h98FS525009863 for ; Wed, 8 Oct 2003 08:28:06 -0700 Received: from maeko.hayai.de (localhost [127.0.0.1]) by maeko.hayai.de (8.12.7/8.12.7) with ESMTP id h97MtPba009141 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO) for ; Wed, 8 Oct 2003 00:55:25 +0200 Received: (from mail@localhost) by maeko.hayai.de (8.12.7/8.12.7/Submit) id h97MtPQB009140 for linux-xfs@oss.sgi.com; Wed, 8 Oct 2003 00:55:25 +0200 Date: Wed, 8 Oct 2003 00:55:24 +0200 From: Marco Wertejuk To: linux-xfs@oss.sgi.com Subject: Kernel Oops Suse Enterprise and NFS Message-ID: <20031007225524.GA8541@maeko.hayai.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.4i X-archive-position: 667 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: wertejuk@mwcis.com Precedence: bulk X-list: linux-xfs Content-Length: 7529 Lines: 111 Hello there, I have a SuSE Linux Enterprise Server 8.0 running XFS on a hardware RAID 5 (SCSI) which is exporting the RAID with NFS. Therefore it uses the kernel based NFSd as delivered by SuSE and I use the original kernel delivered with this distribution. Actually I was not able to find out the XFS Version but it's 2.4.19-64GB-SMP Kernel and I have following xfs packages installed: xfsprogs-2.2.1-29, xfsprogs-devel-2.2.1-29, xfsdump-2.1.3-33. I use xfsdump to backup the RAID and something strange happens. During the xfsdump run there are very often problems with nfs and the kernel throws oopses or nfs locks up (uninterruptible sleep). This is somehow similar to http://oss.sgi.com/bugzilla/show_bug.cgi?id=178 The server runs ext3 on his system partitions and has nfs-utils-1.0.1-109 installed. Perhaps you have an idea what to try or how to provide more detailed information but as told before, the problem is not cleanly reproducable. Oct 7 21:36:56 home kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000000 Oct 7 21:36:56 home kernel: printing eip: Oct 7 21:36:56 home kernel: 00000000 Oct 7 21:36:56 home kernel: *pde = 247e3001 Oct 7 21:36:56 home kernel: Oops: 0000 2.4.19-64GB-SMP #1 SMP Mon Aug 4 23:48:22 UTC 2003 Oct 7 21:36:56 home kernel: CPU: 1 Oct 7 21:36:56 home kernel: EIP: 0010:[<00000000>] Not tainted Oct 7 21:36:56 home kernel: EFLAGS: 00010282 Oct 7 21:36:56 home kernel: eax: e5e56040 ebx: def5ff40 ecx: def5fe68 edx: c045bf80 Oct 7 21:36:56 home kernel: esi: def5fe40 edi: c3b93800 ebp: def5fe40 esp: c33a14f4 Oct 7 21:36:56 home kernel: ds: 0018 es: 0018 ss: 0018 Oct 7 21:36:56 home kernel: Process nfsd (pid: 899, stackpage=c33a1000) Oct 7 21:36:56 home kernel: Stack: c2c83005 e5e56040 def5ff40 c2c9065a 00000002 00000000 c2c9de04 c2c9de04 Oct 7 21:36:56 home kernel: def5fe40 c2c833c6 def5fe40 010cc258 00000000 00000001 00000000 f7f3d21c Oct 7 21:36:56 home kernel: c352c6e0 c2c9de04 c2c9e090 c3b93800 00000801 c2c838a5 f7f3d000 c2c9de14 Oct 7 21:36:56 home kernel: Call Trace: [st:__insmod_st_O/lib/modules/2.4.19-64GB-SMP/kernel/drivers/sc+-9818107/96] [st:__insmod_st_O/lib/modules/2.4.19-64GB-SMP/kernel/drivers/sc+-9763238/96] [st:__insmod_st_O/lib/modules/2.4.19-64GB-SMP/kernel/drivers/sc+-9817146/96] [st:__insmod_st_O/lib/modules/2.4.19-64GB-SMP/kernel/drivers/sc+-9815899/96] [st:__insmod_st_O/lib/modules/2.4.19-64GB-SMP/kernel/drivers/sc+-4910316/96] Oct 7 21:36:56 home kernel: Call Trace: [] [] [] [] [] Oct 7 21:36:56 home kernel: [st:__insmod_st_O/lib/modules/2.4.19-64GB-SMP/kernel/drivers/sc+-5038966/96] [st:__insmod_st_O/lib/modules/2.4.19-64GB-SMP/kernel/drivers/sc+-4690242/96] [st:__insmod_st_O/lib/modules/2.4.19-64GB-SMP/kernel/drivers/sc+-5031352/96] [st:__insmod_st_O/lib/modules/2.4.19-64GB-SMP/kernel/drivers/sc+-5039836/96] [st:__insmod_st_O/lib/modules/2.4.19-64GB-SMP/kernel/drivers/sc+-5029427/96] [st:__insmod_st_O/lib/modules/2.4.19-64GB-SMP/kernel/drivers/sc+-4634828/96] Oct 7 21:36:56 home kernel: [] [] [] [] [] [] Oct 7 21:36:56 home kernel: [st:__insmod_st_O/lib/modules/2.4.19-64GB-SMP/kernel/drivers/sc+-4966052/96] [st:__insmod_st_O/lib/modules/2.4.19-64GB-SMP/kernel/drivers/sc+-4979107/96] [st:__insmod_st_O/lib/modules/2.4.19-64GB-SMP/kernel/drivers/sc+-4966052/96] [st:__insmod_st_O/lib/modules/2.4.19-64GB-SMP/kernel/drivers/sc+-4984337/96] [st:__insmod_st_O/lib/modules/2.4.19-64GB-SMP/kernel/drivers/sc+-4633762/96] [st:__insmod_st_O/lib/modules/2.4.19-64GB-SMP/kernel/drivers/sc+-4632398/96] Oct 7 21:36:56 home kernel: [] [] [] [] [] [] Oct 7 21:36:56 home kernel: [st:__insmod_st_O/lib/modules/2.4.19-64GB-SMP/kernel/drivers/sc+-4906172/96] [st:__insmod_st_O/lib/modules/2.4.19-64GB-SMP/kernel/drivers/sc+-4686912/96] [st:__insmod_st_O/lib/modules/2.4.19-64GB-SMP/kernel/drivers/sc+-4756465/96] [st:__insmod_st_O/lib/modules/2.4.19-64GB-SMP/kernel/drivers/sc+-4696120/96] [st:__insmod_st_O/lib/modules/2.4.19-64GB-SMP/kernel/drivers/sc+-4586955/96] [st:__insmod_st_O/lib/modules/2.4.19-64GB-SMP/kernel/drivers/sc+-4587470/96] Oct 7 21:36:56 home kernel: [] [] [] [] [] [] Oct 7 21:36:56 home kernel: [locate_hd_struct+56/144] [account_io_start+56/96] [req_new_io+103/144] [__make_request+892/1952] [generic_make_request+249/336] [ext3:__insmod_ext3_O/lib/modules/2.4.19-64GB-SMP/kernel/fs/ext3/+-6659316/96] Oct 7 21:36:56 home kernel: [] [] [] [] [] [] Oct 7 21:36:56 home kernel: [st:__insmod_st_O/lib/modules/2.4.19-64GB-SMP/kernel/drivers/sc+-4614333/96] [scsi_done+0/176] [scsi_times_out+0/128] [locate_hd_struct+56/144] [__make_request+1412/1952] [generic_make_request+249/336] Oct 7 21:36:56 home kernel: [] [] [] [] [] [] Oct 7 21:36:56 home kernel: [st:__insmod_st_O/lib/modules/2.4.19-64GB-SMP/kernel/drivers/sc+-4750484/96] [st:__insmod_st_O/lib/modules/2.4.19-64GB-SMP/kernel/drivers/sc+-4686912/96] [st:__insmod_st_O/lib/modules/2.4.19-64GB-SMP/kernel/drivers/sc+-4756465/96] [st:__insmod_st_O/lib/modules/2.4.19-64GB-SMP/kernel/drivers/sc+-4696120/96] [sg:sg_major_ptrs+11315095/62303129] [qdisc_restart+22/432] Oct 7 21:36:56 home kernel: [] [] [] [] [] [] Oct 7 21:36:56 home kernel: [dev_queue_xmit+656/848] [neigh_resolve_output+294/576] [ip_finish_output2+162/272] [ip_output+104/176] [ip_build_xmit+592/960] [ip_route_output_key+59/368] Oct 7 21:36:56 home kernel: [] [] [] [] [] [] Oct 7 21:36:56 home kernel: [udp_sendmsg+626/1168] [udp_getfrag+0/288] [st:__insmod_st_O/lib/modules/2.4.19-64GB-SMP/kernel/drivers/sc+-4789778/96] [st:__insmod_st_O/lib/modules/2.4.19-64GB-SMP/kernel/drivers/sc+-9807485/96] [st:__insmod_st_O/lib/modules/2.4.19-64GB-SMP/kernel/drivers/sc+-9780884/96] [st:__insmod_st_O/lib/modules/2.4.19-64GB-SMP/kernel/drivers/sc+-9773258/96] Oct 7 21:36:56 home kernel: [] [] [] [] [] [] Oct 7 21:36:56 home kernel: [st:__insmod_st_O/lib/modules/2.4.19-64GB-SMP/kernel/drivers/sc+-9753296/96] [st:__insmod_st_O/lib/modules/2.4.19-64GB-SMP/kernel/drivers/sc+-9755592/96] [st:__insmod_st_O/lib/modules/2.4.19-64GB-SMP/kernel/drivers/sc+-9828722/96] [st:__insmod_st_O/lib/modules/2.4.19-64GB-SMP/kernel/drivers/sc+-9753296/96] [svc_process+1071/1344] [st:__insmod_st_O/lib/modules/2.4.19-64GB-SMP/kernel/drivers/sc+-9829297/96] Oct 7 21:36:56 home kernel: [] [] [] [] [] [] Oct 7 21:36:56 home kernel: [arch_kernel_thread+46/64] [st:__insmod_st_O/lib/modules/2.4.19-64GB-SMP/kernel/drivers/sc+-9829888/96] Oct 7 21:36:56 home kernel: [] [] Oct 7 21:36:56 home kernel: Modules: [(nfsd::)] [(e1000::)] Oct 7 21:36:56 home kernel: [(xfs::)] [(aic79xx::)] Oct 7 21:36:56 home kernel: Code: Bad EIP value. -- Mit freundlichen Gruessen, Marco Wertejuk - mwcis.com Consulting & Internet Solutions From owner-linux-xfs@oss.sgi.com Wed Oct 8 08:58:44 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 08 Oct 2003 08:59:24 -0700 (PDT) Received: from Cantor.suse.de (ns.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h98Fwh25012204 for ; Wed, 8 Oct 2003 08:58:44 -0700 Received: from Hermes.suse.de (Hermes.suse.de [195.135.221.8]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by Cantor.suse.de (Postfix) with ESMTP id 24F0A16C6914; Wed, 8 Oct 2003 17:58:38 +0200 (CEST) Date: Wed, 8 Oct 2003 17:58:37 +0200 From: Andi Kleen To: Marco Wertejuk Cc: linux-xfs@oss.sgi.com Subject: Re: Kernel Oops Suse Enterprise and NFS Message-ID: <20031008155837.GC16937@wotan.suse.de> References: <20031007225524.GA8541@maeko.hayai.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031007225524.GA8541@maeko.hayai.de> X-archive-position: 668 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: linux-xfs Content-Length: 618 Lines: 18 On Wed, Oct 08, 2003 at 12:55:24AM +0200, Marco Wertejuk wrote: > I have a SuSE Linux Enterprise Server 8.0 running XFS on > a hardware RAID 5 (SCSI) which is exporting the RAID with > NFS. > Therefore it uses the kernel based NFSd as delivered by > SuSE and I use the original kernel delivered with this > distribution. > Actually I was not able to find out the XFS Version > but it's 2.4.19-64GB-SMP Kernel and I have following The XFS in that kernel is based on XFS 1.1, which is a somewhat old codebase. The upcomming Service Pack 3 of SLES8 will include XFS 1.3 and it may be worth retrying with that. -Andi From owner-linux-xfs@oss.sgi.com Wed Oct 8 09:36:10 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 08 Oct 2003 09:36:48 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h98Ga925015762 for ; Wed, 8 Oct 2003 09:36:10 -0700 Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h98Ga4q0012385 for ; Wed, 8 Oct 2003 09:36:04 -0700 Received: from stout.americas.sgi.com (localhost [127.0.0.1]) by stout.americas.sgi.com (8.12.8/8.12.8) with ESMTP id h98Ga33u024159 for ; Wed, 8 Oct 2003 11:36:03 -0500 Received: (from sandeen@localhost) by stout.americas.sgi.com (8.12.8/8.12.8/Submit) id h98Ga00J024157 for linux-xfs@oss.sgi.com; Wed, 8 Oct 2003 11:36:00 -0500 Date: Wed, 8 Oct 2003 11:36:00 -0500 From: Eric Sandeen Message-Id: <200310081636.h98Ga00J024157@stout.americas.sgi.com> Subject: TAKE - change default userspace pkg versions X-archive-position: 669 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@stout.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 514 Lines: 21 Default package version to 1, not 0, to follow convention Maximum RPM and rpmlint both think that "-0" is an odd package version. So, go along to get along... Date: Wed Oct 8 09:34:49 PDT 2003 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/xfs-cmds The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:159675a acl/VERSION - 1.59 attr/VERSION - 1.41 xfsprogs/VERSION - 1.91 xfsdump/VERSION - 1.53 xfstests/VERSION - 1.2 dmapi/VERSION - 1.18 From owner-linux-xfs@oss.sgi.com Wed Oct 8 10:11:50 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 08 Oct 2003 10:12:23 -0700 (PDT) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h98HBn25019342 for ; Wed, 8 Oct 2003 10:11:49 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h98HTWHc012378 for ; Wed, 8 Oct 2003 12:29:32 -0500 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h98HBicc12022164 for ; Wed, 8 Oct 2003 12:11:44 -0500 (CDT) Received: from sgi.com (penguin.americas.sgi.com [128.162.240.135]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h98HBiRn287959681 for ; Wed, 8 Oct 2003 12:11:44 -0500 (CDT) Received: from penguin.americas.sgi.com (localhost.localdomain [127.0.0.1]) by sgi.com (8.12.8/8.12.8) with ESMTP id h98H00Gf018291 for ; Wed, 8 Oct 2003 12:00:00 -0500 Received: (from lord@localhost) by penguin.americas.sgi.com (8.12.8/8.12.8/Submit) id h98H00P6018289 for linux-xfs@oss.sgi.com; Wed, 8 Oct 2003 12:00:00 -0500 Date: Wed, 8 Oct 2003 12:00:00 -0500 From: Steve Lord Message-Id: <200310081700.h98H00P6018289@penguin.americas.sgi.com> Subject: TAKE - remove FINVIS from xfs To: linux-xfs@oss.sgi.com X-archive-position: 670 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@penguin.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1141 Lines: 41 remove FINVIS from xfs, instead use a seperate file ops vector for files which are opened for invisible I/O. Date: Wed Oct 8 10:10:55 PDT 2003 Workarea: penguin.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:159680a linux/fs/xfs/dmapi/dmapi_xfs.c - 1.21 - remove setting of FINVIS linux/fs/xfs/dmapi/dmapi_register.c - 1.27 - instead of setting FINVIS, use a different file ops vector to control invisible I/O. linux/fs/xfs/linux/xfs_ioctl.c - 1.98 - instead of setting FINVIS, use a different file ops vector to control invisible I/O. Pass down an io flag to the various ioctl ops which need to be aware of invisible I/O. linux/fs/xfs/linux/xfs_linux.h - 1.113 - FINVIS goes away linux/fs/xfs/linux/xfs_file.c - 1.98 - add a new file ops vector for files opened with a request for invisible I/O. linux/fs/xfs/linux/xfs_vnode.h - 1.84 - changed ioctl interface linux/fs/xfs/linux/xfs_super.c - 1.272 - changed ioctl interface linux/fs/xfs/linux/xfs_iops.h - 1.23 - export linvfs_invis_file_operations From owner-linux-xfs@oss.sgi.com Wed Oct 8 16:30:26 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 08 Oct 2003 16:31:09 -0700 (PDT) Received: from hob.acsalaska.net (hob.acsalaska.net [209.112.155.42]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h98NUM25009391 for ; Wed, 8 Oct 2003 16:30:25 -0700 Received: from erbenson.alaska.net (3-pm29.nwc.alaska.net [209.112.158.3]) by hob.acsalaska.net (8.12.10/8.12.10) with ESMTP id h98NUJOM062306 for ; Wed, 8 Oct 2003 15:30:20 -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 3327B39E4 for ; Wed, 8 Oct 2003 15:30:18 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id 69FCF40FF35; Wed, 8 Oct 2003 15:30:18 -0800 (AKDT) Date: Wed, 8 Oct 2003 15:30:18 -0800 From: Ethan Benson To: XFS mailing list Subject: Re: chattr +A doesn't work Message-ID: <20031008233018.GR2828@plato.local.lan> Mail-Followup-To: XFS mailing list References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4ECF1u7dKBoUGhe3" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-ACS-Spam-Status: no X-ACS-Scanned-By: MD 2.37; SA 2.60; spamdefang 1.58 X-archive-position: 671 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: erbenson@alaska.net Precedence: bulk X-list: linux-xfs Content-Length: 1257 Lines: 44 --4ECF1u7dKBoUGhe3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 07, 2003 at 05:28:22PM -0600, James Rich wrote: > Hey everyone, >=20 > While testing some things for a friend I discovered that chattr +A doesn't > work on XFS: >=20 > root@stumpy:~# touch testatime > root@stumpy:~# chattr +A testatime > chattr: Inappropriate ioctl for device while reading flags on testatime >=20 > This is with linux-2.6.0-test5. Is this specifically not supported? I > realize there is a mount option for noatime - haven't tried that yet, but > chattr should work, right? I just got code to implement this and immutable, append-only, sync, and nodump merged very recently into XFS, it has not found its way into test5 yet, i think it is in test6 though. its also in the SGI trees. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --4ECF1u7dKBoUGhe3 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 iEYEARECAAYFAj+EngoACgkQJKx7GixEevx1RwCZAYvA0uMLBUZ+yMzruqbGJpC2 TxkAniTonwKOOnN8macvdQCIEtQEM9tY =RZgX -----END PGP SIGNATURE----- --4ECF1u7dKBoUGhe3-- From owner-linux-xfs@oss.sgi.com Wed Oct 8 16:55:06 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 08 Oct 2003 16:55:39 -0700 (PDT) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h98Nt525010367 for ; Wed, 8 Oct 2003 16:55:05 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id h98LwrOO031425 for ; Wed, 8 Oct 2003 14:58:55 -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 JAA03707; Thu, 9 Oct 2003 09:54:55 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h98NsrUc395365; Thu, 9 Oct 2003 09:54:54 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id h98NqHbZ000934; Thu, 9 Oct 2003 09:52:17 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id h98NqGZH000932; Thu, 9 Oct 2003 09:52:16 +1000 Date: Thu, 9 Oct 2003 09:52:16 +1000 From: Nathan Scott To: Jan Derfinak Cc: "Kevin P. Fleming" , linux-xfs@oss.sgi.com Subject: Re: BLKGETSIZE64, BLKBSZSET, BLKSSZGET definition in xfsprogs. Message-ID: <20031008235216.GA813@frodo> References: <20031006055957.GC1001@frodo> <3F82C06A.1020808@backtobasicsmgmt.com> <3F82CFFB.2000209@backtobasicsmgmt.com> <3F8382D3.5050703@backtobasicsmgmt.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i X-archive-position: 672 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 778 Lines: 24 On Wed, Oct 08, 2003 at 12:35:14PM +0200, Jan Derfinak wrote: > On Tue, 7 Oct 2003, Kevin P. Fleming wrote: > > > Jan Derfinak wrote: > > > > > Is there any reason to stay with old definition and have different > > > definition of these macros in kernel and in xfsprogs? > > > Did I miss something? > > > > > > > There is no particular reason to stay with the old definitions, but > > there's no particular reason (or rush) to change them either. The two > > I disagree with you. The old definition isn't good and change in kernel is > reasonable. Not syncing xfsprogs with kernel brings confusion to source code > and in current status xfsprogs are not compilable with recent kernel. If it doesn't compile, please send a patch (and the compile error). thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Oct 8 22:22:24 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 08 Oct 2003 22:22:57 -0700 (PDT) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h995MO25022826 for ; Wed, 8 Oct 2003 22:22:24 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h993QEOO026447 for ; Wed, 8 Oct 2003 20:26:15 -0700 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h995MDjj785315; Thu, 9 Oct 2003 15:22:13 +1000 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h995LvH5784856; Thu, 9 Oct 2003 15:21:57 +1000 (EST) Date: Thu, 9 Oct 2003 15:21:57 +1000 (EST) From: Nathan Scott Message-Id: <200310090521.h995LvH5784856@snort.melbourne.sgi.com> To: sgi.bugs.xfs@engr.sgi.com, linux-xfs@oss.sgi.com Subject: PARTIAL TAKE 902106 - tracing option X-archive-position: 673 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1110 Lines: 39 Rename pagebuf debug option (i.e. pagebuf tracing) into a generic XFS tracing option for the other XFS trace code to use too (once fixed). Specifically, we want to enable some IO path tracing at the end of this to try to hunt down a particular bug, but may as well fix up the rest of the existing trace code while we're at it. Also fixed up some pointers in diagnostics, print using %p not %x for 64 bit platforms. Date: Tue Oct 7 22:50:22 PDT 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/clean-2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:159652a linux/fs/xfs/xfs_log_recover.c - 1.281 Date: Wed Oct 8 21:19:33 PDT 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/clean-2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:159717a linux/fs/xfs/Makefile - 1.52 linux/fs/xfs/pagebuf/Makefile - 1.21 linux/fs/xfs/linux/xfs_super.h - 1.53 Modid: 2.4.x-xfs:slinx:159717b linux/fs/Config.in - 1.91 linux/Documentation/Configure.help - 1.149 From owner-linux-xfs@oss.sgi.com Thu Oct 9 01:41:34 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 09 Oct 2003 01:42:13 -0700 (PDT) Received: from kerberos.suse.cz (kerberos.suse.cz [195.47.106.10]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h998fU25030179 for ; Thu, 9 Oct 2003 01:41:33 -0700 Received: from chimera.suse.cz (chimera.suse.cz [10.20.0.2]) by kerberos.suse.cz (****** SuSE CR *******) with ESMTP id 379F44FB7F; Thu, 9 Oct 2003 10:41:24 +0200 (MEST) Received: from alienAngel.upjs.sk (test12.suse.cz [10.20.3.140]) by chimera.suse.cz (Postfix) with ESMTP id 8FF975092; Thu, 9 Oct 2003 10:41:23 +0200 (CEST) Received: from localhost (ja@localhost) by alienAngel.upjs.sk (8.12.7/8.12.6/Submit) with ESMTP id h998hJNu027281; Thu, 9 Oct 2003 10:43:19 +0200 X-Authentication-Warning: alienAngel.home.sk: ja owned process doing -bs Date: Thu, 9 Oct 2003 10:43:19 +0200 (CEST) From: Jan Derfinak X-X-Sender: ja@alienAngel.home.sk To: Nathan Scott Cc: linux-xfs@oss.sgi.com Subject: Re: BLKGETSIZE64, BLKBSZSET, BLKSSZGET definition in xfsprogs. In-Reply-To: <20031008235216.GA813@frodo> Message-ID: References: <20031006055957.GC1001@frodo> <3F82C06A.1020808@backtobasicsmgmt.com> <3F82CFFB.2000209@backtobasicsmgmt.com> <3F8382D3.5050703@backtobasicsmgmt.com> <20031008235216.GA813@frodo> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 674 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ja@mail.upjs.sk Precedence: bulk X-list: linux-xfs Content-Length: 1584 Lines: 50 On Thu, 9 Oct 2003, Nathan Scott wrote: Hi. > If it doesn't compile, please send a patch (and the compile error). Of course. To trigger error you must have includes from kernel 2.6.0-test5 or higher. The error: /usr/bin/libtool --mode=compile gcc -O1 -g -DNDEBUG -funsigned-char -Wall -I../include -DVERSION=\"2.5.10\" -DLOCALEDIR=\"/usr/local/share/locale\" -DPACKAGE=\"xfsprogs\" -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -I. -D_REENTRANT -fno-strict-aliasing -c linux.c rm -f .libs/linux.lo gcc -O1 -g -DNDEBUG -funsigned-char -Wall -I../include -DVERSION=\"2.5.10\" -DLOCALEDIR=\"/usr/local/share/locale\" -DPACKAGE=\"xfsprogs\" -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -I. -D_REENTRANT -fno-strict-aliasing -c linux.c -fPIC -DPIC -o .libs/linux.lo linux.c: In function `platform_set_blocksize': linux.c:116: parse error before '[' token linux.c: In function `platform_findsizes': linux.c:148: parse error before '[' token make[1]: *** [linux.lo] Error 1 make: *** [default] Error 2 The patch: (from /usr/include/linux/fs.h) diff -uNr xfsprogs.orig/libxfs/linux.c xfsprogs/libxfs/linux.c --- xfsprogs.orig/libxfs/linux.c 2003-06-11 13:49:17.000000000 +0200 +++ xfsprogs/libxfs/linux.c 2003-10-09 10:30:12.000000000 +0200 @@ -42,10 +42,10 @@ extern char *progname; #ifndef BLKGETSIZE64 -# define BLKGETSIZE64 _IOR(0x12,114,sizeof(__uint64_t)) +# define BLKGETSIZE64 _IOR(0x12,114,size_t) #endif #ifndef BLKBSZSET -# define BLKBSZSET _IOW(0x12,113,sizeof(int)) +# define BLKBSZSET _IOW(0x12,113,size_t) #endif #ifndef BLKSSZGET # define BLKSSZGET _IO(0x12,104) jan -- From owner-linux-xfs@oss.sgi.com Thu Oct 9 07:36:44 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 09 Oct 2003 07:37:23 -0700 (PDT) Received: from THOR.goeci.com (thor.goeci.com [66.28.220.99]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h99Eah25006204 for ; Thu, 9 Oct 2003 07:36:43 -0700 Received: by THOR.goeci.com with Internet Mail Service (5.5.2653.19) id <4MAMZFDJ>; Thu, 9 Oct 2003 10:36:37 -0400 Message-ID: <2D92FEBFD3BE1346A6C397223A8DD3FC09241F@THOR.goeci.com> From: Murthy Kambhampaty To: XFS mailing list Subject: RE: XFS Bugzilla #259; Solved? Date: Thu, 9 Oct 2003 10:36:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-archive-position: 676 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: murthy.kambhampaty@goeci.com Precedence: bulk X-list: linux-xfs Content-Length: 561 Lines: 10 The failure pattern I reported in #259 - 'xfs_freeze gets stuck in "D" state in the function "down"' - does not appear when running linux-2.4-xfs of Tue Sep 30 13:28:08 2003. The test script which I used to trigger the problem originally has been running hourly for over a week, no problems. I'm cautiously optimistic that the problem went away. PS: I tried posting this as a follow-up in the bugzilla database, but the "add an attachment" thing (which seemed to be the only mechanism) doesn't work if you don't have an attachment (I didn't). Can it be done? From owner-linux-xfs@oss.sgi.com Thu Oct 9 07:41:37 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 09 Oct 2003 07:42:11 -0700 (PDT) Received: from rrzs2.rz.uni-regensburg.de (rrzs2.rz.uni-regensburg.de [132.199.1.2]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h99Efa25006745 for ; Thu, 9 Oct 2003 07:41:36 -0700 Received: from rss1.rz.uni-regensburg.de (rss1.rz.uni-regensburg.de [132.199.1.200]) by rrzs2.rz.uni-regensburg.de (8.11.7+Sun/8.11.6) with SMTP id h99EfY912346 for ; Thu, 9 Oct 2003 16:41:35 +0200 (MEST) Received: (qmail 21382 invoked from network); 9 Oct 2003 16:41:34 +0200 Received: from pc9391.physik.uni-regensburg.de (HELO pc9391) (guc28561@132.199.98.219) by rss1.rz.uni-regensburg.de with SMTP; 9 Oct 2003 16:41:34 +0200 Date: Thu, 9 Oct 2003 16:41:34 +0200 From: Christian Guggenberger To: Murthy Kambhampaty Cc: XFS mailing list Subject: Re: XFS Bugzilla #259; Solved? Message-ID: <20031009164134.G30564@pc9391.uni-regensburg.de> References: <2D92FEBFD3BE1346A6C397223A8DD3FC09241F@THOR.goeci.com> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In-Reply-To: <2D92FEBFD3BE1346A6C397223A8DD3FC09241F@THOR.goeci.com>; from murthy.kambhampaty@goeci.com on Thu, Oct 09, 2003 at 16:36:33 +0200 X-Mailer: Balsa 1.2.4 X-archive-position: 677 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Christian.Guggenberger@physik.uni-regensburg.de Precedence: bulk X-list: linux-xfs Content-Length: 680 Lines: 16 On 09.10.2003 16:36 Murthy Kambhampaty wrote: > The failure pattern I reported in #259 - 'xfs_freeze gets stuck in "D" state > in the function "down"' - does not appear when running linux-2.4-xfs of Tue > Sep 30 13:28:08 2003. The test script which I used to trigger the problem > originally has been running hourly for over a week, no problems. I'm > cautiously optimistic that the problem went away. > > PS: I tried posting this as a follow-up in the bugzilla database, but the > "add an attachment" thing (which seemed to be the only mechanism) doesn't > work if you don't have an attachment (I didn't). Can it be done? > > what about "Additional Comments" ? Christian From owner-linux-xfs@oss.sgi.com Thu Oct 9 07:43:13 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 09 Oct 2003 07:43:45 -0700 (PDT) Received: from THOR.goeci.com (thor.goeci.com [66.28.220.99]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h99EhD25007144 for ; Thu, 9 Oct 2003 07:43:13 -0700 Received: by THOR.goeci.com with Internet Mail Service (5.5.2653.19) id <4MAMZF1G>; Thu, 9 Oct 2003 10:43:07 -0400 Message-ID: <2D92FEBFD3BE1346A6C397223A8DD3FC092420@THOR.goeci.com> From: Murthy Kambhampaty To: Murthy Kambhampaty , XFS mailing list Subject: RE: XFS Bugzilla #259; Solved? [Buzilla posting] Date: Thu, 9 Oct 2003 10:43:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-archive-position: 678 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: murthy.kambhampaty@goeci.com Precedence: bulk X-list: linux-xfs Content-Length: 308 Lines: 9 >PS: I tried posting this as a follow-up in the bugzilla >database, but the >"add an attachment" thing (which seemed to be the only >mechanism) doesn't >work if you don't have an attachment (I didn't). Can it be done? > Duh, I finally saw the "Commit" button under "Additional Comments". Pardon the noise From owner-linux-xfs@oss.sgi.com Thu Oct 9 08:07:59 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 09 Oct 2003 08:08:12 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10) with ESMTP id h99F7x25008527 for ; Thu, 9 Oct 2003 08:07:59 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id h99F7xHn008526 for linux-xfs@oss.sgi.com; Thu, 9 Oct 2003 08:07:59 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10) with ESMTP id h99F7v27008512 for ; Thu, 9 Oct 2003 08:07:57 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id h99Eb6TY006224; Thu, 9 Oct 2003 07:37:06 -0700 Date: Thu, 9 Oct 2003 07:37:06 -0700 Message-Id: <200310091437.h99Eb6TY006224@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 259] xfs_freeze gets stuck in "D" state in the function "down" X-Bugzilla-Reason: AssignedTo X-archive-position: 679 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 476 Lines: 18 http://oss.sgi.com/bugzilla/show_bug.cgi?id=259 ------- Additional Comments From murthy.kambhampaty@goeci.com 2003-09-10 07:37 PDT ------- Solved? I updated linux-2.4-xfs from CVS 9/30/2003 13:28; the failure pattern reported has not occurred after a week of running the test script hourly, so I'm cautiously optimistic that the problem went away. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Oct 9 15:31:37 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 09 Oct 2003 15:32:23 -0700 (PDT) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h99MVa25032731 for ; Thu, 9 Oct 2003 15:31:37 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id h99KZSOO022255 for ; Thu, 9 Oct 2003 13:35:29 -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 IAA14953; Fri, 10 Oct 2003 08:31:27 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h99MVQUc430813; Fri, 10 Oct 2003 08:31:26 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id h99MSoa2000747; Fri, 10 Oct 2003 08:28:50 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id h99MSlgK000745; Fri, 10 Oct 2003 08:28:47 +1000 Date: Fri, 10 Oct 2003 08:28:47 +1000 From: Nathan Scott To: Jan Derfinak Cc: linux-xfs@oss.sgi.com Subject: Re: BLKGETSIZE64, BLKBSZSET, BLKSSZGET definition in xfsprogs. Message-ID: <20031009222847.GC658@frodo> References: <20031006055957.GC1001@frodo> <3F82C06A.1020808@backtobasicsmgmt.com> <3F82CFFB.2000209@backtobasicsmgmt.com> <3F8382D3.5050703@backtobasicsmgmt.com> <20031008235216.GA813@frodo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i X-archive-position: 680 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1809 Lines: 58 On Thu, Oct 09, 2003 at 10:43:19AM +0200, Jan Derfinak wrote: > On Thu, 9 Oct 2003, Nathan Scott wrote: > > Hi. > > > If it doesn't compile, please send a patch (and the compile error). > > Of course. > > To trigger error you must have includes from kernel 2.6.0-test5 or higher. Thanks Jan, I'll put this change in shortly. cheers. > The error: > /usr/bin/libtool --mode=compile gcc -O1 -g -DNDEBUG -funsigned-char -Wall > -I../include -DVERSION=\"2.5.10\" -DLOCALEDIR=\"/usr/local/share/locale\" > -DPACKAGE=\"xfsprogs\" -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -I. > -D_REENTRANT -fno-strict-aliasing -c linux.c > rm -f .libs/linux.lo > gcc -O1 -g -DNDEBUG -funsigned-char -Wall -I../include -DVERSION=\"2.5.10\" > -DLOCALEDIR=\"/usr/local/share/locale\" -DPACKAGE=\"xfsprogs\" -D_GNU_SOURCE > -D_FILE_OFFSET_BITS=64 -I. -D_REENTRANT -fno-strict-aliasing -c linux.c > -fPIC -DPIC -o .libs/linux.lo > linux.c: In function `platform_set_blocksize': > linux.c:116: parse error before '[' token > linux.c: In function `platform_findsizes': > linux.c:148: parse error before '[' token > make[1]: *** [linux.lo] Error 1 > make: *** [default] Error 2 > > The patch: (from /usr/include/linux/fs.h) > diff -uNr xfsprogs.orig/libxfs/linux.c xfsprogs/libxfs/linux.c > --- xfsprogs.orig/libxfs/linux.c 2003-06-11 13:49:17.000000000 +0200 > +++ xfsprogs/libxfs/linux.c 2003-10-09 10:30:12.000000000 +0200 > @@ -42,10 +42,10 @@ > extern char *progname; > > #ifndef BLKGETSIZE64 > -# define BLKGETSIZE64 _IOR(0x12,114,sizeof(__uint64_t)) > +# define BLKGETSIZE64 _IOR(0x12,114,size_t) > #endif > #ifndef BLKBSZSET > -# define BLKBSZSET _IOW(0x12,113,sizeof(int)) > +# define BLKBSZSET _IOW(0x12,113,size_t) > #endif > #ifndef BLKSSZGET > # define BLKSSZGET _IO(0x12,104) > > > jan > > -- -- Nathan From owner-linux-xfs@oss.sgi.com Thu Oct 9 16:40:54 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 09 Oct 2003 16:41:32 -0700 (PDT) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h99Ner25005068 for ; Thu, 9 Oct 2003 16:40:53 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h99NwdHc027940 for ; Thu, 9 Oct 2003 18:58:40 -0500 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h99Nejjj1295362 for ; Fri, 10 Oct 2003 09:40:45 +1000 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h99Nej5S1295585 for linux-xfs@oss.sgi.com; Fri, 10 Oct 2003 09:40:45 +1000 (EST) Date: Fri, 10 Oct 2003 09:40:45 +1000 (EST) From: Nathan Scott Message-Id: <200310092340.h99Nej5S1295585@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - block ioctls X-archive-position: 681 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 389 Lines: 15 Rejig block ioctl definitions in libxfs, using Jans patch. Date: Thu Oct 9 16:39:38 PDT 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-cmds The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:159788a xfsprogs/VERSION - 1.92 xfsprogs/doc/CHANGES - 1.129 xfsprogs/debian/changelog - 1.83 xfsprogs/libxfs/linux.c - 1.7 From owner-linux-xfs@oss.sgi.com Fri Oct 10 01:19:43 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 10 Oct 2003 01:20:25 -0700 (PDT) Received: from phoenix.infradead.org (pub234.cambridge.redhat.com [213.86.99.234] (may be forged)) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9A8Jg25025654 for ; Fri, 10 Oct 2003 01:19:43 -0700 Received: from hch by phoenix.infradead.org with local (Exim 4.22) id 1A7sUu-0007Yh-VJ; Fri, 10 Oct 2003 09:19:40 +0100 Date: Fri, 10 Oct 2003 09:19:40 +0100 From: Christoph Hellwig To: Steve Lord Cc: linux-xfs@oss.sgi.com Subject: Re: TAKE - remove FINVIS from xfs Message-ID: <20031010091940.A29029@infradead.org> References: <200310081700.h98H00P6018289@penguin.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200310081700.h98H00P6018289@penguin.americas.sgi.com>; from lord@penguin.americas.sgi.com on Wed, Oct 08, 2003 at 12:00:00PM -0500 X-archive-position: 682 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs Content-Length: 242 Lines: 6 On Wed, Oct 08, 2003 at 12:00:00PM -0500, Steve Lord wrote: > remove FINVIS from xfs, instead use a seperate file ops > vector for files which are opened for invisible I/O. This means the uio_fmode member of struct uio can go away aswell.. From owner-linux-xfs@oss.sgi.com Fri Oct 10 06:32:15 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 10 Oct 2003 06:32:53 -0700 (PDT) Received: from kerberos.suse.cz (kerberos.suse.cz [195.47.106.10]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9ADW825009933 for ; Fri, 10 Oct 2003 06:32:14 -0700 Received: from chimera.suse.cz (chimera.suse.cz [10.20.0.2]) by kerberos.suse.cz (****** SuSE CR *******) with ESMTP id C7E774FB8B for ; Fri, 10 Oct 2003 15:32:02 +0200 (MEST) Received: from alienAngel.upjs.sk (test12.suse.cz [10.20.3.140]) by chimera.suse.cz (Postfix) with ESMTP id 6030B5090 for ; Fri, 10 Oct 2003 15:32:02 +0200 (CEST) Received: from localhost (ja@localhost) by alienAngel.upjs.sk (8.12.7/8.12.6/Submit) with ESMTP id h9ADXSvx032321 for ; Fri, 10 Oct 2003 15:33:28 +0200 X-Authentication-Warning: alienAngel.home.sk: ja owned process doing -bs Date: Fri, 10 Oct 2003 15:33:28 +0200 (CEST) From: Jan Derfinak X-X-Sender: ja@alienAngel.home.sk To: linux-xfs@oss.sgi.com Subject: xfs removed from ftp? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 684 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ja@mail.upjs.sk Precedence: bulk X-list: linux-xfs Content-Length: 1647 Lines: 50 Hi. During last two weeks there was many problems with ftp access to xfs source code. There were notices about this problems in mailing list but I missed answers. Just now I tried ftp://oss.sgi.com but there is no xfs projects. Does it means that xfs was definitely removed from ftp server? Or it is moved somewhere else? But links from web page still point to ftp://oss.sgi.org/projects/xfs. Is there any official statement? Thanks. jan > ncftp oss.sgi.com NcFTP 3.1.3 (Mar 27, 2002) by Mike Gleason (ncftp@ncftp.com). Connecting to 192.48.159.27... --------- Welcome to Pure-FTPd ---------- You are user number 16 of 50 allowed. Local time is now 06:21. Server port: 21. You will be disconnected after 15 minutes of inactivity. Logging in... ------------------------------------------------------- Welcome to the SGI open source repository. web, ftp and cvs roots are shared for your convenience Thanks for visiting SGI, may the source be with you. ------------------------------------------------------- . . . launch Real Audio. In this case, you want to use the shift trick to download the file as well. Anonymous user logged in Logged in to oss.sgi.com. ncftp / > cd projects ncftp /projects > cd xfs Could not chdir to xfs: server said: Can't change directory to xfs: No such file or directory ncftp /projects > ls OpenOffice.org/ inventor/ mozilla/ performer/ cpumemsets/ kdb/ numa/ rhino/ csa/ kernprof/ ogl-sample/ sgi_propack/ failsafe/ lockmeter/ pagg/ fam/ ltp/ pcp/ ncftp /projects > -- From owner-linux-xfs@oss.sgi.com Fri Oct 10 07:09:13 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 10 Oct 2003 07:09:55 -0700 (PDT) Received: from linux-sxs.org (d60-65-142-166.col.wideopenwest.com [65.60.166.142]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9AE9C25011063 for ; Fri, 10 Oct 2003 07:09:12 -0700 Received: from linux-sxs.org (localhost [127.0.0.1]) by linux-sxs.org (8.12.10/8.12.10) with ESMTP id h9ADd6b7020586; Fri, 10 Oct 2003 09:39:06 -0400 Received: from localhost (netllama@localhost) by linux-sxs.org (8.12.10/8.12.10/Submit) with ESMTP id h9ADd6du020231; Fri, 10 Oct 2003 09:39:06 -0400 Date: Fri, 10 Oct 2003 09:39:06 -0400 (EDT) From: Net Llama! To: Jan Derfinak cc: linux-xfs@oss.sgi.com Subject: Re: xfs removed from ftp? In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: OK, scanned by File::Scan,ClamAV X-Scanned-By: MIMEDefang 2.38 X-archive-position: 685 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: netllama@linux-sxs.org Precedence: bulk X-list: linux-xfs Content-Length: 2382 Lines: 64 I get the bad feeling that we can thank SCO for this. I just wish that some kind of official statement would be made, even if its dripping in protective legalese. If I can't access any XFS code, its going to be damn difficult for me to maintain the array of production servers I have that are all running with XFS right now. Also, XFS remains in the 2.6.x kernel, so i'm not clear on how pulling it from 2.4.x changes much. On Fri, 10 Oct 2003, Jan Derfinak wrote: > Hi. > > During last two weeks there was many problems with ftp access to xfs > source code. There were notices about this problems in mailing list but I > missed answers. Just now I tried ftp://oss.sgi.com but there is no xfs > projects. Does it means that xfs was definitely removed from ftp server? > Or it is moved somewhere else? But links from web page still point to > ftp://oss.sgi.org/projects/xfs. Is there any official statement? > Thanks. > > jan > > > > ncftp oss.sgi.com > NcFTP 3.1.3 (Mar 27, 2002) by Mike Gleason (ncftp@ncftp.com). > Connecting to 192.48.159.27... > --------- Welcome to Pure-FTPd ---------- > You are user number 16 of 50 allowed. > Local time is now 06:21. Server port: 21. > You will be disconnected after 15 minutes of inactivity. > Logging in... > > > ------------------------------------------------------- > Welcome to the SGI open source repository. > web, ftp and cvs roots are shared for your convenience > Thanks for visiting SGI, may the source be with you. > ------------------------------------------------------- > . > . > . > launch Real Audio. In this case, you want to use the shift > trick to download the file as well. > Anonymous user logged in > Logged in to oss.sgi.com. > ncftp / > cd projects > ncftp /projects > cd xfs > Could not chdir to xfs: server said: Can't change directory to xfs: No such > file or directory > ncftp /projects > ls > OpenOffice.org/ inventor/ mozilla/ performer/ > cpumemsets/ kdb/ numa/ rhino/ > csa/ kernprof/ ogl-sample/ sgi_propack/ > failsafe/ lockmeter/ pagg/ > fam/ ltp/ pcp/ > ncftp /projects > > > > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lonni J Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo http://netllama.ipfox.com From owner-linux-xfs@oss.sgi.com Fri Oct 10 17:14:06 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 10 Oct 2003 17:14:47 -0700 (PDT) Received: from cfa.harvard.edu (cfa.harvard.edu [131.142.10.1]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9B0E525001760 for ; Fri, 10 Oct 2003 17:14:06 -0700 Received: from antu (antu [131.142.25.237]) by cfa.harvard.edu (8.12.9-20030924/8.12.9/cfunix Mast-Sol 1.0) with ESMTP id h9B0E4Vk014515 for ; Fri, 10 Oct 2003 20:14:05 -0400 (EDT) Date: Fri, 10 Oct 2003 20:14:04 -0400 (EDT) From: Gaspar Bakos Reply-To: gbakos@cfa.harvard.edu To: linux-xfs@oss.sgi.com Subject: Kernel Oops - still not solved Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 686 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: gbakos@cfa.harvard.edu Precedence: bulk X-list: linux-xfs Content-Length: 3815 Lines: 71 Hi, Some time ago I reported on a problem I encountered. I could still not solve it, but I thought the details might help someone to help me... System: i386 PIV, ASUS mobo, 512Mb RAM, 2 x 80Gb Seagate disks as RAID-1 array, as hda and hdc. I have about 10 partitions on each disk, in the same configuration, and each is run as RAID-1 with its relevant pair on the other disk. Everything has XFS, except for 2 x 1Gb swap. Kernel: 2.4.18, XFS = 1.1, XFS utils are: xfsprogs-2.0.3-0. I have this exact configuration running on two other PCs, and they have been running for 0.5yr now with no hint of problem. Anyway, there is this nasty PC, which crashed, prints an ugly kernel oops in /var/log/messages, then kswapd becomes zombie, sometimes other processes (kupdated) as well, the system starts to behave erratically (shutdown segfaults, CTRL+ALT+DEL segfaults, etc.), and then finally it dies. I booted up XFS RH7,3 CD, and issued an xfs_repair on all the devices, of course none mounted yet, such as: xfs_repair /dev/md0 .... One some of the /dev/md devices, and notably on a third disk (/dev/hdd, not part of the RAID) I get quite a few messages, but xfs_repair vades itself through them, and returns. What I would expect that it repaired the filesystem, and so if I run it again, I don't see any "disconnected inode ..., bad fork, ..." messages. But this is not true; a new xfs_repair produces almost exactly the same messages. Any clue on this? Any idea or suggestion what else should be used? I also issued xfs_check, which seemed to repair things, or at least report. I did not clearly catch if the operations by xfs_check are also WRITE ones, or solely READ. The mystical thing is that if I unplug these two harddrives, hda and hdc, and place them in an identically configured other PC (really all components are the same brand/type), then I see no crashes. It might be only luck, although I applied quite heavy disk IO and CPU-load tests. I replaced the motherboard and VGA card in the original system, moreover, got rid of all unnecessary cards, such as SCSI, watchdog, etc. Crash still happens if I copy a few gigs back and forth, then delete it. Cheers Gaspar Sep 28 21:50:10 hat7 kernel: EFSCORRUPTED returned from file xfs_bmap.c line 4678 Sep 28 21:50:10 hat7 kernel: Unable to handle kernel paging request at virtual address ff00001c Sep 28 21:50:10 hat7 kernel: printing eip: Sep 28 21:50:10 hat7 kernel: c01afd76 Sep 28 21:50:10 hat7 kernel: *pde = 00000000 Sep 28 21:50:10 hat7 kernel: Oops: 0000 Sep 28 21:50:10 hat7 kernel: CPU: 0 Sep 28 21:50:10 hat7 kernel: EIP: 0010:[] Not tainted Sep 28 21:50:10 hat7 kernel: EFLAGS: 00010286 Sep 28 21:50:10 hat7 kernel: eax: 6cc1842c ebx: 6cc1842c ecx: 00000200 edx: 00000200 Sep 28 21:50:10 hat7 kernel: esi: ff000000 edi: 00000000 ebp: cf3dcc80 esp: c1831e9c Sep 28 21:50:10 hat7 kernel: ds: 0018 es: 0018 ss: 0018 Sep 28 21:50:10 hat7 kernel: Process kswapd (pid: 5, stackpage=c1831000) Sep 28 21:50:10 hat7 kernel: Stack: 00000004 cf3ddc6d c019b11b 6cc1842c ff000000 000003de c01c83d7 c01c60f6 Sep 28 21:50:10 hat7 kernel: cf3ddc6d 00000004 cf3ddc84 00000000 cf3dcc80 00000000 c304c483 c01c51a6 Sep 28 21:50:10 hat7 kernel: cf3ddd7c 00000000 cf3dcc80 c02ecc00 00000200 c01c83d7 00000fd8 00000000 Sep 28 21:50:10 hat7 kernel: Call Trace: [] [] [] [] [] Sep 28 21:50:10 hat7 kernel: [] [] [] [] [] [] Sep 28 21:50:10 hat7 kernel: [] [] [] [] [] [] Sep 28 21:50:10 hat7 kernel: [] Sep 28 21:50:10 hat7 kernel: Sep 28 21:50:10 hat7 kernel: Code: f6 46 1c 01 74 26 f6 83 30 02 00 00 10 75 1d 8d 43 18 50 e8 From owner-linux-xfs@oss.sgi.com Sat Oct 11 11:18:25 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 11 Oct 2003 11:19:03 -0700 (PDT) Received: from mail.bardstown.com (IDENT:Y0yN/yZTwYA5g3d9cIIgveHVrHLOawnT@www.bardstown.com [209.215.186.5]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9BIIO25004468 for ; Sat, 11 Oct 2003 11:18:25 -0700 Received: from Debug (IDENT:D7XTtn5oxMVyAKdUuf20L7akhXbVaZst@mail.bardstown.com [209.215.186.5]) by mail.bardstown.com (8.11.6/8.11.6) with SMTP id h9BIHvB31485; Sat, 11 Oct 2003 14:17:57 -0400 Message-Id: <200310111817.h9BIHvB31485@mail.bardstown.com> To: linux-kernel@vger.kernel.org Cc: linux-xfs@oss.sgi.com, kernel@kolivas.org, owen@bardstown.com From: owen@bardstown.com Subject: Kernel Panic on 2.6.0-test5 with XFS filesystem Date: Sat, 11 Oct 2003 18:18:00 GMT X-Mailer: Endymion MailMan Standard Edition v3.0.33 X-archive-position: 687 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: owen@bardstown.com Precedence: bulk X-list: linux-xfs Content-Length: 1177 Lines: 37 Upon an upgrade from the 2.4.22-AC4 series kernel to the 2.6.0-test5 kernel, a serious problem was encountered. A kernel panic occured, stating that the XFS magic number on the root partition was bad. However, 2.4.22-AC4 gave no errors and loaded fine. A bug was filed with Gentoo Linux, detailing this issue. The X86-Kernel team suggested that I follow up with LKML. References: is the original bug report. is a copy of the kernel config I used to build these kernels. is a bug report filed against SGI's XFS team. This problem was encountered on: 2.4.20 kernels Con Kolivas built 2.6.0-test5 kernel Gentoo's 2.4.20-gaming-r5 kernel This problem was NOT encountered on: 2.4.22-ac4 kernel Any followup would be nice :) I have CC'ed the SGI XFS team and Con Kolivas. ***Please CC me on any followup reports. I am not suscribed.*** My sincerest apologies if this is a duplicate report. I STFW many times, but saw nothing similar. -o -- Owen Marshall Systems Administration, Bardstown Internet (502)349-9444 x106 From owner-linux-xfs@oss.sgi.com Sat Oct 11 12:08:09 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 11 Oct 2003 12:08:21 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10) with ESMTP id h9BJ8925006535 for ; Sat, 11 Oct 2003 12:08:09 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id h9BJ89R0006534 for linux-xfs@oss.sgi.com; Sat, 11 Oct 2003 12:08:09 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10) with ESMTP id h9BJ8727006520 for ; Sat, 11 Oct 2003 12:08:07 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id h9BIHAUM004437; Sat, 11 Oct 2003 11:17:10 -0700 Date: Sat, 11 Oct 2003 11:17:10 -0700 Message-Id: <200310111817.h9BIHAUM004437@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 282] New: Kernel panic/Bad magic number on XFS filesystem X-Bugzilla-Reason: AssignedTo X-archive-position: 688 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1026 Lines: 37 http://oss.sgi.com/bugzilla/show_bug.cgi?id=282 Summary: Kernel panic/Bad magic number on XFS filesystem Product: Linux XFS Version: unspecified Platform: All OS/Version: Linux Status: NEW Severity: blocker Priority: High Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: owen@bardstown.com Upon using kernel version 2.6.0-test5, the kernel panics and states that the magic number on my root partition is bad. However, on the 2.4.22-ac4 kernel, this problem does not exist. This problem was encountered on: 2.4.20 kernels Con Kolivas built 2.6.0-test5 kernel Gentoo's 2.4.20-gaming-r5 kernel This problem was NOT encountered on: 2.4.22-ac4 kernel This is a **blocker**. Gentoo's X86-Kernel team states the bug is upstream. I have reported this issue many places :) ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Sat Oct 11 13:23:19 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 11 Oct 2003 13:24:03 -0700 (PDT) Received: from sundancer.oche.de (sundancer.oche.de [194.94.252.29]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9BKNH25014584 for ; Sat, 11 Oct 2003 13:23:19 -0700 Received: by sundancer.oche.de (Postfix, from userid 10) id 09AFD12AFA; Sat, 11 Oct 2003 22:23:13 +0200 (CEST) Received: from foehn.quickstep.oche.de (localhost [127.0.0.1]) by foehn.quickstep.oche.de (8.12.10/8.12.8) with ESMTP id h9BK2Ikq002149 for ; Sat, 11 Oct 2003 22:02:18 +0200 (CEST) Received: (from news@localhost) by foehn.quickstep.oche.de (8.12.10/8.12.8/Submit) id h9BK2GVd002148 for linux-xfs@oss.sgi.com; Sat, 11 Oct 2003 22:02:16 +0200 (CEST) To: linux-xfs@oss.sgi.com Path: not-for-mail From: Martin Spott Newsgroups: list.linux-xfs Subject: Re: xfs removed from ftp? Date: 11 Oct 2003 20:02:16 GMT Organization: home Message-ID: References: NNTP-Posting-Host: osprey.quickstep.oche.de X-Trace: foehn.quickstep.oche.de 1065902536 2089 192.168.48.3 (11 Oct 2003 20:02:16 GMT) X-Complaints-To: usenet@foehn.quickstep.oche.de NNTP-Posting-Date: 11 Oct 2003 20:02:16 GMT User-Agent: tin/1.4.7-20030322 ("Suggestions") (UNIX) (AIX/5-1) X-archive-position: 689 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Martin.Spott@uni-duisburg.de Precedence: bulk X-list: linux-xfs Content-Length: 614 Lines: 14 Jan Derfinak wrote: > During last two weeks there was many problems with ftp access to xfs > source code. There were notices about this problems in mailing list but I > missed answers. Just now I tried ftp://oss.sgi.com but there is no xfs > projects. Does it means that xfs was definitely removed from ftp server? Even if you can't access it on the official site, there are still mirror servers that contain the recent releases, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -------------------------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Sat Oct 11 17:12:59 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 11 Oct 2003 17:13:32 -0700 (PDT) Received: from linux-sxs.org (d60-65-142-166.col.wideopenwest.com [65.60.166.142]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9C0Cw25022058 for ; Sat, 11 Oct 2003 17:12:59 -0700 Received: from linux-sxs.org (localhost [127.0.0.1]) by linux-sxs.org (8.12.10/8.12.10) with ESMTP id h9BNgtb7017553; Sat, 11 Oct 2003 19:42:55 -0400 Received: from localhost (netllama@localhost) by linux-sxs.org (8.12.10/8.12.10/Submit) with ESMTP id h9BNgtbc032403; Sat, 11 Oct 2003 19:42:55 -0400 Date: Sat, 11 Oct 2003 19:42:55 -0400 (EDT) From: Net Llama! To: Martin Spott cc: linux-xfs@oss.sgi.com Subject: Re: xfs removed from ftp? In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: OK, scanned by File::Scan,ClamAV X-Scanned-By: MIMEDefang 2.38 X-archive-position: 690 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: netllama@linux-sxs.org Precedence: bulk X-list: linux-xfs Content-Length: 1001 Lines: 23 On Sat, 11 Oct 2003, Martin Spott wrote: > Jan Derfinak wrote: > > > During last two weeks there was many problems with ftp access to xfs > > source code. There were notices about this problems in mailing list but I > > missed answers. Just now I tried ftp://oss.sgi.com but there is no xfs > > projects. Does it means that xfs was definitely removed from ftp server? > > Even if you can't access it on the official site, there are still > mirror servers that contain the recent releases, That's not true. I googled for the mirrors, and they're all either months out of date, or no longer host the XFS code at all. On the good news front, a person who wishes to remain anonymous told me that everything should be back on the server within a few days, once SGI's legal dept puts together a statement. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lonni J Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo http://netllama.ipfox.com From owner-linux-xfs@oss.sgi.com Sat Oct 11 19:06:31 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 11 Oct 2003 19:07:14 -0700 (PDT) Received: from linux-sxs.org (d60-65-142-166.col.wideopenwest.com [65.60.166.142]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9C26S25024476 for ; Sat, 11 Oct 2003 19:06:30 -0700 Received: from linux-sxs.org (localhost [127.0.0.1]) by linux-sxs.org (8.12.10/8.12.10) with ESMTP id h9C1aNb7023799; Sat, 11 Oct 2003 21:36:23 -0400 Received: from localhost (netllama@localhost) by linux-sxs.org (8.12.10/8.12.10/Submit) with ESMTP id h9C1aNZN000107; Sat, 11 Oct 2003 21:36:23 -0400 Date: Sat, 11 Oct 2003 21:36:23 -0400 (EDT) From: Net Llama! To: Zeitgeist cc: Martin Spott , linux-xfs@oss.sgi.com Subject: Re: xfs removed from ftp? In-Reply-To: <1065924206.24644.1.camel@geist.zeit.zg> Message-ID: References: <1065924206.24644.1.camel@geist.zeit.zg> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: OK, scanned by File::Scan,ClamAV X-Scanned-By: MIMEDefang 2.38 X-archive-position: 691 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: netllama@linux-sxs.org Precedence: bulk X-list: linux-xfs Content-Length: 907 Lines: 23 On Sat, 11 Oct 2003, Zeitgeist wrote: > On Sat, 2003-10-11 at 18:42, Net Llama! wrote: > > On Sat, 11 Oct 2003, Martin Spott wrote: > > > > On the good news front, a person who wishes to remain anonymous told me > > that everything should be back on the server within a few days, once SGI's > > legal dept puts together a statement. > > Why is SGI bending their ass over for these losers? I can't answer that question, because i don't work for SGI. If i had to speculate, i'd say its primarily because SGI is alot smaller (and unfortunately, less stable) of a company than IBM. > All the other companies just ignore them, like SGI should. We all know > the company in question is avoiding actually going into the courtroom > because they have absolutely NO PROOF and just make bogus statements to > inflate their stock prices because nobody buys their shitty, piss-poor > products. No argument there. From owner-linux-xfs@oss.sgi.com Sat Oct 11 19:40:38 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 11 Oct 2003 19:41:14 -0700 (PDT) Received: from hermes.acsalaska.net (hermes.acsalaska.net [209.112.155.38]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9C2ec25025428 for ; Sat, 11 Oct 2003 19:40:38 -0700 Received: from erbenson.alaska.net (50-pm1.nwc.alaska.net [209.112.138.50]) by hermes.acsalaska.net (8.12.10/8.12.10) with ESMTP id h9C2eZMB063891 for ; Sat, 11 Oct 2003 18:40:36 -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 C7E0039E5 for ; Sat, 11 Oct 2003 18:40:33 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id 6ABB440FF35; Sat, 11 Oct 2003 18:40:34 -0800 (AKDT) Date: Sat, 11 Oct 2003 18:40:34 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: xfs removed from ftp? Message-ID: <20031012024034.GC24569@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KN5l+BnMqAQyZLvT" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-ACS-Spam-Status: no X-ACS-Scanned-By: MD 2.37; SA 2.60; spamdefang 1.58 X-archive-position: 692 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: erbenson@alaska.net Precedence: bulk X-list: linux-xfs Content-Length: 1719 Lines: 52 --KN5l+BnMqAQyZLvT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Oct 11, 2003 at 07:42:55PM -0400, Net Llama! wrote: > On Sat, 11 Oct 2003, Martin Spott wrote: > > Jan Derfinak wrote: > > > > > During last two weeks there was many problems with ftp access to xfs > > > source code. There were notices about this problems in mailing list b= ut I > > > missed answers. Just now I tried ftp://oss.sgi.com but there is no xfs > > > projects. Does it means that xfs was definitely removed from ftp serv= er? > > > > Even if you can't access it on the official site, there are still > > mirror servers that contain the recent releases, >=20 > That's not true. I googled for the mirrors, and they're all either months > out of date, or no longer host the XFS code at all. well if the mirror is activly mirroring the main sgi site then the mirror will reflect the deletion of all the XFS files. > On the good news front, a person who wishes to remain anonymous told me > that everything should be back on the server within a few days, once SGI's > legal dept puts together a statement. hrm, well i certianly hope they don't decide to wait until SCO is told to FOAD in court, as that won't happen till 2005 + years later. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --KN5l+BnMqAQyZLvT 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 iEYEARECAAYFAj+IvyIACgkQJKx7GixEevyWqwCePj5MsR4i5WmGUnBtDGsztnG5 mOIAnj37HCWqkrBvOacmWamL5y9/Z2XD =+Ysi -----END PGP SIGNATURE----- --KN5l+BnMqAQyZLvT-- From owner-linux-xfs@oss.sgi.com Sat Oct 11 20:43:10 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 11 Oct 2003 20:43:44 -0700 (PDT) Received: from linux-sxs.org (d60-65-142-166.col.wideopenwest.com [65.60.166.142]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9C3h925029981 for ; Sat, 11 Oct 2003 20:43:09 -0700 Received: from linux-sxs.org (localhost [127.0.0.1]) by linux-sxs.org (8.12.10/8.12.10) with ESMTP id h9C3D3b7010320; Sat, 11 Oct 2003 23:13:04 -0400 Received: from localhost (netllama@localhost) by linux-sxs.org (8.12.10/8.12.10/Submit) with ESMTP id h9C3D3Sj014329; Sat, 11 Oct 2003 23:13:03 -0400 Date: Sat, 11 Oct 2003 23:13:03 -0400 (EDT) From: Net Llama! To: Ethan Benson cc: linux-xfs@oss.sgi.com Subject: Re: xfs removed from ftp? In-Reply-To: <20031012024034.GC24569@plato.local.lan> Message-ID: References: <20031012024034.GC24569@plato.local.lan> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: OK, scanned by File::Scan,ClamAV X-Scanned-By: MIMEDefang 2.38 X-archive-position: 694 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: netllama@linux-sxs.org Precedence: bulk X-list: linux-xfs Content-Length: 593 Lines: 15 On Sat, 11 Oct 2003, Ethan Benson wrote: > > On the good news front, a person who wishes to remain anonymous told me > > that everything should be back on the server within a few days, once SGI's > > legal dept puts together a statement. > > hrm, well i certianly hope they don't decide to wait until SCO is told > to FOAD in court, as that won't happen till 2005 + years later. cvs should be working right now. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lonni J Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo http://netllama.ipfox.com From owner-linux-xfs@oss.sgi.com Sat Oct 11 20:42:36 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 11 Oct 2003 20:43:15 -0700 (PDT) Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9C3gX25029959 for ; Sat, 11 Oct 2003 20:42:34 -0700 Received: (qmail 28983 invoked from network); 12 Oct 2003 03:42:31 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 12 Oct 2003 03:42:30 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 46411C00AE; Sun, 12 Oct 2003 13:42: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 436F014008A for ; Sun, 12 Oct 2003 13:42:21 +1000 (EST) X-Mailer: exmh version 2.5 01/15/2001 with nmh-1.0.4 From: Keith Owens To: linux-xfs@oss.sgi.com Subject: Re: xfs removed from ftp? In-reply-to: Your message of "Sat, 11 Oct 2003 21:36:23 -0400." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 12 Oct 2003 13:42:20 +1000 Message-ID: <27001.1065930140@ocs3.intra.ocs.com.au> X-archive-position: 693 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@ocs.com.au Precedence: bulk X-list: linux-xfs Content-Length: 820 Lines: 22 On Sat, 11 Oct 2003 21:36:23 -0400 (EDT), Net Llama! wrote: >On Sat, 11 Oct 2003, Zeitgeist wrote: > >> On Sat, 2003-10-11 at 18:42, Net Llama! wrote: >> > On Sat, 11 Oct 2003, Martin Spott wrote: >> > >> > On the good news front, a person who wishes to remain anonymous told me >> > that everything should be back on the server within a few days, once SGI's >> > legal dept puts together a statement. >> >> Why is SGI bending their ass over for these losers? > >I can't answer that question, because i don't work for SGI. If i had to >speculate, i'd say its primarily because SGI is alot smaller (and >unfortunately, less stable) of a company than IBM. For SGI's response, see http://oss.sgi.com/letter_100103.txt Paragraphs 4 and 5 answer this question. Not speaking for SGI, IANAL, etc. From owner-linux-xfs@oss.sgi.com Sat Oct 11 21:04:21 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 11 Oct 2003 21:04:56 -0700 (PDT) Received: from hob.acsalaska.net (hob.acsalaska.net [209.112.155.42]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9C44K25031190 for ; Sat, 11 Oct 2003 21:04:20 -0700 Received: from erbenson.alaska.net (50-pm1.nwc.alaska.net [209.112.138.50]) by hob.acsalaska.net (8.12.10/8.12.10) with ESMTP id h9C44ImF057080 for ; Sat, 11 Oct 2003 20:04: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 C1E1339E5 for ; Sat, 11 Oct 2003 20:04:17 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id 462EA40FF35; Sat, 11 Oct 2003 20:04:17 -0800 (AKDT) Date: Sat, 11 Oct 2003 20:04:17 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: xfs removed from ftp? Message-ID: <20031012040417.GD24569@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <27001.1065930140@ocs3.intra.ocs.com.au> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="JwB53PgKC5A7+0Ej" Content-Disposition: inline In-Reply-To: <27001.1065930140@ocs3.intra.ocs.com.au> User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-ACS-Spam-Status: no X-ACS-Scanned-By: MD 2.37; SA 2.60; spamdefang 1.58 X-archive-position: 695 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: erbenson@alaska.net Precedence: bulk X-list: linux-xfs Content-Length: 1626 Lines: 54 --JwB53PgKC5A7+0Ej Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Oct 12, 2003 at 01:42:20PM +1000, Keith Owens wrote: > On Sat, 11 Oct 2003 21:36:23 -0400 (EDT),=20 > Net Llama! wrote: > >On Sat, 11 Oct 2003, Zeitgeist wrote: > > > >> On Sat, 2003-10-11 at 18:42, Net Llama! wrote: > >> > On Sat, 11 Oct 2003, Martin Spott wrote: > >> > > >> > On the good news front, a person who wishes to remain anonymous told= me > >> > that everything should be back on the server within a few days, once= SGI's > >> > legal dept puts together a statement. > >> > >> Why is SGI bending their ass over for these losers? > > > >I can't answer that question, because i don't work for SGI. If i had to > >speculate, i'd say its primarily because SGI is alot smaller (and > >unfortunately, less stable) of a company than IBM. >=20 > For SGI's response, see http://oss.sgi.com/letter_100103.txt > Paragraphs 4 and 5 answer this question. >=20 > Not speaking for SGI, IANAL, etc. also the xfs dir is available now, but no code is there yet. however there is a README explaining this: ftp://oss.sgi.com/projects/xfs/download/README --=20 Ethan Benson http://www.alaska.net/~erbenson/ --JwB53PgKC5A7+0Ej 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 iEYEARECAAYFAj+I0sEACgkQJKx7GixEevzN7gCeNcMUMC7iPClDBNKzDqUkqyRk f/QAn1k53sQk/Bi5TYe/YWuimcGBmWKM =+slp -----END PGP SIGNATURE----- --JwB53PgKC5A7+0Ej-- From owner-linux-xfs@oss.sgi.com Sun Oct 12 02:23:20 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 12 Oct 2003 02:23:59 -0700 (PDT) Received: from sundancer.oche.de (sundancer.oche.de [194.94.252.29]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9C9NH25007816 for ; Sun, 12 Oct 2003 02:23:18 -0700 Received: by sundancer.oche.de (Postfix, from userid 10) id C102E12670; Sun, 12 Oct 2003 11:23:12 +0200 (CEST) Received: from foehn.quickstep.oche.de (localhost [127.0.0.1]) by foehn.quickstep.oche.de (8.12.10/8.12.8) with ESMTP id h9C9JRkq013413 for ; Sun, 12 Oct 2003 11:19:27 +0200 (CEST) Received: (from news@localhost) by foehn.quickstep.oche.de (8.12.10/8.12.8/Submit) id h9C9JPLY013412 for linux-xfs@oss.sgi.com; Sun, 12 Oct 2003 11:19:25 +0200 (CEST) To: linux-xfs@oss.sgi.com Path: not-for-mail From: Martin Spott Newsgroups: list.linux-xfs Subject: Re: xfs removed from ftp? Date: 12 Oct 2003 09:19:25 GMT Organization: home Message-ID: References: NNTP-Posting-Host: osprey.quickstep.oche.de X-Trace: foehn.quickstep.oche.de 1065950365 13298 192.168.48.3 (12 Oct 2003 09:19:25 GMT) X-Complaints-To: usenet@foehn.quickstep.oche.de NNTP-Posting-Date: 12 Oct 2003 09:19:25 GMT User-Agent: tin/1.4.7-20030322 ("Suggestions") (UNIX) (AIX/5-1) X-archive-position: 696 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Martin.Spott@uni-duisburg.de Precedence: bulk X-list: linux-xfs Content-Length: 487 Lines: 17 Net Llama! wrote: > On Sat, 11 Oct 2003, Martin Spott wrote: >> Even if you can't access it on the official site, there are still >> mirror servers that contain the recent releases, > > That's not true. You don't believe me without a proof ? Please see: ftp://ftp.ihg.uni-duisburg.de/Mirrors/ Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -------------------------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Sun Oct 12 06:22:17 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 12 Oct 2003 06:22:59 -0700 (PDT) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9CDMG25024134 for ; Sun, 12 Oct 2003 06:22:16 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h9CBQIOO014948 for ; Sun, 12 Oct 2003 04:26:18 -0700 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h9CDMAcc12129595; Sun, 12 Oct 2003 08:22:10 -0500 (CDT) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-32.corp.sgi.com [134.15.64.32]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h9CDM8Rn322516650; Sun, 12 Oct 2003 08:22:09 -0500 (CDT) Subject: Re: xfs removed from ftp? it's back From: Steve Lord To: Ethan Benson Cc: linux-xfs@oss.sgi.com In-Reply-To: <20031012040417.GD24569@plato.local.lan> References: <27001.1065930140@ocs3.intra.ocs.com.au> <20031012040417.GD24569@plato.local.lan> Content-Type: text/plain Organization: Message-Id: <1065964924.1507.7.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 12 Oct 2003 08:22:04 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 697 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 599 Lines: 20 On Sat, 2003-10-11 at 23:04, Ethan Benson wrote: > > also the xfs dir is available now, but no code is there yet. however > there is a README explaining this: > > ftp://oss.sgi.com/projects/xfs/download/README There is code in there, sorry things were down for some time, we were under instruction not to say anything about this. The README is what we are allowed to say about it. Unfortunately, we were asked to remove all old content and recreate new content, which is why you see less than there used to be. You can blame you know who for all of this. Steve -- Steve Lord From owner-linux-xfs@oss.sgi.com Sun Oct 12 20:36:48 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 12 Oct 2003 20:37:22 -0700 (PDT) Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9D3al25024407 for ; Sun, 12 Oct 2003 20:36:48 -0700 Received: from geist.zeit.zg (pcp558713pcs.rthfrd01.tn.comcast.net[68.52.100.149]) by comcast.net (sccrmhc11) with SMTP id <2003101202023701100otqise>; Sun, 12 Oct 2003 02:02:37 +0000 Subject: Re: xfs removed from ftp? From: Zeitgeist To: Net Llama! Cc: Martin Spott , linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Message-Id: <1065924206.24644.1.camel@geist.zeit.zg> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Sat, 11 Oct 2003 21:03:26 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 698 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: zeitgeist@comcast.net Precedence: bulk X-list: linux-xfs Content-Length: 633 Lines: 15 On Sat, 2003-10-11 at 18:42, Net Llama! wrote: > On Sat, 11 Oct 2003, Martin Spott wrote: > > On the good news front, a person who wishes to remain anonymous told me > that everything should be back on the server within a few days, once SGI's > legal dept puts together a statement. Why is SGI bending their ass over for these losers? All the other companies just ignore them, like SGI should. We all know the company in question is avoiding actually going into the courtroom because they have absolutely NO PROOF and just make bogus statements to inflate their stock prices because nobody buys their shitty, piss-poor products. From owner-linux-xfs@oss.sgi.com Mon Oct 13 00:55:39 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 13 Oct 2003 00:56:20 -0700 (PDT) Received: from mail.dev.rtsoft.ru (RT-soft-2.Moscow.itn.ru [80.240.96.70]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9D7ta25022136 for ; Mon, 13 Oct 2003 00:55:37 -0700 Received: (qmail 13183 invoked from network); 13 Oct 2003 07:48:32 -0000 Received: from maya.dev.rtsoft.ru (192.168.1.211) by mail.dev.rtsoft.ru with SMTP; 13 Oct 2003 07:48:32 -0000 From: Roman Vasylyev Organization: RTsoft To: linux-xfs@oss.sgi.com Subject: kernel warnings on xfstest 013 Date: Mon, 13 Oct 2003 11:55:23 +0400 User-Agent: KMail/1.5 MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_rpli/5A6EqTji6s" Message-Id: <200310131155.24320.romis@dev.rtsoft.ru> X-archive-position: 699 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: romis@dev.rtsoft.ru Precedence: bulk X-list: linux-xfs Content-Length: 26739 Lines: 1077 --Boundary-00=_rpli/5A6EqTji6s Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, I need to test created XFS filesystems. And for that i choose xfstests from xfs-cmds CVStree. On test 013 i starts to receive very much kernel warnings: XFS mounting filesystem ide0(3,8) Ending clean XFS mount for filesystem: ide0(3,8) Filesystem "ide0(3,8)": xfs_dilocate: agno (1108) >= mp->m_sb.sb_agcount (8) Filesystem "ide0(3,8)": xfs_dilocate: agno (5080) >= mp->m_sb.sb_agcount (8) Filesystem "ide0(3,8)": xfs_dilocate: agno (7288) >= mp->m_sb.sb_agcount (8) Filesystem "ide0(3,8)": xfs_dilocate: agno (576) >= mp->m_sb.sb_agcount (8) Filesystem "ide0(3,8)": xfs_dilocate: agno (2452) >= mp->m_sb.sb_agcount (8) Filesystem "ide0(3,8)": xfs_dilocate: agno (6028) >= mp->m_sb.sb_agcount (8) Filesystem "ide0(3,8)": xfs_dilocate: agno (34) >= mp->m_sb.sb_agcount (8) Filesystem "ide0(3,8)": xfs_dilocate: agno (3469) >= mp->m_sb.sb_agcount (8) Filesystem "ide0(3,8)": xfs_dilocate: agno (7052) >= mp->m_sb.sb_agcount (8) Filesystem "ide0(3,8)": xfs_dilocate: agno (1728) >= mp->m_sb.sb_agcount (8) Filesystem "ide0(3,8)": xfs_dilocate: agno (2437) >= mp->m_sb.sb_agcount (8) Filesystem "ide0(3,8)": xfs_dilocate: agno (3803) >= mp->m_sb.sb_agcount (8) Filesystem "ide0(3,8)": xfs_dilocate: agno (137) >= mp->m_sb.sb_agcount (8) Filesystem "ide0(3,8)": xfs_dilocate: agno (7262) >= mp->m_sb.sb_agcount (8) Filesystem "ide0(3,8)": xfs_dilocate: agno (4531) >= mp->m_sb.sb_agcount (8) Filesystem "ide0(3,8)": xfs_dilocate: agno (302) >= mp->m_sb.sb_agcount (8) Filesystem "ide0(3,8)": xfs_dilocate: agno (3194) >= mp->m_sb.sb_agcount (8) Filesystem "ide0(3,8)": xfs_dilocate: agno (1203) >= mp->m_sb.sb_agcount (8) Filesystem "ide0(3,8)": xfs_dilocate: agno (7886) >= mp->m_sb.sb_agcount (8) Filesystem "ide0(3,8)": xfs_dilocate: agno (1198) >= mp->m_sb.sb_agcount (8) Filesystem "ide0(3,8)": xfs_dilocate: agno (4473) >= mp->m_sb.sb_agcount (8) Filesystem "ide0(3,8)": xfs_dilocate: agno (2527) >= mp->m_sb.sb_agcount (8) Filesystem "ide0(3,8)": xfs_dilocate: agno (427) >= mp->m_sb.sb_agcount (8) ........................... e.t.c. Did some one explain why this happends. Test 013 not unique. 013, 014,015. All makes this warning. I have Linux-kenrel-2.4.21 from kernel.org. With applyed patch linux-2.4.21-core-xfs-1.3.0.patch.gz and linux-xfs-1.3.0.patch.gz ------------------------------------------------------------------- My partitions: [root@maya xfs]# /sbin/fdisk -l Disk /dev/hda: 80.0 GB, 80026361856 bytes 255 heads, 63 sectors/track, 9729 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/hda1 1 638 5124703+ 7 HPFS/NTFS /dev/hda2 639 8582 63810180 f Win95 Ext'd (LBA) /dev/hda5 639 5738 40965718+ b Win95 FAT32 /dev/hda6 5739 5869 1052226 82 Linux swap /dev/hda7 5870 8454 20763981 83 Linux /dev/hda8 8455 8518 514048+ 83 Linux /dev/hda9 8519 8582 514048+ 83 Linux ------------------------------------------------------------------- in common.config known_hosts() { case "$HOST" in maya) TEST_DEV=/dev/hda8 TEST_DIR=/mnt/xfs0 SCRATCH_DEV=/dev/hda9 SCRATCH_MNT=/mnt/xfs1 ;; --------------------------------------------------------------------- in attached file saved kernel configuration. --Boundary-00=_rpli/5A6EqTji6s Content-Type: text/plain; charset="us-ascii"; name=".config" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=".config" # # Automatically generated by make menuconfig: don't edit # CONFIG_X86=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_MK8 is not set # CONFIG_MELAN is not set # CONFIG_MCRUSOE is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set CONFIG_X86_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_HAS_TSC=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_PGE=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_F00F_WORKS_OK=y CONFIG_X86_MCE=y # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set # CONFIG_HIGHMEM is not set # CONFIG_MATH_EMULATION is not set # CONFIG_MTRR is not set CONFIG_SMP=y # CONFIG_X86_NUMA is not set # CONFIG_X86_TSC_DISABLE is not set CONFIG_X86_TSC=y CONFIG_HAVE_DEC_LOCK=y # # General setup # CONFIG_NET=y CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=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_ISA=y CONFIG_PCI_NAMES=y # CONFIG_EISA is not set # CONFIG_MCA is not set CONFIG_HOTPLUG=y # # PCMCIA/CardBus support # CONFIG_PCMCIA=y CONFIG_CARDBUS=y # CONFIG_TCIC is not set # CONFIG_I82092 is not set # CONFIG_I82365 is not set # # PCI Hotplug Support # # CONFIG_HOTPLUG_PCI is not set # CONFIG_HOTPLUG_PCI_COMPAQ is not set # CONFIG_HOTPLUG_PCI_COMPAQ_NVRAM is not set # CONFIG_HOTPLUG_PCI_IBM is not set # CONFIG_HOTPLUG_PCI_ACPI is not set 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=y CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=y CONFIG_PM=y # CONFIG_ACPI is not set # CONFIG_APM is not set # # Memory Technology Devices (MTD) # CONFIG_MTD=m # CONFIG_MTD_DEBUG is not set # CONFIG_MTD_PARTITIONS is not set # CONFIG_MTD_CONCAT is not set # CONFIG_MTD_REDBOOT_PARTS is not set # CONFIG_MTD_CMDLINE_PARTS is not set # CONFIG_MTD_CHAR is not set # CONFIG_MTD_BLOCK is not set # CONFIG_MTD_BLOCK_RO is not set # CONFIG_FTL is not set # CONFIG_NFTL is not set # # RAM/ROM/Flash chip drivers # # CONFIG_MTD_CFI is not set # CONFIG_MTD_JEDECPROBE is not set # CONFIG_MTD_GEN_PROBE is not set # CONFIG_MTD_CFI_INTELEXT is not set # CONFIG_MTD_CFI_AMDSTD is not set # CONFIG_MTD_CFI_STAA is not set # CONFIG_MTD_RAM is not set # CONFIG_MTD_ROM is not set # CONFIG_MTD_ABSENT is not set # CONFIG_MTD_OBSOLETE_CHIPS is not set # CONFIG_MTD_AMDSTD is not set # CONFIG_MTD_SHARP is not set # CONFIG_MTD_JEDEC is not set # # Mapping drivers for chip access # # CONFIG_MTD_PHYSMAP is not set # CONFIG_MTD_PNC2000 is not set # CONFIG_MTD_SC520CDP is not set # CONFIG_MTD_NETSC520 is not set # CONFIG_MTD_SBC_GXX is not set # CONFIG_MTD_ELAN_104NC is not set # CONFIG_MTD_DILNETPC is not set # CONFIG_MTD_MIXMEM is not set # CONFIG_MTD_OCTAGON is not set # CONFIG_MTD_VMAX is not set # CONFIG_MTD_SCx200_DOCFLASH is not set # CONFIG_MTD_L440GX is not set # CONFIG_MTD_AMD76XROM is not set # CONFIG_MTD_ICH2ROM is not set # CONFIG_MTD_NETtel is not set # CONFIG_MTD_SCB2_FLASH is not set # CONFIG_MTD_PCI is not set # CONFIG_MTD_PCMCIA is not set # # Self-contained MTD device drivers # # CONFIG_MTD_PMC551 is not set # CONFIG_MTD_SLRAM is not set # CONFIG_MTD_MTDRAM is not set # CONFIG_MTD_BLKMTD is not set # CONFIG_MTD_DOC1000 is not set # CONFIG_MTD_DOC2000 is not set # CONFIG_MTD_DOC2001 is not set # CONFIG_MTD_DOCPROBE is not set # # NAND Flash Device Drivers # # CONFIG_MTD_NAND is not set # # Parallel port support # CONFIG_PARPORT=m # CONFIG_PARPORT_PC is not set # CONFIG_PARPORT_AMIGA is not set # CONFIG_PARPORT_MFC3 is not set # CONFIG_PARPORT_ATARI is not set # CONFIG_PARPORT_GSC is not set # CONFIG_PARPORT_SUNBPP is not set # CONFIG_PARPORT_OTHER is not set # CONFIG_PARPORT_1284 is not set # # Plug and Play configuration # CONFIG_PNP=y CONFIG_ISAPNP=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_CISS_SCSI_TAPE is not set # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_UMEM is not set CONFIG_BLK_DEV_LOOP=m CONFIG_BLK_DEV_NBD=m CONFIG_BLK_DEV_RAM=m CONFIG_BLK_DEV_RAM_SIZE=4096 # CONFIG_BLK_DEV_INITRD is not set # CONFIG_BLK_STATS 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 is not set # CONFIG_NETLINK_DEV is not set CONFIG_NETFILTER=y # CONFIG_NETFILTER_DEBUG is not set CONFIG_FILTER=y CONFIG_UNIX=y CONFIG_INET=y # CONFIG_IP_MULTICAST is not set # CONFIG_IP_ADVANCED_ROUTER is not set # CONFIG_IP_PNP is not set # CONFIG_NET_IPIP is not set # CONFIG_NET_IPGRE is not set # CONFIG_ARPD is not set # CONFIG_INET_ECN is not set # CONFIG_SYN_COOKIES is not set # # IP: Netfilter Configuration # # CONFIG_IP_NF_CONNTRACK is not set # CONFIG_IP_NF_QUEUE is not set # CONFIG_IP_NF_IPTABLES is not set # CONFIG_IP_NF_ARPTABLES is not set # 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_VLAN_8021Q is not set # CONFIG_IPX is not set # CONFIG_ATALK is not set # # Appletalk devices # # CONFIG_DEV_APPLETALK 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 # # Network testing # # CONFIG_NET_PKTGEN 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 # 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_IDEDISK_STROKE is not set # CONFIG_BLK_DEV_IDECS is not set CONFIG_BLK_DEV_IDECD=y # CONFIG_BLK_DEV_IDETAPE is not set # CONFIG_BLK_DEV_IDEFLOPPY is not set # CONFIG_BLK_DEV_IDESCSI is not set # CONFIG_IDE_TASK_IOCTL is not set CONFIG_BLK_DEV_CMD640=y # CONFIG_BLK_DEV_CMD640_ENHANCED is not set # CONFIG_BLK_DEV_ISAPNP is not set CONFIG_BLK_DEV_IDEPCI=y # CONFIG_BLK_DEV_GENERIC is not set CONFIG_IDEPCI_SHARE_IRQ=y CONFIG_BLK_DEV_IDEDMA_PCI=y # CONFIG_BLK_DEV_OFFBOARD is not set # CONFIG_BLK_DEV_IDEDMA_FORCED is not set CONFIG_IDEDMA_PCI_AUTO=y # CONFIG_IDEDMA_ONLYDISK is not set CONFIG_BLK_DEV_IDEDMA=y # CONFIG_IDEDMA_PCI_WIP is not set # CONFIG_BLK_DEV_ADMA100 is not set # CONFIG_BLK_DEV_AEC62XX 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_TRIFLEX 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_BLK_DEV_NS87415 is not set # CONFIG_BLK_DEV_OPTI621 is not set # CONFIG_BLK_DEV_PDC202XX_OLD is not set # CONFIG_PDC202XX_BURST is not set # CONFIG_BLK_DEV_PDC202XX_NEW is not set CONFIG_BLK_DEV_RZ1000=y # CONFIG_BLK_DEV_SC1200 is not set # CONFIG_BLK_DEV_SVWKS is not set # CONFIG_BLK_DEV_SIIMAGE is not set # CONFIG_BLK_DEV_SIS5513 is not set # CONFIG_BLK_DEV_SLC90E66 is not set # CONFIG_BLK_DEV_TRM290 is not set CONFIG_BLK_DEV_VIA82CXXX=m # 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 # CONFIG_BLK_DEV_ATARAID_SII 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 is not set # CONFIG_I2O_PCI is not set # CONFIG_I2O_BLOCK is not set # CONFIG_I2O_LAN is not set # CONFIG_I2O_SCSI is not set # CONFIG_I2O_PROC is not set # # 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=y # CONFIG_SUNLANCE is not set # CONFIG_HAPPYMEAL is not set # CONFIG_SUNBMAC is not set # CONFIG_SUNQE is not set # CONFIG_SUNGEM is not set CONFIG_NET_VENDOR_3COM=y # CONFIG_EL1 is not set # CONFIG_EL2 is not set # CONFIG_ELPLUS is not set # CONFIG_EL16 is not set # CONFIG_EL3 is not set # CONFIG_3C515 is not set # CONFIG_ELMC is not set # CONFIG_ELMC_II is not set CONFIG_VORTEX=m # CONFIG_TYPHOON is not set # CONFIG_LANCE is not set # CONFIG_NET_VENDOR_SMC is not set # CONFIG_NET_VENDOR_RACAL is not set # CONFIG_AT1700 is not set # CONFIG_DEPCA is not set # CONFIG_HP100 is not set # CONFIG_NET_ISA is not set # CONFIG_NET_PCI is not set # CONFIG_NET_POCKET is not set # # Ethernet (1000 Mbit) # # CONFIG_ACENIC is not set # CONFIG_DL2K is not set # CONFIG_E1000 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_R8169 is not set # CONFIG_SK98LIN is not set # CONFIG_TIGON3 is not set # CONFIG_FDDI is not set # CONFIG_HIPPI is not set # CONFIG_PLIP is not set # CONFIG_PPP 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=y # CONFIG_PCMCIA_AXNET is not set # 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=y CONFIG_PCMCIA_RAYCS=y # CONFIG_PCMCIA_NETWAVE is not set # CONFIG_PCMCIA_WAVELAN is not set # CONFIG_AIRONET4500_CS is not set # # Amateur Radio support # # CONFIG_HAMRADIO is not set # # IrDA (infrared) support # # CONFIG_IRDA is not set # # 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=m CONFIG_INPUT_KEYBDEV=m CONFIG_INPUT_MOUSEDEV=m CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 CONFIG_INPUT_JOYDEV=m CONFIG_INPUT_EVDEV=m # # 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 is not set # CONFIG_PPDEV is not set # CONFIG_TIPAR 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 # CONFIG_MK712_MOUSE is not set # # Joysticks # # CONFIG_INPUT_GAMEPORT is not set # CONFIG_INPUT_NS558 is not set # CONFIG_INPUT_LIGHTNING is not set # CONFIG_INPUT_PCIGAME is not set # CONFIG_INPUT_CS461X is not set # CONFIG_INPUT_EMU10K1 is not set # CONFIG_INPUT_SERIO is not set # CONFIG_INPUT_SERPORT is not set # CONFIG_INPUT_ANALOG is not set # CONFIG_INPUT_A3D is not set # CONFIG_INPUT_ADI is not set # CONFIG_INPUT_COBRA is not set # CONFIG_INPUT_GF2K is not set # CONFIG_INPUT_GRIP is not set # CONFIG_INPUT_INTERACT is not set # CONFIG_INPUT_TMDC is not set # CONFIG_INPUT_SIDEWINDER is not set # CONFIG_INPUT_IFORCE_USB is not set # CONFIG_INPUT_IFORCE_232 is not set # CONFIG_INPUT_WARRIOR is not set # CONFIG_INPUT_MAGELLAN is not set # CONFIG_INPUT_SPACEORB is not set # CONFIG_INPUT_SPACEBALL is not set # CONFIG_INPUT_STINGER is not set # CONFIG_INPUT_DB9 is not set # CONFIG_INPUT_GAMECON is not set # CONFIG_INPUT_TURBOGRAFX is not set # CONFIG_QIC02_TAPE is not set # CONFIG_IPMI_HANDLER is not set # CONFIG_IPMI_PANIC_EVENT is not set # CONFIG_IPMI_DEVICE_INTERFACE is not set # CONFIG_IPMI_KCS is not set # CONFIG_IPMI_WATCHDOG is not set # # Watchdog Cards # # CONFIG_WATCHDOG is not set # CONFIG_SCx200_GPIO is not set # CONFIG_AMD_RNG is not set # CONFIG_INTEL_RNG is not set # CONFIG_AMD_PM768 is not set CONFIG_NVRAM=m CONFIG_RTC=m # 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=y CONFIG_AGP_VIA=y CONFIG_AGP_AMD=y # CONFIG_AGP_AMD_8151 is not set CONFIG_AGP_SIS=y CONFIG_AGP_ALI=y # CONFIG_AGP_SWORKS is not set CONFIG_DRM=y # CONFIG_DRM_OLD is not set CONFIG_DRM_NEW=y CONFIG_DRM_TDFX=y # CONFIG_DRM_R128 is not set CONFIG_DRM_RADEON=y CONFIG_DRM_I810=y CONFIG_DRM_I810_XFREE_41=y # CONFIG_DRM_I830 is not set # CONFIG_DRM_MGA is not set # CONFIG_DRM_SIS is not set # # PCMCIA character devices # # CONFIG_PCMCIA_SERIAL_CS is not set # CONFIG_SYNCLINK_CS is not set # CONFIG_MWAVE is not set # # Multimedia devices # # CONFIG_VIDEO_DEV is not set # # File systems # CONFIG_QUOTA=y CONFIG_QFMT_V1=m CONFIG_QFMT_V2=m CONFIG_QIFACE_COMPAT=y CONFIG_QIFACE_V1=y # CONFIG_QIFACE_V2 is not set CONFIG_AUTOFS_FS=m CONFIG_AUTOFS4_FS=y CONFIG_REISERFS_FS=m CONFIG_REISERFS_CHECK=y CONFIG_REISERFS_PROC_INFO=y # 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_BEFS_FS is not set # CONFIG_BEFS_DEBUG is not set # CONFIG_BFS_FS is not set CONFIG_EXT3_FS=y CONFIG_JBD=y CONFIG_JBD_DEBUG=y CONFIG_FAT_FS=m CONFIG_MSDOS_FS=m CONFIG_UMSDOS_FS=m CONFIG_VFAT_FS=m # CONFIG_EFS_FS is not set CONFIG_JFFS_FS=m CONFIG_JFFS_FS_VERBOSE=0 CONFIG_JFFS_PROC_FS=y CONFIG_JFFS2_FS=m CONFIG_JFFS2_FS_DEBUG=2 CONFIG_CRAMFS=m CONFIG_TMPFS=y CONFIG_RAMFS=y CONFIG_ISO9660_FS=y CONFIG_JOLIET=y CONFIG_ZISOFS=y CONFIG_JFS_FS=m # CONFIG_JFS_DEBUG is not set # CONFIG_JFS_STATISTICS is not set # CONFIG_MINIX_FS is not set CONFIG_VXFS_FS=m CONFIG_NTFS_FS=m CONFIG_NTFS_RW=y CONFIG_HPFS_FS=y 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=m CONFIG_QNX4FS_RW=y # 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=m CONFIG_UFS_FS_WRITE=y CONFIG_XFS_FS=y CONFIG_XFS_POSIX_ACL=y CONFIG_XFS_RT=y CONFIG_XFS_QUOTA=y CONFIG_XFS_DMAPI=y CONFIG_XFS_DEBUG=y # CONFIG_PAGEBUF_DEBUG is not set # # Network File Systems # # CONFIG_CODA_FS is not set # CONFIG_INTERMEZZO_FS is not set CONFIG_NFS_FS=y # CONFIG_NFS_V3 is not set # CONFIG_ROOT_NFS is not set CONFIG_NFSD=y # CONFIG_NFSD_V3 is not set # CONFIG_NFSD_TCP is not set CONFIG_SUNRPC=y CONFIG_LOCKD=y # 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 CONFIG_ZISOFS_FS=y # # Partition Types # CONFIG_PARTITION_ADVANCED=y # CONFIG_ACORN_PARTITION is not set # CONFIG_OSF_PARTITION is not set # CONFIG_AMIGA_PARTITION is not set # CONFIG_ATARI_PARTITION is not set # CONFIG_MAC_PARTITION is not set CONFIG_MSDOS_PARTITION=y CONFIG_BSD_DISKLABEL=y # CONFIG_MINIX_SUBPARTITION is not set # CONFIG_SOLARIS_X86_PARTITION is not set # CONFIG_UNIXWARE_DISKLABEL is not set # CONFIG_LDM_PARTITION is not set CONFIG_SGI_PARTITION=y # CONFIG_ULTRIX_PARTITION is not set # CONFIG_SUN_PARTITION is not set # CONFIG_EFI_PARTITION is not set # CONFIG_SMB_NLS is not set CONFIG_NLS=y # # Native Language Support # CONFIG_NLS_DEFAULT="iso8859-1" # CONFIG_NLS_CODEPAGE_437 is not set # CONFIG_NLS_CODEPAGE_737 is not set # CONFIG_NLS_CODEPAGE_775 is not set # CONFIG_NLS_CODEPAGE_850 is not set # CONFIG_NLS_CODEPAGE_852 is not set CONFIG_NLS_CODEPAGE_855=m # 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=m # CONFIG_NLS_CODEPAGE_869 is not set # CONFIG_NLS_CODEPAGE_936 is not set # CONFIG_NLS_CODEPAGE_950 is not set # CONFIG_NLS_CODEPAGE_932 is not set # CONFIG_NLS_CODEPAGE_949 is not set # CONFIG_NLS_CODEPAGE_874 is not set # CONFIG_NLS_ISO8859_8 is not set # CONFIG_NLS_CODEPAGE_1250 is not set CONFIG_NLS_CODEPAGE_1251=m CONFIG_NLS_ISO8859_1=m # CONFIG_NLS_ISO8859_2 is not set # CONFIG_NLS_ISO8859_3 is not set # CONFIG_NLS_ISO8859_4 is not set CONFIG_NLS_ISO8859_5=m # 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=m CONFIG_NLS_KOI8_U=m CONFIG_NLS_UTF8=m # # Console drivers # CONFIG_VGA_CONSOLE=y CONFIG_VIDEO_SELECT=y CONFIG_MDA_CONSOLE=m # # Frame-buffer support # CONFIG_FB=y CONFIG_DUMMY_CONSOLE=y CONFIG_FB_RIVA=m # CONFIG_FB_CLGEN is not set # CONFIG_FB_PM2 is not set # CONFIG_FB_PM3 is not set # CONFIG_FB_CYBER2000 is not set CONFIG_FB_VESA=y CONFIG_FB_VGA16=m # CONFIG_FB_HGA is not set CONFIG_VIDEO_SELECT=y # CONFIG_FB_MATROX is not set # CONFIG_FB_ATY is not set # CONFIG_FB_RADEON is not set # CONFIG_FB_ATY128 is not set # CONFIG_FB_INTEL is not set # CONFIG_FB_SIS is not set # CONFIG_FB_NEOMAGIC is not set # CONFIG_FB_3DFX is not set # CONFIG_FB_VOODOO1 is not set # CONFIG_FB_TRIDENT is not set CONFIG_FB_VIRTUAL=m CONFIG_FBCON_ADVANCED=y CONFIG_FBCON_MFB=m CONFIG_FBCON_CFB2=m CONFIG_FBCON_CFB4=m CONFIG_FBCON_CFB8=y CONFIG_FBCON_CFB16=y CONFIG_FBCON_CFB24=y CONFIG_FBCON_CFB32=y # CONFIG_FBCON_AFB is not set # CONFIG_FBCON_ILBM is not set # CONFIG_FBCON_IPLAN2P2 is not set # CONFIG_FBCON_IPLAN2P4 is not set # CONFIG_FBCON_IPLAN2P8 is not set CONFIG_FBCON_MAC=m CONFIG_FBCON_VGA_PLANES=m CONFIG_FBCON_VGA=m # CONFIG_FBCON_HGA is not set # CONFIG_FBCON_FONTWIDTH8_ONLY is not set CONFIG_FBCON_FONTS=y CONFIG_FONT_8x8=y CONFIG_FONT_8x16=y # CONFIG_FONT_SUN8x16 is not set # CONFIG_FONT_SUN12x22 is not set # CONFIG_FONT_6x11 is not set # CONFIG_FONT_PEARL_8x8 is not set # CONFIG_FONT_ACORN_8x8 is not set # # Sound # CONFIG_SOUND=y # CONFIG_SOUND_ALI5455 is not set # CONFIG_SOUND_BT878 is not set CONFIG_SOUND_CMPCI=m CONFIG_SOUND_CMPCI_FM=y CONFIG_SOUND_CMPCI_FMIO=388 CONFIG_SOUND_CMPCI_FMIO=388 CONFIG_SOUND_CMPCI_MIDI=y CONFIG_SOUND_CMPCI_MPUIO=330 CONFIG_SOUND_CMPCI_JOYSTICK=y CONFIG_SOUND_CMPCI_CM8738=y # CONFIG_SOUND_CMPCI_SPDIFINVERSE is not set # CONFIG_SOUND_CMPCI_SPDIFLOOP is not set CONFIG_SOUND_CMPCI_SPEAKERS=2 # 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_FORTE 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=y # CONFIG_USB_DEBUG is not set CONFIG_USB_DEVICEFS=y # CONFIG_USB_BANDWIDTH is not set # CONFIG_USB_EHCI_HCD is not set CONFIG_USB_UHCI_ALT=y # CONFIG_USB_OHCI is not set # CONFIG_USB_AUDIO is not set # CONFIG_USB_EMI26 is not set # CONFIG_USB_BLUETOOTH is not set # CONFIG_USB_MIDI 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_SDDR55 is not set # CONFIG_USB_STORAGE_JUMPSHOT is not set # CONFIG_USB_ACM is not set # CONFIG_USB_PRINTER is not set CONFIG_USB_HID=m # CONFIG_USB_HIDINPUT is not set # CONFIG_USB_HIDDEV is not set # CONFIG_USB_KBD is not set # CONFIG_USB_MOUSE is not set # CONFIG_USB_AIPTEK is not set # CONFIG_USB_WACOM is not set # CONFIG_USB_KBTAB is not set # CONFIG_USB_POWERMATE is not set # 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 # CONFIG_USB_PEGASUS is not set # CONFIG_USB_RTL8150 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 # CONFIG_USB_USS720 is not set # # USB Serial Converter support # # CONFIG_USB_SERIAL is not set # CONFIG_USB_RIO500 is not set # CONFIG_USB_AUERSWALD is not set # CONFIG_USB_TIGL is not set # CONFIG_USB_BRLVGER is not set # CONFIG_USB_LCD is not set # # Bluetooth support # # CONFIG_BLUEZ is not set # # Kernel hacking # # CONFIG_DEBUG_KERNEL is not set # # Library routines # CONFIG_ZLIB_INFLATE=y CONFIG_ZLIB_DEFLATE=m --Boundary-00=_rpli/5A6EqTji6s-- From owner-linux-xfs@oss.sgi.com Mon Oct 13 02:05:02 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 13 Oct 2003 02:05:47 -0700 (PDT) Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9D95125024014 for ; Mon, 13 Oct 2003 02:05:02 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.28]) by smtpzilla5.xs4all.nl (8.12.9/8.12.9) with ESMTP id h9D8VjLf017204; Mon, 13 Oct 2003 10:31:45 +0200 (CEST) Message-Id: <4.3.2.7.2.20031013103103.02df9280@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 13 Oct 2003 10:31:42 +0200 To: gbakos@cfa.harvard.edu, linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: Kernel Oops - still not solved In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 700 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs Content-Length: 577 Lines: 18 At 20:14 10-10-2003 -0400, Gaspar Bakos wrote: >Hi, > >I have this exact configuration running on two other PCs, and they have >been running for 0.5yr now with no hint of problem. Anyway, there is this >nasty PC, which crashed, prints an ugly kernel oops in /var/log/messages, >then kswapd becomes zombie, sometimes other processes (kupdated) as well, >the system starts to behave erratically (shutdown segfaults, CTRL+ALT+DEL >segfaults, etc.), and then finally it dies. 1. Run memtest86 2. Buy new memory. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Mon Oct 13 02:18:40 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 13 Oct 2003 02:19:13 -0700 (PDT) Received: from goliath.sylaba.poznan.pl (goliath.sylaba.poznan.pl [195.216.104.3]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9D9IS25024680 for ; Mon, 13 Oct 2003 02:18:29 -0700 Received: by goliath.sylaba.poznan.pl (Postfix, from userid 1003) id 15CAD94AEF; Mon, 13 Oct 2003 10:52:56 +0200 (CEST) Received: from venus.local.navi.pl (ps103.poznan.sdi.tpnet.pl [217.97.72.103]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by goliath.sylaba.poznan.pl (Postfix) with ESMTP id A197094AE6; Mon, 13 Oct 2003 10:52:55 +0200 (CEST) Received: from venus.local.navi.pl (venus.local.navi.pl [127.0.0.1]) by venus.local.navi.pl (8.12.5/8.12.5) with ESMTP id h9D8rgiX002741; Mon, 13 Oct 2003 10:53:43 +0200 Subject: Re: xfs removed from ftp? it's back From: Olaf Fraczyk To: Steve Lord Cc: linux-xfs@oss.sgi.com In-Reply-To: <1065964924.1507.7.camel@laptop.americas.sgi.com> References: <27001.1065930140@ocs3.intra.ocs.com.au> <20031012040417.GD24569@plato.local.lan> <1065964924.1507.7.camel@laptop.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 13 Oct 2003 10:53:42 +0200 Message-Id: <1066035223.1817.51.camel@venus> Mime-Version: 1.0 X-archive-position: 701 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: olaf@navi.pl Precedence: bulk X-list: linux-xfs Content-Length: 595 Lines: 23 On Sun, 2003-10-12 at 15:22, Steve Lord wrote: > On Sat, 2003-10-11 at 23:04, Ethan Benson wrote: > > > > also the xfs dir is available now, but no code is there yet. however > > there is a README explaining this: > > > > ftp://oss.sgi.com/projects/xfs/download/README > > There is code in there, sorry things were down for some time, we were > under instruction not to say anything about this. The README is what > we are allowed to say about it. Hi, Couldn't you just say, that you know about it, but you can't say anything about it? I would be less confusing. Regards, Olaf Fraczyk From owner-linux-xfs@oss.sgi.com Mon Oct 13 05:56:52 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 13 Oct 2003 05:57:27 -0700 (PDT) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9DCup25011535 for ; Mon, 13 Oct 2003 05:56:52 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h9DB0vOO012760 for ; Mon, 13 Oct 2003 04:00:57 -0700 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h9DCujcc12162612; Mon, 13 Oct 2003 07:56:45 -0500 (CDT) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-81.corp.sgi.com [134.15.64.81]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h9DCueRn304228966; Mon, 13 Oct 2003 07:56:44 -0500 (CDT) Subject: Re: kernel warnings on xfstest 013 From: Steve Lord To: Roman Vasylyev Cc: linux-xfs@oss.sgi.com In-Reply-To: <200310131155.24320.romis@dev.rtsoft.ru> References: <200310131155.24320.romis@dev.rtsoft.ru> Content-Type: text/plain Organization: Message-Id: <1066049797.1513.6.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 13 Oct 2003 07:56:37 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 703 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 978 Lines: 24 On Mon, 2003-10-13 at 02:55, Roman Vasylyev wrote: > Hi, > > I need to test created XFS filesystems. And for that i choose xfstests from > xfs-cmds CVStree. On test 013 i starts to receive very much kernel warnings: You built XFS with debug enabled, apart from doubling the size of the code and slowing things down a lot, this also turns on some diagnostic messages. This particular one means we have attempted to read an inode number which is out of range for the filesystem. The tests you mention execute fsstress, a program which feeds random parameters into system calls. One of the xfs specific calls, bulkstat, takes an inode number as a parameter, you feed it random numbers and you fall off the end of the filesystem like this. This is one of the things all new developers working on XFS find and get confused about. Summary, nothing to worry about here, and be careful to turn debug off unless you are doing development work. Steve -- Steve Lord From owner-linux-xfs@oss.sgi.com Mon Oct 13 07:51:23 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 13 Oct 2003 07:52:03 -0700 (PDT) Received: from sundancer.oche.de (sundancer.oche.de [194.94.252.29]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9DEpC25023337 for ; Mon, 13 Oct 2003 07:51:14 -0700 Received: by sundancer.oche.de (Postfix, from userid 10) id 42AE712C9A; Mon, 13 Oct 2003 16:51:05 +0200 (CEST) Received: from foehn.quickstep.oche.de (localhost [127.0.0.1]) by foehn.quickstep.oche.de (8.12.10/8.12.8) with ESMTP id h9DEoEEu017446 for ; Mon, 13 Oct 2003 16:50:14 +0200 (CEST) Received: (from news@localhost) by foehn.quickstep.oche.de (8.12.10/8.12.8/Submit) id h9DEoCdV017445 for linux-xfs@oss.sgi.com; Mon, 13 Oct 2003 16:50:12 +0200 (CEST) To: linux-xfs@oss.sgi.com Path: not-for-mail From: Martin Spott Newsgroups: list.linux-xfs Subject: Re: xfs removed from ftp? Date: 13 Oct 2003 14:50:12 GMT Organization: home Message-ID: References: NNTP-Posting-Host: foehn.quickstep.oche.de X-Trace: foehn.quickstep.oche.de 1066056612 17327 192.168.48.1 (13 Oct 2003 14:50:12 GMT) X-Complaints-To: usenet@foehn.quickstep.oche.de NNTP-Posting-Date: 13 Oct 2003 14:50:12 GMT User-Agent: tin/1.4.5-20010409 ("One More Nightmare") (UNIX) (SunOS/5.8 (sun4m)) X-archive-position: 704 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Martin.Spott@uni-duisburg.de Precedence: bulk X-list: linux-xfs Content-Length: 661 Lines: 21 Martin Spott wrote: > You don't believe me without a proof ? Please see: > > ftp://ftp.ihg.uni-duisburg.de/Mirrors/ Did you know the "Unix Administration Horror Story Summary" ? "More systems have been wiped out by admins than any hacker could do in a lifetime." This monday morning I've proven to be too stupid for this world .... Please look here if you want to access some of the remains that I copied manually: ftp://ftp.uni-duisburg.de/Linux/filesys/XFS/ Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -------------------------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Mon Oct 13 08:43:48 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 13 Oct 2003 08:44:29 -0700 (PDT) Received: from pop3.inarcassa.it ([62.110.174.210]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9DFhi25028615 for ; Mon, 13 Oct 2003 08:43:48 -0700 Received: from inarcassa.it by pop3.inarcassa.it (too easy) with SMTP id h9DFhaN26938 for ; Mon, 13 Oct 2003 17:43:36 +0200 Received: from 10.100.100.100 (SquirrelMail authenticated user tranel05) by webmail.inarcassa.it with HTTP; Mon, 13 Oct 2003 17:43:23 +0200 (CEST) Message-ID: <1635.10.100.100.100.1066059803.squirrel@webmail.inarcassa.it> Date: Mon, 13 Oct 2003 17:43:23 +0200 (CEST) Subject: XFS and IBM SAN From: "Gianluca Tranelli" To: X-Priority: 3 Importance: Normal X-Mailer: SquirrelMail (version 1.2.8) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-INARCASSA-MailScanner-Information: Please contact the ISP for more information X-Smtp-AntiVirus: Found to be clean X-archive-position: 705 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: g.tranelli@inarcassa.it Precedence: bulk X-list: linux-xfs Content-Length: 291 Lines: 12 I have an IBM SAN (Total Storage) and I have some problems but I don't know what is the cause. To make the best XFS filesystem on a RAID-5 (4 disks) configuration what options I should use ???. Many thanks From owner-linux-xfs@oss.sgi.com Mon Oct 13 09:23:29 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 13 Oct 2003 09:24:07 -0700 (PDT) Received: from beast.clarksys.com (sm02.cthought.com [64.81.233.33]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9DGNR25004825 for ; Mon, 13 Oct 2003 09:23:29 -0700 Received: (qmail 28243 invoked by uid 1000); 13 Oct 2003 16:22:41 -0000 Date: Mon, 13 Oct 2003 09:22:41 -0700 From: Max Clark To: linux-xfs@oss.sgi.com Subject: Re: xfs removed from ftp? Message-ID: <20031013162241.GA28237@beast.clarksys.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.5.4i X-archive-position: 706 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: maxc-xfs@beast.clarksys.com Precedence: bulk X-list: linux-xfs Content-Length: 169 Lines: 9 Can anyone point me to a working mirror with the Release 1.3.1? Thanks, Max -- Max Clark Max Clark From owner-linux-xfs@oss.sgi.com Mon Oct 13 09:52:52 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 13 Oct 2003 09:53:30 -0700 (PDT) Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9DGqp25006008 for ; Mon, 13 Oct 2003 09:52:52 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h9DGqkq0004998 for ; Mon, 13 Oct 2003 09:52:46 -0700 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h9DGqjcc12174244; Mon, 13 Oct 2003 11:52:45 -0500 (CDT) Received: from naboo (naboo.americas.sgi.com [128.162.233.73]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h9DGqjRn314942082; Mon, 13 Oct 2003 11:52:45 -0500 (CDT) Subject: Re: xfs removed from ftp? From: Russell Cattelan To: Max Clark Cc: linux-xfs@oss.sgi.com In-Reply-To: <20031013162241.GA28237@beast.clarksys.com> References: <20031013162241.GA28237@beast.clarksys.com> Content-Type: text/plain Message-Id: <1066063487.10404.4.camel@naboo> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4-8mdk Date: Mon, 13 Oct 2003 11:44:48 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 707 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cattelan@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 279 Lines: 12 On Mon, 2003-10-13 at 11:22, Max Clark wrote: > Can anyone point me to a working mirror with the Release 1.3.1 http://oss.sgi.com/projects/xfs/download.html > > Thanks, > Max > > -- > Max Clark > Max Clark > From owner-linux-xfs@oss.sgi.com Mon Oct 13 12:48:45 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 13 Oct 2003 12:55:26 -0700 (PDT) Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9DJmj25013828; Mon, 13 Oct 2003 12:48:45 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h9DJmdq0001161; Mon, 13 Oct 2003 12:48:39 -0700 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h9DJmdcc12186977; Mon, 13 Oct 2003 14:48:39 -0500 (CDT) Received: from naboo.americas.sgi.com (naboo.americas.sgi.com [128.162.233.73]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h9DJmdRn317550418; Mon, 13 Oct 2003 14:48:39 -0500 (CDT) Received: by naboo.americas.sgi.com (Postfix, from userid 29039) id DFB541899B92; Mon, 13 Oct 2003 14:40:39 -0500 (CDT) To: linux-xfs-announce@oss.sgi.com, linux-xfs@oss.sgi.com From: xfs-masters@oss.sgi.com Subject: XFS 1.3.1 Message-Id: <20031013194039.DFB541899B92@naboo.americas.sgi.com> Date: Mon, 13 Oct 2003 14:40:39 -0500 (CDT) X-archive-position: 708 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: xfs-masters@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1029 Lines: 21 Consistent with our recent letter to the open source community (http://oss.sgi.com/letter_100103.txt), SGI has removed and replaced a trivial number of code segments in XFS that may arguably be related to UNIX code. These changes are in three areas: macros used to define and manipulate the extended inode mode bits (in xfs_vnode.h), macros for filesystem quota operations (in dqblk_xfs.h), and the data copying function uiomove()(in move.c). These revisions also required insignificant changes to other files that interact with the revised code. We encourage you to move promptly to this version of XFS. This code is now available for download from our open source repository at http://oss.sgi.com. Initially we have provided updated kernel patches for recent 2.4 series kernels, updated user space tools, and an updated version of the XFS 1.3 release. The CVS repositories for the 2.4 and 2.6 kernels are also available. Please contact xfs-masters@oss.sgi.com with any questions about this XFS update. -- The XFS Team From owner-linux-xfs@oss.sgi.com Mon Oct 13 15:38:53 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 13 Oct 2003 15:39:32 -0700 (PDT) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9DMco25019538 for ; Mon, 13 Oct 2003 15:38:52 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id h9DMunHc032462 for ; Mon, 13 Oct 2003 17:56:50 -0500 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 IAA28824; Tue, 14 Oct 2003 08:38:36 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h9DMcXUc525681; Tue, 14 Oct 2003 08:38:33 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h9DMcT7Q512571; Tue, 14 Oct 2003 08:38:29 +1000 (EST) Date: Tue, 14 Oct 2003 08:38:29 +1000 From: Nathan Scott To: Roman Vasylyev Cc: linux-xfs@oss.sgi.com Subject: Re: kernel warnings on xfstest 013 Message-ID: <20031014083828.B518276@wobbly.melbourne.sgi.com> References: <200310131155.24320.romis@dev.rtsoft.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200310131155.24320.romis@dev.rtsoft.ru>; from romis@dev.rtsoft.ru on Mon, Oct 13, 2003 at 11:55:23AM +0400 X-archive-position: 709 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 456 Lines: 16 On Mon, Oct 13, 2003 at 11:55:23AM +0400, Roman Vasylyev wrote: > > Did some one explain why this happends. Test 013 not unique. 013, 014,015. > All makes this warning. fsstress on a debug kernel will produce these errors. It is a result of fsstress making XFS "bulkstat" calls with random inode numbers -- inode numbers that don't match to valid inodes on-disk will cause these errors to be generated. They can be safely ignored. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Oct 13 19:54:32 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 13 Oct 2003 19:55:13 -0700 (PDT) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9E2sV25028079 for ; Mon, 13 Oct 2003 19:54:31 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h9E0wbOO031155 for ; Mon, 13 Oct 2003 17:58:38 -0700 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h9E2sGjj1891453; Tue, 14 Oct 2003 12:54:16 +1000 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h9E2sFCg1877746; Tue, 14 Oct 2003 12:54:15 +1000 (EST) Date: Tue, 14 Oct 2003 12:54:15 +1000 (EST) From: Nathan Scott Message-Id: <200310140254.h9E2sFCg1877746@snort.melbourne.sgi.com> To: sgi.bugs.xfs@engr.sgi.com Cc: linux-xfs@oss.sgi.com Subject: TAKE 902464 - fix an implicit inum cast-down X-archive-position: 710 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 362 Lines: 13 Use an xfs_ino_t to hold the result of inode extraction from a handle, not a possibly-32-bit number. Date: Mon Oct 13 19:48:52 PDT 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/clean-2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:159943a linux/fs/xfs/linux/xfs_ioctl.c - 1.99 From owner-linux-xfs@oss.sgi.com Tue Oct 14 00:23:14 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 14 Oct 2003 00:23:57 -0700 (PDT) Received: from sundancer.oche.de (sundancer.oche.de [194.94.252.29]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9E7ND25011303 for ; Tue, 14 Oct 2003 00:23:14 -0700 Received: by sundancer.oche.de (Postfix, from userid 10) id 9787412C88; Tue, 14 Oct 2003 09:23:09 +0200 (CEST) Received: from foehn.quickstep.oche.de (localhost [127.0.0.1]) by foehn.quickstep.oche.de (8.12.10/8.12.8) with ESMTP id h9E6RbEu002539 for ; Tue, 14 Oct 2003 08:27:37 +0200 (CEST) Received: (from news@localhost) by foehn.quickstep.oche.de (8.12.10/8.12.8/Submit) id h9E6RZMS002538 for linux-xfs@oss.sgi.com; Tue, 14 Oct 2003 08:27:35 +0200 (CEST) To: linux-xfs@oss.sgi.com Path: not-for-mail From: Martin Spott Newsgroups: list.linux-xfs Subject: Re: xfs removed from ftp? Date: 14 Oct 2003 06:27:35 GMT Organization: home Message-ID: References: <1066063487.10404.4.camel@naboo> NNTP-Posting-Host: sirius.quickstep.oche.de X-Trace: foehn.quickstep.oche.de 1066112855 2529 192.168.48.4 (14 Oct 2003 06:27:35 GMT) X-Complaints-To: usenet@foehn.quickstep.oche.de NNTP-Posting-Date: 14 Oct 2003 06:27:35 GMT User-Agent: tin/1.4.5-20010409 ("One More Nightmare") (UNIX) (IRIX64/6.5 (IP30)) X-archive-position: 711 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Martin.Spott@uni-duisburg.de Precedence: bulk X-list: linux-xfs Content-Length: 481 Lines: 12 Russell Cattelan wrote: > On Mon, 2003-10-13 at 11:22, Max Clark wrote: >> Can anyone point me to a working mirror with the Release 1.3.1 > http://oss.sgi.com/projects/xfs/download.html Would'nt it have been useful to put a patch for the current kernel into the updated Release - say for 2.4.22 ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -------------------------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Tue Oct 14 03:14:26 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 14 Oct 2003 03:15:08 -0700 (PDT) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9EAEN25018278 for ; Tue, 14 Oct 2003 03:14:26 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h9E8IVOO001764 for ; Tue, 14 Oct 2003 01:18:32 -0700 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h9EAEHcc12262090; Tue, 14 Oct 2003 05:14:17 -0500 (CDT) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-45.corp.sgi.com [134.15.64.45]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h9EAEGRn324769542; Tue, 14 Oct 2003 05:14:16 -0500 (CDT) Subject: Re: xfs removed from ftp? From: Steve Lord To: Martin Spott Cc: linux-xfs@oss.sgi.com In-Reply-To: References: <1066063487.10404.4.camel@naboo> Content-Type: text/plain Organization: Message-Id: <1066126453.1536.11.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 14 Oct 2003 05:14:14 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 712 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 689 Lines: 19 On Tue, 2003-10-14 at 01:27, Martin Spott wrote: > Russell Cattelan wrote: > > On Mon, 2003-10-13 at 11:22, Max Clark wrote: > >> Can anyone point me to a working mirror with the Release 1.3.1 > > http://oss.sgi.com/projects/xfs/download.html > > Would'nt it have been useful to put a patch for the current kernel into > the updated Release - say for 2.4.22 ? Yes, but given the schedule we were on, there was no time. 2.4.22 changes the file system I/O path, we would have had to backport that to 1.3.1. The only way to get something with a reasonable guarantee of stability was what we did. A 2.4.22 version may show up later. Steve -- Steve Lord From owner-linux-xfs@oss.sgi.com Tue Oct 14 06:58:50 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 14 Oct 2003 06:59:29 -0700 (PDT) Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9EDwm25029712 for ; Tue, 14 Oct 2003 06:58:50 -0700 Received: from mail-veri.imag.fr (pave.imag.fr [129.88.43.12]) by imag.imag.fr (8.12.10/8.12.10) with ESMTP id h9EDwjd8025354 for ; Tue, 14 Oct 2003 15:58:45 +0200 (CEST) Received: from astazou.imag.fr ([129.88.43.102] helo=astazou.imag.fr.imag.fr ident=kowalski) by mail-veri.imag.fr with esmtp (Exim 3.35 #1 (Debian)) id 1A9PhF-0005Ox-00 for ; Tue, 14 Oct 2003 15:58:45 +0200 To: linux-xfs@oss.sgi.com Subject: XFS and async NFS exports From: Nicolas Kowalski Mail-Copies-To: never Date: Tue, 14 Oct 2003 15:58:43 +0200 Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Common Lisp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IMAG-MailScanner: Found to be clean X-IMAG-MailScanner-Information: Please contact the ISP for more information X-archive-position: 713 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Nicolas.Kowalski@imag.fr Precedence: bulk X-list: linux-xfs Content-Length: 688 Lines: 22 Hello. [I apologize, this is not completely XFS-related, but perhaps some XFS+NFS gurus will be able to give some information.] I recently faced a power outage on a fileserver with XFS filesystems (CVS-2003-09-24_05). Some files written on NFS clients a few seconds before the crash were damaged (zero-sized). On a first approach, I thought this was XFS-related, but afterwards, I also realized that this server was exporting its filesystems with the async export option...It this possible that this async option have caused these file damages ? If I use sync exports, does this mean that XFS will effectively write on disk all pending data ? Many thanks in advance. -- Nicolas From owner-linux-xfs@oss.sgi.com Tue Oct 14 08:01:30 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 14 Oct 2003 08:02:03 -0700 (PDT) Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9EF1U25032080 for ; Tue, 14 Oct 2003 08:01:30 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h9EF1Oq0021936 for ; Tue, 14 Oct 2003 08:01:24 -0700 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h9EF1OaP12266102; Tue, 14 Oct 2003 10:01:24 -0500 (CDT) Received: from fsgi158.americas.sgi.com (fsgi158.americas.sgi.com [128.162.233.81]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h9EF1ORn322074656; Tue, 14 Oct 2003 10:01:24 -0500 (CDT) Received: from fsgi158.americas.sgi.com by fsgi158.americas.sgi.com (SGI-8.12.5/SGI-client-1.7) via ESMTP id h9EF1Net080483; Tue, 14 Oct 2003 10:01:23 -0500 (CDT) Received: (from tbd@localhost) by fsgi158.americas.sgi.com (SGI-8.12.5/8.12.5/Submit) id h9EF1Nco078807; Tue, 14 Oct 2003 10:01:23 -0500 (CDT) From: Tad Dolphay Message-Id: <200310141501.h9EF1Nco078807@fsgi158.americas.sgi.com> Subject: Re: XFS and async NFS exports To: Nicolas.Kowalski@imag.fr (Nicolas Kowalski) Date: Tue, 14 Oct 2003 10:01:22 -0500 (CDT) Cc: linux-xfs@oss.sgi.com In-Reply-To: from "Nicolas Kowalski" at Oct 14, 2003 03:58:43 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 715 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tbd@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 882 Lines: 20 > recently faced a power outage on a fileserver with XFS filesystems >(CVS-2003-09-24_05). Some files written on NFS clients a few seconds >before the crash were damaged (zero-sized). > >On a first approach, I thought this was XFS-related, but afterwards, I >also realized that this server was exporting its filesystems with the >async export option...It this possible that this async option have >caused these file damages ? If I use sync exports, does this mean that >XFS will effectively write on disk all pending data ? If "async" is used, the NFS server can respond that the data is commited when it really isn't on disk. Thus, when the NFS server crashes, the NFS client does not think it has to re-commit the data. If sync exports are used on the NFS server and hard mounts are used on the NFS client, I doubt there will be any loss of data when a server crashes. Tad From owner-linux-xfs@oss.sgi.com Tue Oct 14 08:01:04 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 14 Oct 2003 08:01:44 -0700 (PDT) Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9EF1225032050 for ; Tue, 14 Oct 2003 08:01:03 -0700 Received: from mail-veri.imag.fr (pave.imag.fr [129.88.43.12]) by imag.imag.fr (8.12.10/8.12.10) with ESMTP id h9EF0wd8013980 for ; Tue, 14 Oct 2003 17:00:58 +0200 (CEST) Received: from astazou.imag.fr ([129.88.43.102] helo=astazou.imag.fr.imag.fr ident=kowalski) by mail-veri.imag.fr with esmtp (Exim 3.35 #1 (Debian)) id 1A9QfS-000446-00 for ; Tue, 14 Oct 2003 17:00:58 +0200 To: linux-xfs@oss.sgi.com Subject: Re: XFS and async NFS exports References: From: Nicolas Kowalski Mail-Copies-To: never Date: Tue, 14 Oct 2003 17:00:57 +0200 In-Reply-To: (Nicolas Kowalski's message of "Tue, 14 Oct 2003 15:58:43 +0200") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Common Lisp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IMAG-MailScanner: Found to be clean X-IMAG-MailScanner-Information: Please contact the ISP for more information X-archive-position: 714 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Nicolas.Kowalski@imag.fr Precedence: bulk X-list: linux-xfs Content-Length: 425 Lines: 17 Nicolas Kowalski writes: [...] > If I use sync exports, does this mean that XFS will effectively > write on disk all pending data ? I did some tests on a workstation, with sync exports, and yes, it works ; it is slow, but it works. If I unplug the power during an NFS-client write to this workstation, the files just written before the power outage are fine. Sorry for the noise. -- Nicolas From owner-linux-xfs@oss.sgi.com Tue Oct 14 08:30:35 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 14 Oct 2003 08:31:12 -0700 (PDT) Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9EFUX25003790 for ; Tue, 14 Oct 2003 08:30:34 -0700 Received: from mail-veri.imag.fr (pave.imag.fr [129.88.43.12]) by imag.imag.fr (8.12.10/8.12.10) with ESMTP id h9EFUSd8023973 for ; Tue, 14 Oct 2003 17:30:28 +0200 (CEST) Received: from astazou.imag.fr ([129.88.43.102] helo=astazou.imag.fr.imag.fr ident=kowalski) by mail-veri.imag.fr with esmtp (Exim 3.35 #1 (Debian)) id 1A9R7z-0004gT-00 for ; Tue, 14 Oct 2003 17:30:28 +0200 To: linux-xfs@oss.sgi.com Subject: Re: XFS and async NFS exports References: <200310141501.h9EF1Nco078807@fsgi158.americas.sgi.com> From: Nicolas Kowalski Mail-Copies-To: never Date: Tue, 14 Oct 2003 17:30:27 +0200 In-Reply-To: <200310141501.h9EF1Nco078807@fsgi158.americas.sgi.com> (Tad Dolphay's message of "Tue, 14 Oct 2003 10:01:22 -0500 (CDT)") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Common Lisp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IMAG-MailScanner: Found to be clean X-IMAG-MailScanner-Information: Please contact the ISP for more information X-archive-position: 716 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Nicolas.Kowalski@imag.fr Precedence: bulk X-list: linux-xfs Content-Length: 434 Lines: 17 Tad Dolphay writes: > If sync exports are used on the NFS server and hard mounts are used on > the NFS client, I doubt there will be any loss of data when a server crashes. Thanks for your reply. This is the way I reconfigured my file server and its clients. I also modified my samba configuration to include the "strict sync" option. All is running fine, despite a higher load average. Best regards. -- Nicolas From owner-linux-xfs@oss.sgi.com Tue Oct 14 11:08:24 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 14 Oct 2003 11:08:41 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10) with ESMTP id h9EI8N25014822 for ; Tue, 14 Oct 2003 11:08:24 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id h9EI8NTw014821 for linux-xfs@oss.sgi.com; Tue, 14 Oct 2003 11:08:23 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10) with ESMTP id h9EI8L27014803 for ; Tue, 14 Oct 2003 11:08:21 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id h9EI8ARE014792; Tue, 14 Oct 2003 11:08:10 -0700 Date: Tue, 14 Oct 2003 11:08:10 -0700 Message-Id: <200310141808.h9EI8ARE014792@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 282] Kernel panic/Bad magic number on XFS filesystem X-Bugzilla-Reason: AssignedTo X-archive-position: 717 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 650 Lines: 19 http://oss.sgi.com/bugzilla/show_bug.cgi?id=282 ------- Additional Comments From lord@sgi.com 2003-14-10 11:08 PDT ------- The exact error message would be useful if you can provide it, we have just seen a case here were a partition was reported as a different size between 2.6 and 2.4. End result in that case was under 2.6 it was larger and the end of the filesystem was not visible under 2.4. Mount does attempt to read what the superblock reports as the last block in the fs and will fail the mount if it cannot do so. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Tue Oct 14 11:11:48 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 14 Oct 2003 11:12:29 -0700 (PDT) Received: from beast.clarksys.com (sm02.cthought.com [64.81.233.33]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9EIBl25015556 for ; Tue, 14 Oct 2003 11:11:48 -0700 Received: (qmail 49274 invoked by uid 1000); 14 Oct 2003 18:11:04 -0000 Date: Tue, 14 Oct 2003 11:11:04 -0700 From: Max Clark To: linux-xfs@oss.sgi.com Subject: Redhat 7.3 Installation Message-ID: <20031014181104.GB48433@beast.clarksys.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.5.4i X-archive-position: 718 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: maxc-xfs@beast.clarksys.com Precedence: bulk X-list: linux-xfs Content-Length: 255 Lines: 11 Hi all, Are there any published instructions for installing xfs on a RedHat 7.3 system? I would like to end up with as close as possible to the stock RedHat kernel. Thanks, Max -- Max Clark My Blog http://www.clarksys.com From owner-linux-xfs@oss.sgi.com Tue Oct 14 11:15:21 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 14 Oct 2003 11:15:54 -0700 (PDT) Received: from linux-sxs.org (d60-65-142-166.col.wideopenwest.com [65.60.166.142]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9EIFI25015975 for ; Tue, 14 Oct 2003 11:15:20 -0700 Received: from linux-sxs.org (localhost [127.0.0.1]) by linux-sxs.org (8.12.10/8.12.10) with ESMTP id h9EHj9b7026118; Tue, 14 Oct 2003 13:45:09 -0400 Received: from localhost (netllama@localhost) by linux-sxs.org (8.12.10/8.12.10/Submit) with ESMTP id h9EHj9al028902; Tue, 14 Oct 2003 13:45:09 -0400 Date: Tue, 14 Oct 2003 13:45:09 -0400 (EDT) From: Net Llama! To: Max Clark cc: linux-xfs@oss.sgi.com Subject: Re: Redhat 7.3 Installation In-Reply-To: <20031014181104.GB48433@beast.clarksys.com> Message-ID: References: <20031014181104.GB48433@beast.clarksys.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: OK, scanned by File::Scan,ClamAV X-Scanned-By: MIMEDefang 2.38 X-archive-position: 719 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: netllama@linux-sxs.org Precedence: bulk X-list: linux-xfs Content-Length: 480 Lines: 16 On Tue, 14 Oct 2003, Max Clark wrote: > Hi all, > > Are there any published instructions for installing xfs on a RedHat 7.3 system? I would like to end up with as close as possible to the stock RedHat kernel. > > Thanks, > Max Insert the XFS CD into your box, boot off of it, install RH-7.3. Done. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lonni J Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo http://netllama.ipfox.com From owner-linux-xfs@oss.sgi.com Tue Oct 14 11:34:12 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 14 Oct 2003 11:34:47 -0700 (PDT) Received: from beast.clarksys.com (sm02.cthought.com [64.81.233.33]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9EIYC25018615 for ; Tue, 14 Oct 2003 11:34:12 -0700 Received: (qmail 49629 invoked by uid 1000); 14 Oct 2003 18:33:30 -0000 Date: Tue, 14 Oct 2003 11:33:30 -0700 From: Max Clark To: linux-xfs@oss.sgi.com Subject: Re: Redhat 7.3 Installation Message-ID: <20031014183330.GC48433@beast.clarksys.com> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20031014181104.GB48433@beast.clarksys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i X-archive-position: 720 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: maxc-xfs@beast.clarksys.com Precedence: bulk X-list: linux-xfs Content-Length: 831 Lines: 14 On Tue, Oct 14, 2003 at 01:45:09PM -0400, Net Llama! wrote: > > Are there any published instructions for installing xfs on a RedHat 7.3 system? I would like to end up with as close as possible to the stock RedHat kernel. > Insert the XFS CD into your box, boot > off of it, install RH-7.3. Done. Sorry, I should have been more specific. I have an existing RedHat 7.3 system with 2 internal SCSI drives mirrored running extfs. I have internal 3ware cards with about 1.5TB of formatted capacity currently formated with ReiserFS. I want to convert the 3ware mount to xfs. I normally would download and install my own kernel, but considering that I want to keep this one as RedHatish as possible, what are the steps that I need to do for this? Thanks, Max -- Max Clark My Blog http://www.clarksys.com From owner-linux-xfs@oss.sgi.com Tue Oct 14 11:54:43 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 14 Oct 2003 11:55:17 -0700 (PDT) Received: from linux-sxs.org (d60-65-142-166.col.wideopenwest.com [65.60.166.142]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9EIsg25020398 for ; Tue, 14 Oct 2003 11:54:43 -0700 Received: from linux-sxs.org (localhost [127.0.0.1]) by linux-sxs.org (8.12.10/8.12.10) with ESMTP id h9EIObb7030071; Tue, 14 Oct 2003 14:24:37 -0400 Received: from localhost (netllama@localhost) by linux-sxs.org (8.12.10/8.12.10/Submit) with ESMTP id h9EIObK0013869; Tue, 14 Oct 2003 14:24:37 -0400 Date: Tue, 14 Oct 2003 14:24:37 -0400 (EDT) From: Net Llama! To: Max Clark cc: linux-xfs@oss.sgi.com Subject: Re: Redhat 7.3 Installation In-Reply-To: <20031014183330.GC48433@beast.clarksys.com> Message-ID: References: <20031014181104.GB48433@beast.clarksys.com> <20031014183330.GC48433@beast.clarksys.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: OK, scanned by File::Scan,ClamAV X-Scanned-By: MIMEDefang 2.38 X-archive-position: 721 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: netllama@linux-sxs.org Precedence: bulk X-list: linux-xfs Content-Length: 1260 Lines: 19 On Tue, 14 Oct 2003, Max Clark wrote: > On Tue, Oct 14, 2003 at 01:45:09PM -0400, Net Llama! wrote: > > > Are there any published instructions for installing xfs on a RedHat 7.3 system? I would like to end up with as close as possible to the stock RedHat kernel. > > Insert the XFS CD into your box, boot > > off of it, install RH-7.3. Done. > > Sorry, I should have been more specific. I have an existing RedHat 7.3 system with 2 internal SCSI drives mirrored running extfs. I have internal 3ware cards with about 1.5TB of formatted capacity currently formated with ReiserFS. I want to convert the 3ware mount to xfs. I normally would download and install my own kernel, but considering that I want to keep this one as RedHatish as possible, what are the steps that I need to do for this? You can't non-destructively convert any other filesystem to XFS. So you're going to have to backup all your data before doing anything. Beyond that, all you need to do is build an XFS enabled kernel, install xfsprogs, partition & format xfs partition(s), and then put your data back on. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lonni J Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo http://netllama.ipfox.com From owner-linux-xfs@oss.sgi.com Tue Oct 14 12:05:27 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 14 Oct 2003 12:06:02 -0700 (PDT) Received: from beast.clarksys.com (sm02.cthought.com [64.81.233.33]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9EJ5625021637 for ; Tue, 14 Oct 2003 12:05:27 -0700 Received: (qmail 50093 invoked by uid 1000); 14 Oct 2003 19:04:24 -0000 Date: Tue, 14 Oct 2003 12:04:24 -0700 From: Max Clark To: linux-xfs@oss.sgi.com Subject: Re: Redhat 7.3 Installation Message-ID: <20031014190424.GD48433@beast.clarksys.com> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20031014181104.GB48433@beast.clarksys.com> <20031014183330.GC48433@beast.clarksys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i X-archive-position: 722 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: maxc-xfs@beast.clarksys.com Precedence: bulk X-list: linux-xfs Content-Length: 677 Lines: 19 On Tue, Oct 14, 2003 at 02:24:37PM -0400, Net Llama! wrote: > Beyond that, all you need to do is build an XFS enabled kernel, install > xfsprogs, partition & format xfs partition(s), and then put your data back > on. RedHat 7.3 uses linux-2.4.20-20.7 as their latest kernel. When I look in the Release-1.3.1 directory I see linux-2.4.21.core-xfs-1.3.1.patch.gz linux-xfs-1.3.1.patch.gz What is the difference between these two files? I am assuming that I am going to have to apply this patch against the 2.4.21 kernel version. Is there a patch against the redhat 2.4.20-20.7 kernel? Thanks, Max -- Max Clark My Blog http://www.clarksys.com From owner-linux-xfs@oss.sgi.com Tue Oct 14 12:08:23 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 14 Oct 2003 12:08:25 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10) with ESMTP id h9EJ8M25022096 for ; Tue, 14 Oct 2003 12:08:22 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id h9EJ8MSA022095 for linux-xfs@oss.sgi.com; Tue, 14 Oct 2003 12:08:22 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10) with ESMTP id h9EJ8L27022080 for ; Tue, 14 Oct 2003 12:08:21 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id h9EIvfuj021017; Tue, 14 Oct 2003 11:57:41 -0700 Date: Tue, 14 Oct 2003 11:57:41 -0700 Message-Id: <200310141857.h9EIvfuj021017@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 274] xfs_iunlink_remove: xfs_inotobp() returned error 22 X-Bugzilla-Reason: AssignedTo X-archive-position: 723 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1534 Lines: 41 http://oss.sgi.com/bugzilla/show_bug.cgi?id=274 ------- Additional Comments From walt_holman@generalplastics.com 2003-14-10 11:57 PDT ------- Just happened again unfortunately. Log Info (apologize for the mess): Oct 14 08:18:10 goliath kernel: xfs_inactive:^Ixfs_ifree() returned an error = 22 on md(9,3) Oct 14 08:18:10 goliath kernel: xfs_force_shutdown(md(9,3),0x1) called from line 1845 of file xfs_vnodeops.c. Return address = 0xc01f423c Oct 14 08:18:10 goliath kernel: Filesystem "md(9,3)": I/O Error Detected. Shutting down filesystem: md(9,3) Oct 14 08:18:10 goliath kernel: Please umount the filesystem, and rectify the problem(s) Oct 14 08:18:10 goliath kernel: xfs_inotobp: xfs_imap() returned an error 22 on md(9,3). Returning error. Oct 14 08:18:10 goliath kernel: xfs_iunlink_remove: xfs_inotobp() returned an error 22 on md(9,3). Returning error. Since my original report, the kernel was upgraded and is currently running 2.4.22 from a CVS pull ~ Sep. 14, 2003 This system was originally a Mandrake install and prior kernels were compiled using 2.91.66 as well as their 2.96 versioned gcc. The current kernel was compiled from my development workstation using gcc-3.2.3 I boot the system passing it acpi=off and mem=nopentium and have tried booting without with similar results. Uptimes are variable from 1 - 3 weeks now. Getting heat about this box :( Any other info you need? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Tue Oct 14 13:44:53 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 14 Oct 2003 13:45:28 -0700 (PDT) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9EKiq25028800 for ; Tue, 14 Oct 2003 13:44:53 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h9EL2vHc029256 for ; Tue, 14 Oct 2003 16:02:57 -0500 Received: from tulip-e236.americas.sgi.com (tulip-e236.americas.sgi.com [128.162.236.208]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h9EKilaP12324736; Tue, 14 Oct 2003 15:44:47 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by tulip-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h9EKilSn33949080; Tue, 14 Oct 2003 15:44:47 -0500 (CDT) Received: from jen.americas.sgi.com (localhost.localdomain [127.0.0.1]) by jen.americas.sgi.com (8.12.8/8.12.8) with ESMTP id h9EKik95025368; Tue, 14 Oct 2003 15:44:46 -0500 Received: (from lord@localhost) by jen.americas.sgi.com (8.12.8/8.12.8/Submit) id h9EKikLG025366; Tue, 14 Oct 2003 15:44:46 -0500 X-Authentication-Warning: jen.americas.sgi.com: lord set sender to lord@sgi.com using -f Subject: Re: Kernel Oops - still not solved From: Steve Lord To: gbakos@cfa.harvard.edu Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1066164284.25234.4.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 14 Oct 2003 15:44:46 -0500 X-archive-position: 724 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2943 Lines: 70 On Fri, 2003-10-10 at 19:14, Gaspar Bakos wrote: > Hi, > > Some time ago I reported on a problem I encountered. I could still not > solve it, but I thought the details might help someone to help me... > > System: i386 PIV, ASUS mobo, 512Mb RAM, 2 x 80Gb Seagate disks as RAID-1 > array, as hda and hdc. I have about 10 partitions on each disk, in the > same configuration, and each is run as RAID-1 with its relevant pair on > the other disk. Everything has XFS, except for 2 x 1Gb swap. > Kernel: 2.4.18, XFS = 1.1, XFS utils are: xfsprogs-2.0.3-0. > > I have this exact configuration running on two other PCs, and they have > been running for 0.5yr now with no hint of problem. Anyway, there is this > nasty PC, which crashed, prints an ugly kernel oops in /var/log/messages, > then kswapd becomes zombie, sometimes other processes (kupdated) as well, > the system starts to behave erratically (shutdown segfaults, CTRL+ALT+DEL > segfaults, etc.), and then finally it dies. > > I booted up XFS RH7,3 CD, and issued an xfs_repair on all the devices, of > course none mounted yet, such as: > xfs_repair /dev/md0 > .... > One some of the /dev/md devices, and notably on a third disk > (/dev/hdd, not part of the RAID) I get quite a few messages, but > xfs_repair vades itself through them, and returns. What I would expect > that it repaired the filesystem, and so if I run it again, I don't see any > "disconnected inode ..., bad fork, ..." messages. But this is not true; > a new xfs_repair produces almost exactly the same messages. If you run xfs_repair with files in lost+found, it blows them away first, so repeated repair runs which put stuff in lost+found will generate output. This should probably be in a FAQ somewhere. Mounting and unmounting before running repair is a good idea, as repair does not replay the log - anyone care to implement that ;-). > > Any clue on this? > Any idea or suggestion what else should be used? > > I also issued xfs_check, which seemed to repair things, or at least > report. I did not clearly catch if the operations by xfs_check are also > WRITE ones, or solely READ. > xfs_check is a readonly command, it does not fix anything. > The mystical thing is that if I unplug these two harddrives, hda and hdc, > and place them in an identically configured other PC (really all > components are the same brand/type), then I see no crashes. It might be > only luck, although I applied quite heavy disk IO and CPU-load tests. > > I replaced the motherboard and VGA card in the original system, moreover, > got rid of all unnecessary cards, such as SCSI, watchdog, etc. Crash still > happens if I copy a few gigs back and forth, then delete it. > Hmm, did you try something like moving the memory between the machines, or your ide cables? 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 14 14:34:53 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 14 Oct 2003 14:35:27 -0700 (PDT) Received: from heretic.physik.fu-berlin.de (root@heretic.physik.fu-berlin.de [160.45.32.86]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9ELYp25030573 for ; Tue, 14 Oct 2003 14:34:52 -0700 Received: from puariko.homeip.net (pD9E7D442.dip.t-dialin.net [217.231.212.66]) by heretic.physik.fu-berlin.de (8.12.8/8.12.8) with ESMTP id h9ELYmk0029008 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 14 Oct 2003 23:34:50 +0200 Received: (from thimm@localhost) by puariko.nirvana (8.12.10/8.12.8/Submit) id h9ELYm4P015920; Tue, 14 Oct 2003 23:34:48 +0200 Date: Tue, 14 Oct 2003 23:34:48 +0200 From: Axel Thimm To: linux-xfs@oss.sgi.com Subject: Re: Redhat 7.3 Installation Message-ID: <20031014213448.GF14576@puariko.nirvana> References: <20031014181104.GB48433@beast.clarksys.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SxgehGEc6vB0cZwN" Content-Disposition: inline In-Reply-To: <20031014181104.GB48433@beast.clarksys.com> User-Agent: Mutt/1.4.1i X-archive-position: 725 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Axel.Thimm@physik.fu-berlin.de Precedence: bulk X-list: linux-xfs Content-Length: 1147 Lines: 39 --SxgehGEc6vB0cZwN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 14, 2003 at 11:11:04AM -0700, Max Clark wrote: > Are there any published instructions for installing xfs on a RedHat > 7.3 system? I would like to end up with as close as possible to the > stock RedHat kernel. Yes, publishing now: ;) Get kernel and userland components from http://atrpms.physik.fu-berlin.de/name/kernel/ and http://atrpms.physik.fu-= berlin.de/name/xfs/ If you want to have a XFS root partition, you either need to do that manually with copying the root back and forth (see the FAQ), or better grab an installer and upgrade your kernel/xfs components to the above. Upgrading XFS as well as doing your RH7.3 errata is best done with apt/yum. --=20 Axel.Thimm@physik.fu-berlin.de --SxgehGEc6vB0cZwN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/jGv4QBVS1GOamfERArK/AJ9SeQiQ+TdTmnVG1KXnVbd/u0E+RwCdHcvl I9kTsxIKPEBLyNwAaCOHEXA= =8D1j -----END PGP SIGNATURE----- --SxgehGEc6vB0cZwN-- From owner-linux-xfs@oss.sgi.com Wed Oct 15 12:59:52 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 15 Oct 2003 13:00:31 -0700 (PDT) Received: from cfa.harvard.edu (cfa.harvard.edu [131.142.10.1]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9FJxp25002654 for ; Wed, 15 Oct 2003 12:59:52 -0700 Received: from antu (antu [131.142.25.237]) by cfa.harvard.edu (8.12.9-20030924/8.12.9/cfunix Mast-Sol 1.0) with ESMTP id h9FJxjMf013184; Wed, 15 Oct 2003 15:59:45 -0400 (EDT) Date: Wed, 15 Oct 2003 15:59:44 -0400 (EDT) From: Gaspar Bakos Reply-To: gbakos@cfa.harvard.edu To: Seth Mos cc: linux-xfs@oss.sgi.com Subject: Re: Kernel Oops - still not solved In-Reply-To: <4.3.2.7.2.20031013103103.02df9280@pop.xs4all.nl> Message-ID: References: <4.3.2.7.2.20031013103103.02df9280@pop.xs4all.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 726 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: gbakos@cfa.harvard.edu Precedence: bulk X-list: linux-xfs Content-Length: 275 Lines: 13 Hi, Seth, RE: > 1. Run memtest86 > 2. Buy new memory. Great! I replaced virtually everything in the machine, and was still crashing (even the motherboard). The same harddrives in other computers worked fine. Finally I replaced the memory. The problem is now gone. Gaspar From owner-linux-xfs@oss.sgi.com Wed Oct 15 13:03:06 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 15 Oct 2003 13:03:39 -0700 (PDT) Received: from cfa.harvard.edu (cfa.harvard.edu [131.142.10.1]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9FK3525002955 for ; Wed, 15 Oct 2003 13:03:06 -0700 Received: from antu (antu [131.142.25.237]) by cfa.harvard.edu (8.12.9-20030924/8.12.9/cfunix Mast-Sol 1.0) with ESMTP id h9FK32UT013371; Wed, 15 Oct 2003 16:03:02 -0400 (EDT) Date: Wed, 15 Oct 2003 16:03:01 -0400 (EDT) From: Gaspar Bakos Reply-To: gbakos@cfa.harvard.edu To: Steve Lord cc: linux-xfs@oss.sgi.com Subject: Re: Kernel Oops - still not solved In-Reply-To: <1066164284.25234.4.camel@jen.americas.sgi.com> Message-ID: References: <1066164284.25234.4.camel@jen.americas.sgi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 727 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: gbakos@cfa.harvard.edu Precedence: bulk X-list: linux-xfs Content-Length: 401 Lines: 15 Hi, Steve, RE: > Hmm, did you try something like moving the memory between the machines, > or your ide cables? As I just replied to Seth... I also tried the IDE cables, with no success, but finally it turned out to be the memory. Interestingly, the memory seemed fine at boot-up memoery test all the time. Anyway, no the problem is gone. Thanks for all of you for the heplful suggestions! Gaspar From owner-linux-xfs@oss.sgi.com Wed Oct 15 13:41:10 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 15 Oct 2003 13:41:51 -0700 (PDT) Received: from cfa.harvard.edu (cfa.harvard.edu [131.142.10.1]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9FKf925004369 for ; Wed, 15 Oct 2003 13:41:10 -0700 Received: from antu (antu [131.142.25.237]) by cfa.harvard.edu (8.12.9-20030924/8.12.9/cfunix Mast-Sol 1.0) with ESMTP id h9FKf9VI016448 for ; Wed, 15 Oct 2003 16:41:09 -0400 (EDT) Date: Wed, 15 Oct 2003 16:41:08 -0400 (EDT) From: Gaspar Bakos Reply-To: gbakos@cfa.harvard.edu To: linux-xfs@oss.sgi.com Subject: RH9.0 + XFS - advice Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 728 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: gbakos@cfa.harvard.edu Precedence: bulk X-list: linux-xfs Content-Length: 1388 Lines: 47 Howdy, I am trying to ugprade a RH9.0 2.4.20-9SGI-XFS-1.2.0 installation on a laptop (done from XFS installer CD) to a new kernel, such as 2.4.22 with XFS-1.3.1 Any advice on what (not) to do would be welcome... - Is the 2.4.22 kernel-patch considered as stable? - Will it cause a problem that the current XFS filesystem on the disk is 1.2.0, i.e. does one have to 'migrate'? - If I happen to use the RH9.0 XFS iso disk for rescue purposes, and have to boot in and due xfs_repair, won't it be a problem that the iso CD is xfs-1.2? - Is there any iso for RH9.0 with XFS1.3 (if this question makes sense at all)? To be honest, I am a bit confused at the XFS download section; in the FAQ http://oss.sgi.com/projects/xfs/faq.html#stablexfspatches there are (dead?) links to the latest stable versions: ftp://oss.sgi.com/projects/xfs/download/patches and ftp://oss.sgi.com/projects/xfs/download/latest/kernel_patches/ Anyway, I downloaded the following goodies following links from http://oss.sgi.com/projects/xfs/download.html: acl-2.2.15.src.tar.gz attr-2.4.8.src.tar.gz dmapi-2.0.8.src.tar.gz xfsdump-2.2.13.src.tar.gz xfsprogs-2.5.6.src.tar.gz xfs-2.4.22-all-i386.bz2 linux-2.4.22.tar.bz2 (from ftp://rpmfind.net/linux/SGILinux/) Let me know if any of these is considered obsolete, or some bugs have been corrected and new versions are recommended. Best wishes Gaspar From owner-linux-xfs@oss.sgi.com Wed Oct 15 14:00:40 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 15 Oct 2003 14:01:20 -0700 (PDT) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9FL0d25007538 for ; Wed, 15 Oct 2003 14:00:39 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h9FLIlHc001874 for ; Wed, 15 Oct 2003 16:18:47 -0500 Received: from tulip-e236.americas.sgi.com (tulip-e236.americas.sgi.com [128.162.236.208]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h9FL0XaP12349005; Wed, 15 Oct 2003 16:00:33 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by tulip-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h9FL0XSn33932196; Wed, 15 Oct 2003 16:00:33 -0500 (CDT) Received: from jen.americas.sgi.com (localhost.localdomain [127.0.0.1]) by jen.americas.sgi.com (8.12.8/8.12.8) with ESMTP id h9FL0X95031213; Wed, 15 Oct 2003 16:00:33 -0500 Received: (from lord@localhost) by jen.americas.sgi.com (8.12.8/8.12.8/Submit) id h9FL0WG0031211; Wed, 15 Oct 2003 16:00:32 -0500 X-Authentication-Warning: jen.americas.sgi.com: lord set sender to lord@sgi.com using -f Subject: Re: RH9.0 + XFS - advice From: Steve Lord To: gbakos@cfa.harvard.edu Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1066251631.30994.56.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 15 Oct 2003 16:00:31 -0500 X-archive-position: 729 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1872 Lines: 59 On Wed, 2003-10-15 at 15:41, Gaspar Bakos wrote: > Howdy, > > I am trying to ugprade a RH9.0 2.4.20-9SGI-XFS-1.2.0 installation on a > laptop (done from XFS installer CD) to a new kernel, such as > 2.4.22 with XFS-1.3.1 > > Any advice on what (not) to do would be welcome... > - Is the 2.4.22 kernel-patch considered as stable? > - Will it cause a problem that the current XFS filesystem on the disk is > 1.2.0, i.e. does one have to 'migrate'? > - If I happen to use the RH9.0 XFS iso disk for rescue purposes, and have > to boot in and due xfs_repair, won't it be a problem that the iso CD is > xfs-1.2? > - Is there any iso for RH9.0 with XFS1.3 (if this question makes sense at > all)? XFS metadata format does not change between versions, there are some new features, but nothing which has affected the on disk format. You can always mount older filesystems with newer code. Steve > > To be honest, I am a bit confused at the XFS download section; > in the FAQ > http://oss.sgi.com/projects/xfs/faq.html#stablexfspatches > there are (dead?) links to the latest stable versions: > > ftp://oss.sgi.com/projects/xfs/download/patches > and > ftp://oss.sgi.com/projects/xfs/download/latest/kernel_patches/ > > Anyway, I downloaded the following goodies following links from > http://oss.sgi.com/projects/xfs/download.html: > > acl-2.2.15.src.tar.gz > attr-2.4.8.src.tar.gz > dmapi-2.0.8.src.tar.gz > xfsdump-2.2.13.src.tar.gz > xfsprogs-2.5.6.src.tar.gz > > xfs-2.4.22-all-i386.bz2 > > linux-2.4.22.tar.bz2 > > (from > ftp://rpmfind.net/linux/SGILinux/) > > Let me know if any of these is considered obsolete, or some bugs have > been corrected and new versions are recommended. > > Best wishes > Gaspar -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Wed Oct 15 14:39:21 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 15 Oct 2003 14:39:56 -0700 (PDT) Received: from heretic.physik.fu-berlin.de (root@heretic.physik.fu-berlin.de [160.45.32.86]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9FLdK25009027 for ; Wed, 15 Oct 2003 14:39:21 -0700 Received: from puariko.homeip.net (pD9E7F41C.dip.t-dialin.net [217.231.244.28]) by heretic.physik.fu-berlin.de (8.12.8/8.12.8) with ESMTP id h9FLdDk0028540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 15 Oct 2003 23:39:17 +0200 Received: (from thimm@localhost) by puariko.nirvana (8.12.10/8.12.8/Submit) id h9FLd6VX020990; Wed, 15 Oct 2003 23:39:07 +0200 Date: Wed, 15 Oct 2003 23:39:04 +0200 From: Axel Thimm To: Gaspar Bakos Cc: linux-xfs@oss.sgi.com Subject: Re: RH9.0 + XFS - advice Message-ID: <20031015213904.GB9344@puariko.nirvana> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zx4FCpZtqtKETZ7O" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-archive-position: 730 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Axel.Thimm@physik.fu-berlin.de Precedence: bulk X-list: linux-xfs Content-Length: 1331 Lines: 41 --zx4FCpZtqtKETZ7O Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 15, 2003 at 04:41:08PM -0400, Gaspar Bakos wrote: > I am trying to ugprade a RH9.0 2.4.20-9SGI-XFS-1.2.0 installation on a > laptop (done from XFS installer CD) to a new kernel, such as > 2.4.22 with XFS-1.3.1 XFS 1.3.0 kernels and userland tools for Red Hat Linux 7.3, 8.0 and 9 can be found at http://atrpms.physik.fu-berlin.de/name/kernel/ and http://atrpms.physik.fu-berlin.de/name/xfs/. These kernels are based on RH latest errata for the given release, e.g. kernels are based on 2.4.20+. If you really want to test RH 2.4.22+ kernels with XFS 1.3.0, you can use patched rawhide kernels at http://atrpms.physik.fu-berlin.de/name/kernel-bleeding/ While the latter kernel also works fine on RH9, it is a test kernel, which may spontaneously eat your disk, CPU, keyboard and the user in front of it (at least the case is not affected ...). --=20 Axel.Thimm@physik.fu-berlin.de --zx4FCpZtqtKETZ7O Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/jb54QBVS1GOamfERAks9AJwMHYofx/EVLknE1Db9LhTnV6pXtgCgjsiu F5lmcD6E1+DrGcj2imWsmCk= =hq31 -----END PGP SIGNATURE----- --zx4FCpZtqtKETZ7O-- From owner-linux-xfs@oss.sgi.com Wed Oct 15 20:57:59 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 15 Oct 2003 20:58:37 -0700 (PDT) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9G3vw25021882 for ; Wed, 15 Oct 2003 20:57:58 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h9G22COO007853 for ; Wed, 15 Oct 2003 19:02:12 -0700 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h9G3vpjj2483742 for ; Thu, 16 Oct 2003 13:57:51 +1000 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h9G3voM82484666 for linux-xfs@oss.sgi.com; Thu, 16 Oct 2003 13:57:50 +1000 (EST) Date: Thu, 16 Oct 2003 13:57:50 +1000 (EST) From: Nathan Scott Message-Id: <200310160357.h9G3voM82484666@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: PARTIAL TAKE 902612 - fix inode btree lookup precision X-archive-position: 731 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 337 Lines: 13 Fix inode btree lookup code precision problem with very large allocation groups. Date: Wed Oct 15 20:53:49 PDT 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:160092a linux/fs/xfs/xfs_ialloc_btree.c - 1.77 From owner-linux-xfs@oss.sgi.com Thu Oct 16 00:23:59 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 16 Oct 2003 00:24:43 -0700 (PDT) Received: from ahriman.bucharest.roedu.net (ahriman.bucharest.roedu.net [141.85.128.71]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9G7Nj25031424 for ; Thu, 16 Oct 2003 00:23:59 -0700 Received: (qmail 3061 invoked by uid 1000); 16 Oct 2003 07:23:00 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 16 Oct 2003 07:23:00 -0000 Date: Thu, 16 Oct 2003 10:22:58 +0300 (EEST) From: Mihai RUSU X-X-Sender: dizzy@ahriman.bucharest.roedu.net To: linux-xfs@oss.sgi.com Subject: XFS 1.3.1 RedHat9 sources compilation trouble Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 732 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dizzy@roedu.net Precedence: bulk X-list: linux-xfs Content-Length: 2067 Lines: 58 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi I am trying to compile the RedHat9 "kernel-source" from the 1.3.1 XFS release but I have this problems: gcc -D__KERNEL__ -I/usr/src/linux-2.4.20-20.9.XFS1.3.1/include -Wall - -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common - -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686 - -nostdinc -iwithprefix include -DKBUILD_BASENAME=uid16 -c -o uid16.o uid16.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 lowlat.o profile.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 kksymoops.o futex.o pid.o uid16.o kksymoops.o(.text+0x60): In function `print_modules': : multiple definition of `print_modules' module.o(.text+0x3a0): first defined here ld: Warning: size of symbol `print_modules' changed from 1 to 35 in kksymoops.o make[2]: *** [kernel.o] Error 1 make[2]: Leaving directory `/usr/src/linux-2.4.20-20.9.XFS1.3.1/kernel' make[1]: *** [first_rule] Error 2 make[1]: Leaving directory `/usr/src/linux-2.4.20-20.9.XFS1.3.1/kernel' make: *** [_dir_kernel] Error 2 ver_linux says: Gnu C 3.2.2 Gnu make 3.80 util-linux 2.11z mount 2.11z modutils 2.4.22 e2fsprogs 1.32 Linux C Library 3.1.so* (this is strange, glibc is in fact 2.3.1) Dynamic linker (ldd) 2.3.1 Linux C++ Library 5.0.2* Procps 3.1.6 Net-tools 1.60 Kbd 1.08 Sh-utils 2.0 The base system is a Slackware 9.0, please help :) - ---------------------------- Mihai RUSU Email: dizzy@roedu.net GPG : http://dizzy.roedu.net/dizzy-gpg.txt WWW: http://dizzy.roedu.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/jkdUPZzOzrZY/1QRAucQAKDJ4puhvhNtvgFaAN+puce9NrZcggCfd3ar R1VXQAJ4fBij2x/DgLeIWNM= =NZSq -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Thu Oct 16 00:36:03 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 16 Oct 2003 00:36:48 -0700 (PDT) Received: from ishtar.tlinx.org ([64.81.58.33]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9G7a325032378 for ; Thu, 16 Oct 2003 00:36:03 -0700 Received: from tlinx.org (shiva [192.168.3.20]) by ishtar.tlinx.org (8.12.6/8.12.2/SuSE Linux 0.6) with ESMTP id h9G6xdZI006424; Wed, 15 Oct 2003 23:59:39 -0700 Message-ID: <3F8E41DA.4060500@tlinx.org> Date: Wed, 15 Oct 2003 23:59:38 -0700 From: lw User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20030916 X-Accept-Language: en-us, en-ca, en-gb, en-nz, en MIME-Version: 1.0 To: Russell Cattelan CC: Max Clark , linux-xfs@oss.sgi.com Subject: Re: xfs removed from ftp? References: <20031013162241.GA28237@beast.clarksys.com> <1066063487.10404.4.camel@naboo> In-Reply-To: <1066063487.10404.4.camel@naboo> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 733 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: xfs@tlinx.org Precedence: bulk X-list: linux-xfs Content-Length: 1140 Lines: 64 Russell Cattelan wrote: >On Mon, 2003-10-13 at 11:22, Max Clark wrote: > > >>Can anyone point me to a working mirror with the Release 1.3.1 >> >> >http://oss.sgi.com/projects/xfs/download.html > > >>Thanks, >>Max >> >>-- >>Max Clark >>Max Clark >> >> === oh, you mean there as in "here": ERROR The requested URL could not be retrieved ------------------------------------------------------------------------ The following URL could not be retrieved: ftp://oss.sgi.com/projects/xfs/download/ Squid sent the following FTP command: * CWD download * and then received this reply * Can't change directory to download: No such file or directory * ** This might be caused by an FTP URL with an absolute path (which does not comply with RFC 1738). If this is the cause, then the file can be found at ftp://oss.sgi.com/%2f/projects/xfs/download/. Your cache administrator is squid@ishtar . ------------------------------------------------------------------------ Generated Thu, 16 Oct 2003 06: From owner-linux-xfs@oss.sgi.com Thu Oct 16 04:59:41 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 16 Oct 2003 05:00:22 -0700 (PDT) Received: from ahriman.bucharest.roedu.net (ahriman.bucharest.roedu.net [141.85.128.71]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9GBxd25016677 for ; Thu, 16 Oct 2003 04:59:41 -0700 Received: (qmail 9185 invoked by uid 1000); 16 Oct 2003 11:58:55 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 16 Oct 2003 11:58:55 -0000 Date: Thu, 16 Oct 2003 14:58:50 +0300 (EEST) From: Mihai RUSU X-X-Sender: dizzy@ahriman.bucharest.roedu.net To: linux-xfs@oss.sgi.com Subject: Re: XFS 1.3.1 RedHat9 sources compilation trouble In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 735 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dizzy@roedu.net Precedence: bulk X-list: linux-xfs Content-Length: 2258 Lines: 64 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have tried on a RedHat9 system and I get the same error, please help! :) On Thu, 16 Oct 2003, Mihai RUSU wrote: > Hi > > I am trying to compile the RedHat9 "kernel-source" from the 1.3.1 XFS > release but I have this problems: > > gcc -D__KERNEL__ -I/usr/src/linux-2.4.20-20.9.XFS1.3.1/include -Wall > -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common > -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686 > -nostdinc -iwithprefix include -DKBUILD_BASENAME=uid16 -c -o uid16.o > uid16.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 lowlat.o profile.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 kksymoops.o futex.o pid.o uid16.o > kksymoops.o(.text+0x60): In function `print_modules': > : multiple definition of `print_modules' > module.o(.text+0x3a0): first defined here > ld: Warning: size of symbol `print_modules' changed from 1 to 35 in > kksymoops.o > make[2]: *** [kernel.o] Error 1 > make[2]: Leaving directory `/usr/src/linux-2.4.20-20.9.XFS1.3.1/kernel' > make[1]: *** [first_rule] Error 2 > make[1]: Leaving directory `/usr/src/linux-2.4.20-20.9.XFS1.3.1/kernel' > make: *** [_dir_kernel] Error 2 > > ver_linux says: > > Gnu C 3.2.2 > Gnu make 3.80 > util-linux 2.11z > mount 2.11z > modutils 2.4.22 > e2fsprogs 1.32 > Linux C Library 3.1.so* (this is strange, glibc is in fact 2.3.1) > Dynamic linker (ldd) 2.3.1 > Linux C++ Library 5.0.2* > Procps 3.1.6 > Net-tools 1.60 > Kbd 1.08 > Sh-utils 2.0 > > The base system is a Slackware 9.0, please help :) > > - ---------------------------- Mihai RUSU Email: dizzy@roedu.net GPG : http://dizzy.roedu.net/dizzy-gpg.txt WWW: http://dizzy.roedu.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/jof+PZzOzrZY/1QRAqeAAJoDsRpky39IEenSEXaegbkfckx4WACg4sqP n4e3hRVZMzi99u9ywsqZzfU= =m5Az -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Thu Oct 16 06:21:28 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 16 Oct 2003 06:22:11 -0700 (PDT) Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9GDLP25018639 for ; Thu, 16 Oct 2003 06:21:26 -0700 Received: (qmail 19807 invoked from network); 16 Oct 2003 13:21:21 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 16 Oct 2003 13:21:20 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id DEE04C00AD; Thu, 16 Oct 2003 23:21: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 2D22A14014F; Thu, 16 Oct 2003 23:21:08 +1000 (EST) X-Mailer: exmh version 2.5 01/15/2001 with nmh-1.0.4 From: Keith Owens To: lw Cc: Russell Cattelan , linux-xfs@oss.sgi.com Subject: Re: xfs removed from ftp? In-reply-to: Your message of "Wed, 15 Oct 2003 23:59:38 MST." <3F8E41DA.4060500@tlinx.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 16 Oct 2003 23:21:06 +1000 Message-ID: <2984.1066310466@ocs3.intra.ocs.com.au> X-archive-position: 736 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 186 Lines: 4 ftp://oss.sgi.com/projects/xfs/download/ does not exist. Use ftp://oss.sgi.com/projects/xfs/ for now. Could somebody on oss please put back the old name, including the download path? From owner-linux-xfs@oss.sgi.com Thu Oct 16 08:03:07 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 16 Oct 2003 08:03:41 -0700 (PDT) Received: from psychedelic.baana.suomi.net (smmsp@psychedelic.baana.suomi.net [213.139.166.169]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9GF3525021342 for ; Thu, 16 Oct 2003 08:03:06 -0700 Received: (from bunnyh@localhost) by psychedelic.baana.suomi.net (8.11.6p3/8.11.6) id h9GF33T25896 for linux-xfs@oss.sgi.com; Thu, 16 Oct 2003 18:03:03 +0300 (EEST) Date: Thu, 16 Oct 2003 18:03:03 +0300 From: Juha K Kallio To: linux-xfs@oss.sgi.com Subject: xfs_fsr not defragging properly? Message-ID: <20031016150303.GA25882@psychedelic.baana.suomi.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-archive-position: 737 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bunnyh@psychedelic.baana.suomi.net Precedence: bulk X-list: linux-xfs Content-Length: 430 Lines: 5 I have a 80GB partition with many files with variable sizes that is 76% full ATM. I've noticed that there are some inodes that xfs_fsr never defrags (eg. "No improvement made: ino=156196115"), even though there certainly is enough space (19GB) for the file (less than 1GB). What's the cause for this? If there's no consistent space for the inode to fit in to, shouldn't the program re-organize other inodes to make that space? From owner-linux-xfs@oss.sgi.com Thu Oct 16 12:31:45 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 16 Oct 2003 12:32:26 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9GJVi25008399 for ; Thu, 16 Oct 2003 12:31:45 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h9GJVdq0032129 for ; Thu, 16 Oct 2003 12:31:39 -0700 Received: from thistle-e236.americas.sgi.com (thistle-e236.americas.sgi.com [128.162.236.204]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h9GJVdaP12352829 for ; Thu, 16 Oct 2003 14:31:39 -0500 (CDT) Received: from clink.americas.sgi.com (clink.americas.sgi.com [128.162.236.153]) by thistle-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h9GJVd0L21341919 for ; Thu, 16 Oct 2003 14:31:39 -0500 (CDT) Received: from clink.americas.sgi.com (localhost [127.0.0.1]) by clink.americas.sgi.com (SGI-8.12.5/8.12.5/erikj-IRIX6519-news) with ESMTP id h9GJVctZ8821979 for ; Thu, 16 Oct 2003 14:31:38 -0500 (CDT) Received: (from roehrich@localhost) by clink.americas.sgi.com (SGI-8.12.5/8.12.5/Submit) id h9GJVcEX7891273 for linux-xfs@oss.sgi.com; Thu, 16 Oct 2003 14:31:38 -0500 (CDT) Date: Thu, 16 Oct 2003 14:31:38 -0500 (CDT) From: Dean Roehrich Message-Id: <200310161931.h9GJVcEX7891273@clink.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: PARTIAL TAKE 902005 - X-archive-position: 738 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: roehrich@clink.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1565 Lines: 45 Implement dm_get_bulkall Date: Thu Oct 16 12:31:15 PDT 2003 Workarea: clink.americas.sgi.com:/data/clink/a67/roehrich/2.4.x-xfs Author: roehrich Merged by: roehrich Merged mods: 2.4.x-xfs-kern:slinx:159760a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:159760a linux/fs/xfs/xfs_itable.c - 1.119 - Merge of 2.4.x-xfs-kern:slinx:159760a by roehrich. Change xfs_bulkstat() to take a pointer to private data that the formatter will use for its own purposes. Keep track of the buffer size in bytes rather than in units of statstruct_size. Tell the formatter how big the buffer is, and let the formatter tell us how much it used. linux/fs/xfs/xfs_itable.h - 1.41 - Merge of 2.4.x-xfs-kern:slinx:159760a by roehrich. Update prototypes of xfs_bulkstat and bulkstat_one_pf. linux/fs/xfs/quota/xfs_qm_syscalls.c - 1.6 - Merge of 2.4.x-xfs-kern:slinx:159760a by roehrich. Update use of xfs_bulkstat. linux/fs/xfs/quota/xfs_qm.c - 1.7 - Merge of 2.4.x-xfs-kern:slinx:159760a by roehrich. Update use of xfs_bulkstat. linux/fs/xfs/dmapi/dmapi_xfs.c - 1.22 - Merge of 2.4.x-xfs-kern:slinx:159760a by roehrich. Change DM_STAT_SIZE to take a type parameter. Provide implementation for dm_get_bulkall_rvp(). Modify xfs_dm_bulkstat_one() to handle dm_xstat_t or dm_stat_t. Change xfs_dm_get_config() to return TRUE for DM_CONFIG_BULKALL. linux/fs/xfs/linux/xfs_ioctl.c - 1.100 - Merge of 2.4.x-xfs-kern:slinx:159760a by roehrich. Update use of xfs_bulkstat. From owner-linux-xfs@oss.sgi.com Thu Oct 16 13:02:56 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 16 Oct 2003 13:03:37 -0700 (PDT) Received: from beast.clarksys.com (sm02.cthought.com [64.81.233.33]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9GK2t25010091 for ; Thu, 16 Oct 2003 13:02:56 -0700 Received: (qmail 90094 invoked by uid 1000); 16 Oct 2003 20:02:20 -0000 Date: Thu, 16 Oct 2003 13:02:20 -0700 From: Max Clark To: linux-xfs@oss.sgi.com Subject: Advise for filesystem creation Message-ID: <20031016200220.GA89959@beast.clarksys.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.5.4i X-archive-position: 739 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: maxc-xfs@beast.clarksys.com Precedence: bulk X-list: linux-xfs Content-Length: 451 Lines: 18 Hi all, I am testing xfs on one of my systems and I am curious about some tunning options. Given that my filesystem is 1.5TB The average filesize will be 750MB of binary data What tunning options should I use when I create the filesystem, and when I mount the filesystem? Thanks in advance, Max -- Max Clark My Blog http://www.clarksys.com >> spamtrap: spam@clarksys.com - do NOT ever send email to this address << From owner-linux-xfs@oss.sgi.com Thu Oct 16 13:46:11 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 16 Oct 2003 13:46:52 -0700 (PDT) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9GKkB25013407 for ; Thu, 16 Oct 2003 13:46:11 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h9GIoSOO001377 for ; Thu, 16 Oct 2003 11:50:28 -0700 Received: from tulip-e236.americas.sgi.com (tulip-e236.americas.sgi.com [128.162.236.208]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h9GKk3P512351912; Thu, 16 Oct 2003 15:46:03 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by tulip-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h9GKk3Sn33871130; Thu, 16 Oct 2003 15:46:03 -0500 (CDT) Received: from jen.americas.sgi.com (localhost.localdomain [127.0.0.1]) by jen.americas.sgi.com (8.12.8/8.12.8) with ESMTP id h9GKk295001141; Thu, 16 Oct 2003 15:46:03 -0500 Received: (from lord@localhost) by jen.americas.sgi.com (8.12.8/8.12.8/Submit) id h9GKk2LK001139; Thu, 16 Oct 2003 15:46:02 -0500 X-Authentication-Warning: jen.americas.sgi.com: lord set sender to lord@sgi.com using -f Subject: Re: Advise for filesystem creation From: Steve Lord To: Max Clark Cc: linux-xfs@oss.sgi.com In-Reply-To: <20031016200220.GA89959@beast.clarksys.com> References: <20031016200220.GA89959@beast.clarksys.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1066337160.30991.204.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 16 Oct 2003 15:46:01 -0500 X-archive-position: 740 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1642 Lines: 50 On Thu, 2003-10-16 at 15:02, Max Clark wrote: > Hi all, > > I am testing xfs on one of my systems and I am curious about some tunning options. > > Given that my filesystem is 1.5TB > The average filesize will be 750MB of binary data Thats not a lot of files in a filesystem.... Since you are going over 1 Tbyte, make sure you use -i size=512 this will make inodes 512 bytes, and have the affect of keeping inode numbers under 32 bits. After this is comes down to how you will be doing I/O to the filesystem, and what underlying hardware it is made of and do you have speed requirements. You can specify stripe alignment on the mkfs command line, for some configurations it will work it out automatically. The file system uses this as a hint to the how to initially lay out the filesystem, and what are good boundaries to start extents on. The mkfs man page talks about this. After that, the only one which might be worth mentioning is using version 2 logs if you are running on top of software raid5. You want to stripe align the log to avoid non-aligned writes from blowing the raid5 stripe cache away. I would recommend doing some experiments before you commit yourself to a layout. Steve > > What tunning options should I use when I create the filesystem, and when I mount the filesystem? > > Thanks in advance, > Max > > -- > Max Clark > My Blog http://www.clarksys.com > > >> spamtrap: spam@clarksys.com - do NOT ever send email to this address << -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Oct 16 14:26:57 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 16 Oct 2003 14:27:31 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9GLQu25014932 for ; Thu, 16 Oct 2003 14:26:56 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h9GLQpq0013387 for ; Thu, 16 Oct 2003 14:26:51 -0700 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h9GLQoP512394977; Thu, 16 Oct 2003 16:26:50 -0500 (CDT) Received: from nstraz by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1AAFdy-0001se-00; Thu, 16 Oct 2003 16:26:50 -0500 Date: Thu, 16 Oct 2003 16:26:50 -0500 From: Nathan Straz To: Juha K Kallio Cc: linux-xfs@oss.sgi.com Subject: Re: xfs_fsr not defragging properly? Message-ID: <20031016212650.GC29803@sgi.com> Mail-Followup-To: Juha K Kallio , linux-xfs@oss.sgi.com References: <20031016150303.GA25882@psychedelic.baana.suomi.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031016150303.GA25882@psychedelic.baana.suomi.net> User-Agent: Mutt/1.5.3i X-archive-position: 741 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nstraz@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 982 Lines: 19 On Thu, Oct 16, 2003 at 06:03:03PM +0300, Juha K Kallio wrote: > I have a 80GB partition with many files with variable sizes that is > 76% full ATM. I've noticed that there are some inodes that xfs_fsr > never defrags (eg. "No improvement made: ino=156196115"), even though > there certainly is enough space (19GB) for the file (less than 1GB). > What's the cause for this? If there's no consistent space for the > inode to fit in to, shouldn't the program re-organize other inodes to > make that space? There probably isn't a contiguous hole big enough for the file. xfs_fsr does not defragment free space. So unless you get lucky and move a file out of the way to make a large contiguous hole, you're probably not going to get a better layout for that file. -- 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 16 17:08:33 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 16 Oct 2003 17:08:36 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10) with ESMTP id h9H08X25004791 for ; Thu, 16 Oct 2003 17:08:33 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id h9H08XAQ004789 for linux-xfs@oss.sgi.com; Thu, 16 Oct 2003 17:08:33 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10) with ESMTP id h9H08V27004775 for ; Thu, 16 Oct 2003 17:08:31 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id h9GNObDP024599; Thu, 16 Oct 2003 16:24:37 -0700 Date: Thu, 16 Oct 2003 16:24:37 -0700 Message-Id: <200310162324.h9GNObDP024599@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 282] Kernel panic/Bad magic number on XFS filesystem X-Bugzilla-Reason: AssignedTo X-archive-position: 742 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 786 Lines: 25 http://oss.sgi.com/bugzilla/show_bug.cgi?id=282 owen@bardstown.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID ------- Additional Comments From owen@bardstown.com 2003-16-10 16:24 PDT ------- *sigh* I am resolving this as INVALID. This is my own stupid fault. Apparently INITRD throws an error if I do not build in ext2fs support, and that error reads bad magic number. This is by no means a bug with XFS. XFS rocks. Sorry for the bugspam ;-(( ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Oct 16 19:30:20 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 16 Oct 2003 19:30:54 -0700 (PDT) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9H2UK25007564 for ; Thu, 16 Oct 2003 19:30:20 -0700 Received: from bruce.melbourne.sgi.com (bruce.melbourne.sgi.com [134.14.54.176]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h9H2mTHc027003 for ; Thu, 16 Oct 2003 21:48:32 -0500 Received: from bruce.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by bruce.melbourne.sgi.com (8.12.8/8.12.8) with ESMTP id h9H2U34Y002926 for ; Fri, 17 Oct 2003 12:30:03 +1000 Received: (from nathans@localhost) by bruce.melbourne.sgi.com (8.12.8/8.12.8/Submit) id h9H2U2ie002925 for linux-xfs@oss.sgi.com; Fri, 17 Oct 2003 12:30:02 +1000 Date: Fri, 17 Oct 2003 12:30:02 +1000 From: Nathan Scott Message-Id: <200310170230.h9H2U2ie002925@bruce.melbourne.sgi.com> Subject: TAKE 901693 - tracing X-archive-position: 743 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@bruce.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 417 Lines: 16 Add some IO path tracing, move inval_cached_pages to a better home to help. Date: Thu Oct 16 19:22:25 PDT 2003 Workarea: bruce.melbourne.sgi.com:/build2/clean24 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:160171a linux/fs/xfs/xfs_rw.h - 1.74 linux/fs/xfs/xfs_rw.c - 1.385 linux/fs/xfs/linux/xfs_lrw.h - 1.38 linux/fs/xfs/linux/xfs_lrw.c - 1.202 From owner-linux-xfs@oss.sgi.com Thu Oct 16 20:34:06 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 16 Oct 2003 20:34:39 -0700 (PDT) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9H3Y525011975 for ; Thu, 16 Oct 2003 20:34:06 -0700 Received: from bruce.melbourne.sgi.com (bruce.melbourne.sgi.com [134.14.54.176]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h9H3qHHc023730 for ; Thu, 16 Oct 2003 22:52:17 -0500 Received: from bruce.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by bruce.melbourne.sgi.com (8.12.8/8.12.8) with ESMTP id h9H3XsdR001540 for ; Fri, 17 Oct 2003 13:33:54 +1000 Received: (from nathans@localhost) by bruce.melbourne.sgi.com (8.12.8/8.12.8/Submit) id h9H3XskW001539 for linux-xfs@oss.sgi.com; Fri, 17 Oct 2003 13:33:54 +1000 Date: Fri, 17 Oct 2003 13:33:54 +1000 From: Nathan Scott Message-Id: <200310170333.h9H3XskW001539@bruce.melbourne.sgi.com> Subject: TAKE 901693 - ktrace fixes X-archive-position: 744 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@bruce.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 491 Lines: 17 Fix ktrace code - dont build unilaterally, and do earlier initialisation for pagebuf use (later). Date: Thu Oct 16 20:29:52 PDT 2003 Workarea: bruce.melbourne.sgi.com:/build2/clean24 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:160172a linux/fs/xfs/xfs_vfsops.c - 1.435 linux/fs/xfs/support/Makefile - 1.16 linux/fs/xfs/support/ktrace.c - 1.17 linux/fs/xfs/support/ktrace.h - 1.10 linux/fs/xfs/linux/xfs_super.c - 1.273 From owner-linux-xfs@oss.sgi.com Fri Oct 17 01:52:32 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 17 Oct 2003 01:53:17 -0700 (PDT) Received: from mail.vcc.de (mail.vcc.de [217.111.2.122]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9H8qV25023225 for ; Fri, 17 Oct 2003 01:52:32 -0700 Received: from localhost (localhost [127.0.0.1]) by mail.vcc.de (Postfix) with ESMTP id E84F5161ED5 for ; Fri, 17 Oct 2003 10:52:28 +0200 (CEST) Received: from mail.vcc.de ([127.0.0.1]) by localhost (mail.vcc.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03192-10 for ; Fri, 17 Oct 2003 10:52:28 +0200 (CEST) Received: from opticalart.de (wolverine.vcc.de [217.111.2.200]) by mail.vcc.de (Postfix) with ESMTP id 0DB1A161EAE for ; Fri, 17 Oct 2003 10:52:28 +0200 (CEST) Message-ID: <3F8FADAF.6090001@opticalart.de> Date: Fri, 17 Oct 2003 10:51:59 +0200 From: Frank Hellmann Organization: Optical Art Film- und Special-Effects GmbH User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030926 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Redhat 9 XFS installer X-Enigmail-Version: 0.76.4.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at vcc.de X-archive-position: 745 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: frank@opticalart.de Precedence: bulk X-list: linux-xfs Content-Length: 521 Lines: 14 Hi! Has anybody a link to a Redhat 9 + SGI XFS install iso? It seems that the "old" / "possibly SCOs right infringing" copies are gone from the offical servers. Whats the plan for a XFS1.3.1 installer, anyway? Cheers, Frank... -- -------------------------------------------------------------------------- Frank Hellmann Optical Art GmbH Waterloohain 7a Digital Cinema http://www.opticalart.de 22769 Hamburg frank@opticalart.de Tel: ++49 40 5111051 Fax: ++49 40 43169199 From owner-linux-xfs@oss.sgi.com Fri Oct 17 02:08:36 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 17 Oct 2003 02:09:01 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10) with ESMTP id h9H98Z25023971 for ; Fri, 17 Oct 2003 02:08:35 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id h9H98ZEa023970 for linux-xfs@oss.sgi.com; Fri, 17 Oct 2003 02:08:35 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10) with ESMTP id h9H98Y27023956 for ; Fri, 17 Oct 2003 02:08:34 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id h9H8wRUD023714; Fri, 17 Oct 2003 01:58:27 -0700 Date: Fri, 17 Oct 2003 01:58:27 -0700 Message-Id: <200310170858.h9H8wRUD023714@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 283] New: kernel-source-2.4.20-20.9.XFS1.3.1.i386.rpm fails to compile X-Bugzilla-Reason: AssignedTo X-archive-position: 746 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2535 Lines: 68 http://oss.sgi.com/bugzilla/show_bug.cgi?id=283 Summary: kernel-source-2.4.20-20.9.XFS1.3.1.i386.rpm fails to compile Product: Linux XFS Version: Current Platform: IA32 OS/Version: Linux Status: NEW Severity: normal Priority: Medium Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: dizzy@roedu.net Hi I am trying to compile the kernel source from kernel-source-2.4.20-20.9.XFS1.3.1.i386.rpm (md5: 2d8218de17c798b79a77e38aec3f563b). I have tried it on Slackware 9.0, Gentoo 1.4, RedHat9 and it fails on all this distros with exactly the same error. gcc -D__KERNEL__ -I/usr/src/linux-2.4.20-20.9.XFS1.3.1/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686 -nostdinc -iwithprefix include -DKBUILD_BASENAME=uid16 -c -o uid16.o uid16.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 lowlat.o profile.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 kksymoops.o futex.o pid.o uid16.o kksymoops.o(.text+0x60): In function `print_modules': : multiple definition of `print_modules' module.o(.text+0x3a0): first defined here ld: Warning: size of symbol `print_modules' changed from 1 to 35 in kksymoops.o make[2]: *** [kernel.o] Error 1 make[2]: Leaving directory `/usr/src/linux-2.4.20-20.9.XFS1.3.1/kernel' make[1]: *** [first_rule] Error 2 make[1]: Leaving directory `/usr/src/linux-2.4.20-20.9.XFS1.3.1/kernel' make: *** [_dir_kernel] Error 2 $ . scripts/ver_linux If some fields are empty or look unusual you may have an old version. Compare to the current minimal requirements in Documentation/Changes. Linux heracle 2.4.18-18SGI_XFS_1.2.0custom #24 SMP Mon Jul 14 17:23:22 EEST 2003 i686 unknown Gnu C 3.2.2 Gnu make 3.80 util-linux 2.11z mount 2.11z modutils 2.4.22 e2fsprogs 1.32 Linux C Library 3.1.so* (in fact its glibc 2.3.1) Dynamic linker (ldd) 2.3.1 Linux C++ Library 5.0.2* Procps 3.1.6 Net-tools 1.60 Kbd 1.08 Sh-utils 2.0 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Fri Oct 17 07:08:37 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 17 Oct 2003 07:09:00 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10) with ESMTP id h9HE8b25006026 for ; Fri, 17 Oct 2003 07:08:37 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id h9HE8bwv006025 for linux-xfs@oss.sgi.com; Fri, 17 Oct 2003 07:08:37 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10) with ESMTP id h9HE8Z27006009 for ; Fri, 17 Oct 2003 07:08:35 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id h9HDYTLL004026; Fri, 17 Oct 2003 06:34:29 -0700 Date: Fri, 17 Oct 2003 06:34:29 -0700 Message-Id: <200310171334.h9HDYTLL004026@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 283] kernel-source-2.4.20-20.9.XFS1.3.1.i386.rpm fails to compile X-Bugzilla-Reason: AssignedTo X-archive-position: 748 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 662 Lines: 23 http://oss.sgi.com/bugzilla/show_bug.cgi?id=283 ------- Additional Comments From dizzy@roedu.net 2003-17-10 01:59 PDT ------- Created an attachment (id=88) --> (http://oss.sgi.com/bugzilla/attachment.cgi?id=88&action=view) .config file I use when getting the error I have attached the .config file on which I get the error. ------- Additional Comments From dizzy@roedu.net 2003-17-10 06:34 PDT ------- I have also tried Axel Thimm's RedHat9 xfs 1.3.0 kernel (kernel-source-2.4.20-20_29.rh9.at.i386.rpm) and it compiled just fine. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Fri Oct 17 08:08:37 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 17 Oct 2003 08:09:00 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10) with ESMTP id h9HF8b25010850 for ; Fri, 17 Oct 2003 08:08:37 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id h9HF8bix010849 for linux-xfs@oss.sgi.com; Fri, 17 Oct 2003 08:08:37 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10) with ESMTP id h9HF8Z27010835 for ; Fri, 17 Oct 2003 08:08:35 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id h9HF6nG7010801; Fri, 17 Oct 2003 08:06:49 -0700 Date: Fri, 17 Oct 2003 08:06:49 -0700 Message-Id: <200310171506.h9HF6nG7010801@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 283] kernel-source-2.4.20-20.9.XFS1.3.1.i386.rpm fails to compile X-Bugzilla-Reason: AssignedTo X-archive-position: 749 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 349 Lines: 15 http://oss.sgi.com/bugzilla/show_bug.cgi?id=283 ------- Additional Comments From sandeen@sgi.com 2003-17-10 08:06 PDT ------- As a workaround, I think a make mrproper might clean it up? Not sure what the root problem is. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Fri Oct 17 09:08:37 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 17 Oct 2003 09:09:01 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10) with ESMTP id h9HG8b25016705 for ; Fri, 17 Oct 2003 09:08:37 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id h9HG8bsh016704 for linux-xfs@oss.sgi.com; Fri, 17 Oct 2003 09:08:37 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10) with ESMTP id h9HG8Z27016688 for ; Fri, 17 Oct 2003 09:08:35 -0700 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id h9HFEGu4011353; Fri, 17 Oct 2003 08:14:16 -0700 Date: Fri, 17 Oct 2003 08:14:16 -0700 Message-Id: <200310171514.h9HFEGu4011353@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 283] kernel-source-2.4.20-20.9.XFS1.3.1.i386.rpm fails to compile X-Bugzilla-Reason: AssignedTo X-archive-position: 750 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 412 Lines: 16 http://oss.sgi.com/bugzilla/show_bug.cgi?id=283 ------- Additional Comments From dizzy@roedu.net 2003-17-10 08:14 PDT ------- Already did that before getting the problem and to make sure I did now again make mrproper, make menuconfig, make dep, make bzImage and I get the same error. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Fri Oct 17 09:39:09 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 17 Oct 2003 09:39:43 -0700 (PDT) Received: from allanon.amazing-internet.net (lorn.amazing-internet.net [213.210.55.94]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9HGd725018778 for ; Fri, 17 Oct 2003 09:39:09 -0700 Received: from althea.amazing-internet.net ([172.16.1.190] helo=amazinginternet.com) by allanon.amazing-internet.net with esmtp (Exim 3.35 #1 (Debian)) id 1AAXcj-0002L6-00; Fri, 17 Oct 2003 17:38:45 +0100 Message-ID: <3F901B15.70609@amazinginternet.com> Date: Fri, 17 Oct 2003 17:38:45 +0100 From: Ronny Adsetts Organization: Amazing Internet Ltd User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com, linux-lvm@sistina.com Subject: Error on unmounting XFS LVM snapshot Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner: Found to be clean X-archive-position: 751 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ronny.adsetts@amazinginternet.com Precedence: bulk X-list: linux-xfs Content-Length: 1649 Lines: 57 Hi, Please Cc me on any replies. I am seeing an error logged when unmounting an LVM snapshot of an XFS partition. Google doesn't give me much. I have reproduced this error on a different system using a totally different disk sub-system (Mylex eXtremeRAID 3000) - the system below has an Adaptec 2400A. Details are: System is XFS on top of LVM on top of hardware RAID. Software used: Debian: 3.0 (Mostly) Kernel: 2.4.21 Kernel patches: Debian standard kernel patches; XFS 1.3.0 LVM utils: 1.0.4-4 (Debian) XFS utils: 2.5.6-1 (Debian) Sequence of actions: 1: xfs_freeze -f /home 2: lvcreate -L 1G -s -n home_lv_bak /dev/vg0/home_lv 3: xfs_freeze -u /home 4: mount -t xfs -onouuid,ro,usrquota /dev/vg0/home_lv_bak /mnt/home 5: umount /mnt/home 6: lvremove -f /dev/vg0/home_lv_bak On step 5 of above, an error is logged: Logs: Oct 17 17:23:44 jettero kernel: lvm - lvm_map: ll_rw_blk write for readonly LV /dev/vg0/home_lv_bak Oct 17 17:23:44 jettero kernel: xfs_force_shutdown(lvm(58,10),0x1) called from line 351 of file xfs_rw.c. Return address = 0xc01fd6aa Oct 17 17:23:44 jettero kernel: Filesystem "lvm(58,10)": I/O Error Detected. Shutting down filesystem: lvm(58,10) Oct 17 17:23:44 jettero kernel: Please umount the filesystem, and rectify the problem(s) There is no oops and machine seems stable enough, though it's only been running a couple of days since I first did this. Is this anything to worry about? Is this a known problem? Are there any patches to fix it? Thanks and regards, Ronny Adsetts -- Technical Director Amazing Internet Ltd, London t: +44 20 8607 9535 f: +44 20 8607 9536 w: www.amazinginternet.com From owner-linux-xfs@oss.sgi.com Fri Oct 17 13:36:23 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 17 Oct 2003 13:37:01 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9HKaN25029810 for ; Fri, 17 Oct 2003 13:36:23 -0700 Received: from bruce.melbourne.sgi.com (bruce.melbourne.sgi.com [134.14.54.176]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h9HKaHq0000845 for ; Fri, 17 Oct 2003 13:36:17 -0700 Received: from bruce.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by bruce.melbourne.sgi.com (8.12.8/8.12.8) with ESMTP id h9HKa98m031624 for ; Sat, 18 Oct 2003 06:36:09 +1000 Received: (from nathans@localhost) by bruce.melbourne.sgi.com (8.12.8/8.12.8/Submit) id h9HKa9el031623 for linux-xfs@oss.sgi.com; Sat, 18 Oct 2003 06:36:09 +1000 Date: Sat, 18 Oct 2003 06:36:09 +1000 From: Nathan Scott Message-Id: <200310172036.h9HKa9el031623@bruce.melbourne.sgi.com> Subject: TAKE - tracing X-archive-position: 752 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@bruce.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 651 Lines: 26 Fix log tracing code so it is independent of DEBUG like other traces. Date: Fri Oct 17 02:13:05 PDT 2003 Workarea: bruce.melbourne.sgi.com:/build2/clean24 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:160178a linux/fs/xfs/xfs_log.c - 1.284 linux/fs/xfs/xfs_log_priv.h - 1.98 Add back xfsidbg tracing code, remove ktrace<->debug dependency. Date: Fri Oct 17 13:34:24 PDT 2003 Workarea: bruce.melbourne.sgi.com:/build2/clean24 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:160219a linux/fs/xfs/xfsidbg.c - 1.241 From owner-linux-xfs@oss.sgi.com Sat Oct 18 09:47:29 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 18 Oct 2003 09:48:08 -0700 (PDT) Received: from ying.yingternet.com (n105.priced2go.net [208.179.93.105]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9IGlS25006527 for ; Sat, 18 Oct 2003 09:47:28 -0700 Received: from gateway-att.yingternet.com (c-24-126-235-193.we.client2.attbi.com [24.126.235.193]) by ying.yingternet.com (Postfix) with ESMTP id C1AAF30009A for ; Sat, 18 Oct 2003 09:47:32 -0700 (PDT) Received: from kenshin.yingternet.org (kenshin.yingternet.com [192.168.10.10]) by gateway-att.yingternet.com (Postfix) with ESMTP id 94FAC8152F for ; Sat, 18 Oct 2003 09:32:51 -0700 (PDT) Received: from yingternet.com (kyoka.yingternet.org [192.168.10.11]) by kenshin.yingternet.org (Postfix) with ESMTP id 6DE7C2007B6 for ; Sat, 18 Oct 2003 09:52:50 -0700 (PDT) Message-ID: <3F916F45.8090801@yingternet.com> Date: Sat, 18 Oct 2003 09:50:13 -0700 From: Ying-Hung Chen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031017 X-Accept-Language: en-us, zh-tw, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: xfs quota does not work with encrypted loop filesystem X-Enigmail-Version: 0.76.7.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 753 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ying@yingternet.com Precedence: bulk X-list: linux-xfs Content-Length: 513 Lines: 25 Hi, I am currently running mandrake 9.2, (this applies to 9.1 and 9.0 also) xfs quota does not work with encrypted option turned on. (through the loop device) for example: /dev/hde11 /home xfs encryption=AES128,encrypted,grpquota,usrquota 0 0 has the encryption, but unable to assign quota, enforce or show quota. without the encryption, quota just works. I believe this is probably not mandrake specific problem, does anyone have similar setup that works? Thanks, -Ying PS. Please CC me on reply. From owner-linux-xfs@oss.sgi.com Sat Oct 18 19:31:45 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 18 Oct 2003 19:32:24 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9J2Vj25026034 for ; Sat, 18 Oct 2003 19:31:45 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h9J2Vdq0028295 for ; Sat, 18 Oct 2003 19:31:40 -0700 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h9J2VdP512381472 for ; Sat, 18 Oct 2003 21:31:39 -0500 (CDT) Received: from sgi.com (penguin.americas.sgi.com [128.162.240.135]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h9J2VdRn311997937 for ; Sat, 18 Oct 2003 21:31:39 -0500 (CDT) Received: from penguin.americas.sgi.com (localhost.localdomain [127.0.0.1]) by sgi.com (8.12.8/8.12.8) with ESMTP id h9J2PjGf032207 for ; Sat, 18 Oct 2003 21:25:46 -0500 Received: (from sandeen@localhost) by penguin.americas.sgi.com (8.12.8/8.12.8/Submit) id h9J2Pjf2032205 for linux-xfs@oss.sgi.com; Sat, 18 Oct 2003 21:25:45 -0500 Date: Sat, 18 Oct 2003 21:25:45 -0500 From: Eric Sandeen Message-Id: <200310190225.h9J2Pjf2032205@penguin.americas.sgi.com> Subject: TAKE - update fsck.xfs man page X-archive-position: 754 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@penguin.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 489 Lines: 18 Add references to xfs_check & xfs_repair for problems beyond the scope of normal recovery. slashdotters won't know they exist otherwise. :) Date: Sat Oct 18 19:30:37 PDT 2003 Workarea: penguin.americas.sgi.com:/src/sandeen/xfs-cmds The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:160239a xfsprogs/man/man8/fsck.xfs.8 - 1.3 - Add references to xfs_check & xfs_repair for problems beyond the scope of normal recovery. From owner-linux-xfs@oss.sgi.com Sun Oct 19 17:38:34 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 19 Oct 2003 17:39:15 -0700 (PDT) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9K0cY25010753 for ; Sun, 19 Oct 2003 17:38:34 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id h9JMh0OO026216 for ; Sun, 19 Oct 2003 15:43:00 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA02025; Mon, 20 Oct 2003 10:38:20 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h9K0c3Uc667027; Mon, 20 Oct 2003 10:38:04 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id h9K0ZLIl001299; Mon, 20 Oct 2003 10:35:21 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id h9K0ZK7e001297; Mon, 20 Oct 2003 10:35:20 +1000 Date: Mon, 20 Oct 2003 10:35:20 +1000 From: Nathan Scott To: Ying-Hung Chen Cc: linux-xfs@oss.sgi.com Subject: Re: xfs quota does not work with encrypted loop filesystem Message-ID: <20031020003520.GA1042@frodo> References: <3F916F45.8090801@yingternet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F916F45.8090801@yingternet.com> User-Agent: Mutt/1.5.3i X-archive-position: 755 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 639 Lines: 27 On Sat, Oct 18, 2003 at 09:50:13AM -0700, Ying-Hung Chen wrote: > Hi, > > I am currently running mandrake 9.2, (this applies to 9.1 and 9.0 > also) > > xfs quota does not work with encrypted option turned on. (through the > loop device) > > for example: > > /dev/hde11 /home xfs encryption=AES128,encrypted,grpquota,usrquota 0 0 > > has the encryption, but unable to assign quota, enforce or show quota. > > without the encryption, quota just works. Can you send the output from "cat /proc/mounts"? > I believe this is probably not mandrake specific problem, does anyone > have similar setup that works? cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Oct 19 18:27:07 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 19 Oct 2003 18:27:41 -0700 (PDT) Received: from ying.yingternet.com (n105.priced2go.net [208.179.93.105]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9K1R725011775 for ; Sun, 19 Oct 2003 18:27:07 -0700 Received: from gateway-att.yingternet.com (c-24-126-235-193.we.client2.attbi.com [24.126.235.193]) by ying.yingternet.com (Postfix) with ESMTP id B900B300084; Sun, 19 Oct 2003 18:27:12 -0700 (PDT) Received: from kenshin.yingternet.org (kenshin.yingternet.com [192.168.10.10]) by gateway-att.yingternet.com (Postfix) with ESMTP id BA8748152F; Sun, 19 Oct 2003 18:12:23 -0700 (PDT) Received: from yingternet.com (kyoka.yingternet.org [192.168.10.11]) by kenshin.yingternet.org (Postfix) with ESMTP id 2F2F82007B6; Sun, 19 Oct 2003 18:32:32 -0700 (PDT) Message-ID: <3F933A90.80809@yingternet.com> Date: Sun, 19 Oct 2003 18:29:52 -0700 From: Ying-Hung Chen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031017 X-Accept-Language: en-us, zh-tw, en MIME-Version: 1.0 To: Nathan Scott Cc: linux-xfs@oss.sgi.com, Ying-Hung Chen Subject: Re: xfs quota does not work with encrypted loop filesystem References: <3F916F45.8090801@yingternet.com> <20031020003520.GA1042@frodo> In-Reply-To: <20031020003520.GA1042@frodo> X-Enigmail-Version: 0.76.7.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 756 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ying@yingternet.com Precedence: bulk X-list: linux-xfs Content-Length: 1340 Lines: 49 Hi there, > > > Can you send the output from "cat /proc/mounts"? > [ying@mdk9.2 ~]$ cat /proc/mounts rootfs / rootfs rw 0 0 /dev/root / ext3 rw 0 0 none /dev devfs rw 0 0 none /proc proc rw 0 0 none /proc/bus/usb usbfs rw 0 0 none /dev/pts devpts rw 0 0 none /mnt/cdrom supermount ro,dev=/dev/hdc,fs=udf:iso9660,tray_lock=onwrite,--,iocharset=utf8 0 0 none /mnt/floppy supermount rw,sync,dev=/dev/fd0,fs=ext2:vfat,tray_lock=onwrite,--,iocharset=utf8 0 0 /dev/hda5 /tmp reiserfs rw 0 0 /dev/hda6 /usr xfs rw 0 0 /dev/hda7 /usr/local xfs rw 0 0 /dev/hda8 /var xfs rw 0 0 /dev/hda9 /var/spool/mail xfs rw,usrquota 0 0 /dev/loop0 /home xfs rw,usrquota 0 0 my /etc/fstab looks like [ying@mdk9.2 ~]$ cat /etc/fstab /dev/hda1 / ext3 defaults 1 1 none /dev/pts devpts mode=0620 0 0 /dev/hda10 /home xfs encrypted,usrquota,encryption=AES128 0 0 none /mnt/cdrom supermount dev=/dev/hdc,fs=udf:iso9660,ro,--,iocharset=utf8 0 0 none /mnt/floppy supermount dev=/dev/fd0,fs=ext2:vfat,--,sync,iocharset=utf8 0 0 none /proc proc defaults 0 0 /dev/hda5 /tmp reiserfs notail 1 2 /dev/hda6 /usr xfs defaults 1 2 /dev/hda7 /usr/local xfs defaults 1 2 /dev/hda8 /var xfs defaults 1 2 /dev/hda9 /var/spool/mail xfs usrquota 1 2 /dev/hda2 swap swap defaults 0 0 so the quota for /var/spool/mail works fine, but does not work on /home Thanks, -Ying From owner-linux-xfs@oss.sgi.com Sun Oct 19 18:58:21 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 19 Oct 2003 18:58:58 -0700 (PDT) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9K1wJ25012716 for ; Sun, 19 Oct 2003 18:58:20 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id h9K2GdHc027806 for ; Sun, 19 Oct 2003 21:16:41 -0500 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 LAA04040; Mon, 20 Oct 2003 11:58:09 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h9K1w7Uc694958; Mon, 20 Oct 2003 11:58:08 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id h9K1tOIl002297; Mon, 20 Oct 2003 11:55:24 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id h9K1tOOv002295; Mon, 20 Oct 2003 11:55:24 +1000 Date: Mon, 20 Oct 2003 11:55:24 +1000 From: Nathan Scott To: Ying-Hung Chen Cc: linux-xfs@oss.sgi.com Subject: Re: xfs quota does not work with encrypted loop filesystem Message-ID: <20031020015523.GA1560@frodo> References: <3F916F45.8090801@yingternet.com> <20031020003520.GA1042@frodo> <3F933A90.80809@yingternet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F933A90.80809@yingternet.com> User-Agent: Mutt/1.5.3i X-archive-position: 757 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 498 Lines: 20 On Sun, Oct 19, 2003 at 06:29:52PM -0700, Ying-Hung Chen wrote: > Hi there, > > > > > >Can you send the output from "cat /proc/mounts"? > > > [ying@mdk9.2 ~]$ cat /proc/mounts > /dev/hda9 /var/spool/mail xfs rw,usrquota 0 0 > /dev/loop0 /home xfs rw,usrquota 0 0 Hmm... I was wondering whether the quota mount options were getting through to the kernel - looks like they are. I'm stumped - it also works fine on just plain loopback (without crypto, iow), I just tried that. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Oct 19 19:35:43 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 19 Oct 2003 19:36:22 -0700 (PDT) Received: from ying.yingternet.com (n105.priced2go.net [208.179.93.105]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9K2Zh25013799 for ; Sun, 19 Oct 2003 19:35:43 -0700 Received: from gateway-att.yingternet.com (c-24-126-235-193.we.client2.attbi.com [24.126.235.193]) by ying.yingternet.com (Postfix) with ESMTP id DE1B2300084; Sun, 19 Oct 2003 19:35:48 -0700 (PDT) Received: from kenshin.yingternet.org (kenshin.yingternet.com [192.168.10.10]) by gateway-att.yingternet.com (Postfix) with ESMTP id 4D7048152F; Sun, 19 Oct 2003 19:21:00 -0700 (PDT) Received: from yingternet.com (kyoka.yingternet.org [192.168.10.11]) by kenshin.yingternet.org (Postfix) with ESMTP id CCBC32007B6; Sun, 19 Oct 2003 19:41:08 -0700 (PDT) Message-ID: <3F934AA5.1040501@yingternet.com> Date: Sun, 19 Oct 2003 19:38:29 -0700 From: Ying-Hung Chen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031017 X-Accept-Language: en-us, zh-tw, en MIME-Version: 1.0 To: Nathan Scott Cc: linux-xfs@oss.sgi.com Subject: Re: xfs quota does not work with encrypted loop filesystem References: <3F916F45.8090801@yingternet.com> <20031020003520.GA1042@frodo> <3F933A90.80809@yingternet.com> <20031020015523.GA1560@frodo> In-Reply-To: <20031020015523.GA1560@frodo> X-Enigmail-Version: 0.76.7.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 758 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ying@yingternet.com Precedence: bulk X-list: linux-xfs Content-Length: 427 Lines: 14 > > Hmm... I was wondering whether the quota mount options were > getting through to the kernel - looks like they are. I'm > stumped - it also works fine on just plain loopback (without > crypto, iow), I just tried that. > can you show me how to mount through loopback without encryption? i was suspecting on the encryption all alone. but just want to double check it is not the problem with loop device, Thanks, -Ying From owner-linux-xfs@oss.sgi.com Sun Oct 19 20:01:32 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 19 Oct 2003 20:02:05 -0700 (PDT) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9K31V25014768 for ; Sun, 19 Oct 2003 20:01:32 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id h9K15pOO005551 for ; Sun, 19 Oct 2003 18:05:55 -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 NAA05616; Mon, 20 Oct 2003 13:01:16 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h9K31EUc695290; Mon, 20 Oct 2003 13:01:14 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id h9K2wUIl002500; Mon, 20 Oct 2003 12:58:30 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id h9K2wUZe002498; Mon, 20 Oct 2003 12:58:30 +1000 Date: Mon, 20 Oct 2003 12:58:30 +1000 From: Nathan Scott To: Ying-Hung Chen Cc: linux-xfs@oss.sgi.com Subject: Re: xfs quota does not work with encrypted loop filesystem Message-ID: <20031020025830.GB1560@frodo> References: <3F916F45.8090801@yingternet.com> <20031020003520.GA1042@frodo> <3F933A90.80809@yingternet.com> <20031020015523.GA1560@frodo> <3F934AA5.1040501@yingternet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F934AA5.1040501@yingternet.com> User-Agent: Mutt/1.5.3i X-archive-position: 759 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1554 Lines: 37 On Sun, Oct 19, 2003 at 07:38:29PM -0700, Ying-Hung Chen wrote: > > > >Hmm... I was wondering whether the quota mount options were > >getting through to the kernel - looks like they are. I'm > >stumped - it also works fine on just plain loopback (without > >crypto, iow), I just tried that. > > > can you show me how to mount through loopback without encryption? i was > suspecting on the encryption all alone. but just want to double check it > is not the problem with loop device, > Sure - something like this... # mkfs.xfs -dfile,size=1g,name=/tmp/loopy meta-data=/tmp/loopy isize=256 agcount=8, agsize=32768 blks = sectsz=512 data = bsize=4096 blocks=262144, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=2560, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 # mkdir /mnt/loopy # mount -t xfs -o loop,usrquota /tmp/loopy /mnt/loopy # repquota /mnt/loopy *** Report for user quotas on device /dev/loop0 Block grace time: 7days; Inode grace time: 7days Block limits File limits User used soft hard grace used soft hard grace ---------------------------------------------------------------------- root -- 0 0 0 3 0 0 -- Nathan From owner-linux-xfs@oss.sgi.com Sun Oct 19 20:17:58 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 19 Oct 2003 20:18:31 -0700 (PDT) Received: from ying.yingternet.com (n105.priced2go.net [208.179.93.105]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9K3Hw25015471 for ; Sun, 19 Oct 2003 20:17:58 -0700 Received: from gateway-att.yingternet.com (c-24-126-235-193.we.client2.attbi.com [24.126.235.193]) by ying.yingternet.com (Postfix) with ESMTP id C0E37300084; Sun, 19 Oct 2003 20:18:03 -0700 (PDT) Received: from kenshin.yingternet.org (kenshin.yingternet.com [192.168.10.10]) by gateway-att.yingternet.com (Postfix) with ESMTP id EA9708152F; Sun, 19 Oct 2003 20:03:14 -0700 (PDT) Received: from yingternet.com (kyoka.yingternet.org [192.168.10.11]) by kenshin.yingternet.org (Postfix) with ESMTP id ACB1A2007B6; Sun, 19 Oct 2003 20:23:23 -0700 (PDT) Message-ID: <3F93548C.3010908@yingternet.com> Date: Sun, 19 Oct 2003 20:20:44 -0700 From: Ying-Hung Chen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031017 X-Accept-Language: en-us, zh-tw, en MIME-Version: 1.0 To: Nathan Scott Cc: linux-xfs@oss.sgi.com Subject: Re: xfs quota does not work with encrypted loop filesystem References: <3F916F45.8090801@yingternet.com> <20031020003520.GA1042@frodo> <3F933A90.80809@yingternet.com> <20031020015523.GA1560@frodo> <3F934AA5.1040501@yingternet.com> <20031020025830.GB1560@frodo> In-Reply-To: <20031020025830.GB1560@frodo> X-Enigmail-Version: 0.76.7.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 760 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ying@yingternet.com Precedence: bulk X-list: linux-xfs Content-Length: 291 Lines: 15 Hi, > > Sure - something like this... > > # mkfs.xfs -dfile,size=1g,name=/tmp/loopy i just tryied myself and works, so it is definitely something to do with the encrypt layer, I also filed a bug report on mandrake's bugtrack, I'll report back if I found out anything, Thanks, -Ying From owner-linux-xfs@oss.sgi.com Sun Oct 19 21:34:57 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 19 Oct 2003 21:35:30 -0700 (PDT) Received: from ying.yingternet.com (n105.priced2go.net [208.179.93.105]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9K4Yu25020016 for ; Sun, 19 Oct 2003 21:34:57 -0700 Received: from gateway-att.yingternet.com (c-24-126-235-193.we.client2.attbi.com [24.126.235.193]) by ying.yingternet.com (Postfix) with ESMTP id 77CF8300084 for ; Sun, 19 Oct 2003 21:35:02 -0700 (PDT) Received: from kenshin.yingternet.org (kenshin.yingternet.com [192.168.10.10]) by gateway-att.yingternet.com (Postfix) with ESMTP id CF3658152F for ; Sun, 19 Oct 2003 21:20:13 -0700 (PDT) Received: from yingternet.com (kyoka.yingternet.org [192.168.10.11]) by kenshin.yingternet.org (Postfix) with ESMTP id 6BBC72007B6 for ; Sun, 19 Oct 2003 21:40:23 -0700 (PDT) Message-ID: <3F936698.2090600@yingternet.com> Date: Sun, 19 Oct 2003 21:37:44 -0700 From: Ying-Hung Chen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031017 X-Accept-Language: en-us, zh-tw, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: xfs quota does not work with encrypted loop filesystem X-Enigmail-Version: 0.76.7.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 761 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ying@yingternet.com Precedence: bulk X-list: linux-xfs Content-Length: 270 Lines: 7 Just a little update, I believe it is also not distribution specific since I just compile vanilla linux 2.4.22 + xfs + loop-AES-1.7e a minute ago, still suffer the same problem, I have also contacted the author of loop-AES, hopefully we'll get some feedback, -Ying From owner-linux-xfs@oss.sgi.com Sun Oct 19 21:36:53 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 19 Oct 2003 21:37:26 -0700 (PDT) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9K4aq25020315 for ; Sun, 19 Oct 2003 21:36:53 -0700 Received: from bruce.melbourne.sgi.com (bruce.melbourne.sgi.com [134.14.54.176]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h9K4tDHc032480 for ; Sun, 19 Oct 2003 23:55:14 -0500 Received: from bruce.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by bruce.melbourne.sgi.com (8.12.8/8.12.8) with ESMTP id h9K4aORZ009038 for ; Mon, 20 Oct 2003 14:36:24 +1000 Received: (from nathans@localhost) by bruce.melbourne.sgi.com (8.12.8/8.12.8/Submit) id h9K4aO9g009037 for linux-xfs@oss.sgi.com; Mon, 20 Oct 2003 14:36:24 +1000 Date: Mon, 20 Oct 2003 14:36:24 +1000 From: Nathan Scott Message-Id: <200310200436.h9K4aO9g009037@bruce.melbourne.sgi.com> Subject: TAKE 901693 - fix tracing code X-archive-position: 762 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@bruce.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2734 Lines: 117 Rename the vnode tracing macro to be consistent with the other trace code. Date: Sun Oct 19 19:04:36 PDT 2003 Workarea: bruce.melbourne.sgi.com:/build2/clean24 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:160241a linux/fs/xfs/linux/xfs_vnode.c - 1.121 linux/fs/xfs/linux/xfs_vnode.h - 1.86 Enable tracing in the quota code if requested. Date: Sun Oct 19 19:10:51 PDT 2003 Workarea: bruce.melbourne.sgi.com:/build2/clean24 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:160242a linux/fs/xfs/quota/Makefile - 1.4 linux/fs/xfs/quota/xfs_dquot.h - 1.4 linux/fs/xfs/quota/xfs_dquot.c - 1.5 Fix exports for tracing symbol access in idbg code. Date: Sun Oct 19 20:56:07 PDT 2003 Workarea: bruce.melbourne.sgi.com:/build2/clean24 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:160243a linux/fs/xfs/linux/xfs_globals.c - 1.61 When tracing extended attribute calls, only access the buffer when it exists. Date: Sun Oct 19 21:11:06 PDT 2003 Workarea: bruce.melbourne.sgi.com:/build2/clean24 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:160244a linux/fs/xfs/xfs_attr.c - 1.111 Fix build with tracing enabled, couple of portability macros, and move externs into headers. Date: Sun Oct 19 21:21:43 PDT 2003 Workarea: bruce.melbourne.sgi.com:/build2/clean24 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:160245a linux/fs/xfs/xfs_buf_item.h - 1.41 linux/fs/xfs/xfs_buf_item.c - 1.144 linux/fs/xfs/xfs_attr_sf.h - 1.20 linux/fs/xfs/xfs_da_btree.c - 1.147 linux/fs/xfs/xfs_vnodeops.c - 1.617 linux/fs/xfs/xfs_dir.h - 1.42 linux/fs/xfs/xfs_dir.c - 1.156 linux/fs/xfs/xfs_vfsops.c - 1.436 linux/fs/xfs/xfs_dfrag.c - 1.42 linux/fs/xfs/xfs_iget.c - 1.194 linux/fs/xfs/xfs_bmap_btree.h - 1.61 linux/fs/xfs/xfs_bmap_btree.c - 1.141 linux/fs/xfs/xfs_inode.c - 1.391 linux/fs/xfs/xfs_inode.h - 1.188 linux/fs/xfs/xfs_dir2_trace.c - 1.18 linux/fs/xfs/xfs_dir2_trace.h - 1.10 linux/fs/xfs/xfs_dir_sf.h - 1.25 linux/fs/xfs/xfs_alloc.c - 1.169 linux/fs/xfs/xfs_alloc.h - 1.57 linux/fs/xfs/xfs_bmap.c - 1.313 linux/fs/xfs/xfs_attr.h - 1.27 linux/fs/xfs/linux/xfs_linux.h - 1.114 Enable the tracing options in XFS Makefiles. Date: Sun Oct 19 21:25:52 PDT 2003 Workarea: bruce.melbourne.sgi.com:/build2/clean24 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:160246a linux/fs/xfs/linux/Makefile - 1.195 linux/fs/xfs/Makefile - 1.53 From owner-linux-xfs@oss.sgi.com Mon Oct 20 00:31:57 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 20 Oct 2003 00:32:38 -0700 (PDT) Received: from iris.acsalaska.net (iris.acsalaska.net [209.112.155.43]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9K7Vt25027475 for ; Mon, 20 Oct 2003 00:31:56 -0700 Received: from erbenson.alaska.net (74-pm14.nwc.alaska.net [209.112.141.74]) by iris.acsalaska.net (8.12.10/8.12.10) with ESMTP id h9K7VqXB069632 for ; Sun, 19 Oct 2003 23:31:53 -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 2F94739E9 for ; Sun, 19 Oct 2003 23:31:51 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id 8986C40FF35; Sun, 19 Oct 2003 23:31:51 -0800 (AKDT) Date: Sun, 19 Oct 2003 23:31:51 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: [PATCH] [PRELIMINARY] Add support for file flags to xfsdump #1 Message-ID: <20031020073151.GD3648@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6e7ZaeXHKrTJCxdu" Content-Disposition: inline User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-ACS-Spam-Status: no X-ACS-Scanned-By: MD 2.37; SA 2.60; spamdefang 1.58 X-archive-position: 763 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: erbenson@alaska.net Precedence: bulk X-list: linux-xfs Content-Length: 7904 Lines: 277 --6e7ZaeXHKrTJCxdu Content-Type: multipart/mixed; boundary="LTeJQqWS0MN7I/qa" Content-Disposition: inline --LTeJQqWS0MN7I/qa Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, Recently my patches to add file flags to XFS were merged (immutable, append-only etc). xfsdump has some problems with the new flags: * immutable/append-only files cannot be restored correctly as these flags are restored too soon, denying xfsrestore the permission it needs to complete its task. * file flags are not restored to directories. * the new nodump flag is ignored. The attached patch fixes all of this, however I don't know enough about xfsdump internals to know for sure that my fixes are truly correct, I need someone with SGI who is familiar with xfsdump to comment on this. What I have done to fix the above problems in order: * restore/content.c: move the restoration of xflags to the end of the restore_reg() function, right before the file is closed, previously it was done before DMAPI events were restored. * restore/tree.c: Add code to restore xflags, this currently needs work, as you will notice I tried to use the same method as the DMAPI restore code does, open_by_handle(), however open_by_handle() does not work in my tests (always returns EBADF), I cannot explain why. For now I #ifdef'ed out that code and replaced it with a standard open() call. Also I am not sure if the new code needs to be wrapped in a test to check whether xattrs are being restored or not, all the other functions restoring xflags seem to have such a test, however its not clear to me how to test that in this context. * dump/inomap.c: Add warning when SGI_XFSDUMP_SKIP_FILE xattr is present, but still honor it, this attribute is deprecated in favor of the new nodump file flag, support for the obsolete xattr should be removed in a future xfsdump (its not that old so this shouldn't be much of a problem). Add check for new nodump file flag. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --LTeJQqWS0MN7I/qa Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="xfsdump-xflags.diff" Content-Transfer-Encoding: quoted-printable diff -urN xfsdump-2.2.13.orig/dump/inomap.c xfsdump-2.2.13/dump/inomap.c --- xfsdump-2.2.13.orig/dump/inomap.c Wed Apr 30 22:00:47 2003 +++ xfsdump-2.2.13/dump/inomap.c Sun Oct 19 21:58:23 2003 @@ -759,11 +759,24 @@ statp->bs_ino, statp->bs_uid, estimated_size ); + mlog( MLOG_NORMAL | MLOG_WARNING , + "deprecated SGI_XFSDUMP_SKIP_FILE extended attribute set on ino= %llu\n", + statp->bs_ino ); map_add( ino, MAP_NDR_NOCHNG ); inomap_exclude_skipattr++; return 0; } } + if (allowexcludefiles_pr && statp->bs_xflags & XFS_XFLAG_NODUMP) { + mlog( MLOG_DEBUG | MLOG_EXCLFILES, + "pruned ino %llu, owner %u, estimated size %llu: skip flag set\n= ", + statp->bs_ino, + statp->bs_uid, + estimated_size ); + map_add( ino, MAP_NDR_NOCHNG ); + inomap_exclude_skipattr++; + return 0; + } #endif /* EXTATTR */ =20 map_add( ino, MAP_NDR_CHANGE ); diff -urN xfsdump-2.2.13.orig/restore/content.c xfsdump-2.2.13/restore/cont= ent.c --- xfsdump-2.2.13.orig/restore/content.c Wed Apr 30 22:00:48 2003 +++ xfsdump-2.2.13/restore/content.c Sun Oct 19 23:14:55 2003 @@ -7339,41 +7339,6 @@ } } =20 -#ifdef EXTATTR - /* set the extended attributes - */ - if ( persp->a.dstdirisxfspr ) { - struct fsxattr fsxattr; - - ( void )memset((void *)&fsxattr, - 0, - sizeof( fsxattr )); - fsxattr.fsx_xflags =3D - bstatp->bs_xflags; - ASSERT( bstatp->bs_extsize >=3D 0 ); - fsxattr.fsx_extsize =3D - ( u_int32_t ) - bstatp->bs_extsize; - - rval =3D ioctl( fd, - XFS_IOC_FSSETXATTR, - (void *)&fsxattr); - if ( rval < 0 ) { - mlog(MLOG_NORMAL | MLOG_WARNING, - _("attempt to set " - "extended attributes " - "(xflags 0x%x, " - "extsize =3D 0x%x)" - "of %s failed: " - "%s\n"), - bstatp->bs_xflags, - bstatp->bs_extsize, - path, - strerror(errno)); - } - } -#endif - #ifdef DMEXTATTR if ( persp->a.restoredmpr) { fsdmidata_t fssetdm; @@ -7551,6 +7516,41 @@ path, strerror( errno )); } + +#ifdef EXTATTR + /* set the extended attributes + */ + if ( persp->a.dstdirisxfspr ) { + struct fsxattr fsxattr; + + ( void )memset((void *)&fsxattr, + 0, + sizeof( fsxattr )); + fsxattr.fsx_xflags =3D + bstatp->bs_xflags; + ASSERT( bstatp->bs_extsize >=3D 0 ); + fsxattr.fsx_extsize =3D + ( u_int32_t ) + bstatp->bs_extsize; + + rval =3D ioctl( fd, + XFS_IOC_FSSETXATTR, + (void *)&fsxattr); + if ( rval < 0 ) { + mlog(MLOG_NORMAL | MLOG_WARNING, + _("attempt to set " + "extended attributes " + "(xflags 0x%x, " + "extsize =3D 0x%x)" + "of %s failed: " + "%s\n"), + bstatp->bs_xflags, + bstatp->bs_extsize, + path, + strerror(errno)); + } + } +#endif =20 rval =3D close( fd ); if ( rval ) { diff -urN xfsdump-2.2.13.orig/restore/tree.c xfsdump-2.2.13/restore/tree.c --- xfsdump-2.2.13.orig/restore/tree.c Wed Apr 30 22:00:49 2003 +++ xfsdump-2.2.13/restore/tree.c Sun Oct 19 21:31:32 2003 @@ -2458,8 +2458,11 @@ mode_t mode; struct utimbuf utimbuf; /* REFERENCED */ - struct fsxattr fsxattr; /* can we get rid of this? */ + struct fsxattr fsxattr; intgen_t rval; + size_t hlen; + void *hanp; + intgen_t fd; =20 if ( dah =3D=3D DAH_NULL ) return; @@ -2469,10 +2472,7 @@ =20 #ifdef DMEXTATTR if ( persp->p_restoredmpr ) { - size_t hlen; - void *hanp; fsdmidata_t fssetdm; - intgen_t fd; =20 fssetdm.fsd_dmevmask =3D dirattr_get_dmevmask( dah ); fssetdm.fsd_padding =3D 0; /* not used */ @@ -2545,6 +2545,54 @@ path, strerror( errno )); } + +#ifdef EXTATTR + /* set the extended attributes + */ +#if 0 /* open_by_handle() doesn't work */ + if (path_to_handle(path, &hanp, &hlen)) { + mlog( MLOG_NORMAL | MLOG_WARNING, _( + "path_to_handle of %s failed:%s\n"), + path, strerror( errno )); + return; + } +=09=09 + fd =3D open_by_handle(hanp, hlen, O_RDONLY); + if (fd < 0) { + mlog( MLOG_NORMAL | MLOG_WARNING, _( + "open_by_handle of %s failed:%s\n"), + path, strerror( errno )); + free_handle(hanp, hlen); + return; + } + free_handle(hanp, hlen); +#else + fd =3D open(path, O_RDONLY); + if (fd < 0) { + mlog( MLOG_NORMAL | MLOG_WARNING, _( + "open of %s failed:%s\n"), + path, strerror( errno )); + return; + } +#endif /* broken *handle() */ + rval =3D ioctl( fd, + XFS_IOC_FSSETXATTR, + (void *)&fsxattr); + if ( rval < 0 ) { + mlog(MLOG_NORMAL | MLOG_WARNING, + _("attempt to set " + "extended attributes " + "(xflags 0x%x, " + "extsize =3D 0x%x)" + "of %s failed: " + "%s\n"), + dirattr_get_xflags( dah ), + dirattr_get_extsize( dah ), + path, + strerror(errno)); + } + ( void )close( fd ); +#endif /* EXTATTR */ } =20 /* deletes orphanage if empty, else warns --LTeJQqWS0MN7I/qa-- --6e7ZaeXHKrTJCxdu 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 iEYEARECAAYFAj+Tj2cACgkQJKx7GixEevzx/gCeIGtp0qC6ZNFpQoTAI58Vl+qZ 5ZQAn1OMFPZ38aUfuJiR3VRAZWFyTbk7 =FjY0 -----END PGP SIGNATURE----- --6e7ZaeXHKrTJCxdu-- From owner-linux-xfs@oss.sgi.com Mon Oct 20 00:38:23 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 20 Oct 2003 00:38:56 -0700 (PDT) Received: from hob.acsalaska.net (hob.acsalaska.net [209.112.155.42]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9K7cM25027951 for ; Mon, 20 Oct 2003 00:38:23 -0700 Received: from erbenson.alaska.net (74-pm14.nwc.alaska.net [209.112.141.74]) by hob.acsalaska.net (8.12.10/8.12.10) with ESMTP id h9K7cKrL045333 for ; Sun, 19 Oct 2003 23:38:21 -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 0C8A739E9 for ; Sun, 19 Oct 2003 23:38:19 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id B5ED140FF36; Sun, 19 Oct 2003 23:38:19 -0800 (AKDT) Date: Sun, 19 Oct 2003 23:38:19 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: [PATCH] Make fsck.xfs more informative Message-ID: <20031020073819.GE3648@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9/eUdp+dLtKXvemk" Content-Disposition: inline User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-ACS-Spam-Status: no X-ACS-Scanned-By: MD 2.37; SA 2.60; spamdefang 1.58 X-archive-position: 764 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: erbenson@alaska.net Precedence: bulk X-list: linux-xfs Content-Length: 2066 Lines: 79 --9/eUdp+dLtKXvemk Content-Type: multipart/mixed; boundary="924gEkU1VlJlwnwX" Content-Disposition: inline --924gEkU1VlJlwnwX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, /sbin/fsck.xfs is a continuing source of confusion and misconception ("XFS doesn't even have a fsck, what kind of fs has no repair utilities?"), part of this has been fixed by making the man page more informative, but i think it would also be helpful to have the actual program print a message notifying the user that its use is not necessary. My patch causes fsck.xfs to print: /dev/hda3: XFS filesystem, no check required. Suggestions on other wordings for this message are welcome, but I think this one should be fine. I was thinking of perhaps=20 /dev/hda3: XFS filesystem, no automatic check required. Patch enclosed. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --924gEkU1VlJlwnwX Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="xfs_fsck.c.diff" Content-Transfer-Encoding: quoted-printable --- xfs_fsck.c.orig Sat Oct 18 19:59:18 2003 +++ xfs_fsck.c Sat Oct 18 20:00:01 2003 @@ -35,8 +35,18 @@ /* This used to be a symlink to /bin/true but that gives a wierd */ /* dependency problem in a certain package manager. */ =20 +#include + int main(int argc, char **argv) { - return 0; + int i; + + for (i =3D 1 ; i < argc ; i++) { + if ((argv[i])[0] !=3D '-') { + printf("%s: XFS filesystem, no check required.\n",= argv[i]); + break; + } + } + return 0; } --924gEkU1VlJlwnwX-- --9/eUdp+dLtKXvemk 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 iEYEARECAAYFAj+TkOsACgkQJKx7GixEevy/0ACgk7xcatscM3xP0KL758vHakrY iOwAniT8NxQ+HjmAyxpspYGzLOdLuyhY =hakk -----END PGP SIGNATURE----- --9/eUdp+dLtKXvemk-- From owner-linux-xfs@oss.sgi.com Mon Oct 20 02:24:23 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 20 Oct 2003 02:24:58 -0700 (PDT) Received: from hammail2.truenorth.com ([213.61.138.99]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9K9OM25005859 for ; Mon, 20 Oct 2003 02:24:23 -0700 Received: from hamburg.fcb.com ([170.200.66.61]) by hammail2.truenorth.com (Netscape Messaging Server 4.15) with ESMTP id HN1U4E00.8MQ; Mon, 20 Oct 2003 11:24:14 +0200 Message-ID: <3F93A9BE.6010708@hamburg.fcb.com> Date: Mon, 20 Oct 2003 11:24:14 +0200 From: "Harald Wagener" User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ethan Benson CC: linux-xfs@oss.sgi.com Subject: Re: [PATCH] Make fsck.xfs more informative References: <20031020073819.GE3648@plato.local.lan> In-Reply-To: <20031020073819.GE3648@plato.local.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 765 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hwagener@hamburg.fcb.com Precedence: bulk X-list: linux-xfs Content-Length: 781 Lines: 31 Ethan Benson wrote: >Hi, > >/sbin/fsck.xfs is a continuing source of confusion and misconception >("XFS doesn't even have a fsck, what kind of fs has no repair >utilities?"), part of this has been fixed by making the man page more >informative, but i think it would also be helpful to have the actual >program print a message notifying the user that its use is not >necessary. > >My patch causes fsck.xfs to print: > >/dev/hda3: XFS filesystem, no check required. > >Suggestions on other wordings for this message are welcome, but I >think this one should be fine. I was thinking of perhaps > >/dev/hda3: XFS filesystem, no automatic check required. > >Patch enclosed. > > I would suggest: /dev/hda3: XFS filesystem, no traditional fsck check required Regards, Harald From owner-linux-xfs@oss.sgi.com Mon Oct 20 08:37:00 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 20 Oct 2003 08:37:33 -0700 (PDT) Received: from fyserv1.fy.chalmers.se (fyserv1.fy.chalmers.se [129.16.110.66]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9KFaw25025243 for ; Mon, 20 Oct 2003 08:36:59 -0700 Received: from fy.chalmers.se (stty [129.16.50.165]) by fyserv1.fy.chalmers.se (8.8.8/8.8.8) with ESMTP id RAA04120; Mon, 20 Oct 2003 17:35:52 +0200 (MEST) Message-ID: <3F940178.40CB3AA5@fy.chalmers.se> Date: Mon, 20 Oct 2003 17:38:32 +0200 From: Andy Polyakov X-Mailer: Mozilla 4.8 [en] (X11; U; Linux 2.6.0-test7 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-raid@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: [PATCH] md - Use sector rather than block numbers when splitting raid0 requests. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 766 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: appro@fy.chalmers.se Precedence: bulk X-list: linux-xfs Content-Length: 332 Lines: 7 Reg. http://marc.theaimsgroup.com/?l=linux-raid&m=106661294929434. I figured that it's worth mentioning and cross-posting to linux-xfs that the problem was addressed while troubleshooting xfs on raid0 corruption under 2.6.0-testX kernel [as discussed at several forums] and it's confirmed that the patch resolves this problem. A. From owner-linux-xfs@oss.sgi.com Mon Oct 20 09:21:52 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 20 Oct 2003 09:22:31 -0700 (PDT) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9KGLn25027434 for ; Mon, 20 Oct 2003 09:21:52 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h9KGeEHc023749 for ; Mon, 20 Oct 2003 11:40:15 -0500 Received: from tulip-e236.americas.sgi.com (tulip-e236.americas.sgi.com [128.162.236.208]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h9KGLhP512407253 for ; Mon, 20 Oct 2003 11:21:43 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by tulip-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h9KGLhSn33989146 for ; Mon, 20 Oct 2003 11:21:43 -0500 (CDT) Received: from jen.americas.sgi.com (localhost.localdomain [127.0.0.1]) by jen.americas.sgi.com (8.12.8/8.12.8) with ESMTP id h9KGLh95018726 for ; Mon, 20 Oct 2003 11:21:43 -0500 Received: (from lord@localhost) by jen.americas.sgi.com (8.12.8/8.12.8/Submit) id h9KGLhc7018724 for linux-xfs@oss.sgi.com; Mon, 20 Oct 2003 11:21:43 -0500 Date: Mon, 20 Oct 2003 11:21:43 -0500 From: Steve Lord Message-Id: <200310201621.h9KGLhc7018724@jen.americas.sgi.com> Subject: TAKE - merge up to 2.6.0-test8 To: linux-xfs@oss.sgi.com X-archive-position: 767 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 19116 Lines: 510 Bring the cvs tree upto test8, apart from dmapi, some a couple of xfs fixes and debug tracing changes, the xfs in here is the same as you get in Linus's kernel. Steve Date: Mon Oct 20 09:18:49 PDT 2003 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.6 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:160259a linux/drivers/media/dvb/frontends/ves1x93.c - 1.1 linux/include/linux/netfilter_bridge/ebt_among.h - 1.1 linux/net/bridge/netfilter/ebt_among.c - 1.1 linux/net/sunrpc/xdr.c - 1.14 linux/net/sunrpc/clnt.c - 1.36 linux/net/ipv6/sit.c - 1.37 linux/net/ipv6/mcast.c - 1.35 linux/net/ipv6/addrconf.c - 1.45 linux/net/ipv4/tcp_ipv4.c - 1.69 linux/net/ipv4/ipip.c - 1.37 linux/net/ipv4/ip_output.c - 1.55 linux/net/ipv4/ip_gre.c - 1.38 linux/net/core/dev.c - 1.86 linux/mm/swapfile.c - 1.79 linux/mm/slab.c - 1.68 linux/mm/mlock.c - 1.19 linux/kernel/sys.c - 1.61 linux/kernel/signal.c - 1.63 linux/kernel/sched.c - 1.113 linux/kernel/resource.c - 1.26 linux/kernel/module.c - 1.50 linux/kernel/fork.c - 1.102 linux/kernel/exit.c - 1.76 linux/kernel/acct.c - 1.31 linux/include/net/if_inet6.h - 1.14 linux/include/linux/sched.h - 1.114 linux/include/linux/rtnetlink.h - 1.23 linux/include/linux/nfs_fs.h - 1.36 linux/include/linux/netdevice.h - 1.57 linux/include/linux/ioport.h - 1.19 linux/include/linux/etherdevice.h - 1.9 linux/include/asm-sparc64/uaccess.h - 1.12 linux/include/asm-sparc/viking.h - 1.3 linux/include/asm-sparc/vac-ops.h - 1.5 linux/include/asm-sparc/turbosparc.h - 1.3 linux/include/asm-sparc/tsunami.h - 1.3 linux/include/asm-sparc/system.h - 1.21 linux/include/asm-sparc/swift.h - 1.3 linux/include/asm-sparc/ross.h - 1.3 linux/include/asm-sparc/processor.h - 1.25 linux/include/asm-sparc/pgtsun4c.h - 1.5 linux/include/asm-sparc/pgtsun4.h - 1.4 linux/include/asm-sparc/irq.h - 1.13 linux/include/asm-sparc/io.h - 1.13 linux/include/asm-sparc/checksum.h - 1.8 linux/include/asm-sparc/bitops.h - 1.20 linux/include/asm-sparc/atomic.h - 1.11 linux/include/asm-i386/processor.h - 1.59 linux/fs/proc/proc_devtree.c - 1.9 linux/fs/proc/array.c - 1.63 linux/fs/open.c - 1.58 linux/fs/locks.c - 1.44 linux/fs/inode.c - 1.105 linux/fs/ext2/acl.c - 1.12 linux/fs/exec.c - 1.91 linux/fs/dquot.c - 1.73 linux/fs/binfmt_elf.c - 1.65 linux/drivers/video/imsttfb.c - 1.31 linux/drivers/net/sunlance.c - 1.35 linux/drivers/net/sunhme.c - 1.52 linux/drivers/net/sunbmac.c - 1.29 linux/drivers/net/slip.c - 1.32 linux/drivers/net/net_init.c - 1.25 linux/drivers/net/myri_sbus.c - 1.23 linux/drivers/net/loopback.c - 1.15 linux/drivers/net/hp100.c - 1.33 linux/drivers/net/hamradio/scc.c - 1.35 linux/drivers/net/hamradio/bpqether.c - 1.27 linux/drivers/net/defxx.c - 1.29 linux/drivers/net/Space.c - 1.50 linux/drivers/char/vt.c - 1.43 linux/drivers/char/tty_io.c - 1.76 linux/drivers/char/synclink.c - 1.42 linux/drivers/char/rocket.c - 1.29 linux/drivers/char/n_tty.c - 1.26 linux/drivers/char/ftape/lowlevel/ftape-proc.c - 1.6 linux/drivers/cdrom/sjcd.c - 1.35 linux/drivers/block/Makefile - 1.39 linux/arch/sparc64/solaris/misc.c - 1.34 linux/arch/sparc64/kernel/unaligned.c - 1.13 linux/arch/sparc64/kernel/sparc64_ksyms.c - 1.64 linux/arch/sparc64/kernel/smp.c - 1.61 linux/arch/sparc64/defconfig - 1.103 linux/arch/ppc/kernel/setup.c - 1.65 linux/arch/ppc/kernel/process.c - 1.55 linux/arch/ppc/kernel/ppc_ksyms.c - 1.61 linux/arch/ppc/kernel/head.S - 1.48 linux/arch/ppc/Makefile - 1.44 linux/arch/m68k/lib/checksum.c - 1.6 linux/arch/i386/mm/fault.c - 1.34 linux/arch/i386/kernel/traps.c - 1.86 linux/arch/i386/kernel/irq.c - 1.63 linux/arch/arm/kernel/armksyms.c - 1.35 linux/arch/arm/boot/Makefile - 1.27 linux/arch/arm/Makefile - 1.52 linux/Makefile - 1.261 linux/Documentation/ide.txt - 1.14 linux/include/linux/ide.h - 1.86 linux/drivers/atm/nicstar.c - 1.27 linux/net/atm/proc.c - 1.27 linux/net/atm/clip.c - 1.24 linux/drivers/char/applicom.c - 1.17 linux/drivers/pcmcia/tcic.c - 1.34 linux/arch/m68k/sun3/sbus.c - 1.5 linux/drivers/net/pcmcia/pcnet_cs.c - 1.31 linux/drivers/net/wan/cosa.c - 1.38 linux/drivers/net/wan/syncppp.c - 1.22 linux/drivers/net/wan/sealevel.c - 1.15 linux/drivers/net/wan/hostess_sv11.c - 1.13 linux/include/asm-i386/div64.h - 1.4 linux/drivers/net/sk98lin/skge.c - 1.31 linux/kernel/timer.c - 1.55 linux/drivers/i2c/i2c-dev.c - 1.35 linux/arch/i386/kernel/apic.c - 1.50 linux/arch/i386/kernel/mpparse.c - 1.45 linux/arch/ia64/kernel/head.S - 1.19 linux/arch/ia64/kernel/gate.S - 1.18 linux/arch/ia64/kernel/acpi.c - 1.30 linux/arch/ia64/ia32/sys_ia32.c - 1.53 linux/arch/ia64/Makefile - 1.35 linux/arch/ia64/kernel/setup.c - 1.32 linux/arch/ia64/kernel/time.c - 1.30 linux/arch/ia64/kernel/unaligned.c - 1.18 linux/arch/ia64/kernel/perfmon.c - 1.32 linux/arch/ia64/kernel/mca.c - 1.27 linux/arch/ia64/mm/init.c - 1.33 linux/arch/ia64/kernel/mca_asm.S - 1.13 linux/include/asm-ia64/delay.h - 1.8 linux/include/asm-ia64/mca_asm.h - 1.9 linux/include/asm-ia64/serial.h - 1.4 linux/include/asm-ia64/posix_types.h - 1.5 linux/include/asm-ia64/pgtable.h - 1.26 linux/include/asm-ia64/pal.h - 1.13 linux/include/asm-ia64/page.h - 1.25 linux/include/asm-ia64/mca.h - 1.12 linux/include/asm-ia64/unistd.h - 1.36 linux/include/asm-ia64/uaccess.h - 1.14 linux/drivers/net/8139too.c - 1.58 linux/arch/i386/kernel/microcode.c - 1.28 linux/drivers/video/matrox/matroxfb_base.h - 1.18 linux/drivers/net/tulip/tulip_core.c - 1.51 linux/drivers/atm/fore200e.c - 1.25 linux/drivers/ide/ide.c - 1.94 linux/drivers/ide/ide-floppy.c - 1.49 linux/drivers/ide/ide-dma.c - 1.43 linux/net/ipv4/netfilter/ipt_owner.c - 1.15 linux/net/ipv4/netfilter/ipt_limit.c - 1.9 linux/include/linux/nfs_xdr.h - 1.18 linux/fs/nfs/nfs3proc.c - 1.25 linux/drivers/usb/serial/visor.h - 1.19 linux/drivers/usb/serial/visor.c - 1.58 linux/include/linux/nfs_page.h - 1.13 linux/include/asm-ia64/asmmacro.h - 1.7 linux/drivers/acpi/tables/tbinstal.c - 1.22 linux/drivers/acpi/resources/rsirq.c - 1.17 linux/drivers/acpi/resources/rsaddr.c - 1.15 linux/drivers/acpi/hardware/hwacpi.c - 1.18 linux/arch/ppc/configs/est8260_defconfig - 1.20 linux/drivers/net/natsemi.c - 1.33 linux/arch/arm/boot/bootp/bootp.lds - 1.4 linux/drivers/macintosh/adbhid.c - 1.13 linux/fs/dnotify.c - 1.11 linux/include/linux/ethtool.h - 1.20 linux/drivers/acpi/tables/tbconvrt.c - 1.21 linux/Documentation/filesystems/xfs.txt - 1.17 linux/include/asm-ia64/sn/nodepda.h - 1.9 linux/include/net/syncppp.h - 1.5 linux/drivers/net/sungem.c - 1.34 linux/include/asm-ia64/perfmon.h - 1.13 linux/arch/ppc/boot/common/ns16550.c - 1.7 linux/drivers/acpi/utilities/utglobal.c - 1.23 linux/drivers/acpi/utilities/utalloc.c - 1.11 linux/drivers/acpi/executer/exsystem.c - 1.11 linux/drivers/acpi/executer/exstoren.c - 1.14 linux/drivers/acpi/executer/exconfig.c - 1.15 linux/drivers/acpi/executer/exfield.c - 1.12 linux/drivers/acpi/executer/exfldio.c - 1.17 linux/drivers/acpi/executer/exprep.c - 1.15 linux/drivers/acpi/executer/exresnte.c - 1.18 linux/drivers/acpi/executer/exresolv.c - 1.16 linux/drivers/acpi/executer/exresop.c - 1.18 linux/arch/ppc/mm/hashtable.S - 1.10 linux/arch/arm/mach-sa1100/lart.c - 1.5 linux/arch/arm/mach-sa1100/cpu-sa1100.c - 1.13 linux/arch/ppc/mm/ppc_mmu.c - 1.10 linux/drivers/char/ite_gpio.c - 1.7 linux/fs/jffs2/background.c - 1.18 linux/fs/jffs2/build.c - 1.6 linux/fs/jffs2/compr.c - 1.6 linux/fs/jffs2/compr_rtime.c - 1.6 linux/fs/jffs2/compr_zlib.c - 1.8 linux/fs/jffs2/dir.c - 1.17 linux/fs/jffs2/erase.c - 1.10 linux/fs/jffs2/file.c - 1.16 linux/fs/jffs2/gc.c - 1.12 linux/fs/jffs2/ioctl.c - 1.3 linux/fs/jffs2/malloc.c - 1.8 linux/fs/jffs2/nodelist.c - 1.9 linux/fs/jffs2/nodelist.h - 1.9 linux/fs/jffs2/nodemgmt.c - 1.9 linux/fs/jffs2/pushpull.h - 1.5 linux/fs/jffs2/read.c - 1.8 linux/fs/jffs2/readinode.c - 1.9 linux/fs/jffs2/scan.c - 1.10 linux/fs/jffs2/super.c - 1.20 linux/fs/jffs2/symlink.c - 1.5 linux/fs/jffs2/write.c - 1.10 linux/include/linux/jffs2_fs_sb.h - 1.10 linux/include/linux/jffs2.h - 1.7 linux/drivers/mtd/devices/lart.c - 1.4 linux/drivers/atm/lanai.c - 1.15 linux/drivers/net/irda/sa1100_ir.c - 1.10 linux/drivers/acpi/executer/exoparg1.c - 1.17 linux/net/ipv6/netfilter/ip6t_owner.c - 1.7 linux/net/8021q/vlan_dev.c - 1.12 linux/fs/ext3/inode.c - 1.47 linux/fs/nfs/pagelist.c - 1.11 linux/fs/reiserfs/procfs.c - 1.16 linux/fs/ext3/acl.c - 1.12 linux/include/linux/device.h - 1.37 linux/arch/arm/mach-clps7500/core.c - 1.4 linux/drivers/base/core.c - 1.31 linux/sound/oss/via82cxxx_audio.c - 1.17 linux/sound/oss/trident.c - 1.20 linux/arch/ppc/configs/TQM8260_defconfig - 1.6 linux/sound/oss/maestro3.c - 1.13 linux/sound/oss/i810_audio.c - 1.20 linux/arch/ppc/platforms/pmac_smp.c - 1.10 linux/arch/ppc/platforms/pmac_time.c - 1.6 linux/sound/oss/cs46xx.c - 1.17 linux/sound/oss/cs4281/cs4281m.c - 1.12 linux/arch/x86_64/kernel/apic.c - 1.21 linux/arch/x86_64/kernel/io_apic.c - 1.14 linux/arch/x86_64/kernel/setup.c - 1.19 linux/arch/x86_64/mm/Makefile - 1.10 linux/sound/isa/sb/emu8000_patch.c - 1.3 linux/sound/drivers/dummy.c - 1.17 linux/sound/core/timer.c - 1.18 linux/sound/core/seq/seq_lock.c - 1.6 linux/sound/core/rawmidi.c - 1.20 linux/sound/core/pcm_native.c - 1.22 linux/sound/core/pcm_lib.c - 1.16 linux/sound/core/oss/pcm_oss.c - 1.23 linux/sound/core/init.c - 1.13 linux/sound/core/hwdep.c - 1.12 linux/sound/core/control.c - 1.16 linux/include/sound/pcm_oss.h - 1.5 linux/include/sound/rawmidi.h - 1.5 linux/include/asm-ppc/mpc10x.h - 1.7 linux/include/asm-ppc64/hardirq.h - 1.10 linux/arch/ppc64/mm/init.c - 1.22 linux/include/asm-ppc64/io.h - 1.6 linux/arch/ppc64/kernel/head.S - 1.16 linux/arch/ppc64/kernel/idle.c - 1.7 linux/arch/ppc64/kernel/irq.c - 1.17 linux/arch/ppc64/kernel/misc.S - 1.23 linux/arch/ppc64/kernel/pacaData.c - 1.8 linux/arch/ppc64/kernel/pci_dma.c - 1.11 linux/arch/ppc64/kernel/ppc_ksyms.c - 1.12 linux/arch/ppc64/kernel/sys_ppc32.c - 1.28 linux/include/asm-ppc64/memory.h - 1.4 linux/include/asm-ppc64/thread_info.h - 1.9 linux/include/asm-ppc64/uaccess.h - 1.10 linux/include/asm-ppc64/siginfo.h - 1.6 linux/include/asm-ppc64/processor.h - 1.19 linux/include/asm-ppc64/pgtable.h - 1.16 linux/include/asm-ppc64/pgalloc.h - 1.8 linux/include/asm-ppc64/pci.h - 1.9 linux/drivers/net/e1000/e1000_main.c - 1.27 linux/Documentation/filesystems/jfs.txt - 1.7 linux/fs/jfs/file.c - 1.16 linux/fs/jfs/inode.c - 1.27 linux/fs/jfs/jfs_dmap.c - 1.15 linux/fs/jfs/jfs_dtree.c - 1.16 linux/fs/jfs/jfs_extent.c - 1.9 linux/fs/jfs/jfs_imap.c - 1.20 linux/fs/jfs/jfs_filsys.h - 1.5 linux/fs/jfs/namei.c - 1.23 linux/fs/jfs/jfs_xtree.c - 1.12 linux/fs/jfs/super.c - 1.29 linux/fs/jfs/jfs_superblock.h - 1.5 linux/fs/jfs/jfs_txnmgr.c - 1.30 linux/fs/jfs/jfs_metapage.c - 1.15 linux/drivers/net/tulip/xircom_cb.c - 1.12 linux/drivers/net/wan/hdlc_cisco.c - 1.8 linux/fs/jffs2/writev.c - 1.4 linux/fs/jffs2/wbuf.c - 1.8 linux/fs/jffs2/os-linux.h - 1.11 linux/kernel/futex.c - 1.20 linux/arch/ia64/sn/kernel/setup.c - 1.15 linux/fs/jffs2/fs.c - 1.11 linux/include/asm-ia64/machvec_sn2.h - 1.7 linux/arch/ia64/sn/io/sn2/ml_SN_intr.c - 1.5 linux/drivers/usb/README - 1.2 linux/drivers/usb/core/devio.c - 1.18 linux/drivers/usb/host/ehci-dbg.c - 1.18 linux/drivers/usb/host/ehci-q.c - 1.23 linux/drivers/usb/host/ehci.h - 1.14 linux/drivers/usb/host/ohci-hcd.c - 1.25 linux/drivers/usb/host/ohci-hub.c - 1.9 linux/drivers/usb/host/ohci-q.c - 1.26 linux/drivers/usb/host/ohci.h - 1.11 linux/include/asm-ia64/percpu.h - 1.9 linux/drivers/char/synclinkmp.c - 1.14 linux/drivers/char/pcmcia/synclink_cs.c - 1.19 linux/drivers/usb/host/uhci-hcd.c - 1.28 linux/mm/page-writeback.c - 1.30 linux/drivers/base/bus.c - 1.21 linux/drivers/video/tridentfb.c - 1.10 linux/include/linux/suspend.h - 1.13 linux/drivers/usb/core/hcd-pci.c - 1.17 linux/drivers/usb/host/ohci-pci.c - 1.12 linux/include/asm-x86_64/suspend.h - 1.9 linux/sound/isa/sb/emu8000_pcm.c - 1.6 linux/drivers/char/agp/ali-agp.c - 1.12 linux/drivers/char/agp/sis-agp.c - 1.14 linux/drivers/char/agp/i460-agp.c - 1.12 linux/drivers/char/agp/sworks-agp.c - 1.11 linux/drivers/char/agp/via-agp.c - 1.16 linux/fs/jfs/resize.c - 1.9 linux/arch/ia64/kernel/perfmon_itanium.h - 1.5 linux/arch/ia64/kernel/perfmon_mckinley.h - 1.6 linux/fs/jfs/xattr.c - 1.12 linux/drivers/ide/setup-pci.c - 1.15 linux/drivers/ide/pci/slc90e66.c - 1.11 linux/drivers/ide/pci/sis5513.c - 1.15 linux/drivers/ide/pci/siimage.c - 1.13 linux/drivers/ide/pci/serverworks.c - 1.13 linux/drivers/ide/pci/piix.c - 1.13 linux/drivers/ide/pci/pdc202xx_old.c - 1.13 linux/drivers/ide/pci/pdc202xx_new.c - 1.16 linux/drivers/ide/pci/it8172.c - 1.10 linux/drivers/ide/pci/hpt366.c - 1.16 linux/drivers/ide/pci/hpt34x.c - 1.12 linux/drivers/ide/pci/cmd64x.c - 1.10 linux/drivers/ide/pci/aec62xx.c - 1.11 linux/drivers/char/vt_ioctl.c - 1.11 linux/kernel/pid.c - 1.8 linux/net/bridge/netfilter/Makefile - 1.8 linux/arch/ppc64/mm/numa.c - 1.7 linux/arch/ppc/boot/openfirmware/coffmain.c - 1.5 linux/arch/ia64/mm/hugetlbpage.c - 1.11 linux/arch/i386/kernel/cpu/cpufreq/longhaul.c - 1.15 linux/sound/usb/usbmixer.c - 1.11 linux/sound/pci/via82xx.c - 1.15 linux/fs/nfs/direct.c - 1.3 linux/net/ipx/ipx_proc.c - 1.7 linux/arch/i386/kernel/timers/timer_tsc.c - 1.18 linux/drivers/isdn/hardware/eicon/divasmain.c - 1.12 linux/fs/nfs/nfs4xdr.c - 1.11 linux/include/asm-x86_64/proto.h - 1.14 linux/fs/nfs/nfs4proc.c - 1.11 linux/arch/i386/kernel/edd.c - 1.9 linux/drivers/net/Kconfig - 1.23 linux/drivers/net/hamradio/Kconfig - 1.7 linux/net/bridge/netfilter/Kconfig - 1.8 linux/drivers/media/dvb/frontends/ves1820.c - 1.8 linux/drivers/media/dvb/frontends/grundig_29504-491.c - 1.6 linux/drivers/media/dvb/frontends/grundig_29504-401.c - 1.7 linux/drivers/media/dvb/frontends/alps_bsrv2.c - 1.6 linux/drivers/media/dvb/frontends/Makefile - 1.8 linux/drivers/media/dvb/frontends/Kconfig - 1.9 linux/arch/ia64/Kconfig - 1.20 linux/drivers/media/dvb/dvb-core/dvb_i2c.h - 1.5 linux/drivers/media/dvb/dvb-core/dvb_i2c.c - 1.6 linux/arch/ia64/mm/discontig.c - 1.7 linux/drivers/char/Kconfig - 1.15 linux/include/asm-ia64/numa.h - 1.6 linux/include/asm-ia64/nodedata.h - 1.4 linux/include/asm-ia64/mmzone.h - 1.6 linux/arch/ppc/8260_io/Kconfig - 1.2 linux/drivers/block/Kconfig - 1.10 linux/sound/pci/Kconfig - 1.8 linux/fs/Kconfig - 1.19 linux/lib/kobject.c - 1.13 linux/drivers/usb/storage/Kconfig - 1.5 linux/drivers/atm/Kconfig - 1.8 linux/drivers/usb/misc/Kconfig - 1.7 linux/sound/oss/Kconfig - 1.14 linux/drivers/usb/class/Kconfig - 1.8 linux/drivers/usb/input/Kconfig - 1.9 linux/init/initramfs.c - 1.4 linux/drivers/media/video/saa7134/saa7134-core.c - 1.9 linux/drivers/net/b44.c - 1.8 linux/drivers/scsi/scsi_sysfs.c - 1.16 linux/drivers/media/dvb/frontends/alps_tdlb7.c - 1.5 linux/drivers/media/dvb/frontends/alps_tdmb7.c - 1.4 linux/drivers/char/agp/amd-k7-agp.c - 1.11 linux/drivers/char/agp/intel-agp.c - 1.14 linux/drivers/i2c/busses/Kconfig - 1.12 linux/drivers/i2c/chips/Kconfig - 1.9 linux/drivers/i2c/chips/adm1021.c - 1.12 linux/drivers/i2c/chips/lm75.c - 1.10 linux/include/asm-i386/mach-numaq/mach_mpparse.h - 1.3 linux/drivers/net/amd8111e.c - 1.10 linux/drivers/net/amd8111e.h - 1.3 linux/drivers/char/ipmi/Kconfig - 1.3 linux/drivers/char/ipmi/ipmi_msghandler.c - 1.6 linux/include/linux/ipmi_msgdefs.h - 1.2 linux/Documentation/ia64/fsys.txt - 1.3 linux/include/acpi/acconfig.h - 1.11 linux/include/acpi/actypes.h - 1.7 linux/include/acpi/actbl2.h - 1.3 linux/include/acpi/actbl1.h - 1.3 linux/include/acpi/actbl.h - 1.4 linux/arch/ia64/kernel/fsys.S - 1.9 linux/include/acpi/acexcep.h - 1.4 linux/drivers/acpi/sleep/main.c - 1.8 linux/arch/i386/kernel/acpi/wakeup.S - 1.3 linux/net/ipv6/anycast.c - 1.7 linux/drivers/video/aty/aty128fb.c - 1.6 linux/drivers/i2c/chips/via686a.c - 1.7 linux/drivers/i2c/chips/w83781d.c - 1.9 linux/arch/arm/lib/div64.S - 1.3 linux/arch/ppc/kernel/cpu_setup_6xx.S - 1.3 linux/arch/x86_64/kernel/acpi/boot.c - 1.6 linux/drivers/media/common/saa7146_fops.c - 1.7 linux/drivers/media/common/saa7146_vbi.c - 1.5 linux/drivers/media/common/saa7146_video.c - 1.8 linux/drivers/media/dvb/frontends/at76c651.c - 1.3 linux/drivers/media/dvb/frontends/dvb_dummy_fe.c - 1.3 linux/drivers/media/dvb/frontends/nxt6000.c - 1.4 linux/drivers/media/dvb/frontends/stv0299.c - 1.4 linux/drivers/media/dvb/ttpci/av7110.c - 1.5 linux/drivers/media/dvb/ttpci/av7110.h - 1.5 linux/include/media/saa7146_vv.h - 1.4 linux/arch/h8300/Kconfig - 1.9 linux/arch/h8300/README - 1.3 linux/arch/ia64/sn/kernel/sn2/io.c - 1.4 linux/include/asm-h8300/semaphore.h - 1.5 linux/drivers/i2c/chips/it87.c - 1.5 linux/init/do_mounts_initrd.c - 1.4 linux/drivers/block/initrd.c - 1.2 linux/drivers/char/agp/uninorth-agp.c - 1.4 linux/dev/null - 1.11 linux/drivers/usb/gadget/net2280.c - 1.7 linux/drivers/usb/gadget/Kconfig - 1.4 linux/drivers/atm/he.c - 1.9 linux/drivers/char/agp/nvidia-agp.c - 1.7 linux/net/core/net-sysfs.c - 1.8 linux/include/asm-ppc64/cputable.h - 1.3 linux/sound/pci/vx222/vx222_ops.c - 1.2 linux/net/ipv6/ip6_tunnel.c - 1.6 linux/drivers/net/wireless/atmel.c - 1.5 linux/drivers/net/wireless/atmel_cs.c - 1.5 linux/drivers/pci/hotplug/Kconfig - 1.5 linux/drivers/i2c/chips/lm85.c - 1.5 linux/drivers/serial/8250_acpi.c - 1.4 linux/fs/compat_ioctl.c - 1.8 linux/drivers/acpi/asus_acpi.c - 1.3 linux/arch/ia64/sn/io/machvec/pci_bus_cvlink.c - 1.4 linux/drivers/i2c/chips/lm78.c - 1.4 linux/arch/ia64/kernel/patch.c - 1.3 linux/arch/ia64/kernel/asm-offsets.c - 1.2 linux/drivers/media/dvb/frontends/cx24110.c - 1.2 linux/net/ipv4/ipvs/ip_vs_ctl.c - 1.6 linux/sound/oss/swarm_cs4297a.c - 1.6 linux/net/ipv4/ipvs/ip_vs_core.c - 1.4 linux/sound/oss/ali5455.c - 1.6 linux/sound/oss/ad1889.c - 1.6 linux/drivers/media/dvb/ttusb-dec/dec2000_frontend.c - 1.3 linux/drivers/media/dvb/frontends/tda1004x.c - 1.3 linux/drivers/media/dvb/frontends/mt312.c - 1.4 linux/security/selinux/ss/policydb.h - 1.2 linux/security/selinux/selinuxfs.c - 1.4 linux/security/selinux/include/security.h - 1.3 linux/Documentation/x86_64/boot-options.txt - 1.2 linux/scripts/split-man - 1.3 linux/scripts/makeman - 1.3 linux/kernel/power/swsusp.c - 1.4 linux/arch/h8300/platform/h8s/ints.c - 1.5 linux/drivers/char/agp/ati-agp.c - 1.4 linux/net/core/ethtool.c - 1.4 linux/drivers/media/video/zoran_card.c - 1.4 linux/drivers/media/video/zoran_device.c - 1.4 linux/drivers/media/video/zoran_driver.c - 1.3 linux/arch/ppc/syslib/of_device.c - 1.4 linux/drivers/net/sis190.c - 1.3 linux/arch/h8300/lib/romfs.S - 1.2 linux/drivers/char/agp/amd64-agp.c - 1.4 linux/arch/ppc/boot/of1275/map.c - 1.3 linux/kernel/power/pmdisk.c - 1.2 linux/kernel/power/disk.c - 1.2 linux/drivers/i2c/algos/i2c-algo-ite.c - 1.2 linux/include/asm-ppc/reg.h - 1.3 linux/include/asm-ppc/reg_booke.h - 1.3 linux/arch/arm/configs/lart_defconfig - 1.2 linux/arch/ia64/mm/contig.c - 1.2 linux/drivers/i2c/busses/i2c-sis630.c - 1.2 linux/arch/ppc64/mm/hugetlbpage.c - 1.2 linux/arch/arm/mach-integrator/lm.c - 1.2 linux/include/asm-ia64/meminit.h - 1.2 linux/drivers/media/dvb/frontends/sp887x.c - 1.2 linux/drivers/usb/serial/keyspan_usa90msg.h - 1.2 linux/arch/x86_64/kernel/cpufreq/Makefile - 1.2 From owner-linux-xfs@oss.sgi.com Tue Oct 21 02:51:55 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 21 Oct 2003 02:52:35 -0700 (PDT) Received: from s-net-04.besancon.org (S-NET-04.besancon.org [62.106.191.194]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9L9ps25010151 for ; Tue, 21 Oct 2003 02:51:55 -0700 Received: (qmail 2118 invoked from network); 21 Oct 2003 09:49:34 -0000 Received: from infor-19.besancon.org (HELO infor-19) (193.55.148.5) by s-net-04.besancon.org with SMTP; 21 Oct 2003 09:49:34 -0000 Message-Id: <3.0.1.16.20031021115041.2e972c4e@s-net-04.besancon.org> X-Sender: titty@s-net-04.besancon.org X-Mailer: Windows Eudora Pro Version 3.0.1 (16) [F] Date: Tue, 21 Oct 2003 11:50:41 To: linux-xfs@oss.sgi.com From: Thierry ITTY Subject: sgi-xfs & redhat install cd Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-archive-position: 768 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: thierry.itty@besancon.org Precedence: bulk X-list: linux-xfs Content-Length: 166 Lines: 8 Hello I can't find anymore iso images of redhat 8 or 9 bootable install cds modified to provide xfs 1.2 or 1.3 nowhere on the internet Is it normal, and why ? tia From owner-linux-xfs@oss.sgi.com Tue Oct 21 10:10:59 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 21 Oct 2003 10:11:38 -0700 (PDT) Received: from localhost.localdomain (firewall.conet.cz [213.175.54.250]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9LHAu25029060 for ; Tue, 21 Oct 2003 10:10:58 -0700 Received: from conet.cz (tricitka [10.128.50.50]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id h9LHApX2018708 for ; Tue, 21 Oct 2003 19:10:52 +0200 Message-ID: <3F9568A5.6050308@conet.cz> Date: Tue, 21 Oct 2003 19:11:01 +0200 From: Libor Vanek User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; cs-CZ; rv:1.5a) Gecko/20030718 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: System halts when disk full Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 770 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: libor@conet.cz Precedence: bulk X-list: linux-xfs Content-Length: 263 Lines: 10 Hi, we're using RH9 with XFS fs with all kinds of kernel (2.4.20 + XFS 1.2 and also 2.4.22 + XFS 1.3). When ANY mount point using XFS (/, /raid etc...) gets full, complete system halt and needs to be rebooted - is this bug or feature? :) Best regards, Libor From owner-linux-xfs@oss.sgi.com Tue Oct 21 10:27:27 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 21 Oct 2003 10:28:06 -0700 (PDT) Received: from localhost.localdomain (host-65-120-145-91.coremetrics.com [65.120.145.91] (may be forged)) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9LHRQ25029551 for ; Tue, 21 Oct 2003 10:27:27 -0700 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id h9LHQsKm003157; Tue, 21 Oct 2003 12:26:54 -0500 Received: (from austin@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id h9LHQrTE003154; Tue, 21 Oct 2003 12:26:53 -0500 X-Authentication-Warning: localhost.localdomain: austin set sender to austin@coremetrics.com using -f Subject: Re: System halts when disk full From: Austin Gonyou To: Libor Vanek Cc: XFS List In-Reply-To: <3F9568A5.6050308@conet.cz> References: <3F9568A5.6050308@conet.cz> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1066757213.1870.1.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Tue, 21 Oct 2003 12:26:53 -0500 X-archive-position: 771 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: austin@coremetrics.com Precedence: bulk X-list: linux-xfs Content-Length: 586 Lines: 18 I'm kind of curious if the disk is 100% or just near, i.e. 1mb to go, or even 10K free, etc. Look back in this list. I have a message around here about the same thing, from several revisions ago. On Tue, 2003-10-21 at 12:11, Libor Vanek wrote: > Hi, > we're using RH9 with XFS fs with all kinds of kernel (2.4.20 + XFS 1.2 > and also 2.4.22 + XFS 1.3). > > When ANY mount point using XFS (/, /raid etc...) gets full, complete > system halt and needs to be rebooted - is this bug or feature? :) > > Best regards, > Libor -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Tue Oct 21 19:48:30 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 21 Oct 2003 19:49:09 -0700 (PDT) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9M2mT25009539 for ; Tue, 21 Oct 2003 19:48:30 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id h9M2mNq0013799 for ; Tue, 21 Oct 2003 19:48:24 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA00591; Wed, 22 Oct 2003 12:48:20 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h9M2mJUc742698; Wed, 22 Oct 2003 12:48:20 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id h9M2jYtS001767; Wed, 22 Oct 2003 12:45:34 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id h9M2jW1M001765; Wed, 22 Oct 2003 12:45:32 +1000 Date: Wed, 22 Oct 2003 12:45:32 +1000 From: Nathan Scott To: Libor Vanek Cc: linux-xfs@oss.sgi.com Subject: Re: System halts when disk full Message-ID: <20031022024532.GC1114@frodo> References: <3F9568A5.6050308@conet.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F9568A5.6050308@conet.cz> User-Agent: Mutt/1.5.3i X-archive-position: 772 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 543 Lines: 18 On Tue, Oct 21, 2003 at 07:11:01PM +0200, Libor Vanek wrote: > Hi, > we're using RH9 with XFS fs with all kinds of kernel (2.4.20 + XFS 1.2 > and also 2.4.22 + XFS 1.3). > > When ANY mount point using XFS (/, /raid etc...) gets full, complete > system halt and needs to be rebooted - is this bug or feature? :) > Doesn't sound like a feature - do you have a reproducible test case? (the QA tests routinely fill up file systems every night, no hangs there atm). A kdb dump from the hung machine would be useful too. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Oct 21 19:54:13 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 21 Oct 2003 19:54:46 -0700 (PDT) Received: from mailhub2.arup.com (mailhub2.arup.com [193.116.20.61]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9M2sB25009979 for ; Tue, 21 Oct 2003 19:54:12 -0700 Received: from mailhub2.arup.com (127.0.0.1) by mailhub2.arup.com (LSMTP for Windows NT v1.1b) with SMTP id <1.01796F5B@mailhub2.arup.com>; Wed, 22 Oct 2003 3:54:05 +0100 Received: from sydnws03 ([169.2.102.3]) by mailhub2.arup.com with InterScan Messaging Security Suite; Wed, 22 Oct 2003 03:54:04 +0100 Received: from ozgateway-Message_Server by sydnws03 with Novell_GroupWise; Wed, 22 Oct 2003 12:52:35 +1000 Message-Id: X-Mailer: Novell GroupWise 5.5.4 Date: Wed, 22 Oct 2003 12:51:26 +1000 From: "Scott Fagg" To: Subject: Re: System halts when disk full Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h9M2sD25009980 X-archive-position: 773 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: scott.fagg@arup.com Precedence: bulk X-list: linux-xfs Content-Length: 823 Lines: 32 Is this in anyway related to problem i observed a little while back where a full FS would generate a LOT of debug output ? What's dmesg show ? Scott Fagg Arup Brisbane (07) 3023 6000 >>> Nathan Scott 22/10/2003 12:45:32 PM >>> On Tue, Oct 21, 2003 at 07:11:01PM +0200, Libor Vanek wrote: > Hi, > we're using RH9 with XFS fs with all kinds of kernel (2.4.20 + XFS 1.2 > and also 2.4.22 + XFS 1.3). > > When ANY mount point using XFS (/, /raid etc...) gets full, complete > system halt and needs to be rebooted - is this bug or feature? :) > Doesn't sound like a feature - do you have a reproducible test case? (the QA tests routinely fill up file systems every night, no hangs there atm). A kdb dump from the hung machine would be useful too. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Oct 22 01:00:26 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 22 Oct 2003 01:00:59 -0700 (PDT) Received: from localhost.localdomain (firewall.conet.cz [213.175.54.250]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9M80C25027080 for ; Wed, 22 Oct 2003 01:00:25 -0700 Received: from conet.cz (thor [192.168.1.130]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id h9M7xYX2031674; Wed, 22 Oct 2003 09:59:35 +0200 Message-ID: <3F9638E5.1040407@conet.cz> Date: Wed, 22 Oct 2003 09:59:33 +0200 From: Libor Vanek User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Austin Gonyou CC: XFS List Subject: Re: System halts when disk full References: <3F9568A5.6050308@conet.cz> <1066757213.1870.1.camel@localhost.localdomain> In-Reply-To: <1066757213.1870.1.camel@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 774 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: libor@conet.cz Precedence: bulk X-list: linux-xfs Content-Length: 632 Lines: 26 Usually it's really 100% full (happens i.e. when somebody tries to run Bonnie with too large test file on bad partition)... Libor >I'm kind of curious if the disk is 100% or just near, i.e. 1mb to go, or >even 10K free, etc. Look back in this list. I have a message around here >about the same thing, from several revisions ago. > > >>Hi, >>we're using RH9 with XFS fs with all kinds of kernel (2.4.20 + XFS 1.2 >>and also 2.4.22 + XFS 1.3). >> >>When ANY mount point using XFS (/, /raid etc...) gets full, complete >>system halt and needs to be rebooted - is this bug or feature? :) >> >>Best regards, >>Libor >> >> From owner-linux-xfs@oss.sgi.com Wed Oct 22 02:49:35 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 22 Oct 2003 02:50:16 -0700 (PDT) Received: from localhost.localdomain (firewall.conet.cz [213.175.54.250]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9M9nW25032362 for ; Wed, 22 Oct 2003 02:49:34 -0700 Received: from conet.cz (thor [192.168.1.130]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id h9M9nMX2001123; Wed, 22 Oct 2003 11:49:27 +0200 Message-ID: <3F9652A1.80602@conet.cz> Date: Wed, 22 Oct 2003 11:49:21 +0200 From: Libor Vanek User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nathan Scott CC: linux-xfs@oss.sgi.com Subject: Re: System halts when disk full References: <3F9568A5.6050308@conet.cz> <20031022024532.GC1114@frodo> In-Reply-To: <20031022024532.GC1114@frodo> Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit X-archive-position: 775 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: libor@conet.cz Precedence: bulk X-list: linux-xfs Content-Length: 636 Lines: 25 >>we're using RH9 with XFS fs with all kinds of kernel (2.4.20 + XFS 1.2 >>and also 2.4.22 + XFS 1.3). >> >>When ANY mount point using XFS (/, /raid etc...) gets full, complete >>system halt and needs to be rebooted - is this bug or feature? :) >> > >Doesn't sound like a feature - do you have a reproducible test case? > Yes - we've about 10s of RH9 systems with this bug (all generated with same system image) >(the QA tests routinely fill up file systems every night, no hangs >there atm). A kdb dump from the hung machine would be useful too. > > I'll try to produce something. Libor [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Wed Oct 22 18:26:27 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 22 Oct 2003 18:27:06 -0700 (PDT) Received: from metro.dynaweb.hu (IDENT:root@metro.dynaweb.hu [195.70.37.87]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9N1QO25000761 for ; Wed, 22 Oct 2003 18:26:26 -0700 Received: from corona.local (caracas-0084.adsl.interware.hu [213.178.100.84]) (authenticated bits=128) by metro.dynaweb.hu (8.12.10/8.12.10) with ESMTP id h9N1Q6jU008447 for ; Thu, 23 Oct 2003 03:26:21 +0200 (CEST) Received: from corona (corona [10.1.1.14]) by corona.local (8.12.9/8.12.9) with SMTP id h9N1Q0kf003980 for ; Thu, 23 Oct 2003 03:26:00 +0200 (CEST) Date: Thu, 23 Oct 2003 03:26:00 +0200 From: Rumi Szabolcs To: linux-xfs@oss.sgi.com Subject: sunit and swidth Message-Id: <20031023032600.14029cfe.rumi_ml@rtfm.hu> X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; sparc-sun-solaris2.9) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 776 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: rumi_ml@rtfm.hu Precedence: bulk X-list: linux-xfs Content-Length: 1216 Lines: 37 Hello! I am running an xfs-based system on top of a hardware RAID5 array which has a 16k stripe size, so I have used the options -d sunit=8,swidth=32 when I mkfs'ed all the file systems, including the root fs. This way now I see the "rw,sunit=8,swidth=32" mount options for the root fs when I list mounted file systems via mount(8) but only "rw" for the others which were also created with the very same parameters. The sunit/swidth options are not explicitly given in fstab for any of the filesystems. Then, I remounted the root fs with "mount -o remount,rw" and apparently nothing happened. Then I remounted with sunit/swidth set explicitly and again, nothing seemed to happen. My questions are: 1.) are these options really safely settable/changeable when the filesystem is already mounted and running or I should expect some kind of corruption by doing that? 2.) is it necessary to explicitly set them via fstab? 3.) if they were not explicitly set via fstab, why is that for the root fs they seem to be set but for the other filesystems they are not? 4.) does 3.) reflect the actual situation? or are the mkfs-time options used regardless of that shown by mount(8)? Thank you! Regards, Szabolcs Rumi From owner-linux-xfs@oss.sgi.com Thu Oct 23 02:24:22 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 23 Oct 2003 02:25:05 -0700 (PDT) Received: from goliath.sylaba.poznan.pl (goliath.sylaba.poznan.pl [195.216.104.3]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9N9OK25015412 for ; Thu, 23 Oct 2003 02:24:22 -0700 Received: by goliath.sylaba.poznan.pl (Postfix, from userid 1003) id B90B894436; Thu, 23 Oct 2003 11:24:19 +0200 (CEST) Received: from venus.local.navi.pl (ps103.poznan.sdi.tpnet.pl [217.97.72.103]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by goliath.sylaba.poznan.pl (Postfix) with ESMTP id 4CDBE9424D for ; Thu, 23 Oct 2003 11:24:19 +0200 (CEST) Received: from venus.local.navi.pl (venus.local.navi.pl [127.0.0.1]) by venus.local.navi.pl (8.12.5/8.12.5) with ESMTP id h9N9PGTm023970 for ; Thu, 23 Oct 2003 11:25:17 +0200 Subject: Problem with XFS-1.3.0 and samba From: Olaf =?iso-8859-2?Q?Fr=B1czyk?= To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 23 Oct 2003 11:25:16 +0200 Message-Id: <1066901117.9568.13.camel@venus> Mime-Version: 1.0 X-archive-position: 777 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: olaf@cbk.poznan.pl Precedence: bulk X-list: linux-xfs Content-Length: 576 Lines: 21 Hi, When configure samba I get: configure: WARNING: xfs/xfs_fs.h: present but cannot be compiled configure: WARNING: xfs/xfs_fs.h: check for missing prerequisite headers? configure: WARNING: xfs/xfs_fs.h: proceeding with the preprocessor's result configure: WARNING: ## ------------------------------------ ## configure: WARNING: ## Report this to bug-autoconf@gnu.org. ## configure: WARNING: ## ------------------------------------ ## What is wrong. I have seen similar report on samba-technical mailing list, but saw no reply for it. Regards, Olaf Fraczyk From owner-linux-xfs@oss.sgi.com Thu Oct 23 08:20:11 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 23 Oct 2003 08:20:51 -0700 (PDT) Received: from mx02.ca.mci.com (mx02.ca.mci.com [142.77.1.60]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9NFK125029455 for ; Thu, 23 Oct 2003 08:20:01 -0700 Received: from co.calibre-dd.com (fw.calibre-dd.com [216.95.225.66]) by mx02.ca.mci.com (Postfix) with ESMTP id 9FE7D7EE22 for ; Thu, 23 Oct 2003 10:46:02 -0400 (EDT) Received: from calibredigital.com (axis.calibre-dd.com [172.16.92.209]) (authenticated) by co-eth1.calibre-dd.com (8.10.2/8.10.2) with ESMTP id h9NEjqN03270 for ; Thu, 23 Oct 2003 10:45:52 -0400 Message-ID: <3F97E9E2.3E343820@calibredigital.com> Date: Thu, 23 Oct 2003 10:46:58 -0400 From: Greg Whynott Organization: Calibre Digital Pictures X-Mailer: Mozilla 4.79C-SGI [en] (X11; I; IRIX64 6.5 IP30) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: xfs log on another device, will it destroy existing data? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-CDP-MailScanner-Information: Please contact the ISP for more information X-CDP-MailScanner: Found to be clean X-archive-position: 779 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: greg@calibredigital.com Precedence: bulk X-list: linux-xfs Content-Length: 531 Lines: 18 I'd like to create an xfs fs on an array. I'd also like to put the metadata log on another device, I currently have an ext3 fs mounted, can I put the log on the ext3 fs without losing the data there now or does it expect a raw partition? the manual page doesn't say one way or another if it will destroy data.. xfs to go on a 2G FC RAID5 array (7x35G disks) log to go on a SCSI 320 mirror set with an ext3 fs mounted under /var thanks folks! greg -- UNIX is user friendly, it's just selective about who its friends are. From owner-linux-xfs@oss.sgi.com Thu Oct 23 08:35:00 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 23 Oct 2003 08:35:39 -0700 (PDT) Received: from rj.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9NFYx25030025 for ; Thu, 23 Oct 2003 08:35:00 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h9NDddOO013214 for ; Thu, 23 Oct 2003 06:39:39 -0700 Received: from tulip-e236.americas.sgi.com (tulip-e236.americas.sgi.com [128.162.236.208]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h9NFYrP512378813; Thu, 23 Oct 2003 10:34:54 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by tulip-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h9NFYsSn34401785; Thu, 23 Oct 2003 10:34:54 -0500 (CDT) Received: from jen.americas.sgi.com (localhost.localdomain [127.0.0.1]) by jen.americas.sgi.com (8.12.8/8.12.8) with ESMTP id h9NFYr95026443; Thu, 23 Oct 2003 10:34:53 -0500 Received: (from lord@localhost) by jen.americas.sgi.com (8.12.8/8.12.8/Submit) id h9NFYrw0026441; Thu, 23 Oct 2003 10:34:53 -0500 X-Authentication-Warning: jen.americas.sgi.com: lord set sender to lord@sgi.com using -f Subject: Re: xfs log on another device, will it destroy existing data? From: Steve Lord To: Greg Whynott Cc: linux-xfs@oss.sgi.com In-Reply-To: <3F97E9E2.3E343820@calibredigital.com> References: <3F97E9E2.3E343820@calibredigital.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1066923291.21480.60.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 23 Oct 2003 10:34:52 -0500 X-archive-position: 780 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 811 Lines: 25 On Thu, 2003-10-23 at 09:46, Greg Whynott wrote: > I'd like to create an xfs fs on an array. I'd also like to put the > metadata log on another device, I currently have an ext3 fs mounted, > can I put the log on the ext3 fs without losing the data there now or > does it expect a raw partition? the manual page doesn't say one way or > another if it will destroy data.. > > xfs to go on a 2G FC RAID5 array (7x35G disks) > log to go on a SCSI 320 mirror set with an ext3 fs mounted under /var > > > thanks folks! > greg The log expects a raw partition, it will start at block zero of the device you specify and write over whatever used to be there. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Oct 23 08:53:17 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 23 Oct 2003 08:53:55 -0700 (PDT) Received: from mx05.ca.mci.com (mx05.ca.mci.com [142.77.2.25]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9NFr625031521 for ; Thu, 23 Oct 2003 08:53:06 -0700 Received: from co.calibre-dd.com (fw.calibre-dd.com [216.95.225.66]) by mx05.ca.mci.com (Postfix) with ESMTP id 1652B3C5DE for ; Thu, 23 Oct 2003 11:12:36 -0400 (EDT) Received: from calibredigital.com (axis.calibre-dd.com [172.16.92.209]) (authenticated) by co-eth1.calibre-dd.com (8.10.2/8.10.2) with ESMTP id h9NFCKN07343 for ; Thu, 23 Oct 2003 11:12:20 -0400 Message-ID: <3F97F016.4AB1E881@calibredigital.com> Date: Thu, 23 Oct 2003 11:13:26 -0400 From: Greg Whynott Organization: Calibre Digital Pictures X-Mailer: Mozilla 4.79C-SGI [en] (X11; I; IRIX64 6.5 IP30) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: what mkfs.xfs options to use with dealing with many small files. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-CDP-MailScanner-Information: Please contact the ISP for more information X-CDP-MailScanner: Found to be clean X-archive-position: 781 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: greg@calibredigital.com Precedence: bulk X-list: linux-xfs Content-Length: 871 Lines: 33 I am putting together an Courier IMAP server and would like to squeeze all the performance I can from the array as there will almost 200 persons collecting mail from the machine. As you may know Courier stores all mail as individual files, averaging in our environment between 2 and 4K each. The RAID 5 array is across 7 disks on a FC controller. Would anyone have a recommended set of arguments to pass mkfs.xfs while creating the fs? the md raid was created using a chunk size of 32, you think this is ok or should it be smaller? I was going to use this line to create the xfs fs: mkfs.xfs -f -b size=2048k -d agcount=16 /dev/md0 also I am considering putting the metadata log on another device. any thoughts on this would be really appreciated. thanks for your time, greg -- UNIX is user friendly, it's just selective about who its friends are. From owner-linux-xfs@oss.sgi.com Thu Oct 23 09:13:24 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 23 Oct 2003 09:13:58 -0700 (PDT) Received: from rj.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9NGDO25032161 for ; Thu, 23 Oct 2003 09:13:24 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h9NEI3OO016602 for ; Thu, 23 Oct 2003 07:18:03 -0700 Received: from tulip-e236.americas.sgi.com (tulip-e236.americas.sgi.com [128.162.236.208]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h9NGDIP512462342; Thu, 23 Oct 2003 11:13:18 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by tulip-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h9NGDISn32912089; Thu, 23 Oct 2003 11:13:18 -0500 (CDT) Received: from jen.americas.sgi.com (localhost.localdomain [127.0.0.1]) by jen.americas.sgi.com (8.12.8/8.12.8) with ESMTP id h9NGDC95026756; Thu, 23 Oct 2003 11:13:12 -0500 Received: (from lord@localhost) by jen.americas.sgi.com (8.12.8/8.12.8/Submit) id h9NGD7XB026754; Thu, 23 Oct 2003 11:13:07 -0500 X-Authentication-Warning: jen.americas.sgi.com: lord set sender to lord@sgi.com using -f Subject: Re: what mkfs.xfs options to use with dealing with many small files. From: Steve Lord To: Greg Whynott Cc: linux-xfs@oss.sgi.com In-Reply-To: <3F97F016.4AB1E881@calibredigital.com> References: <3F97F016.4AB1E881@calibredigital.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1066925583.21480.71.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 23 Oct 2003 11:13:06 -0500 X-archive-position: 782 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1800 Lines: 50 On Thu, 2003-10-23 at 10:13, Greg Whynott wrote: > I am putting together an Courier IMAP server and would like to squeeze > all the performance I can from the array as there will almost 200 > persons collecting mail from the machine. As you may know Courier > stores all mail as individual files, averaging in our environment > between 2 and 4K each. > > The RAID 5 array is across 7 disks on a FC controller. Would anyone > have a recommended set of arguments to pass mkfs.xfs while creating the > fs? > > the md raid was created using a chunk size of 32, you think this is ok > or should it be smaller? > > I was going to use this line to create the xfs fs: > > mkfs.xfs -f -b size=2048k -d agcount=16 /dev/md0 -b size specifies the basic block size of the filesystem, it is in bytes, I do not think 2048k is going to work. Why choose 2K? If you are going to switch from the default of 512 then the best bet is 4096. If you are specifying an external log, then you will need to specify its size, you might want to go above the default in any case. Specifying an agcount is probably not a good move, right now an allocation group is limited to 4G bytes, I would let it do its own thing. If it picks up the stripe infor from md correctly, it will round robin the start of the allocation groups across the spindles. This spreads the metadata I/O load, there are some blocks at the starts of allocation groups which are hit pretty frequently. Steve > > also I am considering putting the metadata log on another device. > > any thoughts on this would be really appreciated. > > thanks for your time, > greg > > > -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Oct 23 09:19:09 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 23 Oct 2003 09:19:41 -0700 (PDT) Received: from server418.dnslive.net (server418.dnslive.net [216.74.126.5]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9NGJ825000366 for ; Thu, 23 Oct 2003 09:19:09 -0700 Received: from [24.229.125.7] (helo=thinker) by server418.dnslive.net with smtp (Exim 4.24) id 1ACiB1-0007Y1-OS; Thu, 23 Oct 2003 12:19:07 -0400 From: "Michael Sinz" To: "linux-xfs@oss.sgi.com" Cc: "lord@sgi.com" Date: Thu, 23 Oct 2003 12:18:17 -0400 Reply-To: "Michael Sinz" Priority: Normal X-Mailer: sinz.org In-Reply-To: <3F97E9E2.3E343820@calibredigital.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: Interesting problem with XFS and NFS... (or just NFS?) Message-Id: X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server418.dnslive.net X-AntiAbuse: Original Domain - oss.sgi.com X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - sinz.org X-archive-position: 783 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Linux@sinz.org Precedence: bulk X-list: linux-xfs Content-Length: 2218 Lines: 52 Ok, this may be a bit complex, but... I have a bunch of files I wanted to make available on a read-only NFS mount that currently live in a directory under my home directory. It turns out that the NFS mount is on the same device (it is in /home/nfs) as my home directory (/home/mks) So, thinking that it would be good to have the files actually be the same files, I did the following (names changed to generics) cp -al /home/mks/sharestuff /home/nfs/mks-stuff What cp -al does in Linux/GNU land is to copy a tree by rather than copying any files, it makes hard-links to those files. Directories are not linked, they are freshly created on the other end. Anyway, this seems to have worked fine - except... sometimes some of the files just can not be read at all over NFS. Which files they are seems to be somewhat random with very consistant behavior. That is, once it starts to happen, even restarting the NFS service on the server and the client does not change which files it is that fail. In the /var/log/messages I get "fh_verify: no root_squashed access at " but the filename is that of that of the file in my home directory! On the client side I get a "stale NFS file handle" It looks like it has something to do with the caching of inode within NFS and then doing a lookup of the filename from the inode and it not being within the NFS export tree, the NFS server is failing the operation. To verify this, I had enough disk space to do a normal copy of the tree and the export worked just fine. Never had a problem since. Very strange, and very annoying. I don't have a large enough disk to try this with another FS currently. (I run everything XFS) so this may not actually be an XFS issue but rather an NFS issue. However, it does bring up an interesting question: Is there some way to get all of the possible names an inode lives under? It would at least allow a work-around to the NFS problem seen here as it would find that there is at least one location where this is just fine. Now to pull out some code and dig into it - but then again, it is working right now and I have some paying work to do. -- Michael Sinz - http://www.sinz.org/Michael.Sinz/Linux - Linux@sinz.org From owner-linux-xfs@oss.sgi.com Thu Oct 23 09:24:35 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 23 Oct 2003 09:25:08 -0700 (PDT) Received: from rj.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9NGOY25000985 for ; Thu, 23 Oct 2003 09:24:35 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h9NETEOO018135 for ; Thu, 23 Oct 2003 07:29:14 -0700 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h9NGOSP512472971; Thu, 23 Oct 2003 11:24:28 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h9NGOSK13639398; Thu, 23 Oct 2003 11:24:28 -0500 (CDT) Subject: Re: what mkfs.xfs options to use with dealing with many small files. From: Eric Sandeen To: Steve Lord Cc: Greg Whynott , linux-xfs@oss.sgi.com In-Reply-To: <1066925583.21480.71.camel@jen.americas.sgi.com> References: <3F97F016.4AB1E881@calibredigital.com> <1066925583.21480.71.camel@jen.americas.sgi.com> Content-Type: text/plain Organization: Message-Id: <1066926267.23500.10.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 23 Oct 2003 11:24:28 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 784 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 724 Lines: 22 On Thu, 2003-10-23 at 11:13, Steve Lord wrote: > > mkfs.xfs -f -b size=2048k -d agcount=16 /dev/md0 > > -b size specifies the basic block size of the filesystem, it is > in bytes, I do not think 2048k is going to work. Why choose 2K? > If you are going to switch from the default of 512 then the best > bet is 4096. Not quite, -b is the filesystem block size, not the device sector size, right? 4k default, page-sized max, 512 minimum. If you're worried about wasted space on small files, smaller -b might make sense, at the expense of a slightly more complex code path, I think. -Eric -- Eric Sandeen [C]XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Thu Oct 23 09:29:18 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 23 Oct 2003 09:29:52 -0700 (PDT) Received: from rj.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9NGTI25001471 for ; Thu, 23 Oct 2003 09:29:18 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h9NEXvOO018623 for ; Thu, 23 Oct 2003 07:33:57 -0700 Received: from tulip-e236.americas.sgi.com (tulip-e236.americas.sgi.com [128.162.236.208]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h9NGTCP512461661; Thu, 23 Oct 2003 11:29:12 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by tulip-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h9NGTCSn34601203; Thu, 23 Oct 2003 11:29:12 -0500 (CDT) Received: from jen.americas.sgi.com (localhost.localdomain [127.0.0.1]) by jen.americas.sgi.com (8.12.8/8.12.8) with ESMTP id h9NGTB95027355; Thu, 23 Oct 2003 11:29:11 -0500 Received: (from lord@localhost) by jen.americas.sgi.com (8.12.8/8.12.8/Submit) id h9NGTBYd027353; Thu, 23 Oct 2003 11:29:11 -0500 X-Authentication-Warning: jen.americas.sgi.com: lord set sender to lord@sgi.com using -f Subject: Re: what mkfs.xfs options to use with dealing with many small files. From: Steve Lord To: Eric Sandeen Cc: Greg Whynott , linux-xfs@oss.sgi.com In-Reply-To: <1066926267.23500.10.camel@stout.americas.sgi.com> References: <3F97F016.4AB1E881@calibredigital.com> <1066925583.21480.71.camel@jen.americas.sgi.com> <1066926267.23500.10.camel@stout.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1066926551.21480.79.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 23 Oct 2003 11:29:11 -0500 X-archive-position: 785 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 712 Lines: 22 On Thu, 2003-10-23 at 11:24, Eric Sandeen wrote: > On Thu, 2003-10-23 at 11:13, Steve Lord wrote: > > > > mkfs.xfs -f -b size=2048k -d agcount=16 /dev/md0 > > > > -b size specifies the basic block size of the filesystem, it is > > in bytes, I do not think 2048k is going to work. Why choose 2K? > > If you are going to switch from the default of 512 then the best > > bet is 4096. > > Not quite, -b is the filesystem block size, not the device sector size, > right? 4k default, page-sized max, 512 minimum. Sorry, I was thinking about -s, not -b. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Oct 23 10:07:35 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 23 Oct 2003 10:08:10 -0700 (PDT) Received: from nks-mail-02.nks.net (nks-mail-02.nks.net [66.152.21.101]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9NH7Y25002354 for ; Thu, 23 Oct 2003 10:07:35 -0700 Received: from hoju.nks.net (hoju.nks.net [192.168.1.17]) by nks-mail-02.nks.net (8.12.3/8.12.3/Debian-5.1) with ESMTP id h9NH7Sri010977 for ; Thu, 23 Oct 2003 13:07:28 -0400 Received: from two.nks.net (two.nks.net [192.168.1.22]) by hoju.nks.net (8.12.9/8.12.7/Debian 8.9.3-21) with ESMTP id h9NH7RJ9009838 for ; Thu, 23 Oct 2003 13:07:27 -0400 Subject: weird XFS+RAID+big IDE problem? From: Derek Glidden To: linux-xfs@oss.sgi.com Content-Type: text/plain Organization: Message-Id: <1066928847.2813.25.camel@two> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 23 Oct 2003 13:07:27 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 786 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dglidden@illusionary.com Precedence: bulk X-list: linux-xfs Content-Length: 4029 Lines: 84 I'm building a new server at home with 4x 160G Samsung IDE hard drives and Linux software RAID5. (I'd love to go SCSI with some nice hardware RAID, but... well, someone send me some money. I barely got away with getting the drives. You know how it is. So don't go there. :) / == /dev/md0 /var == /dev/md1 /usr == /dev/md2 /home == /dev/md3 /opt == /dev/md4 with all drives partitioned exactly the same and each MD being RAID5. I'd love to use XFS on it like I do on everything else I build, but I'm having problems. Any time there is any significant disk I/o on more than one filesystem, e.g. rsync'ing from another box onto /opt while building a kernel under /usr, I wind up with xfs_shutdown on one or more filesystems, kernel panic and really bad filesystem corruption. (More than once to the point that "xfs_repair" reported it could not find an XFS filesystem on the volume.) I've also had random xfs_shutdowns and filesystem corruption while the machine is apparently just sitting idle or with very minimal disk I/o to just one volume, but I can eventually (pretty quickly more often than not) make it crash every time if I start lots of I/o to multiple filesystems simultaneously. I've tried with all four drives on the built-in IDE controllers on the motherboards, I've tried two attached to a PCI Promise card so there is only one drive per IDE channel, I've even built it with all four drives on PCI controllers as just a single RAID volume and a fifth boot/system drive on the built-in IDE so only /opt is XFS/RAID5 and everything else are just single partitions on a single drive as XFS. It gets installed as a base Debian Woody system. I've tried running with 2.4.21 + XFS 1.3.1, 2.4.22 + xfs 2.4.22 split patches, 2.4.21aa1, 2.4.22aa1 and building the kernel with debug stuff enabled. But the panics usually mean that once the box goes down, I'm totally boned, debug symbols/debugger or not, and have to hit the big red button. The same box, without changing any of the hardware configuration and even using the exact same kernel binary, but using ext3 for all the filesystems has been rock solid stable for several days now, no matter how much I throw at it, including all the things that make it crash with XFS. The whole system has been burnt in with "ctcs" for five days straight with absolutely no problems, so I'm hesitant to say it might be a hardware problem, especially since the same box with ext3 in place of XFS has been stable. I've got at least two other servers, at home and at work, built exactly the same way, solid as the proverbial rock, but with 120G drives or smaller. So my only semi-reasonable guess is there is some bizarre interaction with XFS+Software RAID5+IDE larger than 128G that is making it crashy. Has anyone else tried building a similar machine with any success? Has anyone else had problems with XFS and Linux software RAID and big IDE drives? I realize this is a really paltry amount of mostly useless random information, but I've really been flailing since I can't get any idea of where the actual problem might be and the crashes appear pretty randomly other than I can make them happen eventually (once the box lasted three days before seriously eating itself alive) if I start up lots of disk I/o. It's not going "into production" to replace my old server until I'm sure I can keep it rock solid, so I have no problems blowing it away and installing some completely experimental patch or software mod on it, so if anyone has any suggestions, or any code changes they'd like to try to see if they can find the problem, I am completely open to doing whatever to this thing. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- "We all enter this world in the | Support Electronic Freedom same way: naked; screaming; soaked | http://www.eff.org/ in blood. But if you live your | http://www.anti-dmca.org/ life right, that kind of thing |--------------------------- doesn't have to stop there." -- Dana Gould From owner-linux-xfs@oss.sgi.com Thu Oct 23 10:25:38 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 23 Oct 2003 10:26:12 -0700 (PDT) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9NHPc25002919 for ; Thu, 23 Oct 2003 10:25:38 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h9NHiEHc024015 for ; Thu, 23 Oct 2003 12:44:14 -0500 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h9NHPWP512458314; Thu, 23 Oct 2003 12:25:32 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h9NHPWK13972995; Thu, 23 Oct 2003 12:25:32 -0500 (CDT) Subject: Re: weird XFS+RAID+big IDE problem? From: Eric Sandeen To: Derek Glidden Cc: linux-xfs@oss.sgi.com In-Reply-To: <1066928847.2813.25.camel@two> References: <1066928847.2813.25.camel@two> Content-Type: text/plain Organization: Message-Id: <1066929931.23500.14.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 23 Oct 2003 12:25:32 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 787 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 363 Lines: 14 On Thu, 2003-10-23 at 12:07, Derek Glidden wrote: > I realize this is a really paltry amount of mostly useless random > information, Detailed kernel messages from the shutdowns would be a place to start, if you still have them. -Eric -- Eric Sandeen [C]XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Thu Oct 23 10:27:20 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 23 Oct 2003 10:27:54 -0700 (PDT) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9NHRK25003201 for ; Thu, 23 Oct 2003 10:27:20 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h9NHjuHc024949 for ; Thu, 23 Oct 2003 12:45:56 -0500 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h9NHRDP512486205; Thu, 23 Oct 2003 12:27:13 -0500 (CDT) Received: from naboo (naboo.americas.sgi.com [128.162.233.73]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h9NHRDRn342070139; Thu, 23 Oct 2003 12:27:13 -0500 (CDT) Subject: Re: Problem with XFS-1.3.0 and samba From: Russell Cattelan To: Olaf =?iso-8859-2?Q?Fr=B1czyk?= Cc: linux-xfs@oss.sgi.com In-Reply-To: <1066901117.9568.13.camel@venus> References: <1066901117.9568.13.camel@venus> Content-Type: text/plain; charset=UTF-8 Message-Id: <1066930032.10404.13.camel@naboo> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4-8mdk Date: Thu, 23 Oct 2003 12:27:13 -0500 Content-Transfer-Encoding: 8bit X-archive-position: 788 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cattelan@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 785 Lines: 27 Is this trying to compile samba? Give a bit more background samba version and what the ./configure line looks like On Thu, 2003-10-23 at 04:25, Olaf FrDczyk wrote: > Hi, > > When configure samba I get: > > configure: WARNING: xfs/xfs_fs.h: present but cannot be compiled > configure: WARNING: xfs/xfs_fs.h: check for missing prerequisite > headers? > configure: WARNING: xfs/xfs_fs.h: proceeding with the preprocessor's > result > configure: WARNING: ## ------------------------------------ ## > configure: WARNING: ## Report this to bug-autoconf@gnu.org. ## > configure: WARNING: ## ------------------------------------ ## > > What is wrong. > I have seen similar report on samba-technical mailing list, but saw no > reply for it. > > Regards, > > Olaf Fraczyk > From owner-linux-xfs@oss.sgi.com Thu Oct 23 10:44:47 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 23 Oct 2003 10:45:20 -0700 (PDT) Received: from rj.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9NHik25003838 for ; Thu, 23 Oct 2003 10:44:46 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h9NFnQOO026226 for ; Thu, 23 Oct 2003 08:49:26 -0700 Received: from tulip-e236.americas.sgi.com (tulip-e236.americas.sgi.com [128.162.236.208]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h9NHieP512479065 for ; Thu, 23 Oct 2003 12:44:41 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.232.100]) by tulip-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h9NHifSn34342716 for ; Thu, 23 Oct 2003 12:44:41 -0500 (CDT) Received: from jen.americas.sgi.com (localhost.localdomain [127.0.0.1]) by jen.americas.sgi.com (8.12.8/8.12.8) with ESMTP id h9NHie95027961 for ; Thu, 23 Oct 2003 12:44:40 -0500 Received: (from lord@localhost) by jen.americas.sgi.com (8.12.8/8.12.8/Submit) id h9NHieOh027959 for linux-xfs@oss.sgi.com; Thu, 23 Oct 2003 12:44:40 -0500 X-Authentication-Warning: jen.americas.sgi.com: lord set sender to lord@sgi.com using -f Subject: TAKE: Change XFS maintainer From: Steve Lord To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1066930902.21480.178.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 23 Oct 2003 12:44:40 -0500 X-archive-position: 789 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 764 Lines: 27 Tomorrow is my last Day at SGI, so I am handing over the care and feeding of XFS to Nathan Scott. I will be keeping an eye on things, but my new job will probably keep me too busy to be active all the time. This email address will probably start bouncing very quickly after tomorrow, lord AT xfs DOT org will reach me. Steve Date: Thu Oct 23 09:30:36 PDT 2003 Workarea: penguin.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:160507a linux/MAINTAINERS - 1.94 - Put Nathan Scott in as XFS maintainer -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Oct 23 11:08:22 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 23 Oct 2003 11:09:04 -0700 (PDT) Received: from nks-mail-02.nks.net (nks-mail-02.nks.net [66.152.21.101]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9NI8L25004413 for ; Thu, 23 Oct 2003 11:08:21 -0700 Received: from hoju.nks.net (hoju.nks.net [192.168.1.17]) by nks-mail-02.nks.net (8.12.3/8.12.3/Debian-5.1) with ESMTP id h9NI8Cri012665 for ; Thu, 23 Oct 2003 14:08:13 -0400 Received: from two.nks.net (two.nks.net [192.168.1.22]) by hoju.nks.net (8.12.9/8.12.7/Debian 8.9.3-21) with ESMTP id h9NI8CJ9011733 for ; Thu, 23 Oct 2003 14:08:12 -0400 Subject: Re: weird XFS+RAID+big IDE problem? From: Derek Glidden To: linux-xfs@oss.sgi.com In-Reply-To: <1066929931.23500.14.camel@stout.americas.sgi.com> References: <1066928847.2813.25.camel@two> <1066929931.23500.14.camel@stout.americas.sgi.com> Content-Type: text/plain Organization: Message-Id: <1066932492.2813.29.camel@two> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 23 Oct 2003 14:08:12 -0400 Content-Transfer-Encoding: 7bit X-archive-position: 790 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dglidden@illusionary.com Precedence: bulk X-list: linux-xfs Content-Length: 1154 Lines: 29 On Thu, 2003-10-23 at 13:25, Eric Sandeen wrote: > On Thu, 2003-10-23 at 12:07, Derek Glidden wrote: > > > I realize this is a really paltry amount of mostly useless random > > information, > > Detailed kernel messages from the shutdowns would be a place to start, > if you still have them. Yeah, unfortunately I don't because when the xfs_shutdown happens, usually the very next thing is a panic (or something?), and the console goes dead. Nothing ever makes it to disc afterwards, and I never get even an Oops message printed to the console which from what little I know about linux crashes, is weird in itself. I've tried getting the kernel crash dump stuff working, but the patches I've found don't apply cleanly at all and I haven't been able to resolve all the problems. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- "We all enter this world in the | Support Electronic Freedom same way: naked; screaming; soaked | http://www.eff.org/ in blood. But if you live your | http://www.anti-dmca.org/ life right, that kind of thing |--------------------------- doesn't have to stop there." -- Dana Gould From owner-linux-xfs@oss.sgi.com Thu Oct 23 13:49:22 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 23 Oct 2003 13:49:56 -0700 (PDT) Received: from K-7.stesmi.com (as13-5-5.has.s.bonet.se [217.215.179.23]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9NKnK25009067 for ; Thu, 23 Oct 2003 13:49:21 -0700 Received: from stesmi.com (voyager.stesmi.com [192.168.1.11]) by K-7.stesmi.com (8.12.8/8.12.5) with ESMTP id h9NKnIWA005676; Thu, 23 Oct 2003 22:49:19 +0200 Message-ID: <3F983F20.4050006@stesmi.com> Date: Thu, 23 Oct 2003 22:50:40 +0200 From: Stefan Smietanowski User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Steve Lord CC: linux-xfs@oss.sgi.com Subject: Re: TAKE: Change XFS maintainer References: <1066930902.21480.178.camel@jen.americas.sgi.com> In-Reply-To: <1066930902.21480.178.camel@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 791 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: stesmi@stesmi.com Precedence: bulk X-list: linux-xfs Content-Length: 397 Lines: 13 Hi Steve. > Tomorrow is my last Day at SGI, so I am handing over the care and > feeding of XFS to Nathan Scott. I will be keeping an eye on things, > but my new job will probably keep me too busy to be active all the > time. Sad to hear you change jobs but at the same time I hope that you're perhaps going to something even better. Whatever it is - good luck with it in the future! // Stefan From owner-linux-xfs@oss.sgi.com Thu Oct 23 16:47:43 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 23 Oct 2003 16:48:24 -0700 (PDT) Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9NNlg25013623 for ; Thu, 23 Oct 2003 16:47:42 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id h9NNlYq0010821 for ; Thu, 23 Oct 2003 16:47:36 -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 JAA21753; Fri, 24 Oct 2003 09:47:21 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h9NNlKUc801676; Fri, 24 Oct 2003 09:47:20 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id h9NNiYk7001137; Fri, 24 Oct 2003 09:44:34 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id h9NNiPMa001135; Fri, 24 Oct 2003 09:44:25 +1000 Date: Fri, 24 Oct 2003 09:44:25 +1000 From: Nathan Scott To: Olaf Fr?czyk Cc: linux-xfs@oss.sgi.com Subject: Re: Problem with XFS-1.3.0 and samba Message-ID: <20031023234425.GG858@frodo> References: <1066901117.9568.13.camel@venus> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1066901117.9568.13.camel@venus> User-Agent: Mutt/1.5.3i X-archive-position: 792 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1058 Lines: 31 On Thu, Oct 23, 2003 at 11:25:16AM +0200, Olaf Fr?czyk wrote: > Hi, > > When configure samba I get: > > configure: WARNING: xfs/xfs_fs.h: present but cannot be compiled > configure: WARNING: xfs/xfs_fs.h: check for missing prerequisite > headers? > configure: WARNING: xfs/xfs_fs.h: proceeding with the preprocessor's > result > configure: WARNING: ## ------------------------------------ ## > configure: WARNING: ## Report this to bug-autoconf@gnu.org. ## > configure: WARNING: ## ------------------------------------ ## > > What is wrong. > I have seen similar report on samba-technical mailing list, but saw no > reply for it. Hmm... not sure at exactly the problem here but I'll punt that the configure script is trying to test-compile some source which does a #include ... that should be . (dim light bulb flicks on... this has something to do with quota doesn't it? too long ago now for me to remember the details, but that'll be the only thing Samba needs to know specific to XFS). cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Oct 23 17:13:10 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 23 Oct 2003 17:13:53 -0700 (PDT) Received: from rj.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9O0D925014240 for ; Thu, 23 Oct 2003 17:13:09 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id h9NMHiOO026863 for ; Thu, 23 Oct 2003 15:17:46 -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 KAA22065; Fri, 24 Oct 2003 10:12:51 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h9O0CcUc803307; Fri, 24 Oct 2003 10:12:49 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id h9O09qk7001210; Fri, 24 Oct 2003 10:09:52 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id h9O09pZw001208; Fri, 24 Oct 2003 10:09:51 +1000 Date: Fri, 24 Oct 2003 10:09:51 +1000 From: Nathan Scott To: Jirka Kosina Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: 2.6.0-test8 XFS bug Message-ID: <20031024000951.GH858@frodo> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i X-archive-position: 793 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1623 Lines: 37 On Thu, Oct 23, 2003 at 11:49:59PM +0200, Jirka Kosina wrote: > Hi, > > I've installed 2.6.0-test8 on machine attached to HW raid, made 5.5TB 5.5 Tb -- are you using the LBD option, or a 64 bit platform? > partition (using LVM) and made XFS filesystem on this partition. This > partittion was exported to cca 25 nodes. I started some stress tests ^^^^^^^^^^^^^^^^^^^^^^^^ What does that mean? (cca?) thanks. > ... > Oct 22 13:12:56 storage2 kernel: Filesystem "dm-0": XFS internal error xfs_alloc_read_agf at line 2208 of file fs/xfs/xfs_alloc.c. Caller 0xc01e8f5c > Oct 22 13:12:56 storage2 kernel: Call Trace: > Oct 22 13:12:56 storage2 kernel: [] xfs_alloc_read_agf+0x19e/0x214 > Oct 22 13:12:56 storage2 kernel: [] xfs_alloc_fix_freelist+0x458/0x46e > Oct 22 13:12:56 storage2 last message repeated 2 times > Oct 22 13:12:56 storage2 kernel: [] xfs_trans_log_buf+0x6e/0xa8 > Oct 22 13:12:56 storage2 kernel: [] xfs_bmbt_get_state+0x2f/0x3c > Oct 22 13:12:56 storage2 kernel: [] xfs_alloc_vextent+0x2f4/0x520 > Oct 22 13:12:56 storage2 kernel: [] xfs_bmap_alloc+0x8eb/0x1856 > Oct 22 13:12:56 storage2 kernel: [] xfs_iomap_write_delay+0x35e/0x40a You're allocating real disk space for delayed allocate file data down this path, and the read of the allocation group header found something that didn't look at all like metadata on disk. So, you definately have corruption and will need to xfs_repair. Any ideas as to what operations triggered the initial problem? (is it reproducible for you?) thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Oct 23 17:59:34 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 23 Oct 2003 18:00:09 -0700 (PDT) Received: from tolkor.sgi.com (tolkor.sgi.com [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9O0xX25015002 for ; Thu, 23 Oct 2003 17:59:34 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id h9O1I9Hc004961 for ; Thu, 23 Oct 2003 20:18:10 -0500 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 KAA22549 for ; Fri, 24 Oct 2003 10:59:20 +1000 Received: from melbourne.sgi.com (localhost [127.0.0.1]) by omen.melbourne.sgi.com (SGI-8.12.5/8.12.5) with SMTP id h9O0xJZJ031346 for ; Fri, 24 Oct 2003 10:59:20 +1000 (EST) Date: Fri, 24 Oct 2003 10:59:19 +1000 From: Ivan Rayner To: linux-xfs@oss.sgi.com Subject: Re: [PATCH] [PRELIMINARY] Add support for file flags to xfsdump #1 Message-Id: <20031024105919.5e22a10e.ivanr@sgi.com> In-Reply-To: <20031020073151.GD3648@plato.local.lan> References: <20031020073151.GD3648@plato.local.lan> Organization: SGI X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; mips-sgi-irix6.5) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 794 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ivanr@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1223 Lines: 27 On Sun, 19 Oct 2003 23:31:51 -0800, Ethan Benson wrote: > Recently my patches to add file flags to XFS were merged (immutable, > append-only etc). xfsdump has some problems with the new flags: ... > What I have done to fix the above problems in order: Thanks for your work Ethan. Although I've not looked your code, it sounds like you're doing the right sort of thing. > * dump/inomap.c: Add warning when SGI_XFSDUMP_SKIP_FILE xattr is > present, but still honor it, this attribute is deprecated in favor of > the new nodump file flag, support for the obsolete xattr should be > removed in a future xfsdump (its not that old so this shouldn't be > much of a problem). Add check for new nodump file flag. The SKIP_FILE attribute is still the supported mechanism in IRIX, therefore it'd be a good idea to keep support for it in the Linux version. It doesn't hurt performance, so I don't see any reason to remove it. And since this is still a valid method of skipping files that wouldn't be removed from xfsdump, issuing a warning is probably the wrong thing to do. I think perhaps modifying the man page to mention that there is a preferred alternative to the SKIP_FILE attribute would be appropriate. Ivan From owner-linux-xfs@oss.sgi.com Fri Oct 24 00:03:15 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 24 Oct 2003 00:03:55 -0700 (PDT) Received: from twin.jikos.cz (IDENT:root@twin.jikos.cz [213.151.79.26]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9O73E25021936 for ; Fri, 24 Oct 2003 00:03:15 -0700 Received: from localhost (jikos@localhost) by twin.jikos.cz (8.11.6/8.11.6) with ESMTP id h9O731C23164; Fri, 24 Oct 2003 09:03:01 +0200 Date: Fri, 24 Oct 2003 09:03:01 +0200 (CEST) From: Jirka Kosina To: Nathan Scott cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: 2.6.0-test8 XFS bug In-Reply-To: <20031024000951.GH858@frodo> Message-ID: References: <20031024000951.GH858@frodo> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 795 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jikos@jikos.cz Precedence: bulk X-list: linux-xfs Content-Length: 2034 Lines: 41 On Fri, 24 Oct 2003, Nathan Scott wrote: > > I've installed 2.6.0-test8 on machine attached to HW raid, made 5.5TB > 5.5 Tb -- are you using the LBD option, or a 64 bit platform? Using LBD. > > partition (using LVM) and made XFS filesystem on this partition. This > > partittion was exported to cca 25 nodes. I started some stress tests > What does that mean? (cca?) thanks. It means 'approximately'. To be more precise, there were 24 nodes copying data to and from the partition via NFS. > > Oct 22 13:12:56 storage2 kernel: Filesystem "dm-0": XFS internal error xfs_alloc_read_agf at line 2208 of file fs/xfs/xfs_alloc.c. Caller 0xc01e8f5c > > Oct 22 13:12:56 storage2 kernel: Call Trace: > > Oct 22 13:12:56 storage2 kernel: [] xfs_alloc_read_agf+0x19e/0x214 > > Oct 22 13:12:56 storage2 kernel: [] xfs_alloc_fix_freelist+0x458/0x46e > > Oct 22 13:12:56 storage2 last message repeated 2 times > > Oct 22 13:12:56 storage2 kernel: [] xfs_trans_log_buf+0x6e/0xa8 > > Oct 22 13:12:56 storage2 kernel: [] xfs_bmbt_get_state+0x2f/0x3c > > Oct 22 13:12:56 storage2 kernel: [] xfs_alloc_vextent+0x2f4/0x520 > > Oct 22 13:12:56 storage2 kernel: [] xfs_bmap_alloc+0x8eb/0x1856 > > Oct 22 13:12:56 storage2 kernel: [] xfs_iomap_write_delay+0x35e/0x40a > You're allocating real disk space for delayed allocate file data > down this path, and the read of the allocation group header found > something that didn't look at all like metadata on disk. > So, you definately have corruption and will need to xfs_repair. > Any ideas as to what operations triggered the initial problem? > (is it reproducible for you?) I can simply reproduce it - the only thing needed is to nfsmount this partition from clients and start writing a file to it, as I've written before. The crash occurs immediately after the transfer begins. As I've said, I wouldn't blame HW failure or things like this, because ext3 does the job flawlessly, as far as I can see. -- JiKos. From owner-linux-xfs@oss.sgi.com Fri Oct 24 01:01:33 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 24 Oct 2003 01:02:08 -0700 (PDT) Received: from iris.acsalaska.net (iris.acsalaska.net [209.112.155.43]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9O81X25025699 for ; Fri, 24 Oct 2003 01:01:33 -0700 Received: from erbenson.alaska.net (252-pm32.nwc.alaska.net [209.112.158.252]) by iris.acsalaska.net (8.12.10/8.12.10) with ESMTP id h9O81UQr070682 for ; Fri, 24 Oct 2003 00:01:31 -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 37D0839EA for ; Fri, 24 Oct 2003 00:01:28 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id 66C7C40FF35; Fri, 24 Oct 2003 00:01:29 -0800 (AKDT) Date: Fri, 24 Oct 2003 00:01:29 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: [PATCH] [PRELIMINARY] Add support for file flags to xfsdump #1 Message-ID: <20031024080129.GF3648@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20031020073151.GD3648@plato.local.lan> <20031024105919.5e22a10e.ivanr@sgi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/9ZOS6odDaRI+0hI" Content-Disposition: inline In-Reply-To: <20031024105919.5e22a10e.ivanr@sgi.com> User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-ACS-Spam-Status: no X-ACS-Scanned-By: MD 2.37; SA 2.60; spamdefang 1.58 X-archive-position: 796 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: erbenson@alaska.net Precedence: bulk X-list: linux-xfs Content-Length: 1988 Lines: 54 --/9ZOS6odDaRI+0hI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 24, 2003 at 10:59:19AM +1000, Ivan Rayner wrote: > On Sun, 19 Oct 2003 23:31:51 -0800, Ethan Benson wrote: >=20 > > Recently my patches to add file flags to XFS were merged (immutable, > > append-only etc). xfsdump has some problems with the new flags: > ... > > What I have done to fix the above problems in order: >=20 > Thanks for your work Ethan. Although I've not looked your code, it sounds > like you're doing the right sort of thing. hopefully, let me know when you get a chance to look at the code. > > * dump/inomap.c: Add warning when SGI_XFSDUMP_SKIP_FILE xattr is > > present, but still honor it, this attribute is deprecated in favor of > > the new nodump file flag, support for the obsolete xattr should be > > removed in a future xfsdump (its not that old so this shouldn't be > > much of a problem). Add check for new nodump file flag. >=20 > The SKIP_FILE attribute is still the supported mechanism in IRIX, > therefore it'd be a good idea to keep support for it in the Linux version. > It doesn't hurt performance, so I don't see any reason to remove it. well its very young, it was just added last year i think, maybe more recently then that (by request from linux users wanting chattr +d functionality). and the file attributes will probably end up getting merged into irix anyway. the inode flags are really a much cleaner way for this to work, which is why id rather see the xattr kludge go away. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --/9ZOS6odDaRI+0hI 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 iEYEARECAAYFAj+Y3FkACgkQJKx7GixEevzh7gCgi/CGuT8oSp/MIxBeE4ryyvqn E1cAmwQwq89qDzz5r7hT4rF+gaFepbmT =EKyg -----END PGP SIGNATURE----- --/9ZOS6odDaRI+0hI-- From owner-linux-xfs@oss.sgi.com Fri Oct 24 03:22:01 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 24 Oct 2003 03:22:41 -0700 (PDT) Received: from mail.dev.rtsoft.ru (RT-soft-2.Moscow.itn.ru [80.240.96.70]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9OALx25002370 for ; Fri, 24 Oct 2003 03:22:00 -0700 Received: (qmail 25341 invoked from network); 24 Oct 2003 10:13:38 -0000 Received: from maya.dev.rtsoft.ru (HELO dev.rtsoft.ru) (192.168.1.197) by mail.dev.rtsoft.ru with SMTP; 24 Oct 2003 10:13:38 -0000 Message-ID: <3F98FD53.9090407@dev.rtsoft.ru> Date: Fri, 24 Oct 2003 14:22:11 +0400 From: Roman Vasylyev User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: ru, en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: again xfstests - now test 076 Content-Type: multipart/mixed; boundary="------------020206090301040705050901" X-archive-position: 798 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: romis@dev.rtsoft.ru Precedence: bulk X-list: linux-xfs Content-Length: 19775 Lines: 443 This is a multi-part message in MIME format. --------------020206090301040705050901 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 10/13/2003 i wrote about 013 kernel warnings. After turning off debug option in XFS module kernel warnings gone. But 013 test sometimes is hangs on. And i find another test which users fsstress - 076(Test blockdev reads in parallel with file system reads/writes). But if 013 test is passed 076 always fails. In attached file result log. Can some who say is that critical for using XFS. ----------------- fsstress command line in 076 test ltp/fsstress -d /mnt/xfs0 -p 2 -n 2000 >>076.full ----------------- Now applied patches is linux-2.4.21-core-xfs-1.3.1.patch.gz and linux-xfs-1.3.1.patch.gz and xfs-cmds from morning CVS tree. --------------020206090301040705050901 Content-Type: text/plain; name="076.full" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="076.full" *** MKFS *** /sbin/mkfs.xfs -f -bsize=4096 /dev/hda9 meta-data=/dev/hda9 isize=256 agcount=8, agsize=16064 blks = sectsz=512 data = bsize=4096 blocks=128512, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=1200, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 mount -t xfs -ologbufs=2 /dev/hda9 /mnt/xfs0 seed = 1066446671 _check_fs: filesystem on /dev/hda9 is inconsistent *** xfs_check output *** bad magic number 0x3838 for inode 529280 bad magic number 0x3838 for inode 529281 bad magic number 0x3838 for inode 529282 bad magic number 0x3838 for inode 529283 bad magic number 0x3838 for inode 529284 bad magic number 0x3838 for inode 529285 bad magic number 0x3838 for inode 529286 bad magic number 0x3838 for inode 529287 bad magic number 0x3838 for inode 529288 bad magic number 0x3838 for inode 529289 bad magic number 0x3838 for inode 529290 bad magic number 0x3838 for inode 529291 bad magic number 0x3838 for inode 529292 bad magic number 0x3838 for inode 529293 bad magic number 0x3838 for inode 529294 bad magic number 0x3838 for inode 529295 bad magic number 0x3838 for inode 529296 bad magic number 0x3838 for inode 529297 bad magic number 0x3838 for inode 529298 bad magic number 0x3838 for inode 529299 bad magic number 0x3838 for inode 529300 bad magic number 0x3838 for inode 529301 bad magic number 0 for inode 529302 bad magic number 0 for inode 529303 bad magic number 0 for inode 529304 bad magic number 0 for inode 529305 bad magic number 0 for inode 529306 bad magic number 0 for inode 529307 bad magic number 0 for inode 529308 bad magic number 0 for inode 529309 bad magic number 0 for inode 529310 bad magic number 0 for inode 529311 *** end xfs_check output _check_fs: filesystem on /dev/hda9 is inconsistent *** xfs_repair -n output *** Phase 1 - find and verify superblock... Phase 2 - using internal log - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan (but don't clear) agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 found illegal null character in symlink inode 262287 problem with symbolic link in inode 262287 would have cleared inode 262287 - agno = 2 bad magic number 0x3838 on inode 529280 bad version number 0x38 on inode 529280 bad inode format in inode 529280 bad magic number 0x3838 on inode 529281 bad version number 0x38 on inode 529281 bad inode format in inode 529281 bad magic number 0x3838 on inode 529282 bad version number 0x38 on inode 529282 bad inode format in inode 529282 bad magic number 0x3838 on inode 529283 bad version number 0x38 on inode 529283 bad inode format in inode 529283 bad magic number 0x3838 on inode 529284 bad version number 0x38 on inode 529284 bad inode format in inode 529284 bad magic number 0x3838 on inode 529285 bad version number 0x38 on inode 529285 bad inode format in inode 529285 bad magic number 0x3838 on inode 529286 bad version number 0x38 on inode 529286 bad inode format in inode 529286 bad magic number 0x3838 on inode 529287 bad version number 0x38 on inode 529287 bad inode format in inode 529287 bad magic number 0x3838 on inode 529288 bad version number 0x38 on inode 529288 bad inode format in inode 529288 bad magic number 0x3838 on inode 529289 bad version number 0x38 on inode 529289 bad inode format in inode 529289 bad magic number 0x3838 on inode 529290 bad version number 0x38 on inode 529290 bad inode format in inode 529290 bad magic number 0x3838 on inode 529291 bad version number 0x38 on inode 529291 bad inode format in inode 529291 bad magic number 0x3838 on inode 529292 bad version number 0x38 on inode 529292 bad inode format in inode 529292 bad magic number 0x3838 on inode 529293 bad version number 0x38 on inode 529293 bad inode format in inode 529293 bad magic number 0x3838 on inode 529294 bad version number 0x38 on inode 529294 bad inode format in inode 529294 bad magic number 0x3838 on inode 529295 bad version number 0x38 on inode 529295 bad inode format in inode 529295 bad magic number 0x3838 on inode 529296 bad version number 0x38 on inode 529296 bad inode format in inode 529296 bad magic number 0x3838 on inode 529297 bad version number 0x38 on inode 529297 bad inode format in inode 529297 bad magic number 0x3838 on inode 529298 bad version number 0x38 on inode 529298 bad inode format in inode 529298 bad magic number 0x3838 on inode 529299 bad version number 0x38 on inode 529299 bad inode format in inode 529299 bad magic number 0x3838 on inode 529300 bad version number 0x38 on inode 529300 bad inode format in inode 529300 bad magic number 0x3838 on inode 529301 bad version number 0x38 on inode 529301 bad inode format in inode 529301 bad magic number 0x0 on inode 529302 bad version number 0x0 on inode 529302 bad magic number 0x0 on inode 529303 bad version number 0x0 on inode 529303 bad magic number 0x0 on inode 529304 bad version number 0x0 on inode 529304 bad magic number 0x0 on inode 529305 bad version number 0x0 on inode 529305 bad magic number 0x0 on inode 529306 bad version number 0x0 on inode 529306 bad magic number 0x0 on inode 529307 bad version number 0x0 on inode 529307 bad magic number 0x0 on inode 529308 bad version number 0x0 on inode 529308 bad magic number 0x0 on inode 529309 bad version number 0x0 on inode 529309 bad magic number 0x0 on inode 529310 bad version number 0x0 on inode 529310 bad magic number 0x0 on inode 529311 bad version number 0x0 on inode 529311 bad magic number 0x3838 on inode 529280, would reset magic number bad version number 0x38 on inode 529280, would reset version number bad inode format in inode 529280 would have cleared inode 529280 bad magic number 0x3838 on inode 529281, would reset magic number bad version number 0x38 on inode 529281, would reset version number bad inode format in inode 529281 would have cleared inode 529281 bad magic number 0x3838 on inode 529282, would reset magic number bad version number 0x38 on inode 529282, would reset version number bad inode format in inode 529282 would have cleared inode 529282 bad magic number 0x3838 on inode 529283, would reset magic number bad version number 0x38 on inode 529283, would reset version number bad inode format in inode 529283 would have cleared inode 529283 bad magic number 0x3838 on inode 529284, would reset magic number bad version number 0x38 on inode 529284, would reset version number bad inode format in inode 529284 would have cleared inode 529284 bad magic number 0x3838 on inode 529285, would reset magic number bad version number 0x38 on inode 529285, would reset version number bad inode format in inode 529285 would have cleared inode 529285 bad magic number 0x3838 on inode 529286, would reset magic number bad version number 0x38 on inode 529286, would reset version number bad inode format in inode 529286 would have cleared inode 529286 bad magic number 0x3838 on inode 529287, would reset magic number bad version number 0x38 on inode 529287, would reset version number bad inode format in inode 529287 would have cleared inode 529287 bad magic number 0x3838 on inode 529288, would reset magic number bad version number 0x38 on inode 529288, would reset version number bad inode format in inode 529288 would have cleared inode 529288 bad magic number 0x3838 on inode 529289, would reset magic number bad version number 0x38 on inode 529289, would reset version number bad inode format in inode 529289 would have cleared inode 529289 bad magic number 0x3838 on inode 529290, would reset magic number bad version number 0x38 on inode 529290, would reset version number bad inode format in inode 529290 would have cleared inode 529290 bad magic number 0x3838 on inode 529291, would reset magic number bad version number 0x38 on inode 529291, would reset version number bad inode format in inode 529291 would have cleared inode 529291 bad magic number 0x3838 on inode 529292, would reset magic number bad version number 0x38 on inode 529292, would reset version number bad inode format in inode 529292 would have cleared inode 529292 bad magic number 0x3838 on inode 529293, would reset magic number bad version number 0x38 on inode 529293, would reset version number bad inode format in inode 529293 would have cleared inode 529293 bad magic number 0x3838 on inode 529294, would reset magic number bad version number 0x38 on inode 529294, would reset version number bad inode format in inode 529294 would have cleared inode 529294 bad magic number 0x3838 on inode 529295, would reset magic number bad version number 0x38 on inode 529295, would reset version number bad inode format in inode 529295 would have cleared inode 529295 bad magic number 0x3838 on inode 529296, would reset magic number bad version number 0x38 on inode 529296, would reset version number bad inode format in inode 529296 would have cleared inode 529296 bad magic number 0x3838 on inode 529297, would reset magic number bad version number 0x38 on inode 529297, would reset version number bad inode format in inode 529297 would have cleared inode 529297 bad magic number 0x3838 on inode 529298, would reset magic number bad version number 0x38 on inode 529298, would reset version number bad inode format in inode 529298 would have cleared inode 529298 bad magic number 0x3838 on inode 529299, would reset magic number bad version number 0x38 on inode 529299, would reset version number bad inode format in inode 529299 would have cleared inode 529299 bad magic number 0x3838 on inode 529300, would reset magic number bad version number 0x38 on inode 529300, would reset version number bad inode format in inode 529300 would have cleared inode 529300 bad magic number 0x3838 on inode 529301, would reset magic number bad version number 0x38 on inode 529301, would reset version number bad inode format in inode 529301 would have cleared inode 529301 bad magic number 0x0 on inode 529302, would reset magic number bad version number 0x0 on inode 529302, would reset version number bad magic number 0x0 on inode 529303, would reset magic number bad version number 0x0 on inode 529303, would reset version number bad magic number 0x0 on inode 529304, would reset magic number bad version number 0x0 on inode 529304, would reset version number bad magic number 0x0 on inode 529305, would reset magic number bad version number 0x0 on inode 529305, would reset version number bad magic number 0x0 on inode 529306, would reset magic number bad version number 0x0 on inode 529306, would reset version number bad magic number 0x0 on inode 529307, would reset magic number bad version number 0x0 on inode 529307, would reset version number bad magic number 0x0 on inode 529308, would reset magic number bad version number 0x0 on inode 529308, would reset version number bad magic number 0x0 on inode 529309, would reset magic number bad version number 0x0 on inode 529309, would reset version number bad magic number 0x0 on inode 529310, would reset magic number bad version number 0x0 on inode 529310, would reset version number bad magic number 0x0 on inode 529311, would reset magic number bad version number 0x0 on inode 529311, would reset version number - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 entry "lb5" in shortform directory 262285 references free inode 262287 would have junked entry "lb5" in directory inode 262285 found illegal null character in symlink inode 262287 problem with symbolic link in inode 262287 would have cleared inode 262287 - agno = 2 bad magic number 0x3838 on inode 529280, would reset magic number bad version number 0x38 on inode 529280, would reset version number bad inode format in inode 529280 would have cleared inode 529280 bad magic number 0x3838 on inode 529281, would reset magic number bad version number 0x38 on inode 529281, would reset version number bad inode format in inode 529281 would have cleared inode 529281 bad magic number 0x3838 on inode 529282, would reset magic number bad version number 0x38 on inode 529282, would reset version number bad inode format in inode 529282 would have cleared inode 529282 bad magic number 0x3838 on inode 529283, would reset magic number bad version number 0x38 on inode 529283, would reset version number bad inode format in inode 529283 would have cleared inode 529283 bad magic number 0x3838 on inode 529284, would reset magic number bad version number 0x38 on inode 529284, would reset version number bad inode format in inode 529284 would have cleared inode 529284 bad magic number 0x3838 on inode 529285, would reset magic number bad version number 0x38 on inode 529285, would reset version number bad inode format in inode 529285 would have cleared inode 529285 bad magic number 0x3838 on inode 529286, would reset magic number bad version number 0x38 on inode 529286, would reset version number bad inode format in inode 529286 would have cleared inode 529286 bad magic number 0x3838 on inode 529287, would reset magic number bad version number 0x38 on inode 529287, would reset version number bad inode format in inode 529287 would have cleared inode 529287 bad magic number 0x3838 on inode 529288, would reset magic number bad version number 0x38 on inode 529288, would reset version number bad inode format in inode 529288 would have cleared inode 529288 bad magic number 0x3838 on inode 529289, would reset magic number bad version number 0x38 on inode 529289, would reset version number bad inode format in inode 529289 would have cleared inode 529289 bad magic number 0x3838 on inode 529290, would reset magic number bad version number 0x38 on inode 529290, would reset version number bad inode format in inode 529290 would have cleared inode 529290 bad magic number 0x3838 on inode 529291, would reset magic number bad version number 0x38 on inode 529291, would reset version number bad inode format in inode 529291 would have cleared inode 529291 bad magic number 0x3838 on inode 529292, would reset magic number bad version number 0x38 on inode 529292, would reset version number bad inode format in inode 529292 would have cleared inode 529292 bad magic number 0x3838 on inode 529293, would reset magic number bad version number 0x38 on inode 529293, would reset version number bad inode format in inode 529293 would have cleared inode 529293 bad magic number 0x3838 on inode 529294, would reset magic number bad version number 0x38 on inode 529294, would reset version number bad inode format in inode 529294 would have cleared inode 529294 bad magic number 0x3838 on inode 529295, would reset magic number bad version number 0x38 on inode 529295, would reset version number bad inode format in inode 529295 would have cleared inode 529295 bad magic number 0x3838 on inode 529296, would reset magic number bad version number 0x38 on inode 529296, would reset version number bad inode format in inode 529296 would have cleared inode 529296 bad magic number 0x3838 on inode 529297, would reset magic number bad version number 0x38 on inode 529297, would reset version number bad inode format in inode 529297 would have cleared inode 529297 bad magic number 0x3838 on inode 529298, would reset magic number bad version number 0x38 on inode 529298, would reset version number bad inode format in inode 529298 would have cleared inode 529298 bad magic number 0x3838 on inode 529299, would reset magic number bad version number 0x38 on inode 529299, would reset version number bad inode format in inode 529299 would have cleared inode 529299 bad magic number 0x3838 on inode 529300, would reset magic number bad version number 0x38 on inode 529300, would reset version number bad inode format in inode 529300 would have cleared inode 529300 bad magic number 0x3838 on inode 529301, would reset magic number bad version number 0x38 on inode 529301, would reset version number bad inode format in inode 529301 would have cleared inode 529301 bad magic number 0x0 on inode 529302, would reset magic number bad version number 0x0 on inode 529302, would reset version number bad magic number 0x0 on inode 529303, would reset magic number bad version number 0x0 on inode 529303, would reset version number bad magic number 0x0 on inode 529304, would reset magic number bad version number 0x0 on inode 529304, would reset version number bad magic number 0x0 on inode 529305, would reset magic number bad version number 0x0 on inode 529305, would reset version number bad magic number 0x0 on inode 529306, would reset magic number bad version number 0x0 on inode 529306, would reset version number bad magic number 0x0 on inode 529307, would reset magic number bad version number 0x0 on inode 529307, would reset version number bad magic number 0x0 on inode 529308, would reset magic number bad version number 0x0 on inode 529308, would reset version number bad magic number 0x0 on inode 529309, would reset magic number bad version number 0x0 on inode 529309, would reset version number bad magic number 0x0 on inode 529310, would reset magic number bad version number 0x0 on inode 529310, would reset version number bad magic number 0x0 on inode 529311, would reset magic number bad version number 0x0 on inode 529311, would reset version number - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem starting at / ... entry "lb5" in shortform directory inode 262285 points to free inode 262287 would junk entry "lb5" - traversal finished ... - traversing all unattached subtrees ... - traversals finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify link counts... No modify flag set, skipping filesystem flush and exiting. *** end xfs_repair output *** mount output *** /dev/hda7 on / type ext3 (rw) none on /proc type proc (rw) usbdevfs on /proc/bus/usb type usbdevfs (rw) none on /dev/pts type devpts (rw,gid=5,mode=620) none on /dev/shm type tmpfs (rw) /dev/hda1 on /mnt/c: type ntfs (rw,iocharset=utf8) /dev/hda5 on /mnt/d: type vfat (rw,iocharset=utf8) /dev/hda8 on /mnt/xfs1 type xfs (rw,logbufs=2,logbufs=2) *** end mount output --------------020206090301040705050901-- From owner-linux-xfs@oss.sgi.com Fri Oct 24 05:11:11 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 24 Oct 2003 05:11:44 -0700 (PDT) Received: from moving-picture.com (mpc-26.sohonet.co.uk [193.203.82.251]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9OCB825007651 for ; Fri, 24 Oct 2003 05:11:11 -0700 Received: from darke.mpc.local ([172.16.11.6] helo=moving-picture.com) by moving-picture.com with esmtp (Exim 4.24) id 1ACyBn-0005FH-Oy; Fri, 24 Oct 2003 10:24:59 +0100 Message-ID: <3F98EFEB.2615FA1C@moving-picture.com> Date: Fri, 24 Oct 2003 10:24:59 +0100 From: James Pearson Organization: Moving Picture Company X-Mailer: Mozilla 4.7 [en] (X11; I; IRIX64 6.5 IP30) X-Accept-Language: en MIME-Version: 1.0 To: Michael Sinz , "linux-xfs@oss.sgi.com" Subject: Re: Interesting problem with XFS and NFS... (or just NFS?) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Disclaimer: This email and any attachments are confidential, may be legally X-Disclaimer: privileged and intended solely for the use of addressee. If you X-Disclaimer: are not the intended recipient of this message, any disclosure, X-Disclaimer: copying, distribution or any action taken in reliance on it is X-Disclaimer: strictly prohibited and may be unlawful. If you have received X-Disclaimer: this message in error, please notify the sender and delete all X-Disclaimer: copies from your system. X-Disclaimer: X-Disclaimer: Email may be susceptible to data corruption, interception and X-Disclaimer: unauthorised amendment, and we do not accept liability for any X-Disclaimer: such corruption, interception or amendment or the consequences X-Disclaimer: thereof. X-archive-position: 799 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: james-p@moving-picture.com Precedence: bulk X-list: linux-xfs Content-Length: 397 Lines: 12 Michael Sinz wrote: > I have a bunch of files I wanted to make available on a read-only NFS > mount that currently live in a directory under my home directory. > > It turns out that the NFS mount is on the same device (it is in /home/nfs) > as my home directory (/home/mks) Sounds like an NFS issue - try exporting the filesystems/directories with the 'no_subtree_check' option. James Pearson From owner-linux-xfs@oss.sgi.com Fri Oct 24 11:43:47 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 24 Oct 2003 11:44:32 -0700 (PDT) Received: from louise.pinerecords.com (louise.pinerecords.com [213.168.176.16]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9OIhi25016456 for ; Fri, 24 Oct 2003 11:43:46 -0700 Received: from louise.pinerecords.com (localhost [127.0.0.1]) by louise.pinerecords.com with ESMTP id h9OIhgTD013822 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Oct 2003 20:43:42 +0200 Received: (from kala@localhost) by louise.pinerecords.com (submit) id h9OIhgR5013821; Fri, 24 Oct 2003 20:43:42 +0200 Date: Fri, 24 Oct 2003 20:43:42 +0200 From: Tomas Szepe To: Jirka Kosina Cc: Nathan Scott , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: 2.6.0-test8 XFS bug Message-ID: <20031024184342.GA13378@louise.pinerecords.com> References: <20031024000951.GH858@frodo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-archive-position: 800 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: szepe@pinerecords.com Precedence: bulk X-list: linux-xfs Content-Length: 369 Lines: 12 On Oct-24 2003, Fri, 09:03 +0200 Jirka Kosina wrote: > I can simply reproduce it - the only thing needed is to nfsmount this > partition from clients and start writing a file to it, as I've written > before. The crash occurs immediately after the transfer begins. Do the crashes still occur after a re-mkfs? -- Tomas Szepe From owner-linux-xfs@oss.sgi.com Fri Oct 24 21:29:07 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 24 Oct 2003 21:29:47 -0700 (PDT) Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9P4T625031727 for ; Fri, 24 Oct 2003 21:29:06 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id h9P4Swq0012224 for ; Fri, 24 Oct 2003 21:29:00 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA06890; Sat, 25 Oct 2003 14:28:45 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h9P4ShUc842945; Sat, 25 Oct 2003 14:28:43 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h9P4Sff0842698; Sat, 25 Oct 2003 14:28:41 +1000 (EST) Date: Sat, 25 Oct 2003 14:28:41 +1000 From: Nathan Scott To: Jirka Kosina Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: 2.6.0-test8 XFS bug Message-ID: <20031025142841.A833021@wobbly.melbourne.sgi.com> References: <20031024000951.GH858@frodo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jikos@jikos.cz on Fri, Oct 24, 2003 at 09:03:01AM +0200 X-archive-position: 801 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1428 Lines: 32 On Fri, Oct 24, 2003 at 09:03:01AM +0200, Jirka Kosina wrote: > On Fri, 24 Oct 2003, Nathan Scott wrote: > > > Oct 22 13:12:56 storage2 kernel: Filesystem "dm-0": XFS internal error xfs_alloc_read_agf at line 2208 of file fs/xfs/xfs_alloc.c. Caller 0xc01e8f5c > > You're allocating real disk space for delayed allocate file data > > down this path, and the read of the allocation group header found > > something that didn't look at all like metadata on disk. > > So, you definately have corruption and will need to xfs_repair. > > Any ideas as to what operations triggered the initial problem? > > (is it reproducible for you?) > > I can simply reproduce it - the only thing needed is to nfsmount this > partition from clients and start writing a file to it, as I've written > before. The crash occurs immediately after the transfer begins. OK, I missed that information in your last mail then, I thought you had done successful NFS tests and then failed on a local cp. Looks like we need to focus on more XFS/NFS testing in 2.6; will do. > As I've said, I wouldn't blame HW failure or things like this, because > ext3 does the job flawlessly, as far as I can see. Understood -- its good to have it narrowed down to XFS. Was that ext3 test on the same DM device, also at 5.5 Tb with LBD, and NFS involved too? Could you send me your xfs_repair output and also your filesystem geometry (xfs_info). thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Fri Oct 24 21:38:18 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 24 Oct 2003 21:38:52 -0700 (PDT) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9P4cH25032151 for ; Fri, 24 Oct 2003 21:38:17 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id h9P2gxOO006060 for ; Fri, 24 Oct 2003 19:43:00 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA06957; Sat, 25 Oct 2003 14:38:01 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h9P4c0Uc842315; Sat, 25 Oct 2003 14:38:00 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h9P4bxQ7841137; Sat, 25 Oct 2003 14:37:59 +1000 (EST) Date: Sat, 25 Oct 2003 14:37:59 +1000 From: Nathan Scott To: Roman Vasylyev Cc: linux-xfs@oss.sgi.com Subject: Re: again xfstests - now test 076 Message-ID: <20031025143759.B833021@wobbly.melbourne.sgi.com> References: <3F98FD53.9090407@dev.rtsoft.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3F98FD53.9090407@dev.rtsoft.ru>; from romis@dev.rtsoft.ru on Fri, Oct 24, 2003 at 02:22:11PM +0400 X-archive-position: 802 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1101 Lines: 26 On Fri, Oct 24, 2003 at 02:22:11PM +0400, Roman Vasylyev wrote: > 10/13/2003 i wrote about 013 kernel warnings. > After turning off debug option in XFS module kernel warnings gone. But > 013 test sometimes is hangs on. And i find another test which users > fsstress - 076(Test blockdev reads in parallel with file system > reads/writes). > But if 013 test is passed 076 always fails. In attached file result log. > Can some who say is that critical for using XFS. Yes, 076 is a known issue (hence its not in "auto" group - see the -g option to the check script). I have a bunch of pagebuf locking changes which address this issue for small block size filesystems, but afaik its OK with page-sized block sizes... what architecture are you testing here? (what is your page size?). It is a good idea to enable kdb (and debug) while running the tests, when you see the 013 hang again I would be interested in seeing your kdb trace. You do have a relatively small device for you're testing, so you may be hitting the out-of-space hangs some other people have seen recently.. thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Sat Oct 25 04:35:01 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 25 Oct 2003 04:35:41 -0700 (PDT) Received: from server418.dnslive.net (server418.dnslive.net [216.74.126.5]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9PBZ025010169 for ; Sat, 25 Oct 2003 04:35:00 -0700 Received: from [24.229.125.7] (helo=thinker) by server418.dnslive.net with smtp (Exim 4.24) id 1AD1WT-0007eV-Pa; Fri, 24 Oct 2003 08:58:34 -0400 From: "Michael Sinz" To: "James Pearson" , "linux-xfs@oss.sgi.com" Date: Fri, 24 Oct 2003 08:56:21 -0400 Reply-To: "Michael Sinz" Priority: Normal X-Mailer: sinz.org In-Reply-To: <3F98EFEB.2615FA1C@moving-picture.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: Re: Interesting problem with XFS and NFS... (or just NFS?) Message-Id: X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server418.dnslive.net X-AntiAbuse: Original Domain - oss.sgi.com X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - sinz.org X-archive-position: 803 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Linux@sinz.org Precedence: bulk X-list: linux-xfs Content-Length: 933 Lines: 24 On Fri, 24 Oct 2003 10:24:59 +0100, James Pearson wrote: >Michael Sinz wrote: >> I have a bunch of files I wanted to make available on a read-only NFS >> mount that currently live in a directory under my home directory. >> >> It turns out that the NFS mount is on the same device (it is in /home/nfs) >> as my home directory (/home/mks) > >Sounds like an NFS issue - try exporting the filesystems/directories >with the 'no_subtree_check' option. You are correct - that is what is happening in NFS - too bad this induces other potential problems (albeit, with the current setup, it does not matter since the exported tree is read-only and minimally changing) The question would be - how would one do this check such that it does not sometimes fail in the hard-link case? And, I think you are correct in saying that it is not specificaly an XFS issue. -- Michael Sinz - http://www.sinz.org/Michael.Sinz/Linux - Linux@sinz.org From owner-linux-xfs@oss.sgi.com Sat Oct 25 11:35:28 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 25 Oct 2003 11:36:03 -0700 (PDT) Received: from ying.yingternet.com (n105.priced2go.net [208.179.93.105]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9PIZ825017650 for ; Sat, 25 Oct 2003 11:35:28 -0700 Received: from gateway-att.yingternet.com (c-24-126-235-193.we.client2.attbi.com [24.126.235.193]) by ying.yingternet.com (Postfix) with ESMTP id 09781300084; Sat, 25 Oct 2003 11:35:17 -0700 (PDT) Received: from kenshin.yingternet.org (kenshin.yingternet.com [192.168.10.10]) by gateway-att.yingternet.com (Postfix) with ESMTP id 667E88152F; Sat, 25 Oct 2003 11:19:58 -0700 (PDT) Received: from yingternet.com (kyoka.yingternet.org [192.168.10.11]) by kenshin.yingternet.org (Postfix) with ESMTP id AF2382007B6; Sat, 25 Oct 2003 11:40:45 -0700 (PDT) Message-ID: <3F9AC303.1040106@yingternet.com> Date: Sat, 25 Oct 2003 11:37:55 -0700 From: Ying-Hung Chen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031017 X-Accept-Language: en, zh-tw MIME-Version: 1.0 To: Nathan Scott Cc: linux-xfs@oss.sgi.com Subject: Re: xfs quota does not work with encrypted loop filesystem References: <3F916F45.8090801@yingternet.com> <20031020003520.GA1042@frodo> <3F933A90.80809@yingternet.com> <20031020015523.GA1560@frodo> <3F934AA5.1040501@yingternet.com> <20031020025830.GB1560@frodo> In-Reply-To: <20031020025830.GB1560@frodo> X-Enigmail-Version: 0.76.7.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 804 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ying@yingternet.com Precedence: bulk X-list: linux-xfs Content-Length: 197 Lines: 12 Hi, the problem is on the quota package, please see the following link for details. http://sourceforge.net/tracker/index.php?func=detail&atid=394667&aid=828570&group_id=28891 Thanks, -Ying From owner-linux-xfs@oss.sgi.com Sat Oct 25 21:13:41 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 25 Oct 2003 21:14:25 -0700 (PDT) Received: from smtp1.iitb.ac.in (garbo-vsnl1.iitb.ac.in [203.197.74.149]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9Q4Dd25000338 for ; Sat, 25 Oct 2003 21:13:40 -0700 Received: (qmail 32489 invoked by uid 505); 26 Oct 2003 04:13:32 -0000 Received: from soumen@cse.iitb.ac.in by smtp1.iitb.ac.in by uid 502 with qmail-scanner-1.16 (clamscan: 0.54. spamassassin: 2.54. Clear:. Processed in 0.199265 secs); 26 Oct 2003 04:13:32 -0000 Received: from unknown (HELO jeeves.cse.iitb.ac.in) (10.105.1.1) by smtp1.iitb.ac.in with SMTP; 26 Oct 2003 04:13:32 -0000 Received: from surya.cse.iitb.ac.in (surya.cse.iitb.ac.in [10.105.1.14]) by jeeves.cse.iitb.ac.in (8.11.0/8.11.0) with ESMTP id h9Q4DWB19491; Sun, 26 Oct 2003 09:43:32 +0530 Received: from localhost (soumen@localhost) by surya.cse.iitb.ac.in (8.8.8/8.8.8) with ESMTP id JAA17005; Sun, 26 Oct 2003 09:43:33 +0530 (IST) Date: Sun, 26 Oct 2003 09:43:33 +0530 (IST) From: Soumen Chakrabarti To: linux-xfs@oss.sgi.com Subject: Linux 2.4.22 XFS 1.3.1 reservation ran out Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 805 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: soumen@cse.iitb.ac.in Precedence: bulk X-list: linux-xfs Content-Length: 1655 Lines: 39 Repeatable bug, here's how to create the situation: 1. Start with a fresh install of stock RedHat 9. 2. Download kernel 2.4.22. 3. Patch in XFS 1.3.1 and build new kernel. 4. Create an XFS file system and mount it on (say) /mnt/xfs. 5. Download and build bonnie++-1.03a 6. Run bonnie++ with these flags bonnie++ -d /mnt/xfs -u 0:0 -s 0 -n 16 Everything goes fine. This is a test that creates, stats, and deletes 16*1024 empty files. 7. Now up the number of files to 500*1024 bonnie++ -d /mnt/xfs -u 0:0 -s 0 -n 500 Here are the syslog entries. Filesystem "sd(8,17)": xfs_log_write: reservation ran out. Need to up reservation xfs_force_shutdown(sd(8,17),0x8) called from line 1739 of file xfs_log.c. Return address = 0xc01f4cdb Filesystem "sd(8,17)": Corruption of in-memory data detected. Shutting down filesystem: sd(8,17) Please umount the filesystem, and rectify the problem(s) xfs_force_shutdown(sd(8,17),0x2) called from line 747 of file xfs_log.c. Return address = 0xc01f4cdb 8. You can however recover and mount again: umount /mnt/xfs mount /dev/sdb1 /mnt/xfs XFS mounting filesystem sd(8,17) Starting XFS recovery on filesystem: sd(8,17) (dev: 8/17) Ending XFS recovery on filesystem: sd(8,17) (dev: 8/17) Other info: Not specific to hardware, has been reproduced on two different servers, one with SCSI, the other with SCSI RAID. On these same servers, 9. IBM JFS with this bonnie++ benchmark requires a hard reset. 10. Reiserfs survives repeated bonnie++ tests as above. Also, on a third server we have XFS 1.2.0 which works fine too. So XFS 1.3.1 seems heavily implicated. Thanks for any patches and/or fixes. From owner-linux-xfs@oss.sgi.com Sun Oct 26 00:30:17 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 26 Oct 2003 00:31:02 -0700 (PDT) Received: from heretic.physik.fu-berlin.de (root@heretic.physik.fu-berlin.de [160.45.32.86]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9Q7UF25004957 for ; Sun, 26 Oct 2003 00:30:16 -0700 Received: from puariko.homeip.net (pD9E7FB6A.dip.t-dialin.net [217.231.251.106]) by heretic.physik.fu-berlin.de (8.12.8/8.12.8) with ESMTP id h9Q7U3Fd019993 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 26 Oct 2003 08:30:09 +0100 Received: (from thimm@localhost) by puariko.nirvana (8.12.10/8.12.8/Submit) id h9Q7TvoV014942; Sun, 26 Oct 2003 08:29:57 +0100 Date: Sun, 26 Oct 2003 08:29:57 +0100 From: Axel Thimm To: Soumen Chakrabarti Cc: linux-xfs@oss.sgi.com Subject: Re: Linux 2.4.22 XFS 1.3.1 reservation ran out Message-ID: <20031026072957.GE14319@puariko.nirvana> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="R6sEYoIZpp9JErk7" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-archive-position: 806 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Axel.Thimm@physik.fu-berlin.de Precedence: bulk X-list: linux-xfs Content-Length: 2493 Lines: 75 --R6sEYoIZpp9JErk7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Oct 26, 2003 at 09:43:33AM +0530, Soumen Chakrabarti wrote: > Repeatable bug, here's how to create the situation: > 1. Start with a fresh install of stock RedHat 9. > 2. Download kernel 2.4.22. > 3. Patch in XFS 1.3.1 and build new kernel. Would you like retrying with a rawhide 2.4.22 kernel and XFS 1.3.0? http://atrpms.physik.fu-berlin.de/name/kernel-bleeding/ http://atrpms.physik.fu-berlin.de/name/xfs/ Thanks. > 4. Create an XFS file system and mount it on (say) /mnt/xfs. > 5. Download and build bonnie++-1.03a > 6. Run bonnie++ with these flags > bonnie++ -d /mnt/xfs -u 0:0 -s 0 -n 16 > Everything goes fine. This is a test that creates, stats, and > deletes 16*1024 empty files. > 7. Now up the number of files to 500*1024 > bonnie++ -d /mnt/xfs -u 0:0 -s 0 -n 500 > Here are the syslog entries. >=20 > Filesystem "sd(8,17)": xfs_log_write: reservation ran out. Need to up res= ervation > xfs_force_shutdown(sd(8,17),0x8) called from line 1739 of file xfs_log.c.= Return address =3D 0xc01f4cdb > Filesystem "sd(8,17)": Corruption of in-memory data detected. Shutting d= own filesystem: sd(8,17) > Please umount the filesystem, and rectify the problem(s) > xfs_force_shutdown(sd(8,17),0x2) called from line 747 of file xfs_log.c. = Return address =3D 0xc01f4cdb >=20 > 8. You can however recover and mount again: > umount /mnt/xfs > mount /dev/sdb1 /mnt/xfs >=20 > XFS mounting filesystem sd(8,17) > Starting XFS recovery on filesystem: sd(8,17) (dev: 8/17) > Ending XFS recovery on filesystem: sd(8,17) (dev: 8/17) >=20 > Other info: Not specific to hardware, has been reproduced on two > different servers, one with SCSI, the other with SCSI RAID. >=20 > On these same servers, > 9. IBM JFS with this bonnie++ benchmark requires a hard reset. > 10. Reiserfs survives repeated bonnie++ tests as above. > Also, on a third server we have XFS 1.2.0 which works fine too. >=20 > So XFS 1.3.1 seems heavily implicated. > Thanks for any patches and/or fixes. >=20 --=20 Axel.Thimm@physik.fu-berlin.de --R6sEYoIZpp9JErk7 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/m3f1QBVS1GOamfERAk0/AJwIyU14o78H13+4CrnR3oVY16OhGACbBgqf r33+FQcpOKaKaTMEv0ABmu4= =t735 -----END PGP SIGNATURE----- --R6sEYoIZpp9JErk7-- From owner-linux-xfs@oss.sgi.com Sun Oct 26 06:40:06 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 26 Oct 2003 06:40:46 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9QEe425021127 for ; Sun, 26 Oct 2003 06:40:04 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h9QEdwq0002949 for ; Sun, 26 Oct 2003 06:39:58 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h9QEdtP512488652; Sun, 26 Oct 2003 08:39:55 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h9QEdpK24268703; Sun, 26 Oct 2003 08:39:51 -0600 (CST) Date: Sun, 26 Oct 2003 08:39:50 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Soumen Chakrabarti cc: linux-xfs@oss.sgi.com Subject: Re: Linux 2.4.22 XFS 1.3.1 reservation ran out In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 808 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 506 Lines: 20 On Sun, 26 Oct 2003, Soumen Chakrabarti wrote: > Repeatable bug, here's how to create the situation: > 1. Start with a fresh install of stock RedHat 9. > 2. Download kernel 2.4.22. > 3. Patch in XFS 1.3.1 and build new kernel. > 4. Create an XFS file system and mount it on (say) /mnt/xfs. We'll try to reproduce this here, but could you provide the following additional information? xfs_info output from "xfs_info /mnt/xfs" after it's mounted. The XFS portion of your kernel .config Thanks! -Eric From owner-linux-xfs@oss.sgi.com Sun Oct 26 07:58:45 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 26 Oct 2003 07:59:24 -0800 (PST) Received: from mail.epost.de (mail.epost.de [193.28.100.164] (may be forged)) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9QFwh25032263 for ; Sun, 26 Oct 2003 07:58:45 -0800 Received: from epost.de (217.110.232.6) by mail.epost.de (6.7.015) (authenticated as rainer.traut@epost.de) id 3F9967D20002C1FA; Sun, 26 Oct 2003 11:45:17 +0100 Message-ID: <3F9BA5BD.3040704@epost.de> Date: Sun, 26 Oct 2003 11:45:17 +0100 From: Rainer Traut User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Russell Cattelan CC: linux-xfs@oss.sgi.com Subject: Re: Testing the list References: <1063677421.66911.14.camel@lupo.thebarn.com> In-Reply-To: <1063677421.66911.14.camel@lupo.thebarn.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 809 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: rainer.traut@epost.de Precedence: bulk X-list: linux-xfs Content-Length: 744 Lines: 25 Hi, it seems, I'm having difficulties posting to the list. I had sent one mail on friday, but it has not showed up somewhere. The same happened to the last message I tried to send. It showed up on the list after one week?! Gruss Rainer Russell Cattelan wrote: > I appears a lot of people got unsubscribed from > the list when their mail servers rejected the SoBig F > virus (as well they should). > The list software unsub's email address with > to many failures and all the virus rejects were > viewed as delivery failures. > > Anyways I added all the address back in that were > removed on Sept 5 so if the list seem quiet over > the last week or so check the archive for any missed > posts. > http://oss.sgi.com/projects/xfs/ml.html From owner-linux-xfs@oss.sgi.com Sun Oct 26 15:23:27 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 26 Oct 2003 15:24:08 -0800 (PST) Received: from rrzd2.rz.uni-regensburg.de (rrzd2.rz.uni-regensburg.de [132.199.1.12]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9QNNQ25009604 for ; Sun, 26 Oct 2003 15:23:27 -0800 Received: from rrzd2 (rrzd2 [127.0.0.1]) by rrzd2.rz.uni-regensburg.de (8.12.3/8.12.3/Debian -4) with ESMTP id h9QNNMmL015748 for ; Mon, 27 Oct 2003 00:23:22 +0100 Received: from rss1.rz.uni-regensburg.de ([132.199.1.200]) by rrzd2 (MailMonitor for SMTP v1.2.2 ) ; Mon, 27 Oct 2003 00:23:22 +0100 (CET) Received: (qmail 6877 invoked from network); 27 Oct 2003 00:23:21 +0100 Received: from rx3227.cip.uni-regensburg.de (132.199.237.32) by rss1.rz.uni-regensburg.de with SMTP; 27 Oct 2003 00:23:21 +0100 Subject: Re: Linux 2.4.22 XFS 1.3.1 reservation ran out From: Christian Guggenberger Reply-To: christian.guggenberger@physik.uni-regensburg.de To: Soumen Chakrabarti Cc: linux-xfs@oss.sgi.com, Eric Sandeen , Axel Thimm In-Reply-To: References: Content-Type: text/plain Message-Id: <1067210601.717.6.camel@bonnie79> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Mon, 27 Oct 2003 00:23:21 +0100 Content-Transfer-Encoding: 7bit X-archive-position: 810 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: christian.guggenberger@physik.uni-regensburg.de Precedence: bulk X-list: linux-xfs Content-Length: 1995 Lines: 44 On Sun, 2003-10-26 at 05:13, Soumen Chakrabarti wrote: > Repeatable bug, here's how to create the situation: > 1. Start with a fresh install of stock RedHat 9. > 2. Download kernel 2.4.22. > 3. Patch in XFS 1.3.1 and build new kernel. > 4. Create an XFS file system and mount it on (say) /mnt/xfs. > 5. Download and build bonnie++-1.03a > 6. Run bonnie++ with these flags > bonnie++ -d /mnt/xfs -u 0:0 -s 0 -n 16 > Everything goes fine. This is a test that creates, stats, and > deletes 16*1024 empty files. > 7. Now up the number of files to 500*1024 > bonnie++ -d /mnt/xfs -u 0:0 -s 0 -n 500 > Here are the syslog entries. > > Filesystem "sd(8,17)": xfs_log_write: reservation ran out. Need to up reservation > xfs_force_shutdown(sd(8,17),0x8) called from line 1739 of file xfs_log.c. Return address = 0xc01f4cdb > Filesystem "sd(8,17)": Corruption of in-memory data detected. Shutting down filesystem: sd(8,17) > Please umount the filesystem, and rectify the problem(s) > xfs_force_shutdown(sd(8,17),0x2) called from line 747 of file xfs_log.c. Return address = 0xc01f4cdb I also can verify this forced shutdown here on a debian/woody box (PIII, IDE) with XFS CVS of 20031015. After umount/mount, the forced shutdown occures again, if I try to delete the directory created by bonnie++. An xfs_repair after umount/mount/umount fixes this. However, with plain 2.4.21 + xfs-1.3.1 the bonnie++-tests complete without any errors. output of xfs_info: meta-data=/mnt/testxfs isize=256 agcount=11, agsize=262144 blks = sectsz=512 data = bsize=4096 blocks=2725017, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=1200, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 Christian From owner-linux-xfs@oss.sgi.com Sun Oct 26 16:06:34 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 26 Oct 2003 16:07:12 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9R06Y25010983 for ; Sun, 26 Oct 2003 16:06:34 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h9QMBOOO006395 for ; Sun, 26 Oct 2003 14:11:24 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h9R06Qjj4317221 for ; Mon, 27 Oct 2003 11:06:26 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h9R06QCj4307564 for linux-xfs@oss.sgi.com; Mon, 27 Oct 2003 11:06:26 +1100 (EST) Date: Mon, 27 Oct 2003 11:06:26 +1100 (EST) From: Nathan Scott Message-Id: <200310270006.h9R06QCj4307564@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - 2.6.0-test9 X-archive-position: 811 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 8268 Lines: 229 Merge up to 2.6.0-test9. Date: Sun Oct 26 16:03:34 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/clean-2.5.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:160615a linux/drivers/scsi/sata_svw.c - 1.1 linux/Documentation/DocBook/libata.tmpl - 1.1 linux/drivers/scsi/ata_piix.c - 1.1 linux/drivers/scsi/libata-core.c - 1.1 linux/drivers/scsi/sata_promise.c - 1.1 linux/include/linux/ata.h - 1.1 linux/drivers/scsi/libata-scsi.c - 1.1 linux/drivers/scsi/libata.h - 1.1 linux/drivers/scsi/sata_via.c - 1.1 linux/drivers/scsi/sata_sil.c - 1.1 linux/include/linux/libata.h - 1.1 linux/include/scsi/scsi_devinfo.h - 1.1 linux/drivers/char/sn_serial.c - 1.1 linux/net/ipv6/sit.c - 1.38 linux/net/ipv6/addrconf.c - 1.46 linux/net/ipv4/tcp.c - 1.61 linux/net/ipv4/ipip.c - 1.38 linux/net/ipv4/ip_gre.c - 1.39 linux/net/ipv4/devinet.c - 1.26 linux/net/core/sysctl_net_core.c - 1.9 linux/net/core/neighbour.c - 1.26 linux/net/core/dev.c - 1.87 linux/mm/slab.c - 1.69 linux/mm/mmap.c - 1.85 linux/mm/memory.c - 1.114 linux/mm/filemap.c - 1.165 linux/lib/vsprintf.c - 1.24 linux/lib/string.c - 1.20 linux/kernel/time.c - 1.21 linux/kernel/sys.c - 1.62 linux/kernel/sched.c - 1.114 linux/kernel/resource.c - 1.27 linux/kernel/kmod.c - 1.36 linux/ipc/msg.c - 1.22 linux/init/main.c - 1.115 linux/include/net/llc.h - 1.6 linux/include/linux/timex.h - 1.11 linux/include/linux/netdevice.h - 1.58 linux/include/linux/kernel.h - 1.50 linux/include/linux/ioport.h - 1.20 linux/include/linux/etherdevice.h - 1.10 linux/include/asm-sparc64/pgtable.h - 1.43 linux/include/asm-sparc64/page.h - 1.23 linux/fs/nfsd/nfs3xdr.c - 1.43 linux/fs/dquot.c - 1.74 linux/fs/binfmt_elf.c - 1.66 linux/drivers/video/acornfb.c - 1.31 linux/drivers/scsi/sr.c - 1.75 linux/drivers/scsi/sg.c - 1.60 linux/drivers/scsi/sd.c - 1.95 linux/drivers/scsi/scsi.c - 1.84 linux/drivers/scsi/constants.c - 1.18 linux/drivers/scsi/atp870u.c - 1.32 linux/drivers/scsi/Makefile - 1.57 linux/drivers/pci/quirks.c - 1.44 linux/drivers/char/tty_io.c - 1.77 linux/drivers/char/mem.c - 1.57 linux/drivers/char/keyboard.c - 1.40 linux/drivers/char/Makefile - 1.87 linux/arch/sparc64/mm/init.c - 1.62 linux/arch/sparc64/kernel/time.c - 1.41 linux/arch/sparc64/defconfig - 1.104 linux/arch/sparc/kernel/time.c - 1.31 linux/arch/sparc/kernel/pcic.c - 1.31 linux/arch/i386/kernel/time.c - 1.47 linux/arch/i386/kernel/setup.c - 1.101 linux/arch/i386/kernel/irq.c - 1.64 linux/arch/i386/kernel/io_apic.c - 1.70 linux/Makefile - 1.262 linux/MAINTAINERS - 1.153 linux/drivers/parport/parport_pc.c - 1.61 linux/include/asm-i386/hw_irq.h - 1.37 linux/include/asm-i386/pci.h - 1.24 linux/kernel/timer.c - 1.56 linux/drivers/scsi/scsi_scan.c - 1.57 linux/arch/ia64/kernel/efi.c - 1.26 linux/arch/ia64/ia32/sys_ia32.c - 1.54 linux/arch/ia64/ia32/ia32_support.c - 1.12 linux/arch/ia64/ia32/ia32_signal.c - 1.17 linux/arch/ia64/ia32/ia32_entry.S - 1.27 linux/arch/ia64/ia32/binfmt_elf32.c - 1.22 linux/arch/ia64/kernel/irq.c - 1.34 linux/arch/ia64/kernel/setup.c - 1.33 linux/arch/ia64/lib/checksum.c - 1.5 linux/arch/ia64/lib/csum_partial_copy.c - 1.5 linux/arch/ia64/kernel/process.c - 1.32 linux/arch/ia64/kernel/perfmon.c - 1.33 linux/arch/ia64/mm/init.c - 1.34 linux/include/asm-ia64/io.h - 1.17 linux/include/asm-ia64/ia32.h - 1.21 linux/include/asm-ia64/processor.h - 1.39 linux/include/asm-ia64/namei.h - 1.4 linux/include/asm-ia64/unwind.h - 1.9 linux/arch/i386/kernel/microcode.c - 1.29 linux/drivers/usb/serial/ftdi_sio.h - 1.12 linux/drivers/ide/Makefile - 1.38 linux/Documentation/DocBook/Makefile - 1.44 linux/fs/ramfs/inode.c - 1.39 linux/drivers/usb/serial/ftdi_sio.c - 1.55 linux/include/asm-arm/arch-shark/hardware.h - 1.7 linux/arch/ia64/kernel/smpboot.c - 1.26 linux/drivers/usb/serial/digi_acceleport.c - 1.41 linux/drivers/usb/storage/scsiglue.c - 1.37 linux/drivers/acpi/ec.c - 1.22 linux/arch/ia64/kernel/ia64_ksyms.c - 1.23 linux/arch/ia64/kernel/unwind_i.h - 1.7 linux/drivers/media/video/tea6420.c - 1.6 linux/drivers/media/video/bttv-driver.c - 1.35 linux/drivers/char/toshiba.c - 1.11 linux/drivers/md/raid0.c - 1.24 linux/include/linux/toshiba.h - 1.4 linux/include/asm-ia64/module.h - 1.11 linux/mm/shmem.c - 1.68 linux/drivers/acpi/power.c - 1.15 linux/drivers/usb/storage/unusual_devs.h - 1.31 linux/drivers/usb/serial/io_edgeport.c - 1.40 linux/net/bluetooth/af_bluetooth.c - 1.21 linux/drivers/acpi/utilities/utdelete.c - 1.16 linux/arch/ia64/ia32/ia32_ldt.c - 1.4 linux/drivers/char/drm/drm_drv.h - 1.19 linux/fs/jbd/journal.c - 1.30 linux/fs/jbd/commit.c - 1.17 linux/arch/arm/mm/proc-xscale.S - 1.17 linux/sound/core/pcm_native.c - 1.23 linux/drivers/net/tg3.c - 1.28 linux/fs/libfs.c - 1.22 linux/drivers/usb/class/audio.c - 1.20 linux/drivers/usb/class/cdc-acm.c - 1.26 linux/drivers/usb/core/usb.c - 1.42 linux/drivers/usb/net/usbnet.c - 1.30 linux/drivers/usb/media/vicam.c - 1.17 linux/drivers/usb/misc/brlvger.c - 1.19 linux/drivers/isdn/capi/kcapi.c - 1.8 linux/drivers/usb/core/message.c - 1.26 linux/drivers/acpi/battery.c - 1.13 linux/drivers/acpi/bus.c - 1.16 linux/drivers/input/keyboard/atkbd.c - 1.14 linux/drivers/input/gameport/fm801-gp.c - 1.6 linux/drivers/input/gameport/vortex.c - 1.6 linux/drivers/serial/8250.c - 1.21 linux/drivers/ide/pci/siimage.c - 1.14 linux/drivers/ide/pci/piix.c - 1.14 linux/arch/sparc64/mm/hugetlbpage.c - 1.8 linux/net/bridge/netfilter/ebt_redirect.c - 1.5 linux/drivers/block/deadline-iosched.c - 1.14 linux/drivers/base/cpu.c - 1.10 linux/net/llc/af_llc.c - 1.11 linux/net/llc/llc_proc.c - 1.11 linux/drivers/scsi/aacraid/comminit.c - 1.5 linux/drivers/scsi/aacraid/aacraid.h - 1.7 linux/fs/cifs/README - 1.6 linux/fs/cifs/cifs_debug.c - 1.12 linux/fs/cifs/cifsfs.c - 1.18 linux/fs/cifs/cifsglob.h - 1.11 linux/fs/cifs/cifssmb.c - 1.17 linux/fs/cifs/connect.c - 1.17 linux/fs/cifs/dir.c - 1.9 linux/fs/cifs/file.c - 1.15 linux/fs/cifs/misc.c - 1.12 linux/fs/cifs/AUTHORS - 1.5 linux/fs/cifs/CHANGES - 1.16 linux/fs/cifs/transport.c - 1.15 linux/fs/cifs/smbencrypt.c - 1.6 linux/fs/cifs/smbdes.c - 1.3 linux/drivers/block/scsi_ioctl.c - 1.15 linux/net/bridge/br_netfilter.c - 1.11 linux/arch/ia64/mm/discontig.c - 1.8 linux/arch/ia64/mm/numa.c - 1.4 linux/drivers/char/Kconfig - 1.16 linux/drivers/media/dvb/dvb-core/dvb_demux.c - 1.8 linux/include/asm-ia64/numnodes.h - 1.3 linux/drivers/scsi/Kconfig - 1.19 linux/arch/sparc64/Kconfig - 1.24 linux/fs/befs/linuxvfs.c - 1.12 linux/include/net/xfrm.h - 1.20 linux/fs/hugetlbfs/inode.c - 1.18 linux/init/initramfs.c - 1.5 linux/arch/v850/kernel/simcons.c - 1.7 linux/arch/v850/kernel/rte_nb85e_cb.c - 1.4 linux/drivers/scsi/scsi_sysfs.c - 1.17 linux/drivers/mca/mca-driver.c - 1.2 linux/drivers/mca/mca-legacy.c - 1.5 linux/drivers/acpi/events/evgpe.c - 1.11 linux/arch/v850/kernel/as85ep1.c - 1.5 linux/include/asm-i386/mach-voyager/irq_vectors.h - 1.3 linux/include/asm-i386/mach-visws/irq_vectors.h - 1.4 linux/include/asm-i386/mach-default/irq_vectors.h - 1.3 linux/arch/i386/kernel/acpi/boot.c - 1.7 linux/drivers/net/wireless/arlan-proc.c - 1.4 linux/init/do_mounts_rd.c - 1.7 linux/net/compat.c - 1.6 linux/net/ipv6/xfrm6_policy.c - 1.9 linux/drivers/media/common/saa7146_i2c.c - 1.6 linux/drivers/media/dvb/ttpci/av7110.c - 1.6 linux/drivers/media/dvb/ttpci/av7110_firm.h - 1.4 linux/drivers/media/video/tda9840.c - 1.4 linux/drivers/media/video/tea6415c.c - 1.4 linux/arch/ia64/kernel/module.c - 1.5 linux/include/asm-i386/mach-pc9800/irq_vectors.h - 1.2 linux/init/do_mounts_initrd.c - 1.5 linux/drivers/scsi/scsi_priv.h - 1.8 linux/drivers/scsi/scsi_devinfo.c - 1.5 linux/net/core/net-sysfs.c - 1.9 linux/drivers/mtd/inftlcore.c - 1.3 linux/net/ipv6/ip6_tunnel.c - 1.7 linux/include/asm-ia64/perfmon_default_smpl.h - 1.3 linux/drivers/pcmcia/yenta_socket.c - 1.9 linux/include/scsi/scsi_host.h - 1.5 linux/include/scsi/scsi_device.h - 1.7 linux/arch/ia64/kernel/perfmon_default_smpl.c - 1.3 linux/arch/ia64/ia32/ia32priv.h - 1.6 linux/arch/ia64/kernel/gate-data.S - 1.2 linux/drivers/block/as-iosched.c - 1.9 linux/fs/cifs/cifsencrypt.c - 1.4 linux/arch/v850/kernel/rte_me2_cb.c - 1.2 linux/arch/v850/kernel/sim85e2.c - 1.3 linux/drivers/media/dvb/frontends/tda1004x.c - 1.4 linux/drivers/usb/gadget/inode.c - 1.3 From owner-linux-xfs@oss.sgi.com Sun Oct 26 16:23:49 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 26 Oct 2003 16:24:32 -0800 (PST) Received: from mail41.messagelabs.com (mail41.messagelabs.com [64.125.76.51]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9R0Nm25014321 for ; Sun, 26 Oct 2003 16:23:48 -0800 X-VirusChecked: Checked X-Env-Sender: bvenegas@securities.com X-Msg-Ref: server-8.tower-41.messagelabs.com!1067214220!839350 X-StarScan-Version: 5.1.9.3; banners=-,-,- Received: (qmail 27042 invoked from network); 27 Oct 2003 00:23:41 -0000 Received: from mail02.securities.com (57.69.15.72) by server-8.tower-41.messagelabs.com with SMTP; 27 Oct 2003 00:23:41 -0000 Received: from mail02.securities.com (localhost [127.0.0.1]) by mail02.securities.com (8.12.5/8.12.5-DELIVERY) with ESMTP id h9R0Ne2j005423 for ; Sun, 26 Oct 2003 19:23:40 -0500 Received: from mail02.securities.com (localhost [127.0.0.1]) by mail02.securities.com (8.12.5/8.12.5/8.12.5-SMTP) with ESMTP id h9R0NdVp005418 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Sun, 26 Oct 2003 19:23:39 -0500 Received: from localhost (venevene@localhost) by mail02.securities.com (8.12.5/8.12.5/Submit) with ESMTP id h9R0NdSC005414; Sun, 26 Oct 2003 19:23:39 -0500 X-Authentication-Warning: mail02.securities.com: venevene owned process doing -bs Date: Sun, 26 Oct 2003 19:23:39 -0500 (EST) From: "Benito A. Venegas" X-X-Sender: venevene@mail02.securities.com To: Steve Lord cc: linux-xfs@oss.sgi.com Subject: Re: TAKE: Change XFS maintainer In-Reply-To: <1066930902.21480.178.camel@jen.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 812 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bvenegas@securities.com Precedence: bulk X-list: linux-xfs Content-Length: 894 Lines: 38 Steve: Thanks for all your help all the time!! My best wishes for you in your new position..hopefully a better one.. be in touch, of course if you have time.. Cheers -- venevene/Benito On 23 Oct 2003, Steve Lord wrote: > Tomorrow is my last Day at SGI, so I am handing over the care and > feeding of XFS to Nathan Scott. I will be keeping an eye on things, > but my new job will probably keep me too busy to be active all the > time. > > This email address will probably start bouncing very quickly > after tomorrow, lord AT xfs DOT org will reach me. > > Steve > > > Date: Thu Oct 23 09:30:36 PDT 2003 > Workarea: penguin.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:160507a > linux/MAINTAINERS - 1.94 > - Put Nathan Scott in as XFS maintainer > > From owner-linux-xfs@oss.sgi.com Sun Oct 26 17:00:17 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 26 Oct 2003 17:00:49 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9R10G25015450 for ; Sun, 26 Oct 2003 17:00:16 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h9R1J3Hc001478 for ; Sun, 26 Oct 2003 19:19:04 -0600 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h9R108jj4298193 for ; Mon, 27 Oct 2003 12:00:08 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h9R108Gw4316854 for linux-xfs@oss.sgi.com; Mon, 27 Oct 2003 12:00:08 +1100 (EST) Date: Mon, 27 Oct 2003 12:00:08 +1100 (EST) From: Nathan Scott Message-Id: <200310270100.h9R108Gw4316854@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - add some additional debug code X-archive-position: 813 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 794 Lines: 30 Dump the pagebuf locked field for debugging purposes. Date: Sun Oct 26 16:37:08 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/clean-2.5.x-xfs Author: nathans Merged by: nathans Merged mods: xfs-linux:slinx:160616a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:160616a linux/fs/xfs/xfsidbg.c - 1.246 - Merge of xfs-linux:slinx:160616a by nathans. Fix pagebuf delwri list (static) accesses from within xfsidbg code. Date: Sun Oct 26 16:55:45 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/clean-2.5.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:160617a linux/fs/xfs/xfsidbg.c - 1.247 linux/fs/xfs/pagebuf/page_buf.c - 1.126 From owner-linux-xfs@oss.sgi.com Sun Oct 26 20:36:45 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 26 Oct 2003 20:37:23 -0800 (PST) Received: from smtp2.iitb.ac.in (garbo-vsnl1.iitb.ac.in [203.197.74.149]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9R4ah25021163 for ; Sun, 26 Oct 2003 20:36:44 -0800 Received: (qmail 5033 invoked by uid 505); 27 Oct 2003 04:36:41 -0000 Received: from shantanu@it.iitb.ac.in by smtp2.iitb.ac.in by uid 502 with qmail-scanner-1.16 (clamscan: 0.54. spamassassin: 2.54. Clear:. Processed in 1.278645 secs); 27 Oct 2003 04:36:41 -0000 Received: from unknown (HELO akash.it.iitb.ac.in) (10.129.1.1) by smtp2.iitb.ac.in with SMTP; 27 Oct 2003 04:36:39 -0000 Received: (qmail 19112 invoked by uid 576); 27 Oct 2003 10:06:40 +0530 Date: Mon, 27 Oct 2003 10:06:40 +0530 From: Shantanu Godbole To: linux-xfs@oss.sgi.com Subject: Re: Linux 2.4.22 XFS 1.3.1 reservation ran out Message-ID: <20031027100640.A18791@it.iitb.ac.in> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from soumen@cse.iitb.ac.in on Sun, Oct 26, 2003 at 09:43:33AM +0530 X-archive-position: 814 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: shantanu@it.iitb.ac.in Precedence: bulk X-list: linux-xfs Content-Length: 405 Lines: 17 I could recreate this bug on a Debian 'testing' system (2 P3 Processors, 2 GB RAM, 4 SCSI disks, no RAID). Kernel info: 2.4.22, XFS 1.3.1 patch, Himem enabled at 4G. === from .config === CONFIG_XFS_FS=y CONFIG_XFS_POSIX_ACL=y # CONFIG_XFS_RT is not set CONFIG_XFS_QUOTA=y # CONFIG_XFS_DMAPI is not set # CONFIG_XFS_TRACE is not set # CONFIG_XFS_DEBUG is not set ====== The error massages were similar. From owner-linux-xfs@oss.sgi.com Sun Oct 26 22:14:43 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 26 Oct 2003 22:15:16 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9R6Eh25023012 for ; Sun, 26 Oct 2003 22:14:43 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h9R4JYOO019679 for ; Sun, 26 Oct 2003 20:19:34 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h9R6Eajj4432047 for ; Mon, 27 Oct 2003 17:14:36 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h9R6EaJA4436509 for linux-xfs@oss.sgi.com; Mon, 27 Oct 2003 17:14:36 +1100 (EST) Date: Mon, 27 Oct 2003 17:14:36 +1100 (EST) From: Nathan Scott Message-Id: <200310270614.h9R6EaJA4436509@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - fix warnings X-archive-position: 816 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 555 Lines: 23 Fix warnings when tracing enabled on 64 bit platforms. Date: Sun Oct 26 22:14:00 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-linux Author: nathans Merged by: nathans Merged mods: 2.4.x-xfs-kern:slinx:160622a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-linux Modid: xfs-linux:slinx:160622a xfsidbg.c - 1.244 xfs_buf_item.c - 1.145 xfs_dir.c - 1.157 xfs_inode.c - 1.392 xfs_dir2_trace.c - 1.19 xfs_bmap.c - 1.314 pagebuf/page_buf.c - 1.136 - Merge of 2.4.x-xfs-kern:slinx:160622a by nathans. From owner-linux-xfs@oss.sgi.com Mon Oct 27 02:25:42 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 27 Oct 2003 02:26:22 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10) with ESMTP id h9RAPg25031347 for ; Mon, 27 Oct 2003 02:25:42 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id h9RAPg7V031345 for linux-xfs@oss.sgi.com; Mon, 27 Oct 2003 02:25:42 -0800 Received: from ahriman.bucharest.roedu.net (ahriman.bucharest.roedu.net [141.85.128.71]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9RAPb25031331 for ; Mon, 27 Oct 2003 02:25:38 -0800 Received: (qmail 6333 invoked by uid 1000); 27 Oct 2003 10:24:30 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 27 Oct 2003 10:24:30 -0000 Date: Mon, 27 Oct 2003 12:24:28 +0200 (EET) From: Mihai RUSU X-X-Sender: dizzy@ahriman.bucharest.roedu.net To: xfs-master@oss.sgi.com Subject: Re: [Bug 283] kernel-source-2.4.20-20.9.XFS1.3.1.i386.rpm fails to compile In-Reply-To: <200310171514.h9HFEGu4011353@oss.sgi.com> Message-ID: References: <200310171514.h9HFEGu4011353@oss.sgi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 817 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dizzy@roedu.net Precedence: bulk X-list: linux-xfs Content-Length: 1202 Lines: 42 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi I dont want to stress anyone but its been almost a week now, and the problem is still present. I have also got an email from some other guy who said he had the same problem too so its a real problem. Please someone help. Thanks! On Fri, 17 Oct 2003 bugzilla-daemon@oss.sgi.com wrote: > http://oss.sgi.com/bugzilla/show_bug.cgi?id=283 > > > > > > ------- Additional Comments From dizzy@roedu.net 2003-17-10 08:14 PDT ------- > Already did that before getting the problem and to make sure I did now again > make mrproper, make menuconfig, make dep, make bzImage and I get the same error. > > > > > ------- You are receiving this mail because: ------- > You are the assignee for the bug, or are watching the assignee. > > - ---------------------------- Mihai RUSU Email: dizzy@roedu.net GPG : http://dizzy.roedu.net/dizzy-gpg.txt WWW: http://dizzy.roedu.net "Linux is obsolete" -- AST -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/nPJePZzOzrZY/1QRAjyNAKChryb1LBTtKkFaCj3kD2MMHJ6C+QCeKMTj Tra+r/kwt1+qbg6qI6tMlc0= =kSzy -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Mon Oct 27 06:34:46 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 27 Oct 2003 06:35:28 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9REYj25009417 for ; Mon, 27 Oct 2003 06:34:45 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h9RErZHc006985 for ; Mon, 27 Oct 2003 08:53:35 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h9REYdP512469500; Mon, 27 Oct 2003 08:34:39 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h9REYcK24378482; Mon, 27 Oct 2003 08:34:39 -0600 (CST) Date: Mon, 27 Oct 2003 08:34:38 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Shantanu Godbole cc: linux-xfs@oss.sgi.com Subject: Re: Linux 2.4.22 XFS 1.3.1 reservation ran out In-Reply-To: <20031027100640.A18791@it.iitb.ac.in> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 819 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 198 Lines: 8 I was unable to reproduce this so far, with 2.4.21 + xfs 1.3.1 the 2nd bonnie run completed succesfully. I'll look at the filesystem geometries posted and see if that makes any difference. -Eric From owner-linux-xfs@oss.sgi.com Mon Oct 27 06:48:44 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 27 Oct 2003 06:49:20 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9REmg25010227 for ; Mon, 27 Oct 2003 06:48:42 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h9REmaq0021320 for ; Mon, 27 Oct 2003 06:48:37 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h9REmXP512541549; Mon, 27 Oct 2003 08:48:33 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h9REmWK24350525; Mon, 27 Oct 2003 08:48:33 -0600 (CST) Date: Mon, 27 Oct 2003 08:48:32 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Soumen Chakrabarti cc: linux-xfs@oss.sgi.com Subject: Re: Linux 2.4.22 XFS 1.3.1 reservation ran out In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 820 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 784 Lines: 23 On Sun, 26 Oct 2003, Soumen Chakrabarti wrote: > Repeatable bug, here's how to create the situation: > 1. Start with a fresh install of stock RedHat 9. > 2. Download kernel 2.4.22. > 3. Patch in XFS 1.3.1 and build new kernel. Ok, for starters, i don't think we shipped patches specifically for xfs 1.3.1 + kernel 2.4.22, and the patches we did ship for 2.4.21 do not apply cleanly to 2.4.22. I assume you hand-merged this; can you mail me (privately) your resulting patch from the hand merge? I doubt that this has anything to do with it, but in the interest of duplicating your setup I'd like to have the exact code you're using, since i was not able to duplicate with 2.4.21 + xfs 1.3.1. Also, the xfs_info output for the tested filesystem would be helpful. Thanks, -Eric From owner-linux-xfs@oss.sgi.com Mon Oct 27 07:11:11 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 27 Oct 2003 07:11:56 -0800 (PST) Received: from mail.dev.rtsoft.ru (RT-soft-2.Moscow.itn.ru [80.240.96.70]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9RFB925011394 for ; Mon, 27 Oct 2003 07:11:10 -0800 Received: (qmail 14138 invoked from network); 27 Oct 2003 15:02:20 -0000 Received: from maya.dev.rtsoft.ru (HELO dev.rtsoft.ru) (192.168.1.197) by mail.dev.rtsoft.ru with SMTP; 27 Oct 2003 15:02:20 -0000 Message-ID: <3F9D2772.5050001@dev.rtsoft.ru> Date: Mon, 27 Oct 2003 17:10:58 +0300 From: Roman Vasylyev User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: ru, en-us, en MIME-Version: 1.0 To: Nathan Scott , linux-xfs@oss.sgi.com Subject: Re: Re: again xfstests - now test 076 References: <3F98FD53.9090407@dev.rtsoft.ru> <20031025143759.B833021@wobbly.melbourne.sgi.com> In-Reply-To: <20031025143759.B833021@wobbly.melbourne.sgi.com> Content-Type: multipart/mixed; boundary="------------030907010905090301070206" X-archive-position: 821 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: romis@dev.rtsoft.ru Precedence: bulk X-list: linux-xfs Content-Length: 9988 Lines: 239 This is a multi-part message in MIME format. --------------030907010905090301070206 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Nathan Scott wrote: > On Fri, Oct 24, 2003 at 02:22:11PM +0400, Roman Vasylyev wrote: > >>10/13/2003 i wrote about 013 kernel warnings. >>After turning off debug option in XFS module kernel warnings gone. But >>013 test sometimes is hangs on. And i find another test which users >>fsstress - 076(Test blockdev reads in parallel with file system >>reads/writes). >>But if 013 test is passed 076 always fails. In attached file result log. >>Can some who say is that critical for using XFS. > > > Yes, 076 is a known issue (hence its not in "auto" group - see the > -g option to the check script). I have a bunch of pagebuf locking > changes which address this issue for small block size filesystems, > but afaik its OK with page-sized block sizes... what architecture > are you testing here? (what is your page size?). > > It is a good idea to enable kdb (and debug) while running the tests, > when you see the 013 hang again I would be interested in seeing your > kdb trace. You do have a relatively small device for you're testing, > so you may be hitting the out-of-space hangs some other people have > seen recently.. > > thanks. > I added dmesg output in this letter. asm/page.h is #ifndef _I386_PAGE_H #define _I386_PAGE_H /* PAGE_SHIFT determines the page size */ #define PAGE_SHIFT 12 #define PAGE_SIZE (1UL << PAGE_SHIFT) #define PAGE_MASK (~(PAGE_SIZE-1)) #endif /* _I386_PAGE_H */ --------------030907010905090301070206 Content-Type: text/plain; name="dmesg" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dmesg" Linux version 2.4.21-xfs (root@maya) (gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)) #2 SMP Thu Oct 23 17:08:44 MSD 2003 BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009fc00 (usable) BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved) BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 000000001ffec000 (usable) BIOS-e820: 000000001ffec000 - 000000001ffef000 (ACPI data) BIOS-e820: 000000001ffef000 - 000000001ffff000 (reserved) BIOS-e820: 000000001ffff000 - 0000000020000000 (ACPI NVS) BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved) BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved) 511MB LOWMEM available. On node 0 totalpages: 131052 zone(0): 4096 pages. zone(1): 126956 pages. zone(2): 0 pages. Kernel command line: ro root=/dev/hda7 vga=0x31b Found and enabled local APIC! Initializing CPU#0 Detected 2423.914 MHz processor. Console: colour dummy device 80x25 Calibrating delay loop... 4836.55 BogoMIPS Memory: 514552k/524208k available (2380k kernel code, 9268k reserved, 634k data, 128k init, 0k highmem) 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: 512 (order: 0, 4096 bytes) Buffer-cache hash table entries: 32768 (order: 5, 131072 bytes) Page-cache hash table entries: 131072 (order: 7, 524288 bytes) CPU: Trace cache: 12K uops, L1 D cache: 8K CPU: L2 cache: 512K CPU: Hyper-Threading is disabled Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU: After generic, caps: bfebfbff 00000000 00000000 00000000 CPU: Common caps: bfebfbff 00000000 00000000 00000000 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX CPU: Trace cache: 12K uops, L1 D cache: 8K CPU: L2 cache: 512K CPU: Hyper-Threading is disabled Intel machine check reporting enabled on CPU#0. CPU: After generic, caps: bfebfbff 00000000 00000000 00000000 CPU: Common caps: bfebfbff 00000000 00000000 00000000 CPU0: Intel(R) Pentium(R) 4 CPU 2.40GHz stepping 07 per-CPU timeslice cutoff: 1463.34 usecs. SMP motherboard not detected. enabled ExtINT on CPU#0 ESR value before enabling vector: 00000000 ESR value after enabling vector: 00000000 Using local APIC timer interrupts. calibrating APIC timer ... ..... CPU clock speed is 2423.8542 MHz. ..... host bus clock speed is 134.6584 MHz. cpu: 0, clocks: 1346584, slice: 673292 CPU0 Waiting on wait_init_idle (map = 0x0) All processors have done init_idle PCI: PCI BIOS revision 2.10 entry at 0xf1eb0, last bus=2 PCI: Using configuration type 1 PCI: Probing PCI hardware PCI: Ignoring BAR0-3 of IDE controller 00:1f.1 Transparent bridge - Intel Corp. 82801BA/CA/DB PCI Bridge PCI: Using IRQ router PIIX [8086/24c0] at 00:1f.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 Starting kswapd VFS: Disk quotas vdquot_6.5.1 Journalled Block Device driver loaded Installing knfsd (copyright (C) 1996 okir@monad.swb.de). SGI XFS 1.3.1 with ACLs, realtime, no debug enabled SGI XFS Quota Management subsystem vesafb: framebuffer at 0xf0000000, mapped to 0xe080d000, size 40960k vesafb: mode is 1280x1024x32, linelength=5120, pages=0 vesafb: protected mode interface info at c000:f910 vesafb: scrolling: redraw vesafb: directcolor: size=8:8:8:8, shift=24:16:8:0 Console: switching to colour frame buffer device 160x64 fb0: VESA VGA frame buffer device pty: 256 Unix98 ptys configured Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI ISAPNP enabled ttyS00 at 0x03f8 (irq = 4) is a 16550A ttyS01 at 0x02f8 (irq = 3) is a 16550A Floppy drive(s): fd0 is 1.44M FDC 0 is a post-1991 82077 Linux agpgart interface v0.99 (c) Jeff Hartmann agpgart: Maximum main memory to use for agp memory: 439M agpgart: Detected Intel i845 chipset agpgart: AGP aperture is 64M @ 0xf8000000 [drm] Initialized tdfx 1.0.0 20010216 on minor 0 [drm] AGP 0.99 on Intel i845 @ 0xf8000000 64MB [drm] Initialized radeon 1.1.1 20010405 on minor 1 [drm] AGP 0.99 on Intel i845 @ 0xf8000000 64MB [drm] Initialized i810 1.2.0 20010920 on minor 2 Uniform Multi-Platform E-IDE driver Revision: 7.00beta4-2.4 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx ICH4: IDE controller at PCI slot 00:1f.1 PCI: Found IRQ 10 for device 00:1f.1 PCI: Sharing IRQ 10 with 00:1d.2 ICH4: chipset revision 1 ICH4: not 100% native mode: will probe irqs later ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:pio hda: ST380011A, ATA DISK drive blk: queue c0464b80, I/O limit 4095Mb (mask 0xffffffff) hdc: TEAC CD-552E, ATAPI CD/DVD-ROM drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 ide1 at 0x170-0x177,0x376 on irq 15 hda: attached ide-disk driver. hda: host protected area => 1 hda: 156301488 sectors (80026 MB) w/2048KiB Cache, CHS=9729/255/63, UDMA(100) hdc: attached ide-cdrom driver. hdc: ATAPI 52X CD-ROM drive, 128kB Cache, UDMA(33) Uniform CD-ROM driver Revision: 3.12 Partition check: hda: hda1 hda2 < hda5 hda6 hda7 hda8 hda9 > Linux Kernel Card Services 3.1.22 options: [pci] [cardbus] [pm] usb.c: registered new driver usbdevfs usb.c: registered new driver hub host/uhci.c: USB Universal Host Controller Interface driver v1.1 PCI: Found IRQ 11 for device 00:1d.0 PCI: Sharing IRQ 11 with 01:00.0 PCI: Setting latency timer of device 00:1d.0 to 64 host/uhci.c: USB UHCI at I/O 0xd800, IRQ 11 usb.c: new USB bus registered, assigned bus number 1 hub.c: USB hub found hub.c: 2 ports detected PCI: Found IRQ 5 for device 00:1d.1 PCI: Setting latency timer of device 00:1d.1 to 64 host/uhci.c: USB UHCI at I/O 0xd400, IRQ 5 usb.c: new USB bus registered, assigned bus number 2 hub.c: USB hub found hub.c: 2 ports detected PCI: Found IRQ 10 for device 00:1d.2 PCI: Sharing IRQ 10 with 00:1f.1 PCI: Setting latency timer of device 00:1d.2 to 64 host/uhci.c: USB UHCI at I/O 0xd000, IRQ 10 usb.c: new USB bus registered, assigned bus number 3 hub.c: USB hub found hub.c: 2 ports detected NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP 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. ds: no socket drivers loaded! kjournald starting. Commit interval 5 seconds EXT3-fs: mounted filesystem with ordered data mode. VFS: Mounted root (ext3 filesystem) readonly. Freeing unused kernel memory: 128k freed Real Time Clock Driver v1.10e usb.c: registered new driver hid hid-core.c: v1.8.1 Andreas Gal, Vojtech Pavlik hid-core.c: USB HID support drivers mice: PS/2 mouse device common for all mice EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,7), internal journal Adding Swap: 1052216k swap-space (priority -1) NTFS driver v1.1.22 [Flags: R/W MODULE] NTFS: Warning! NTFS volume version is Win2k+: Mounting read-only MSDOS FS: IO charset utf8 PCI: Found IRQ 9 for device 02:0a.0 3c59x: Donald Becker and others. www.scyld.com/network/vortex.html See Documentation/networking/vortex.txt 02:0a.0: 3Com PCI 3c905C Tornado at 0xb400. Vers LK1.1.16 00:10:22:ff:06:b0, IRQ 9 product code 4552 rev 00.13 date 01-18-00 Full duplex capable Internal config register is 1800000, transceivers 0xa. 8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate interface. MII transceiver found at address 24, status 782d. Enabling bus-master transmits and whole-frame receives. 02:0a.0: scatter/gather enabled. h/w checksums enabled 0: nvidia: loading NVIDIA Linux x86 nvidia.o Kernel Module 1.0-4496 Wed Jul 16 19:03:09 PDT 2003 cmpci: version $Revision: 5.64 $ time 17:44:37 Oct 22 2003 PCI: Found IRQ 9 for device 02:03.0 cmpci: found CM8738 adapter at io 0xb800 irq 9 cmpci: chip version = 055 --------------030907010905090301070206-- From owner-linux-xfs@oss.sgi.com Mon Oct 27 10:31:16 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 27 Oct 2003 10:31:59 -0800 (PST) Received: from twin.jikos.cz (IDENT:root@twin.jikos.cz [213.151.79.26]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9RIVE25018325 for ; Mon, 27 Oct 2003 10:31:15 -0800 Received: from localhost (jikos@localhost) by twin.jikos.cz (8.11.6/8.11.6) with ESMTP id h9NLnxu13114; Thu, 23 Oct 2003 23:49:59 +0200 Date: Thu, 23 Oct 2003 23:49:59 +0200 (CEST) From: Jirka Kosina To: linux-kernel@vger.kernel.org cc: linux-xfs@oss.sgi.com Subject: 2.6.0-test8 XFS bug Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 822 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jikos@jikos.cz Precedence: bulk X-list: linux-xfs Content-Length: 4147 Lines: 70 Hi, I've installed 2.6.0-test8 on machine attached to HW raid, made 5.5TB partition (using LVM) and made XFS filesystem on this partition. This partittion was exported to cca 25 nodes. I started some stress tests (writing and reading files through NFS) from these nodes to this partition and went home. The other day I found out that syslog filled up /var/log/messages with backtraces (see below), and the XFS filesystem went just totally crappy (for example when I had some file on this partition, and did simple cp to another name, the content of the new file was corrupted (NFS was not involved in this)). When I make this partition ext3, things seem to work well. The backtrace: Oct 22 13:12:56 storage2 kernel: 0x0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Oct 22 13:12:56 storage2 kernel: Filesystem "dm-0": XFS internal error xfs_alloc_read_agf at line 2208 of file fs/xfs/xfs_alloc.c. Caller 0xc01e8f5c Oct 22 13:12:56 storage2 kernel: Call Trace: Oct 22 13:12:56 storage2 kernel: [] xfs_alloc_read_agf+0x19e/0x214 Oct 22 13:12:56 storage2 kernel: [] xfs_alloc_fix_freelist+0x458/0x46e Oct 22 13:12:56 storage2 last message repeated 2 times Oct 22 13:12:56 storage2 kernel: [] xfs_trans_log_buf+0x6e/0xa8 Oct 22 13:12:56 storage2 kernel: [] xfs_bmbt_get_state+0x2f/0x3c Oct 22 13:12:56 storage2 kernel: [] xfs_alloc_vextent+0x2f4/0x520 Oct 22 13:12:56 storage2 kernel: [] xfs_bmap_alloc+0x8eb/0x1856 Oct 22 13:12:56 storage2 kernel: [] xfs_iomap_write_delay+0x35e/0x40a Oct 22 13:12:56 storage2 kernel: [] xfs_bmbt_get_state+0x2f/0x3c Oct 22 13:12:56 storage2 kernel: [] xfs_bmapi+0xfaf/0x165c Oct 22 13:12:56 storage2 kernel: [] _xfs_imap_to_bmap+0x35/0x28e Oct 22 13:12:56 storage2 kernel: [] xfs_bmbt_get_state+0x2f/0x3c Oct 22 13:12:56 storage2 kernel: [] xfs_bmap_do_search_extents+0xb8/0x3f0 Oct 22 13:12:56 storage2 kernel: [] xfs_trans_unlocked_item+0x39/0x58 Oct 22 13:12:56 storage2 kernel: [] xfs_log_reserve+0xc1/0xc6 Oct 22 13:12:56 storage2 kernel: [] xfs_iomap_write_allocate+0x2b5/0x4c4 Oct 22 13:12:56 storage2 kernel: [] generic_file_aio_write_nolock+0x244/0xa9e Oct 22 13:12:56 storage2 kernel: [] xfs_iomap+0x411/0x54a Oct 22 13:12:56 storage2 kernel: [] map_blocks+0x72/0x128 Oct 22 13:12:56 storage2 kernel: [] page_state_convert+0x4fa/0x626 Oct 22 13:12:56 storage2 kernel: [] ip_local_deliver+0x1b7/0x1c8 Oct 22 13:12:56 storage2 kernel: [] ip_rcv+0x341/0x4a2 Oct 22 13:12:56 storage2 kernel: [] linvfs_writepage+0x60/0x10c Oct 22 13:12:56 storage2 kernel: [] mpage_writepages+0x21f/0x2f6 Oct 22 13:12:56 storage2 kernel: [] process_backlog+0x6e/0xfe Oct 22 13:12:56 storage2 kernel: [] linvfs_writepage+0x0/0x10c Oct 22 13:12:56 storage2 kernel: [] do_writepages+0x36/0x38 Oct 22 13:12:56 storage2 kernel: [] __filemap_fdatawrite+0xe3/0xec Oct 22 13:12:57 storage2 kernel: [] filemap_fdatawrite+0x17/0x1c Oct 22 13:12:57 storage2 kernel: [] nfsd_sync+0x63/0xc0 Oct 22 13:12:57 storage2 kernel: [] vfs_writev+0x60/0x64 Oct 22 13:12:57 storage2 kernel: [] nfsd_write+0x1c7/0x356 Oct 22 13:12:57 storage2 kernel: [] udp_sendpage+0x16d/0x2d0 Oct 22 13:12:57 storage2 kernel: [] skb_copy_and_csum_bits+0x1e3/0x2b0 Oct 22 13:12:57 storage2 kernel: [] nfsd_proc_write+0xa8/0x122 Oct 22 13:12:57 storage2 kernel: [] nfsd_dispatch+0xe8/0x1e8 Oct 22 13:12:57 storage2 kernel: [] nfsd_dispatch+0x0/0x1e8 Oct 22 13:12:57 storage2 kernel: [] svc_process+0x4f9/0x684 Oct 22 13:12:57 storage2 kernel: [] nfsd+0x1ff/0x3c6 Oct 22 13:12:57 storage2 kernel: [] nfsd+0x0/0x3c6 Oct 22 13:12:57 storage2 kernel: [] kernel_thread_helper+0x5/0xc P.S.: I am subscribed only to LKML, so please if replying to linux-xfs mailing list, be so kind and CC: me. Thanks. -- JiKos. From owner-linux-xfs@oss.sgi.com Mon Oct 27 13:47:17 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 27 Oct 2003 13:47:56 -0800 (PST) Received: from localhost.localdomain (host-65-120-145-91.coremetrics.com [65.120.145.91] (may be forged)) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9RLlG25001452 for ; Mon, 27 Oct 2003 13:47:17 -0800 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id h9RLlGCI007250 for ; Mon, 27 Oct 2003 15:47:16 -0600 Received: (from austin@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id h9RLlGWF007248 for linux-xfs@oss.sgi.com; Mon, 27 Oct 2003 15:47:16 -0600 X-Authentication-Warning: localhost.localdomain: austin set sender to austin@coremetrics.com using -f Subject: RE: Broken Log Help Needed From: Austin Gonyou To: XFS List Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1067291236.3278.177.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Mon, 27 Oct 2003 15:47:16 -0600 X-archive-position: 824 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: austin@coremetrics.com Precedence: bulk X-list: linux-xfs Content-Length: 1446 Lines: 69 Woops, forgot the xfs_db output and the xfs_info output: [root@Phoenix root]# xfs_db -r /dev/sdb xfs_db> sb 0 xfs_db> print magicnum = 0x58465342 blocksize = 4096 dblocks = 524288 rblocks = 0 rextents = 0 uuid = c7176fce-c067-4e53-b8b5-af201b92f2af logstart = 262148 rootino = 128 rbmino = 129 rsumino = 130 rextsize = 16 agblocks = 65536 agcount = 8 rbmblocks = 0 logblocks = 1200 versionnum = 0x2084 sectsize = 512 inodesize = 256 inopblock = 16 fname = "\000\000\000\000\000\000\000\000\000\000\000\000" blocklog = 12 sectlog = 9 inodelog = 8 inopblog = 4 agblklog = 16 rextslog = 0 inprogress = 0 imax_pct = 25 icount = 36864 ifree = 339 fdblocks = 109203 frextents = 0 uquotino = 0 gquotino = 0 qflags = 0 flags = 0 shared_vn = 0 inoalignmt = 2 unit = 0 width = 0 dirblklog = 0 logsectlog = 0 logsectsize = 0 logsunit = 0 xfs_db> meta-data=/mnt/backup isize=256 agcount=8, agsize=65536 blks = sectsz=512 data = bsize=4096 blocks=524288, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=1200, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Mon Oct 27 13:55:45 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 27 Oct 2003 13:56:29 -0800 (PST) Received: from localhost.localdomain (host-65-120-145-91.coremetrics.com [65.120.145.91] (may be forged)) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9RLth25001879 for ; Mon, 27 Oct 2003 13:55:44 -0800 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id h9RLtiCI007336 for ; Mon, 27 Oct 2003 15:55:44 -0600 Received: (from austin@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id h9RLthbO007334 for linux-xfs@oss.sgi.com; Mon, 27 Oct 2003 15:55:43 -0600 X-Authentication-Warning: localhost.localdomain: austin set sender to austin@coremetrics.com using -f Subject: Broken Log Help Needed From: Austin Gonyou To: XFS List Content-Type: multipart/mixed; boundary="=-kEbuFixda2EUEKhe1aeA" Organization: Coremetrics, Inc. Message-Id: <1067291743.3277.188.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Mon, 27 Oct 2003 15:55:43 -0600 X-archive-position: 825 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: austin@coremetrics.com Precedence: bulk X-list: linux-xfs Content-Length: 70014 Lines: 1166 --=-kEbuFixda2EUEKhe1aeA Content-Type: text/plain Content-Transfer-Encoding: 7bit I think the previous one had too big an attachment. Here is a gzipped set of xfs_logprint and xfs_logprint -t -b -i. I would provide a URL, but I don't have one to use ATM. The issue is that I don't see any "ERROR" statements in this output, but trying to replay the log or mounting -oro will oops the kernel and that one device is then unavailable and the system must be rebooted. I would like to extract the log so I can put this server back into our beta environment. If someone could aid me in this I'd much appreciate it. -- Austin Gonyou Coremetrics, Inc. --=-kEbuFixda2EUEKhe1aeA Content-Disposition: attachment; filename=sdb-logprint-simple.txt.gz Content-Type: application/x-gzip; name=sdb-logprint-simple.txt.gz Content-Transfer-Encoding: base64 H4sICEKPnT8AA3NkYi1sb2dwcmludC1zaW1wbGUudHh0AO29a48kx5El+pn9 KwqYLxIgAuFvdwLzQSOSi8aVqAuK2pnFYEDkk9NQs5uXbGqk/fU3IqsqI9Iq LdPfj/LgLkbNIDPo4WFhduyY2fF/HH/5/v3HH376+d2HT1+8eRj/2m8+bR72 h7+/2x2+eBj+oclwujz+S5dXx39xv//5iwc6GEU0f3h/+PDDp//+4sHIYXjz ZvfP3fvx3ySf/f3w8y/vPn6Y/vjZ+1+m//3d8Nmnzbv33z//3ZvHXz58PD78 cfyPfHvYffx5P933s59+Pvx9vHz85fDpi4fPxxt8+PXHh48//TL+7M2vv74b /6WdIkoed4fPd4NUn/ODYJ9v9VZ8vjnSgWwNPdLNcVz88ePPP27Ge7x/9+nT +8PD4cP+3ebD+Hcffv3Hm88j/vXmzz8dfn74zfDbLx4+TcvbDrthP/6/h2l3 vnjQDw+79+8OH07/7I9//l/jwt5vfhgf56/f/OnPf/3mu4c3f/3w48dfP3x6 OL57f/jln798Ovz45s2/Rvzr5nuhF++FYu+FCXn5ZobFi6GyjTez03LPB6qf 3sywfDPfffv7b/5yfjd/+e73345vJsFiCLIYIvHVfPj44fBmuvTF9FF++udP 48v8w7df/f67rx4e/zr9Znj6m/G1fP9uNKLxhzrFE1DkCSi/8wT/9tevxwf4 l58P0xU6rvSXT5ufPz1s3//tw8cvHhjhQrFhfF3/YMP4F/3t8848PGx/3Pz0 8Mu7/zsZ8dMqGLaPVN9Zxu//19uHf/v1eDyMfuw/pr95ePP36c/jf+eXw//3 L188yKdbSSHY9FZGJ/kguRwf7+ePH8c/EzV+JX8/vD/95Pjz4fAvk3cc//zh 8D/vpkcZXeXwZvvr7m+HT/85PHz+wP5runZ8+uv+H59/y8ffKs/f6vG3hHj+ mNDp18L313L6tbn8dQpL5Jgl3jOB+5aox9f9ZIla/3Z25QtLpE+rEN6WOC7j 4cvff/f7FHsjkVUJemdRb7/585dffbHcnCebHkP8htHzv3yy+If94148woXp r3kP1TB5hLNz246R44sHLgf9tEKFrNDc84SnFT784c/ffvXmx80P73bjUrjh h4cfP+4PDwMZBsmHh6dQN36ij9FmfF0fxgjzt/HCGKoexMAefjj9r3qz+fTu x/GH/2BHvWVktNUf4YUduPBmeurx74eHD9v3H3d/++X058M/Ps3Xx78Zn+D0 D9582Cz+blrP3z5OX87D/sfD33/c/PK30+X9j6MRfjr9+s3paU9Xfzh8OF1J YCE6hYUMh6O9hQjNhxcWwsaLTys0aSyED0qIlwbCngyE3jCQMUQdmLY3kOO4 IwsbIRvMSIio1EoIhp7cnCx74WSZlFzrk5Nl4iDuOFmC4iZ7L/t0Jwy/jIZX 0F8TDNCEBrNxn+Xotp/2+XBvn7GYWjaaESzIRrDCMSI9785+uLM7WFSl4p5L glaIRb/C+4wFhUBwf4L1w21ETzB3f39L/vLX//erbx/+7Y9//sP/c4b2b97t pqx6fMdSTTD+3YTUpzc1QZj9uK6JURjMQNQJxP9jymmTpEse6ecf/vynP71N k39S4EjFUDIbphRZjWs6/Pab3//hu7f/+15CTJI8BEMeoh6sTTmyxIbANuWy ZbhNhfuH9+wH8tGB2ooOlMQAOpAu6EDeCFH7+B5UTXTgeTGu/u8v499/9/2/ f/v2LicoMnCCyjOXZDc8oJg9IJEeLpAhS2zWAxI0l4zhAa8ybPbm+dV/fPfV N9/9ZXqb4y5N5aUUZieQ5cWgoqk5U9HkNnCV2CZZUNFfL6nor+9R0W8mAvrh 37758+OX9Ydvvhvtd3hkox8vk6er5A355dPp+3+/mf7Annhs/shYP8JfyoSY vpmPH344TP8SYdwkiX0Ke0/BRK3kXD+9J3ove9PIKqbvt1zKZdLtDeHPJDbZ 3MtssahYdnMg7RPrC7fKR7GgljgflWnzUUg02eCfhPkoJJw2RfNRyDNtfPNR q/IsSfOCJfIMgd8MlXR0KCcmker7BVrIcM1bGV6hFVcqtEIM5wotI1rwq0Va sVZpc1dpIac422NYhKNaSaoe7XF7YOpehDPe9pgywkF6cBNOHgmmDnxjSR5R xYQZXmZOVMgBoQw3dZBHdDCXqdN0YQcuvIpKLWRJfW1kkV5zyfaDup5eM/rC SNhAhNQvjIQoQxESNJaRIMVaalOsleygmb2NkMtiLcXMhMbLryEve941du/N 5kmwIWnp6bv5SyxBJBlD9+S71WHL71QlKQZpnKu/1B+VwDthYa1wPMHCXBT0 R87o7w4nwrCwFoEUAehvQYpMuE88MSDTn6U3NTJBiwUzIpRKwpsyLLTGwEaP 3RUTNtJ3sBHDAgwhd0NMSmNmWFCJsj3DGTrecT8M89JlP3UWxzm/aIo4fepP uzN+6vTe7qDOebDxOUufyiJ45xQbjWYw6Vko5p+2OLFQBLBQIi0LxbH4UFU1 lF5OR2ikHErIwC/LoXo5tiJaKofuaiqH7pYpR7vl0PNj+OdrL3L6m+VQi6Se IUtsKKenjC/LoWhan64eam+fReqhu0jVEkfsL7FNagX6E3IB/YXJUBOd31Ug eHND/tr7XQHoZsJvlGCTYVnTc5dDEwhYxqxld7A4laO6igWglLhWG2MSV1ex CFEXrpWXbX7o2K+EwJYuG/3o0BKyPZatLCOLSVJYVhlA7TEqsWhdVmbYPpas KvO1qlx49vcYkxm0LyoLb2vMOPt7XlVgSXkbWlLWY6Z6FfyeV1g4+zxIkH2O F3bgwquoKOvoFvKioLywEK+CskljIrHryTcsJGs9OYGRwOTJ08eG1hdg8nT0 ry/AhKcSfw1zIc+NDq2yw9zFZ3eut1EG3AmLZYXfGBbAcmTOmPOOnDkPmTNn zOFXlTkzZpk5iwFImY0595w5jxGxncyZkIpqQvNimq4JzY8RWBNagnK/mtCM yhmyxIZQ+Qgsy9aEHOyzRE1oXl7JmtBikxqpCQkjLmpCnKWvCS3eVcGakMu7 ulkT8rpRgk0mWHQrWhOqZnewOJW/JuSyJSHIdszpc9aErOBUyok7EBF42bqI RFaTDt7JDBnh/BxhlBqxJl0RRk0aQq8njvMSY+A7jgvq3cJ3/KDMC07tSAC+ O5JnfKfMIHYLhKdRRT3GaqXVDPIa8iIyMHi2+PBagWTKXEAymqbqSbC3lRWT gREwl7cF51ZY+J1S7DOPss+hqIxiwbHw7mBRMtgKNeHsqdx5HF3xnd3Bglzo 9FQ1+5zIN1t1+vs75BD0KxPrHzLMgdbF65oLXncED9d5XckYveR1GVvwuqKl jigiLRKRbLzuBXZtsSNqfoKSHVGLfSzZEcXWjqiyHVELayzYEeVijfk6ouZV BXZE7QI7otig6HXq97zCsrUXNoDcfLqwAxdeYUdUDAtJ3BEVzUQid0TdspBX 1hHl62OvNOqEdER5OdnrbP/5Tkq63skfhiQtZ8SJisGtVRHC4nW+fH6gwCMI qnljmCfOfwSBy5a4pODc5E3BIdVrk/flO4KAmJqOIJhXk+gIgiSNA5DUNfVV nyDBa15B9Ultm6s+QYLbFGKSJfbVBSp6ed0pxT5r333+6uu38z6TZ+/xZEun KyfPciYTdno6xcjoN795bAIUw9787mEiZMRv03hM4+6/E4YTyJuXDSeQ7k4d TpI0MzAsJloY75d1Gy/DImVmfTwsGjZTfTfLkwNSVd9ZnGgVLACHRqvC+nhY 7MvbnMCwWOcczBkWWvRdlJhynzkWYuqB1xyLOyu8zgmvORo507MXHAttadkL TdOyFxwLlWXgJsdCUhG4ydHI1NABihwLYxW5VyzEre41q3sNSD3zNROJyyFR Zqx1Q5lpVTiUbGtqJtpqTzdY15Do+TECh0SXfQpeQ6KLRgWGLLGhRgW614WH RO3ts8iQ6DZSzS1sSHRrX32rhBM5naU2cyIkCVpS2LsqOSTq8K5uD4n63CjB JsNOD89djj0kWsvuYHGqwJCow5YE1ehTH8uIRYi6kK26QLYCa5MnRhDQJy+W ffKEy5aw7aEi6dB5MUka5XUGWHuIRIqdzmlmw/mcZrdG+YNLyeVOozw4p/mE DSSX50Z5oq51yQ9rk3zhJvlDpHrSZIlaPp+2POg7YV14W2LGJvlDOAsn5Xa7 0ZYs3FQIZtN/C+SedOD6OvQ9xCThAnLPzR7knuOFHbiQu0k+CT2h41vI+LUc jrYWMn1lFwIRT+zEePF6NhHLQpAeeWbTIy/UmE3ZG8jxskeeoAIHRFRK0sLc ydPJvshQJwch6ClDZUwc7mWoMHfy8bLX053znRy65FPsMwZoQoPZuM/ysZVv 2ueDm2xoLdEMttzHtEI5nK1wf88Ksag6Oq2wfv1a9hkLCgX69R22xIkL0Hm5 ANivb5N+5uvXp0PRSg/o159X01LFG/Trzw9RD9YG/frzEhsC25TLluE26NW3 +vBS+oHLUDZJrZb0AwpZTRJaLEmbNZgRmB8hMHQKyqk5xU8L+QjQzb/Yx3Ba jFyhxbiZ7vtIiwki6DVibFL2WpmxvMwYGKNYGGNYNiHkSTFkMsbN6PvvdBIT b2NM2mdNkWX5h2tyUJsjswzXxmh1pT+Na8mvjzXMKywcrbcEROst6E8bL+Sm xpIgOjDQEctEDpswE1me+CvSmEiAfoQ4iClQWVsI0I8gCRt30hgJhqACOYnp 5fOTjz2yvbg3zIIBJ2dGgmH4pbC3xhBNjh58LIpGZiRUXkaCY3G5UA8+iMei KCMB5i7m1bRToAczFvMj5K3Qg9mKxU4mKtGLORe5XqLnFzV6uT1u1mQkR5le JrRHas72eKchFQymuNnjnY5UYI+LjtQJMZ66Ts3g3YtKmZiEXs/NqIRxkyYy aOxNBXdUSM7105ui98osYDBkXsaUvZSDImJItzuEP/ebkM09UUbibcdJdwcL 48xiqHoBh6/W6J7bcZg4zsZzSozm/WHPC0EjuGupWGCB1P1O/rEQ3glzpu53 8veH8E6Y23C/E/blO99JYh+r+50ifG9Pd8I+Efc7RbNxGc3GZTQbl9FsXEaz cRnNxmU0G1fRbFxFs3EVzcZVNBtX0WxcRbNxFc3GVTQbV9FsXEWzcR3NxnU0 G9fRbFxHs3EdwcYToEKNfTBRUOHj7NWECg/3UKGO9r3paN+bjva96Wjfm4n2 vZlo35uJ9r2ZaN+biRZTTLSYYqLZuIlm4yaajZtoNj5VrqPdKpqVkyGamZMh mp2TIZqhkyGapZMhmqmTIZqtkyGasZMhnrWTeNZO4lk7iWftJJ61k3jWTuJZ O4ln7SSCtSfAiYTEoZ5f4kS3YT5C4n13NMJ3l2KrYQt4rHqMVZM/7Ph22JQ7 NXU9DOeaOiME1NQT69oR2ARuU8VOeS407PguW1UnsPu5wbI6gS3TherqBDZL ly+ss+NaWC9QWCew57xU0IRt5wFBE3Yu1xI0YTPzeV1BQz7jh+Iw5DO9EtgT OpwXiAXWtWk406Q0bNuOYSKRJ+oJ7GyOZSWxZ+pvGMkrmKmH3dvR/PboJLiR z+PM8t44M2xhDvHbGCihbLDuRE6y16l6mhwH62Ejcy2BDTY5x7RFl9F62JU8 V4qcZ+vRjuLSW40FiByJN9oVHDnxhifSp0680TbjqrT2DNDaU4jWniBGAqk9 tZDa47Qhpb1JGrMk54AspmkV6fkx/FWkX4gL3FSRtlAXYMgSaxMX2A4QVA7P oJIbmmkWTTw3OfuaZwkR6Xl5eXv2JbZJDbTsT6Kz6Vv2FfaeAtGtW8e+RlZR tmHfpNsbh359WH6tZHNgKTfWF25XBfL+roOwKEmMRbFAWKgGBELMpmwJSCCr aQyPwVr8xpPlWwCyF/IRNwHZff0IWOM/L7EhKpiKIdexHmevpH0tNA8kg60J m0j0waQwpM2zwtAdRAabGjb2NMJdSEZQSEa5mKbUT/hLGKGZNzCbDgVZHnbK Ex12CpssNpFox0k1w4gT7Xjk4njvZG6KrMKBVEuxOSzN5ig6PGnKbo4HcweX wQ4JB0tOujdYnMyAy2CHg8OWhOAyLtLiMtgwYQOEUkrvgTizLyu9Z5DVNIbL YOPAPgpRdlmgv0uU3arQww6CfSU0mRMqOx5yH7YG+xrs7TMPKoNV/30ZpgwW 9vctUWXTeFd6qgxW3fdluDJYdN/XwQfBAn7M3XFgy2C5vpbdwaJkARkyh087 BJVRkxaVwYK/DQzKX7glg7mo3Bqsckuk1peVW7Os3FLTUuX2WJYqRBaTSBSe ZijbHsNZwshoFFlfu2A0+8G/DoZZpGZ7tGZVvvr67RyjyPPn8bRppyunT+fc zb7Tk3kZ/eY3vzxa5o7y3z1MQwHit0k8gnR3TwkTeFWTs9R5nWUS7Xzjb7hf 1m24sPh7jMTmOWaHsNh7tCf2ymeH04k96bNDWJO2N8K43QJYYC7duxpld65N GrnkzrCI7LM718u4tewzFltqwY2wSLoCRxvgCEu3tSFHWNWNFaasik7+sSmo 6MQTF52weFKo6ITFlTJFJ+9Myg+1pjn3DQtGtfhqWM5dfbWNr4bV4up8NRaB 6+JNCbfjTRmFEy8T5bogTlsaeWG0opGXeTHtiGxQ5AnySmwwbB+LCWwcVoGN EidXYNYYTAm4yGsIb2tMmalKZFWBehgkUA+DCnmVpZ0XWBb88GFzCX6mCztw 4VXoYej4BhJZDcOksZDIWhi3DOQVaGFgACqC/IAgZ3kGdY9YRKGTu+wfdqfH gF9OCCNRMHPUwcBiamHeFQuybrvDr+6OgwoGFlXdzRALf+53whx54TeGee8c lCXmtOJSloPJTFliTrAuZoHSC2aBDAZrySIDB9QC4QtqYQyKDVELvKKerHkx jU0JUOQxAinbZdbiRdnOaQtDVthQ2kKPKveUAPc1zxKdWfPySqppLDapgSaQ 6byY3Goai/eUtctBe78neGRG+I0SbDJM+Tx3ObjTBg1pheXZ0/gKK10OLPik xbXTzdNqxLkjqRK4Vl7iWkoxkTgtwajBhIlnXCuGlnCtqqlkpnxLZvXMGszP UC2oVQ1y8QDU5se09qZZBNMqa8bMfdqAbPR+yxdN2yLjtIGVg8o2bVDYXeq8 7jLDtIGT4X5Zt+FCZK0icaJh0wYLK2kg0eSqwLSBgxGmnDZweVMZpw18dyfy tIHX7lyv69Syz1hsqQc5wurTCh095g2qw46wgBYrUHnMG7h8i0HFO5Z13qA0 aqVYZKlh3iA5bs0xb1Cjt6ZYnFu9tf3EQX3eGovBhVwLCG6maGEc6M7Nq2mn 6R4o082PkLnrnmI7Waztfr+23RdouweSegt7zNp3DyT1XOwxqRSZQJYV2HlP AzvvBUEU7uYVlkUBig6XKGC6sAMXXkXrPdDyi2IikXvvgc5fNBuJ3Hx/y0Ta b75nGJKK0BPucA4lxyDUmFiUFH3kKC7K2jLP/XFR0t2JE6VDW+Z5hCj9dCcs sLrfCQuAhd8YFhZyiJhi/j4y66bzsm7cIxct0FrEDGgtkkhrEVWGwtYiuTyA krfUWrSrqbVo58s51tUyv4vEOi7TDS/WcZFvICtsKN0o3zJvb55F2ot2kSpE YS3zO/taUflOBkYKtMzP76lky7zDe7rdMu9zowSbDBt7PHc5dst8LbuDhagC LfMOWxKCa6nK2zJvg6RSHmUJosGh7CykRFbTUtM47P05P0Q9uA72/pyX2C6w K9D7Y2+dZXp/Dta8kXPjuBl2Sphl/61M2n8LW4ts3FTKQjmtyWvCjqDUXjNJ 7zhsJHIx3i8rN14sxubNuGAL0cGeKCyfcnGZI+WC/UL2Rhg1G4BtQQ5vKukB qlj8y5uRwr4gn9253p5TyT7Ddp0KASRsJFkBpNWJm1iMqwRAwgaYWIHKJt2H rS0O32JQGYumTfdhw0hh4AqbQ8oCV9glkRq4Jmkehz0WFXpr2G6xemurMg4W hivx1rBNxMW1ZKyQcyC+wVBROfZCr54t9eqJaqhCzklFFfJ5Mekq5GlIAeQx /LstuWR7srXstqRsIELqF55VGqRCPq8whmfleLflLc/KD8poBjyrEsCzKvHs WdVmoHLhW/UWc66MV9puyZG3EIhbqaRj1k4m9Er1fYJFYB9dOL8iUH6FES3E E5ky/Vl6syxKyKUUnJAmSdeLxN5VGIlAtZJUn0gEuj0wfYdEUN7vCnAIOvxG CTbZRNnklx/EaZOH501W9ySpsZhYuKqNRcdgE9SEP3Yf0+1xdMJ3dgeLbu4i CFgUqkpsIppbtuoe8HfGQd0DMnH3AOY968L8YrjE/BzrimVCQczPl12xVLeE +VnZ5glkMYnIFJYB8DNPLiUf4GcxqZRCgF/tWgf857cQjG+cIrjAvriKzo9y 2BuvLpBBD0+FdCGGnUlaSFfu7jYhl65rcv4mr/NPwvbAdMHFcj1aQHJaLkw5 5kfLylDAlMPBY1VCUailiGAqigLmU/HCi1v6jEU5Qu7ioYxHOvluTyiFA3Mh n/B7tWN3vpO+i+qS7jMWYepBwwSLOysczgmHKRo5s6v+uXyGQY0bJC3TQrFQ WYXqX2G0SdHI1FDjBsXCWD3ulWIhbnWvWd1rQOKZk3XVl6yrGBDWlY8oC7Cu Yliyrk11WsiaOi3Oi3H1hF/+9U9/+j+kiB9EnsDfDY4pjp0LvNK1NlznWc+r SqNiRZ4cn7itYrU3auH4JlkrTRaOb3T/Azdzx1rLSmfc/SNLCH9AqNZF0Y9E FtOOLqlCniCvLKnG9rGYKuluVSUtoEpqMGsMHrpyESWF7LODOeZsVtHhWcqp vZxZhmisu1xJjZDKOmaS4ttdvtPHw36ZpDxe2IELr0KUFNLVMUwksigppLJj 2UhUUdLbJtK+KCnk7T0d7cv5zdFFiIGfRUnvOVoUP4Xy9vMDjTi8IuI+WkRz kzeF5HwlEQ2S1Z67EypvCnlrfzOEVHHAnTBPXviNYd47R3kBc1qRywsqc3kB c4J1UYoSUooaG94iA4eUol4Ob4mWKMVtTZTi1pdSrEredH6MwLnYZeLiNRc7 Zy4MWWFDiQs9mrLypg7mWULedF5eSXnTxSY1oLXDhofs8qaL95RVTEZ7v6eb 8qZeN0qwyZDU8tzlyPKm1ewOFqLyy5u6bEkIrqUi8YASFh3qwrWKWuJaRqmA E0pyCWwZaWpEaV/TiNJ5MS3Ju1LkGYJg7XanXWAtu9I2RAeO4NrzEkviWjaQ y66h8cLmAteeLjzjWrY55JZ78bXNIrB2b02auU71HAkz4rDVz/KYmmzTymNe QmUxFM29FbKYljyURp4h0EOZYA/FBn4VLc9LLOyhNnt7D0WP+9z604OvceZx UQDlz+tL4qPohY/apfVRMFOwgVEpVfuZu89MuRwsdpYBmViobGoWUvrH+y/r jvewaruPVE1yZOhgkXZvX1gqT9FxkYOigwVkeyO8z9G5yGFjOax7fRVNQMvW V7HokpcLhdXngH1Gk6my+4xFhopyd1gYXpN3G2gMJ3Rqy94pFmxydFBgXjxx B8WQlmlmHsxmSmVtLLSUUdbGIkpLA5oMi0cVuWuGRbrVXd86CME7Rct0EAIW hAv5FsBK0rK+RSOraYkjBUcPzA8R6FuOob5l0TQPThaY11jUt4xJBbnwLacL O3ChoGw/8TXPTLL9FFlfmkrOfstnZme/TcrsgBMJrPxUQrfJuTtLms5tcoGs piVakmPFuiS0ZFaKn2Olv7y0JMeqdy3QkjJL5yDHqod5aUmBluNc6TKBFc7K 0mWCpttnB1pSYMUu933GAkLhfcYiQ0UFe4E5/rVifwOLCu92kkxNRViwyUBL CsyLp6UlReIGWIlFhTIYWGKhpYxyChZRWqIlJRaPKnLXEot0q7u+4a6ld4qW x11Lj1bJlL6lKlpSZqYlk+TXEqMl07T95CSHFMZm5s2vFUoPNpBfqyxtP8qb oYyaXyuMTXTO+xQPv1OKfRbp9tkhv1Yy2j5jAaHwPmORoaJaj8Ic/1rruQHY NBZTKgFsGgs2GfJrjXnxtPm1Stz2o+uqMWkstBTBwBqLKC3l1xqLRxW5a41F utVd33LX3ilaJneNBeEyvsWA6CaKcneGIKtpqe3HUOQhwnzLfhfqWxQ5qxIZ hqyxpG/h/Kjo0rc8XtiBC7Nv2WT2LYb7mmce32IEsr40w5FLZocOPCmzY6S7 n0rpNlVVblPndZtJaElj/I3Xo+0np/GOXhF7trzjiAMaXxsgJk2Wxh8yYOE7 LzNJBixEu0sYD2jcKiwc5h2vopKTZMCCi8dWY4Gh9FZjIaIiUEoGLASsqPSW ZAfU7KgNlhIo2hEr/Flp4BHMn6flKHVqETyoz1EYEROCBZkyAh0Eiy0t0ZSE YJGpJrdNsJi3uu2bbts7a8vltrFwXMjDAI0OocpKAAGhj3k5LZGVBOiCzE/h 72EEUwembD0MVUxo/dLDTBfPi2TIIltqNWQ8k4c55zVAIsXBQjN5GCCWMi8w zZzibjs8cT6CGbpJrOYm3b1VUu8JovSmLD4DaiXzctryngZ5ikDvaS0fgXnP iWo6C/kNyCILe8+duPCe4+2OF95zuvDsPTkRmbznLJ5OfC00k/cEAizzAtOU ey68J0vsPYEui5W3SiqGiYXSMt6TYYGzpYoPYViITNOJnjX8Qz2V+dnCOC8q 6ejaycR8UW1R8oFKKrOlhJd8BFryYURPQ3Cn+s70Z+ld+FHC0EXdR0iT5CAp AsVa7G3xzvvSSo4v6vS+tmNadO88RSjIMr8vchdTJK0gQM0Tzw16Uax53CD9 vEH6XrEGaps4GDQs1kAtkfOt9F1klHarsWBTU04OtUbWnNwqJ4fqJtXl5FCj JFbgsirWQGUSh4/bv1hjplOXE59YhEWXQnAW6ooUhrNQnCQ1nE1TrIFaJlW6 bah0srptK7cNZV2qc9tQ4KW4hwFxblfYwyhkOU3RjVBLZRfJw1jLQqB0Ix/O dU0ourKrxMMc9dLDbDYbvVt6mNOFs4cZ/1sLF8Ny1IOhqou9iWZyMVDnZWed AXpVa7ab3UzX8N0jXcMS0TVQNcbGXaV0n1AApnC1Bmq9pK7WJDrvRiBPkabF PCthDnVb5mfLyzdCwZbZUhrhG+WUHKbnG6GUjL0txuUboRrM/L4K841Qy8Vz g4L5Rijm4mDQkG+EoifnWxXmG6EKSpVVbCiwslaxrarYUACmuio2lIaJFbis +EaoJuPwcYfwjSR1cziUoyldPofSM4XhLNR0SQ1n0/CNUPmlSrcNJWJWt23l tqEETXVuG4rSlPYwUJbmWNjDSGQ5TfGNUILmGMnDbII9jBxTvOdFamSRZT3M dkMvKxrThR24cOYb+S73+AkUorG30EweBkrTHK0TQK/2xgu6USRma6DQjY23 Suk9oWZN4WoNlKdJXa1JQzdCuRgXvtyjvTErXw6lZuZny0s3Ql2Y2VJaoRvp UtYiGd0IBWvsbTEu3Qilaub3VZhuhPIzcTfImm6kUCqmlg2iUDumxtozheIt a+3Z7mhrKDZTW+2ZQgmbWPHG6nBrqFPjEGRCWMLp5ilZQgp1bwoXvSkUzymL QinUzEmNQpOwhBSK6lTpt6GEzeq37fw2VNapzm9D9Z3SLgao5khS1sUA0Zx5 OS3RhBRo7cxPEehitsEuxpAzsAZSOvMiC9OERwlowvHCDlwoRxNSIO7jYKG5 PIxGFpimK3H0+DPLItPShBQo8Fh5q5TeEyrwlC2yUKjAk7rIkoQmpFCBx4Xn 9uhKzMlzUyjcMz9bVpqQQiWc2VJaoQnZ8liuVDQhhYI89rYYlSakUDxnfl+F WTCoohN3g+xpQiifU88GYWXFikrGFCrirCVjKywIFXFqKxlTqIgTK9xYsYRQ ssYhxoSwhJwlZgmh9E3hWjWF2jeFQSgUsUkNQtOwhFCupk63vXb6eLntyjt9 KNS8Ke1hgNTNZBslPQxQvJmX0xRJCMR25qcI9DDWUtaYh1lIWVOgvDMvsqyH 2XF16WGmCztw4dnDMJL7THsKtIAcLDSXh5HIAtP0El6QhCoxxwIEe6y8VVLv iRGyhbwnxqE2RRICwR4nltujlzAryw3UfxbPlpckBPo9C0tphSQUOXoJqcBq qJlJQoEWTwtzYAKrh2YmCQVW8iy+QVhRsaaCscDi2FowvoUFhXe8zYQFJRpK M5CEEot1aUlCkbqVUGKxsxAIlXX1+cjMfT5pSELZQp+PXPt8fNy2rL3PR3qk lUk9DIhzsqyHAXI5Uib2MGlIQiC2Mz9FoIfZB5OEnPLzIimyyKIehhB26WFO F3bgwuxhspOEQGXIwUIzeRigMDQvME0nodnwmWPRiTkWIANk5a1Sek+FEbKF vCfGoTZFEgLVHyeW26OTMCvLDRSEFs+WlyQE0kELS2mFJJRZOgk1VkPNTBJq tHhamAPTWD00M0mosZJn8Q3Cioo1FYw1FsfWgvEtLKi9420mLKjRUJqBJNRY rEtLEqrUnYQGi52FQKipq8/HZO7zSUMSmhb6fMza5+Pjtk3tfT7GI61M6mFA nDOFPYxGltMUSQikeuanCPQwh2APM8bXp0UyoOMzL7Koh2F6f0kSni7swIVy JCEDKkMOFprHwzCgMDQvME0n4QVJaNJyLAyoAFl5q4Tekw0YIVvEe7IB41Bb IgkZEP1xYrk9OglzstwMCAgtni0rSciActDCUlohCXWOTkI2YDXUvCQhI2jx tCwHxghWD81LEjKClTyLbxBWVKyoYMygys9aMLbCglBWqLaCMYOSQrHCjQ1J yKAwz7w7w43/+h/+/M13b7/561cPQUyhXrYTvvnXiH+92f1z9356zM+erHr6 42fvf5n+93eUyc8+bd69//7p74nQY4j78MOn/374eHz448cfHr497D7+PD40 o1TIz376+fD38Z8cfzmMCyWKfvbZCFgePv407TlXb3799bR7iih53B0+3w1S fc4Pgn2+1Vvx+eZIB7I19Eg3x/EFPX5aXzy8f/fp0/vDw+HD/t3mw/h3H379 RwrbwgLSLcv699//5fvp/T589c2XD2/+eDh+evg47uLDaGWTezj+/PHHh19+ Gh9gjOw/PEwgM4mSbl2NBlVlEHnzhyT8LhbKKoq3WNhYo+2NaIuFskpiLRbs yngVkN5ti3oVgyymJU4XJmDbSG7lGOxWDDsfNEOQNZZldM32Un3idGEHLpTz KzBztDfPTMfMMGR9aZo+9WZxJvAm8Skz3N1NpTxkRrizyymPtM5bCktzxAxW XkzT8JmzGAFlXedHy3zADGYmrTC5Jku7J1btzNztiVYPS6siptwe+15PrL5X ens4sq6KCvoUi15rPf/mWGHd5XyKBtAcbZ7eoSWAuyVD8i7PypoIakKdzLu9 pSIKkGHRrCJ3zbBQt7rrWyU3LBBX4q6ZRwqZ0reA6HYo61sUspqWiEAg8To/ RJhvmfqA7X2LmSqowLecPxGDLLCkY+FUTzeCF3bgwuxYjpkdC1B4dbDNPI4F Kr4erBM0r67OCxZwm5ZIgeqxNk4qoc+EMrBlaydQ7zV18SQJCwjVV10obI+O zpwUNtRt3dr0QcRnAaHE6mwmjbCAiuTo54TKr/aGGJUFhIqv89sqS3NBDde4 22PNAkK51Wq2B6sUVlQDhtKnaw3YBv1BodbaasBQrzVWlLFhAaFGq0NoCWEB SWJBSKjwWrj2DLVcy6JOKJGaGnUmYQGhjGqN7hqqra7u2qoVsPKWHajtWti3 AG1XNRT1LUCjdV5NSywg0HCdHyKQBSShLCA9H0YF9FLnJZblAc1AL3nA6cIO XCjoWrSvdWZyLQZZX5puQGUWZ/Hu0lIpQCDWyk0l9JpQ6bVs7QRKuqaunSTh AaHAqguJ7dENmJPEhtKs86Nl5QGhiupsJq3wgDRHNyAUd7U3xKg8IBR1nd9W WaILyrTG3R5rHhAqqtayPVBhtboSMJQ2XUvANtAPCrHWVgKGeqyxQowNCQg1 WB3iSggJyBK3AkIF18KlZ6jVWhZyQgnU1JAzCQkIZVLr89Vru46Hr4ZCrbX5 aijcWtixAOFWxYo6FiDAOq+mJQYQCLTODxHoWGioYxHnk6aAGOq8xKKuRW+2 5sK1nC7swIXZtRxyuxbpa52ZXItC1pemE/CCAdynJVGA+quVm0rpNTGutcw8 8IDxoy1RgATopzoR2B69gDkJbAKkVxfPlnckGMikLiylFRaQ5+gGJANWGM1L A5IBLYlOdylHdJEBK3PmJQLJgNUyi28QVi6spw5MBiyMrYXgW7IwxDvcZtKF IWgkTc8HEoKFurSEIE/cFUgIFjoLSdKQqnp3CMncvJOEEySk/u4dQtb2HS+v XXn/DiEeSWVKBwOEcZQo62CAQM68nJa4QQLkdOanCHQwLNTBqPMJUwRo7cxr LMwOHjaAHRwv7MCFcuwgAVJADgaaycEAHaB5gWk6BKVZnLF7SEywALUeK2eV 1HliXGwh54nxp00xhECfx4ng9ugSzElwEyD2s3i2vAwhkPlZWEorDKHI0SdI GFY4zcwQMrRkWpgAY1gZNDNDyLBaZ/ENwsqJ9dSJCcPC2FoovgUFmXe4zaUc jUbSDAwhx0JdWoZQJm4ZJBwLnYUwKK+qt4fwzM09aRhCXn93D+Fre4+P1+aV 9/cQ7pFUJnUwIMzpwg7GIMtpiiEEUjvzUwQ6GB7qYMhwPqaIACGeeZElPYxQ m+Ow9DCPF3bgQrneZAJ0ghwsNJOHASJB8wLTtBBeUITHxAwLkPKx8lZJzxTB 6Ngy3lNgDGpTFCEQ73HiuD2aCLNy3EAJaPFseSlCoAG0sJRWKEKVpYlQYgXU zBShRCunhRkwiRVDM1OEEit4Ft8grKRYUbUYqvas1WIrKAh1gqqrFkOVoFjR xooihGI7DiEmhCJUqZsIoUhP6TI1VNYpjEFV5h6fNBShaqDHR609Pj5eW9Xe 46M8ksqkDkZWRRECXZ3kFGGiozMx3jVNH0xWlkZhJG7mJFdjNGwzSa7O0gej MSY4c5KrUWq1cA6nvSnVuEmuxujP4hskkIXVVPDQWBxbCx638JL2jreZ8JJG Q2mGLFejBcukWa5J3QhjsNhZCIQaLEaVAaFQcyc1CE2T5UKtnirdNtTiWd22 lduG+kDVuW0oxVPcw4A4tynLo0G5nE1iHi1NJwxU2dmE82jkMH5Z1q12xowY ++UpHVwOzzwahdI7mxp4NDZMh+T8CC/swIWzg2E8k4Oh520jvgaa6XB1KNiz sS5NejXCCMOfKBZyGLFbUoqFQhEgG2eV0HlSKLazLwrPKNTc2SeGZ0mcJ4UC PftI8EwEwzN6PumcQvWefRXwTJvt9gKenS7swIVy8IxCbSF7C83lPQ2ywDST xrP3FGwzpCWoKVT/sfFWKb0nFPsp7D2h/E9q75mkwkKh2I+LAXu0EeY1YCzc 5q2wUKgYtLdnv+qosJxItuQVFgo1iextMWqFhULdoeX7KllAoFDZJ+4GWVdY KBTwqWaDoJJPlVgQ6vusWNAKC0JBoeqwIFQTihVubCosFGryOMSYgAoLHRL3 EVIo5VMahEL5ncIgFKrvpAahSSosFIr21Om2saC3uu1bbhvK/VTntqEOUGkP A/V2jkUrLBTK7hxbrLBQqNFzjNSpLIM9jDgfhE6hgM+xhhKL2O+0uvAwpws7 cKGkh5G+FprLwyhkgWlIQm7mM183JDHHAgWAbLxVUu9pqvKeUAEotfdMQxJC vR8XA/YgCbMaMNQOmp8tL0kIRYNmS2mFJCQ52rAplCWyt8W4JCGUHlq+r6Ic GBT3sXI5f/jzN9+9/eavXz283KVvRlv56ed3468+/PDw8/hyHz4eH2Plm3+N +Neb3T9376cP4rMnnDL98bP3v0z/+zs2DJ992rx7//3T3xOhR0P98MOn/54W 88ePPzx8e9h9/Hk/+Qki+Wc//Xz4+/hPjr8cRlMcAcJnn41u5+HjT5PLocOb X389bY8iSh53h893g1Sf84Ngn2/1Vny+OdKBbA090s1xfP5HsPTFw/t3nz69 PzwcPuzfbT6Mf/fh13+keH9owLgBVP/993/5fnqDD1998+XDmz8ejuM7Gndx fFs/TIDv+PPHHx9++Wl8gPH7/OFhChVJ2pj8P4hSS8Z8f0VZARYW1pzgRk6A xYhKMgIsdGQgitHgkJQmpokb8bEEq0wS4pESJTxpNm8CkqYFHwuKFflp2J2y Omq7syTq9tSwPaawZwEdLZqWne8RyGpaooZB08n8EIG+RQX7FmXOI60KWWNJ 3yL3R86WvuXxwg5cOPsWMWSfyfQ1z1yzPcj60tDCTM+HfGxoYlZtcPdTSVtH a3KboJEludtMwwkzf+P1oISzGi8WZDMzwmh0bYUQZlm6RrH4nZkPxkJ0aToY C4KZW0axWFd4exgWqCpCfwyLXiv6u4H+mHeUzYP+GBpA05OADItwaVlAlrhZ lGERswzqZFhkKoI6GRqgGiICGRbNanLXWKhb3fWtig0WiCtx19wjhUzoW0DX iuZFawygd2VeTUtEIGgsmR8i0LfoUN9CB/6swgGaTuY1lvQtmtIxq/0RXtiB CwWrwdLXPDP5FoWsLw0ROKZtM5fC0nIp4OAsKz+V0m2amtwmOAArudtMQgSC A7KcjNeDCMxpvAILsnmJQIFG11aIQJ6jM1Rg8TsvESiwEF2Y6RJYEMxLBAos 1pXeHixQVYT+BBa9VvR3A/1J7yibB/1JNIBm6AbEIlxaIlAkbgeUWMQsgzol FpmKoE6JBqiGiECJRbOK3LXEQt3qrm+5aywQ1+KuPVLIhL4FnGulVdEiAzjW al5NS0QgONVqfohA32KCfQsbnvW+walW8xqL+hZN9IUYxeOFHbhQzreAQ60c zDOPbwFnWs3rS0MEEr0Q4+NpuRRwPJaVn0rpNlVVblPndZtJiEBwnpWT8XoQ gTmNV2NBNi8RqNHo2goRKHN0BGosfuclAjUWogszXRoLgnmJQI3FutLbgwWq itCfxqLXiv5uoD/tHWXzoD+NBtD0RKDBIlxaIlAm7gg0WMQsgzoNFpnKTAaj AaohItBg0awid22wULe66xvu2mCBuBJ3bTxSyJS+BTsJq4xvwU60aimjJeiZ V2mOn855NhJBD6YKRBuCcqrNBDlsDp9GT5+KkNISNKWlXEyzaafMVRihmXdK O+bDyixyWq6oSvO6sKOs3LI2Bl+XooOgp6RtczyYe0crwwOsHF7XOWd7vpUI v1WSjZZRNvrFdzE6k8GMoGTc6SMXx3unfMMDo87LYNri+0y4PViYqeeoQgIP ZVqPKrQ5qpBAlZ3ajiokUGInVsiyOsIaKtU4+KuQDFknbpUhUOGm8BmJBB7a VPiAWXh2U2ogm0Y/C56sVKPXhqcurV7bzmt7n4Ccy2tj0djCwWRUmGXEVmFW an0pMDup084Cs9Q0pC+rTVn3iiympXYhijyDv2uVcnvcMFvXypiUWr4kIEd/ e1VCdl5hSce608fDfulYHy/swIWzYz2aohKyDqZZQkJ2Xl70TqG9MQdhNs/M lJQ7qpIyU9LdQaVsFKrJXeq87jIJqWr8DdeNUs1uuAQLrYHpKSNcKHqiVEek cZ9TRYNqOKUqUUp1inYn2tQM3mQqZXJYTgoSNp0EkuJNYTE7kOMb35QknD+9 KbK5R6digbkwBYqFvkCqedodzvXT7tD9vd3BQpw714yFlML7jMWWepAjlFBd oaOV8CwW4yrBjlCdNVagsjqo1j86hdCoJnGjEdR0LYxaoTprWdgKBVVT49Y0 h9Ri4agebw2lUFdvbXV+JBaGa/HWWAyujD+VlvzpCAEBfcrI8nyulo7n0ruy BzAgi2nKryLP4OhW6exWuWR7sl24VTK71eFF+yYbiLhSmZKG0Ov06S5m9yZ/ 6VWZhVflB2X0Us/RDEdlhoVXfbzw7FXVdlCbhV9VO8yxMh7DsyawE+7+4SUE WKImNyBfgRtQ1bsBvbqBCtyA8XcDOcGQtgRDlMoXaOjitFLREho61FRMPvhm mX8Z//677//927fflTlZBXmMejwhQ1bYsifcN+cJOfIWMotTYh9dKyPpYtm+ n2okXWLvKuvItcLfVdGJ65SbYz2ub7wNOW2/farN0YQz+rg5o2O8N46Axtay u4PFyhwN4VgUTFzIUIn7wbGwUhfA5vwCYI+AGwPY7CXA1stuTdUGwN4LzelA 6wDYYDGuAPsP3371+7vYWifF1uAJYnTosOHcoUPvHL+E7aMFZnq7xExv7zXo nACPnAb8Hib0NP6L6hEqnX4yuZh/mfIBNiYHHw7/81yW2h43w5vtr7u/HT79 5/Dw+QP7r2Vf1f0/Pv+Wj79Vnr/V428J8fwxodOvhe+v5fRrc/nrpAgeWmNw F5KYCoVP1qjvCZZ7W2PK0C6RVflnwadqK7fMgrFiKxkoh2garLBgsdVwwofl uMrThR248GZOdM8Z8IAlwEOl+a+ObyHj13I42lrI9JXx4YWFsPEiTCniWggf 1Jj9ojQJvUWTCDWmifYGchx3ZFmO36D1eFGplRAMQYU2M44Ogj+m3oyJg7BO oPy9LMx5wJ0KD4ZjoCY0mI37LB8T1WmfD/f2GYuphRNVLMi67Q6/ujvD2Qrv ttRiUdXdCrHo534nzI8XfmOY887RI4n5rMjUgsxLLVDMBxbqkQSOVBSt4VOG rKalIj7lyEPUg9qpQJbYEGynXLYM3Kl0//AKUIxiuKQYOUcoRqEFBRQj5wuK UTRFMaqaKMbzYtLV8JPU+yjyGIG94ks/6NUrvnCEDFlis34w61C4q3lmHgoH y8s7gCqxTWph/pTnmD9V2HsKHz91GLDUyCqm77dc4mXS7Y3LaC4WFQtnpVh8 zFHwxoJa4qxUJi54Y4GwkP4ZCDGbsgMmAllNkpJvGuVUiTxClD45eu6Tu1Pz hYTZvJPhRV/QKHcKbEJMoeyx6Du1yPFrdV9Cl3VfvRZ9MxR9Id8522OEdjdF z+1u9wKc8bbHlAEOUp+bcAbpJOe/t+1+RtT8GaMaoTE3lTBIhIDMiRCQORHy Kgq/kLiNYCNTh/yp0y6kQ54oQxE2N5aNIKVfalP6lexw2SF/20TIZemXYlZC a7USDEgFltxOcf+prXiM+/ROQRLyzT5+9jptOj+QuGdU8E7+WCSp748TGa+8 MSLJCIymN6YOW37vjUWIjE8UGxbM3O+ExZyyb4xhnjhDOsowFxs5HRV501Hm kf8lTEcZcF+7otUBJpHVtNOBzBTyCJlbkDW2k8V6kDdrD3KBdJQZzB6zNiHz wdseUwY4TpBlBTY0iNCGhhF6Pi+RIkssnY5SmGtQmGvQV5GOchbfRiI3InOe xkZidyLfMJH2O5E5BqVidCIb+dwDKu8QfxzFUK5JCcegjCD3LD+pz8agTd5O ZI4F1rIRTWCBNm8nssACq7MVCiz+OdMiAnPkhd8Y5rwzJNkC81mRk2yeN8kW mA+sqwNRsssORDFgQ85CD6ADUbR4JM3j2zjWoakIFtN2B+LRs0ay6EB8UUfz OhZ7UUhjyBJLJy4OdTRw3heau6RrQbS3zyItiMdIjLCjKpHENqkVVSLOHpaq RMpkaEM8+tVbXiQkjqpE2vtdAfxmwm+UYJNhJ6HnLofKG8HOwVp2B4tTWRV8 nLckBNxOWlt5FHzs4VTKhsbLiDCdnlkS3UlkNY3BO9BOOD9H4ISJsMV3Fsw0 6HSb11ga4Dkw0/R4yA3wQGeeg4nmPj0GrC/vlAlow1tsU/1jJkLrHGMmoFFu 8aayzpmAZrh5GWUHTUCDWNTdcZg0oVh8LNyMhQXKHPoHWHBLC8wkT6x/gMXD ulhHBeaeJUNYRzUQOPcs2YJ11KQh1pHwilhHwn1ZxyoOwgbPUC3lOC+xNCL1 pxyzM44OtlmCcZyXF/8kbCF3YrPRTwcKC7bRmzwnYdt7qBwnYdfgL3Vef5n2 JGx3w/2ybsMlWGzNWwUgaFRtpQwglnmikIZn4GAdDDEuQ40F51pOww7andAq CaRRfXbnOgVayz5j8aUi+AgZzRU/+hCatQFISGjGilZux2E7f4whVIcyiakO LKQUknrEQksZqUfvhKomqUcsHlXkriGHubprt/OwK3XXWBAu5FtAdJMWrG7C CckBWU1LvgVMO88PUdERiBRZYlVnII6ehO2Ba2H78xmIu4Gwts9ABEPgVh9f ymlpXpUvEK/BF8j6fYFafUENvkDX5QsALjBFcw4wXz2vph0hPzCLPT9CXiE/ MG+92MmSQn5kFfLLfnobw+wxq5AfmO12scekU7gCWVagkN/BNm5j9MC4muuT 0PMSC9MDY5i2jtttKyeo6DYSW8gPDJNHs5HYQn43TKR1IT+OAanQApybkJ9A EdRgA0AuBs0xJFN40BxDNnn19wQWV92lASKExqtz8NW8MSyC5ZAGwJx35MoV y1u5EpjDL5NFCuD8tkUZJTkgq2lHf08S5BHy6u9Jiu1kMf09s+rvFcgiJcPs Mav+nuTe9pj0FHCBLCtQf09aZgjolOP4ZT0vUSJLXLPIPPmBVPFtJLL+ntRp bCS2/t4NE2lff09iUCrvSeAKxVCuSYnCoExZ/T2FQZu8+nsKC6xlI5rCAm1e /T2FBVZ3K8Tin/udMEde+I1hzjtDkq0wnxU5yaZ5k2yN+cC6JmG1sJyEpVRq MAmrlvp7Y0xsaBL2UNMk7MG3UG0v0JJkuIsij1FR2wqywtq6VjhUZ+F07lox u6U+izo017XCkbeQd1JOYB9dM4NyKsOgnMTeVYw5OetJMIW/q5JyKjrl5lgP ERpvQ86oARhxc/SYoz+1ihxH3+mkAVjN7mCxMr8GoMuWBAFsnRZgw6FVG0hX AGAbYgmwmTBQamYE5wuBa90QwKZDWQlEZDGNKSBS5DEC58+W/WV+82dzgxlD lthQZaC4wLWDfZaQm5mXV1LgerFJrQD28VEvBK6TFPsV9q6yAnaNv6uSgN2k 3Bx71Q8sNhbGpFiUzIFJsdCWFpNKmhiTYuGwkC41iDOsLOspkNU0hsqAuMz8 HIG61NIWlll0bAClmXmNLeGyArrU2tdE8wAzIDMzry+zLvWAbVMDutSKPuTQ pSbYm8qrS02RZRTWpWbpdsdFlxqLj4V1qbFAmUOsCQtuaYEZT3waHsXiYVVk IR+ALrUhWDWeDByQhYYsycKWdKmpqIksFL5kYbmxcYo8Qd6pcYbtY8mh8WEd Gs8+NI5ZY9aZceFtjUmb/ZFVBU6M2/Zxo4T+3MetkBUWThy3W5A4jhd24MKr aPXX0S0k9ry4SWMhscfFbxhI6+PikFD2dLFXppidxsUhgezjY6/Twec7jY7J 8U7+KCSjwnbEN+Y0dw4p2IA3hkUy9zthEafwG8MccY7qCOZiIyfhJHMS7pH2 lUjCpWUSTl4k4VMC32hL/KlQW00SrhutDVHkMQI7dpb43q9jZwb4DFliQwCf 7nXhjh17+yzSsaMjMcZhHTs6YlkoT8cOFRcdOzLJGXIKe1eBWk9BHTsO7+rm kfReN0qwyTBF8tzlyEfSV7M7WJzK347usiUh4Haq+GRsR7eCUwXALbmsMI1g FwO3zEgIbuUS3KqWwO2mpgrTeTFNz3vOj1HrvOe8wsrmPYUA2Ha8cJ733A/U LNCtxuc9a1Uh4chbKDnvufjoWgGjg7kAozzJNy2xd5UVjCrvdwXAqA6/UYJN NlE2OXYbeiWbAyFyPBN0GxzFops7oY1FobpKELHcshXm93fGIZif8MSYH/Oe lWF+fon5yYCNoHI5AMxPloQ2NS1h/n1NhPbel9C2PJiIZQD8e082Ox/g38ck swsBfnVsHfDvo3FtThFcYF9cTR1f9nvz1ddv570hz5/70+s/XTm5gnMv305v D2a3Hd785rFMJIat+d3D1A8pfpvEwyl3d5tw1k3X5PxNXuefJDOE6YKL5X5Z t+XClGMfif52ZChgyuHgsSqhKKb9Sk5RwHzKM7wgHIV9+oxFOfcEEY1UDses pNho71gVlQyCDWEBG40FBSWLZuJYeKgHV8NWrRVYFwHWcIo0VqCymgT0j04h nA1NrMsLR08Lw1Y4gloWt8LJ09TANclxynCEtUb3ioW41b1mda8eSWMB/pZS wN9yrGdDEgr5W77kb2lL/O2xpp6No/b0hFZTwTnaNY6R6j1EKKrlaeSEuE8F H+0rP3engtmdqeApnbp6Dhg161Rw4ang2RrDOGIiBZ9OJpqs0fCBuXHEDtaY kSM+r8ofsDAqjRGWgGXcQ3JtaEAwJa9zvecVJsIrlkMDmz29xCvThR24kHsq OAmm1fEtZBjIkdhaiFCMXLEQzgQyFRzLQqapYOU5FXzl+K9bBgKmgknSqZIE NgIJe08X+/LYpUGL8T2f6Lsj4a5TwT4+9jo/HnAnfxSSsyUnFkTzaclx2BIn emfIS+9ADtsmiUipwHkZOBkt25OikdW0RO8A9nx+iHrQEmDP5yU2BJeI2bcM mABzbvXhlaB2lCW1YyQcNad0OY3DG2J2GK+I2ZkX0/So+fwY/qPmL9zgzVFz Cz/IkCU26wZT5gTkKlHiYJ4lJs3n5UVhFcWZVXSaNF9sUnjnDGAVF50zVKlJ suSxc2ZgxPjLEC/7ZpJIQirsNQXSbZoITh7J3+32bs+M9n5N+cZx4u2NMtxQ /bg38q5AIcGCYlXjONE+cI9TIVy2JCgn1YlzUiwO1oVFGRgNpwrBolrDk8om HDuDUdPSmMj4nVYERpVvRl5LmXF+gpJlxsU+liwz6rXMWLbMuLDGgmVGF2vM V2acVxVInNlKy6IJo9b6OmpVEXmzwV+bbDuYy4RxurADF16h+HAUC0laZoxm IZHLjLcM5JWVGX1dbOQyo5ePvZ51BNzJH4VkLDNGg2geZUaXLXFI6agxmVM6 LJbWUWY0ZQl2jaymnaQGFhlNJBbEMauBhURjT4gkTGvUmtbkTmtgOdPE4izd 8howE+RijxmPk5uXFZjZ6MDMZjqL7vqcz7zENbXJNOsh4ttI5NwGDC5Fs5E1 ubG3EgxI5U1uKIqgXFMSigIZcc+owJ2YPxZJ6fsZGhnTJzfMPxw6JTc6b3LD sHBaJrlhIHTuihZsmEBW45rcfPvVn/58t4OSJ3kEiTxCPaGQKWSJayjMFQqZ jm8lkUE1M2ms5B6oHlZQ/VRtG5AXkBcucYL5ZFe4xCn2QK5wibPwNaV4Y1gw zUtscSyK3t/nldgqRWxZ/5pOO0Z9t4xOe0YfN+0xYNj/dNoy5rtlbNoy5rtl bNoy5rtlfNoy7m1l05ZxXzvj064JkqE5AwOeZRILDkDmoWjVhGtkNYmGs5Kk FtwgD1EPaBQDssRA0PjK8GKSqSxBkL3Piz4ExZZREn2s3YK1oQ+PX68ApGYA Ihj24edtD+VYqC+aGwqRxjvbUOlCem9JzX1CwgNiJkS84hJjclKUShcGWU07 VLockEeoh0qXBFniSqXnokkljW8lkTvvJUtjJSuVbmsjHHkBeal0KTCf7Eql S4k9kCuVLlX4mlK8MSyY5k1mJRZF12S2t2T2MSasmWwHmazCgGeZxEIBkMmK UumKIqtpiUpXDHmIekCj4sgSVyo9OZWuBLL3edGHktgySqKPVd97pdJXADL/ wxT+R2EfflYqXWks1BfNDZVJ451tqHQ9eG9JzSpK2gNipjxvFGBMWZRK1wxZ TTsjt5ojj5AX0GiBLWOlU1ZAswIaj1+3AWi0xD78rIBGK8yTFwU0WiPLqoeN 0AZZ4jpinYeSMEN8G4ktH0XS2MhaDLe3Egw45y10GhQxuxY6DQpcXQudBsOe hfWS0ciYPpk1/uGw5r4wg4XTuiSBubGUBJZMQUlgNiwlgYeGJIG5ruh8inkx TZ9PMT9G4PkUS8Dodz7FjBgZssTqAOMeooH9MxpgAA2goDHZCRUOBlrihIp5 eYHRikpKOCcnfOF8QsVik8JPqBCXNNLihApGtBDPJ1SMf5beJ1QoPUwrfj6j QkiWJA4q7F05YUH24l1pJak+HcVAtyO6vnMUg/Z+VxDAhd8owSYTLLwFMhuP uzw87/K9w0AIGtjK7g4WqHKoo2IRKC26JTSxOioWIQqpo4KIsC174oNEVpOo OYlmEJydH6IidAdkaOc1tgvvWAZ0B6RvHewzD7wDmrjz+u66zK++fjv7a/L8 mTxt2+nK6RM6lxl2WosN0fzNbx7tkW02+989TKU59tscKq9Wjiqh3wRqr4X9 JhB5Te430xyWw/2N98vKjReLsnnzLoqG11YSL0ouEi/OMgidOhhi1JyAYjG6 sKA0FgPz5qUMC3XOiSnDIkth8VYswlQEIxkWd1YYeQtGMizSVQIjWaJwZaUb 7B+jgopaIm3az7CYUkg3GIstZXSDvdMqP/iapMODYwGpIn/NsVC3+uubRR0s FFfirzkWhgtpB4Lwti+rHSiQ1bSjpAK0IedHqKd5DOhFzkusrHmMDMCxkOG1 NI8BkUxvK0kagEwaM4kvpQID0GwnBQIQ0OV08GGZ2goIsr68fYtAu3KxTa6c ABDDWzyQa9+iwIJhVXp2iwfMqzaKRbZ1oqi3iaJVoKWbcSKBgcUqlB/FUJPy 47yalnoggPbj/BBpRqK8sCgQf5zX2BAWbXomCkg/zi8gTbcCHd/8XPDdnAq+ ieq9QDHSyqMkdHBAP7GwgwMyiskdXJJmBaDg6GS7Hs0KOW1XYU+Wt0ccC8rt 9Crwy16FNHaIoYW8vQoKi/eFpWawEJ+3V0Fhgc6Zl1BYYCm8z1iAqQjuKSzs rHAvkyofGjLTdxUoLKi1PSqrPDLXlEqnWDAqo/uExqSGlE41FsEq8qwaC281 SZ2Wd6pJiBaNAYLMymAYAFilTnvj8V/+eqXyXy+VrzFUnVkZDMOWhZXBEnEp VlKn/gRK1VKnHhizgDqMZJfqMNwg6jBkRGMSyMNws5CHGV9XQ/owglakDzMv ph2pV4o8QaDHEJRTc3IbFmiOYbtoQb3eAXPkCpjjZrrvI5gTRNBrWE6tPRk3 sVyShkLMFMNCu5An9D6Z4oYMd6hT4W2KSY+3Qlbln5ST43F7MLb9uAPX4/9/ kZNTNjyf5K2QFRZu9BcC5OXjhR24kD0vTyPZncRE9tLFRMbs5wVtI9lZ5TGN iUwd2+KGhTi3bN8wkdZbtgkGngL7Zqe3T4dTfWqMxeaOjyUoanItTxEMvbjf CcMgDg24KV4YGhMzCCL5x8KaaxgEC6aFBJFA5BRlBZE0spp2EhqgmTM/Qs6M BgjjLPaxYEqj1pQmd0oDVIQWxpgxpwHaQS7GmFTYgyHLCsxqDoFZDRtXc10i aF7imta8TGuS1KOBklEsI4mZ1wCVo2hGsiY2DmaCoaisiQ1F0ZNrOkJREOM6 D8gwJMK0BR5KpzaEBsYMki/+8dApsdF5ExuGxdNCki8gdqqihRogMTSvph1V BqBUND9CPaEQqA7NS1xDYbZQCKSWYplJTFgN9JeimUloa3Q/sBqIR81vICte AvJQC6fsipeAYtLieVzxEtA2mu9UFi9xLJrmZLU4FkQjdF2urNbadLk2XV75 yRR5S3Zccgx2FhJ7AxBzU7ReAjSw5tW0NPMBRLLmh6gHMQJBqnmJ5UY+qgSL SU6PA2pb8+bnxB5Aa2uxiILYY20SXLHHa8YeN36dTbuJYd99zq5QjoX5mkT1 ojlmGxIdKOm5bEnN3UHCA15mlArbFSXRoVTYrj0SHQqF7eoj0aFO2G4l0bOT 6FAqLJKZxOy4h5pfsczkVZLoabSQOPIGspLoUN5s502iQ42xnTeJDjW9dnWQ 6FDja1eCRIcKWg67vCayNj9eE9lXk8hOAfNVZLFQr84Gx6cUTgIQ81iURIdy dccWSXSolHeMRKLHnNHkyBJXEv0CLKok9iGQzc+JPaAk3rEGEn1VTVqxR4XY w+7XjcAPhX33GUl0KB55rINEhyKSsRyzlWbS4L0lVWsmecDLhGgX6EVKUpRE BwqK82raGbEF6ovzI+TEMkAJbrGIlUdZscyKZdx/3QaWAdKLi+8+I5YBQosL J15W/1Ejy6qHhAB6ivMS15HqTEyEGZIYSVSpKJLGSNYSuIOZYKg5a3XToGjZ tbppUNDqWt00GPIsW900aGBMn8ga/3hYczeYweJpmUTWgNjJy2pFDQOynER1 mySnxJCBIE9RD2YiA0XW2BBoAvGwPdxEBub++aVUjhtARJNlpbAHgSynne5Q MkjkGerBxmRQyBqrA8cKOgP1WsAxGXQSQ4kbNUwaQ8nQIYoZSoNRA2juzm8h s+Yuwbyzs1QuUN1dPJFrJkWA7O58q7KpFCFYaM1Z4SAEi6hriWMtcawljot/ 79W0ihKCYdBCaQZQqJamLOsAJKrn5bTULUqASvX8FBXhRyBiPa+x6n5Rlb1K o5NYCJCOnnc/KwQB2tGLVawdoysEWSGI+68bQSFAnX3x4WdssyBAgH0R7Iv2 WRAgSx7NOVudywIEx102peauUUI9gGaBoza1uTxqUzLkqE1KGQUnbUq2OGmT koYO2pTbstUFZDFJmmaTEIEUeYJAj0ElJZzTyW9Q56M2F/sYfi6NuALnluem M6IFv4bnjiucK3vU5sIYw4I71UpS9WiM2wNTTodtuhhjvsM251X5Z+aCqcOk xm+VmVPFhJm+GpCZ88HIq4dtziuMUNfhAd0AagOS8/HCDlzInZynmW+JbiEj MNgPytZC2ECEfMndEGWun7UZzULulIhvVoglO2hmbyCg8EcxG6GV2ggs+3m6 2Bdlv1O818NzvKfa6axNLx979azNhdWTe2Z/+6zNWvw+rPnFe2NEkhERTW9M Hbb83huLEBWvnnQZcics4hR+Y5gjzpGFYy627Y5XyPnbZH0FcnAjLnNwbZAc nJCBgxx8zN/nHJyIlnLwQ9nSG7IY1xz8L+Pff/f9v3/79m4inkTOmiKP4Yje 2A18L2b0RqQHwGfIEhsC+JTvlw1+KMaP0uF3Nam1t8+v/uO7r7757i/T6xy3 ab/5tEminoosLwoBRM4EELkjP4dtkgUB9PWSAPr6HgH0ZqJ9Hv7tmz8/Uj/j P/3DN989/lk+0kCP/5A8/QPyhvzy6eQG3m+mP7DnkuAjVfQYA5Uepoj08cMP h+nfEZIlCYMKe1dOUJBd5Ue0fuZH9L0pU+93BSeWwm+UYJNhiuS5y9dZqKcU aWKhHFOkWnYHi1M5wC0WgNKC2ymRTFphwiJEZeAWFJiMQAtMENuOuHjGti1B WzVUVF6aF+MKbb/865/+9H/IHVSbZI6NIk/gz0lqW8ZavsSyw1UgO68qDQ9J nnCsuD2psjdqgWOn0RVNFjiWj5iCmzOOPbbMVHP3jyy/wxMDAQ4Py+aVkQP0 eMtsXg9tuLyd3ujjQOtweWAxSSrqSVokKfIEgQCJkdElsBNMYoNDRR3uY3hF XV6pqEsxN0gSda2czi4mNOT2uFlL6jlL6tAaw5KZyRq15M/WqO8kM8LbGrOU 1MGq/MGJnOzatmDKmJT6CkpZFEwVssKijBsTx0vG7XRhBy68rpJ6PAsZv5bD 0dZCpq/sQr/i6QjK8SLkUOJaCAJlmU1J/eXQ9U0DOYKh6w3KyYpKrYRgCCqQ l5scxBRXJyfLxOEeL0dQ7ORfVAd3UrIo94SBmtBgNu6zZPR5nw/3mDksphZm 5rAgG9gocNqd4WyF+3tWiEXVgPJ+8J0wP174jWHOOwOXSjGfFZlL1Xm5VIr5 wDJTqhQ4UlG0Uk4ZspqWlLEoRx6iHtROBbLEhmA75bJl4E6l+4eX0g+AUKaK cmxUI6tpyg8Y5CHC2p3JNrDdWRry7AfYgCwxhh/geHZ2yw/wgzKg4Xn87HfQ D+ye/YA6DMQsPIE6Yq6A1ZqeMeL+8SX0BYzW5AsYewW+gPH6fYFYfUENvkDW 5QsALrA51z2hL9DIatoZZ2UGeYS886x8wHay4EDrYR1ozV59I5g5Zp1o5dTb HFPyX5whywqcaSWhM61MnHeOI0ssncrv7MN20xU4LqLbSOypVi7T2Ejcsdab JtL6WCvHcFTesVaOAijXigXHcIzznYQ/FEnp+0WcyBg61ioiRManO2HBzFl+ WGAxp/AbwzxxhmqVwFxs5GqVylutEh7pX8JsVAD3tSvKTAmDrKadVlA5II+Q txdUEmwnizWDqrUZtEA6Kilmj1m7QSXztsek7aAcWVZgZVkHVpbpwPXzEgWy xNLp6B7mGnuYa+xfRToqZXwbidwRKlUaG4neEoqbSPstoRKDUhFaQp8S0qkZ T9wh/iSKoVzTG4VBGTLYgJlkTlth2CZvT6jCImvZkKawSJu3J1RhkdXdDLEA 6H4nzJMXfmOY986QZSvMaUXOsmXeLFthTrCucVOiL8ZNxUCwcVPN9eW46TSq uhiwVy2Nmx7rEI8Ci2lVPAo8hr941Iue2JviURZNsQxZYunM5UVPLF4l4YZm Ox3y6vSmvXlm1o4Cy4tBb1FzprdstaPgJoVrRwF2a6EdNX1ZJ30oM3irRlEm 1HTazLNsFGHcpNWNgu8pmPaRnOun90TvoUCNrOJ0YnExwGXS7Q3hz5QY2dyb msKiYuEJJSw+ZjlQxHtLgtAoSaz2hAXCQufoXYYYQsqqfwhkNenwmEzyHBJ5 jnoaksF05bzEyhqS5UAvAdl4YW5IluN/coZkGuWTq21IBqOp82vIq78JRlEX H14zApzqIb0AJ5iaXbytCP2c9gqcYMr14m2VxFJg3DXy9lhLZ4I5VxdjTro7 WKgN3h1NOHtqBj6OHvTO7qAxtuzuYCEzxzA8FgsTQ80h8TA8FlsKDcGCGMOL Mn9gOJPwRqk/MN04P0egcPyyid5POH7uogcjj/MaS5N/Dl30lPHcyvFgNtPB RPPQf2Dscl5fXuwKRisX29QIdlWGXGBXkuRwdzD6uHhbWbErGHm8eFslsSsY foy8PdbYlWFBsvCoFhYtM6AzjkW4pOiMGJ4WnXEsKJZBZ2AYj0gLsJgOnYG5 O3LBZTWEzsD42vwcgZVZbYvOLJpKwfzavMbS6MyhqZQeD9nP9VG+JpoHnYFh tHl9eauzYJJtsU0NlGcnhJe+PAtG9BZvKmt9FozkzcsoW6AFI3pRd8ehQiuw +Fh4d7BAmWMqDwtuaYHZpNmSdCoPi4d19Quyy8MmBdHYeTxcw35Bohf9gpQ0 1C9ITEX9gvNi2lHIocgT5BXIYdg+FtTH2a/6OGVPp1gYY1Z5HOFtjPlOp5hX FSiOQ0PFceTwnDgqZIVl80YpYQfJeGEHLryKYUQd3UJiS+OYNBYSWRnnloG0 roxDMPiUVxmHoMAp8GyK+U4OZ1Nc7cSsxe/Djsx4b8xJGQe2Yga8MSyShZ4I Uc0bwxxxji5pzMVGzsFF3hwcNtrZZH0FcnB+eUTkmJMjOTghAzgUd8rf5xyc NHIq7uPb2JZtEkcW01hpiCKPEdi3s8T3fn07M8BnyBKrA/hHiN+O58LQbp+9 MORrnyWG9ubl5W3akdgmtdKzo5alISFMEgExhb2rMBURx5Yd7f2uAH4z4TdK sMkwRfLc5dDOH5gi1bI7WJzKAW6xAJQW3MrEghQww7OBUyXArbAEt5TB888n YNxqgelQU4Hp0HyB6VBFgelQQ4FptxaYCheYDlUUmByMMWOB6RCpwMRCC0xa 8uvw91BJgUltQf45XtiBC6+xwBTBQhIXmGJZSOwC0w0DeW0FJk8XG7vA5ONj ryc85zs5NPpdT18q8fsw/Yj3xoIKTAFvDItkwQWmWt4Y5ogLFJgctsQpB+d5 c3BYYLLJ+grk4AIUmDgmCnmlwMSbLTDRoaIC07yYpgtM82MEFpiW+N6vwDQD fIYssSGAT/e6bIHJwT5LFJjm5ZUsMC02qZUCkzAXBSZN0xeYFu+qYIHJ5V3d LDB53SjBJhMsuhUtMFWzO1icyl9gctmSEHDLZdYCkxWcKgFuQYFJoOCWGQnA rVgWmEhLiueUVVRgmhfTmMImRR6jHoFNhqywMn1Ns+eX2Ha8cNbXPA5ks0C3 BtfXlJXSkxx5C3nBqMA+ulbAKGcXYFQm+aYl9q6yglHl/a4AGNXhN0qwySbK JgdjUSwmVqV3HtEEnSQ6IST2t0EIcGvZ50Ru2Qrz+zvjEMzPEot9Esx7Vob5 DcD8WFMZ4y+aysSS0KamJcwvaiK0hfbE/G+/+f0fvnv7v+8BfpYB8J+foVrA f15hw4Bfo4cctQL4RTSuzSmCC+yLq6jjy2Fvvvr67bw35Plzf3r9pysnV3Du 5dtpRrfK7N785rFMJIaN+d3D1A4pfpvEwyl3d5tQS1HX5PxNXuef5jwVLJxa WO6XdVsuTDnmR8t7AAgWX5uhKE4rTk1RwHzKM7wgHIV9+oxFOfcEEY1UZc91 hulM3I22JoMIFljcNxoLCg66FSn2GQsP9eBqijn/FVjnBNY0UaCyOqDFPzoF 1WlF4iZELJoUOqAFiypFcCtFI1Ma4EoynGpUpXvFQtzqXrO6V4+ksQB/KxXg bw02FExhP7Iwy0PqW2JvdU0dG+fFuPrBL//6pz/9H1LECyJP4O8Ep1tYOcAr Rx8M1/na86rSzI6RJ7cnbrk9ofZGLdzeeOEw+rLdcrps4GY+9aDl6ULu/pGV cHigYCWVfZPa6CxbbVLb1FSw2vhCv7qa1Dbh4I9RuRmIpe8jUhBzBfxRIa+7 wE0F0E8IKvjluXxHsrmcv5gunOdn9xs+kIvTX/ZbgU5hRBijTRIiOfImivap bezT7EpIYE4vSGCRJHBJ7F2V7FNzeFe3+9R8bpRgk02UTY7dp1bJ5sCiUUQT FEo865oQ6din5m+DsK5Syz4ncss+fWoOWxLCeVKTt0/NBmgWgP2KWcJ+McZX CPsviA7ZEuzf18R07H2ZDkvGN8lEJUWeIfDAR2E7dY0d+Dgdr3sd9e8jER9h U9eEE3qB+glnl6dxTxeeUT8bIf4C8ecfura3zSJD1+flRW/tOmw3eyMMf2qQ kXJHddIGGenuoRLWyFRN/lLn9ZdJOBLjb7hunV3ZDRfmDvOjZT2AFeYKs5U0 cACrGh4yHMAK8xh7I4x6xChMgs7LKHvEKEyCYu6Ow/G0MB+qZXew+FQR4INd bCvis0F8sGOvNsgHW/dixRerhiwstiVuyOKJG7KwWFmoIQuLS2UasrDw1FRD FhbMKnLXsPNtddc27hq22tXmrmGfXWnfAqLbsWyzp0FW0xL1xwbkIQJ9iwz2 LWN29rxGgqyxsG9he+hb9tC37Oe2p0Nm38Kor3nm8S2MIetLQ/8xvZtZFJaW RWHc3U8ldJtM1OQ2mczrNpMwgEz5G68HBZjVeLEgm5cCZGh0bYAC1MuD9pJR gByL3XkpQI6F57IkF8fiX14KkGNhrvDuYCGqItzHsbi14r5bRV/v+JoH93E0 dKanADkW29JSgCJxfxLHYmUZvCmwuFQEbwosPLVEAQosmFXkrgUW6VZ3fcNd CywQV+KuhUfyWKD3UQvL3kfKFKOg+VGxpUjfwBvqfmS0ou7HeTEtUaAUeYaw M2f4xta1YmfOUCGvdz/OSyzoWfV2XIZZeNanCztw4exZGS/a/ehgmyW6H+fl xac/j6PHO2z1szwY24hNxu5HKw+VrfuxsL/Uef1lhu5HJ8N1pD5zGy7BYmtm XTs0qrYy0ihUhpFGggXuzLp2WHB2HyhDI1ZhXTvvUBVX1w6LK6FHps53Kqxr h0WHipAowbz/CkVv9flggaUSLEqxiJNfJ8/lsw7hZFXqtkwsLFShk1cYBlMs orTEyVIsHlXkrikW6VZ3fctde6dpmdw1FoQL9ReB6MbL9hcRZDUtcZKgeW9+ iEDfsg32LZqc2zIZssbCvuUgL32L2KhL3zJeOLd8M5q7LZP7mmemtkyBrC8N L7nf8pnekWnpHdB5aOWnUrpNVZXb1HndZpq2TONvvB7cZE7j5ViQzctNcjS6 tsJNqhxyaxyL33m5SY6FaGfKjKNhqyw3yb3DVVRukmOhxX2jsahQlpvkWHio CJByzPuvgPRWAxIWWCoBpAKLOBm4SYG58bTcpE7cLyqwsFCoXxSLLWX6RbGI 0hI3KbB4VJG7FlikW931LXftnadlctdYEC7jWySIbqpo3UMSZDUtcZOSIg8R 6Ft2ob6FDeoZj0uGrLGsb2HDxQFBhHByIUdxunBWiSdKL5wLzeBcJPe1zzzO RQpkfWnIyd12mPkdtX3kd3iipknp7qhS+k1Vld/Uef1mEnJSGn/j9SAncxqv wqJsXnJSoeG1FXJSywzkpMICeF5yUmEx2pkzU2jYKktOKu9wZXMghP2pG1ho IacDrMptDxZjKgKSCos8K5C8BSQVFusqAZI6UcCyIRW1f5QKIBXpaDFJSUWN RZUyAFZj0aXM3I93YlURqaixcFaRv9ZYrFv99S1/rbFQXIu/xsJwIecCwpsp WrEwA7KallhFQ5CHCHQuh2DnIjR/XiNF1tiSwkX2bmrDfM0zj28xHFlfGlJx u9nNvIzeJm0aM8LdTyV0m0ZW5TZVXreZZhhb+xuvB6mY1XixIJt5GntAw2sj rKKeTl9OP449YBE88zz2gEVp9znhAQ1dhSeyB++YFZVZJAMWYApTi2TAQk1F cJIMWARa8eStM24GLOZVAijJkChyWR3BC0VMHNxfCL1IdFp6kUBVlMJYlkD5 kbJglkAZktRoNgnDSKAESpVuG+qhrG7bym1D/Zbq3DaUhSnuYUCc25WVeoTS L7vENYwkNCOBUiy7SEWMY7CH0fz8qUA9ll0FVYzJf2y3Fx6GqoO58DDThWcP s6E6t4eBUjL2FprJw0BRmPMC01CNm81CO8+kZWsIVJix8VYpvSfUmCnsPaFa TGrvmYRtJFBPxsWAPejGvAaMhdvMfCNUd5ktpRW+keToYiRQdsbeFiPrP2LB 2p1vhLIv860K841Q68Vzr4P5RqiestzronwjlE2pElZCAZQVVlrBSijUUh2s hNotsSKXFd8INVcc3F8I38gStzMSKLhSGs9C5ZXCeBYqnKTGs2n4RiiQUqXb htorq9u2cttQGqY6tw1FY4p7GBDnDmUrGlBy5pC4opGGb4SiNIc4FQ0xhHoY PphnJQYCNWAOdVQ0tmpzWdGYLuzAhXNFg+9zexgoTWNvoZk8DNSvOVi3iXjx jWaz0MPbJKZroIiNjbdK6T2hik1h7wllbFJ7zzR8I9SxcTFgD74xrwFj4TYz 3wgVZQ72DSOV8I0sS38jVLaxt8W4fCOUtHF4X5BvhHo0863IXXiSlE6DGjOe ex3MN0IdmXmD+FD0qBio1FIlrIRyLSustIKVUAqmOlgJxWFiRS4rvhFqwTi4 vxC+kafub4TyMKXxLNR0KYxnobZLajybhm+E0itVum0ozLK6bSu3DVVoqnPb UI6muIe5jHOclK1oADmaeTlN8Y1AsGZ+Cn8PQw5qc2S2HsYYfZIqhw5Gy3MD NVCHmddYWKRhSy6VX6cLO3Dh7GBGn5vHwZyRDxCtcTDQTA4GKNvMC0xDN+rN s8IdOWgypGVrgLyNlbNK6TyBvk1p5wkEbpI7zzR0I1C4cTJgD7oxrwFj0TYw aROUU22mzM2GbNRokA0nGwlKNlIu2PDEKQojNPMmG0cTmTLDM9vIFVVpXhcW xwMZMEUHQU8E2OZ4MPf4L41FageuMcXuGCwUBu7OiCAGMyKlcXuOXBzvUbEG C3hMF23XNFiwqggEGiyArSDwFgg03oE2Ewg0aAzNQA4aLMilJQdl6mZEg4XN QujTYNGpDPo0aJhqiBykAxbU6vHadMAi3uq1b3htOmABuRKvTQePdPLZwbz5 14h/vdn9c/d+ss7Pnmxh+uNn73+Z/vd3krHPPm3evf/+6e+FVCOS//DDp/9+ +Hh8+OPHHx6+Pew+/ryfgo3Wn/308+Hv4z84/nKY+gK0+Oyz8Rt++PjTFF7I m19/PT2uIkoed4fPd4NUn/ODYJ9v9VZ8vjmOtr419Eg3x/ELeTTHLx7ev/v0 6f3h4fBh/27zYfy7D7/+I8X7AJ6Ala29IItxda5/+Par3393z7UmyaYo8gRR Om3oudOG3kYnDNtHi9T37TL1fXuvz+aUtwox1XmmJPixw4Y/Jr2nX0045l+m eLAdN//wP0/RQg9vtr/u/nb49J/Dw+cP7L+WhMX9Pz7/lo+/VZ6/1eNvCfH8 MaHTr4Xvr+X0a3P56yRHaWLGGKG1RdFzG9Gd1F54G2PKzFUiq3JEQBSUR/kC AZEZAQ221VFB6FnZHllhydqo2G6H3bI2+nhhBy68mVHOGf0MGPoZYlRGE1iI jm4hXLL9oGwthA1EXMHIRJnnL8uksRA+KCFwA6E3DGR8woNm9gYysWA2AuS0 UhshGHxyc7H8arx/6tQc4z29Rw+iwMm5URMDMA6HQj+Pa1bp90mcoHjljRFJ RkQ0vTF12PJ7byxCVHxu54p2JyziFH5jmCPOQvN5b4kTy8fysnzUI+srkYMb yxyckIFf5uBT/j7n4ES0lIPLshQnshjXHPwv499/9/2/f/v2biIuMiTiMpzh fIHvvdofFwCfIUtsCOCD5kcU40fsfuS+9pnpVGpkeXlHrSS2Sa0MWhFxMWjF eJJjAbF3FWPMynr0R3u/K4DfTPiNEmwyTJE8dxkZsLIfZkPjWtndweJUFkEd 7y0JAbdcpdbTcYdTBcAtty4wMTlAcGuaLTDpmgpM58U0W2DSkZLhsAKTtk+L 0xWYNmuBqXCBSftxaZELTA7GmLHAdF5VYIFJhBaYmJLX4e95hSXzT2l2h2GZ fz5e2IELr7HAFMFCEheYYllI1ALTbQN5bQUmTxcbu8Dk42OvJzznO00+I6jA VInfh+lHvDcWVGAKeGNYJAsuMNXyxjBHXKDA5LAlTjk4zZuDwwKTTdZXIgcP KDDxdgtM25oKTNvXUWDaRiowLfG9X4FpBvgMWWJDAJ+O/9WyBSZ7+yxSYNpW UWDatlZgUsZcFJiIzlBg2lZRYHJ4V7cLTD43SrDJMEXy3OXYBaZadgeLUwUK TA5bEgJuGclbYLKBUwXArbAuMFFGIbhtt8C0r6nAdF5MswWmfaRkOKzAtLdP i9MVmMxaYCpcYNr7cWmRC0wOxpixwHReVWCBSYYWmCSj1+HveYVl8889M5f5 53RhBy68xgJTBAtJXGCKZSGRC0y3DOS1FZg8XWzsApOPj72e8MxWT6yF5q+n L5X4fZh+xHtjQQWmgDeGRbLgAlMtbwxzxAUKTA5b4pSDk7w5OCww2WR9JXLw gAKTaLbAJIaKCkzzYpouMM2PEVhgWuJ7vwLTDPAZssSGAD7lx7IFJgf7LFFg mpdXssC02KRWCkxjErEsMA1JRNgV9q4KFphc3tXNApPXjRJsMsGiW9ECUzW7 g8Wp/AUmly0JAbfTcGLGApMVnCoAbqVtgYlx+gLcXhSYaEvgllZUYJoXk6TA lKQpgiJPEOgvGOFCsZPXYINrgWmxj+EFJnmlwCRP/4XHAhNR16pL0786l5fk 9rhZK0zZK0wLawyL7ZM1asmfrVHfie3C2xrzVZjmVfnXD+Rk18ayfsCYlNMe wgSUsoFfx7/nFUZIQKV3ArolYnuRgJ4u7MCFV1hhimIh49dyONpayPSV8eGF hbDx4vWUIpaFIBUmZlNhEmpMqewN5HhZYSIblKIQlVoJTKA8neyLNHVyEPwx TWVMHIRjAuXjZa/nPAsUJosex4GhmtBoNm60ZPR5ow/3NhoLqoUzVSzKBhbO TrsznM1wf/eo52hmiIU/9zthjrz06TtpcgUbboFiTisytzDk5RYo5gTr4hYU sS2ccSUBtyAvCme8JW5B1FQ4E6+jcCbCC2cv0pabhTOLvIUhS2wob6FHU7hw Zm+fRQpnIhIRfiK2qDkTW26FMxGxcAaIrUXhbPq0TsUxM3iXzCgTcjmURRg3 SUKgwt5TMOUjOddP74neg4EaWYWDDkKCvTHp9obwZzqMbO5BZCwsFoajWIDM UerColpSOEqmMcmkpS4sElYGR4UlHOWKQDg6QtkZjoqhJTiqaip1Ke0JRy2P 2kvSoEGRZ6gXi56X2C4WzQ9F7W2zCBRV1kzXV1+/dTtdXBmumd49nS4u5Y6Z pKeLS3cPlfB4UlWTv9R5/aXMgD9dDPfLug0XYloVict0TA8hhlX2tGb5/HA6 6zx9fgihtr0Rxk2CsMBc1fhR1N1xSJ9hMee8jLL5Myzu1Aj4YNloRXw2iA+W yGqDfLBWFiu++NTKHFxVUK2M562VFQabFItLRdAmRcNTGrhJkjwEFswqctcU i3Sru77hrikWiCtx19QjdUzpW0B02xQtRFODrKadLnc2II+Quc2dYDtZrM9d rH3uBfrcGcXsMWujO2Pe9pgybWMcWVZgq/smtNVdyPNpkQJZYtFh6y07yEsY MF3YgQuvotedyfg2ErnZnak0NhK52/2WibTf7c4wKBWj212dm7Dv6fMwFEO5 NgdzDMo4nAmfYJ85Bm3yNrtzLLCWjWgcC7R5m905FljdrRCLf1Tcc27wTpgj L/zGMOedgcDjmM+KS+Bpk5fA45gPrKu7SEv/Znclmm1239XUXbTzpS/ranbf RSIwl4mLH4G5yFyQJTaUuJRvdre3zyIdRrtI1aawZvedfd2pfDPDSRk3d7P7 /J5KNrufV1FVs3vMvQlodncw4pzN7rG+cJ9md4ctCYCjxOi8ze42AKgAHDWD bbO7eXEy/QhlZzjKTUtw9FjT7OVx8ISjFTW7Hz0J0oxY9NggiV682d3eNotA 0aM10+Xa7L7f7Y7H3XZY9Axvcja723iofM3uZf2lzusvczS7uxjul3UbLsS0 x0hcZmCz+9Ge1iyfH14ICGdrdrc3wqTN7g5vKmeze8zdCWh2Py+jrmb3GgEf bHZfEZ9Ps3ttkA82u8eKLz7N7g6uKqhWxvI2uxcGm7DZvSzahM3uqeFmlmb3 Gt01bHZf3bVPs3tt7ho2u5f2LZfRTZKygzQGWU2zze7zIxRtdl/sZLFmd742 u5dvdl/YY8lmdxd7zNjsPi8rsNl9G9rsrkfIcLXZfV5iWRigBehkni7swIXX 2OwexUbSNrtHs5HIze63TOTVNbvH87SjjxB0eG4zvnc2FkMx1HTAVsGeXhQY 5e1R9wdGSXcnTpgO7lGPEKavdruH3AkLgIXfGBYWcvSoY/4+Mu+m8/Ju3CMZ zd8UpAZrQXZiBAVdQWZYNqkPLXWpS16UeCTIYpruUp8fI5B5XGYcfszjIuVA lthQxlG8S93BPku0Bs3LK9mlvtikBroQpMrfpb54TwW71OdV1NSlHnVv/LvU XYw4Y5d6tC/co0vdZUsCACkxKmuXuhUASlisAS04UpadGhTIalrq0wZ9O/ND +MMxwdRBCFs4RhUTZngJx8a7PMMx0Lczr7EoHjO7w3CBx04XduDCGY+N/9Wi fTsO5lmkb2deX/xe7S3ZkFnfWbDNcZu05RW0BVn5qZQ1blKT2wTdPMndZpJ2 bdAE5GS8X1ZuvFiQDYRRVNIRY5IJTFF9P1GiaHQNz5QEmikxoqfQdUqLpj9L 73xJKbMc6hViSDNnhcXvQIUhqpWc6iXT29oe2L2iC8VCtDPbDRty5jsNNgaY LLuArTlxN1o/b7S+k3vB9hr/jYYdMuc76buwKmlHAhYeKgKksJljBaQ2gBT2 mtQGSGGjSazAZ8MfwB4Lh886qKBF0/IHsC+jMBCGHQplgTBsVEgNhJM0ksOu hhrdNWx5WN21VTnHO0/L465hq0Zh3wL7PUzRWjHsGTG+xeKS3CTsMDHhpeKT b5HBvkWyc8OQQtZY1rfsmbn0LdOFHbgw+5Zjbt+ifc0zk28xyPriH5p40Fu6 2egzvbMd0tI7YnD3UwndpiA1uU1B87rNJNykYP7G68ZN5jdeLMjm5SYFGl0b 4SY1WQpKCEFUkreFxe+83KTAQrQzZSbQsFWWmxTe4SoqNymx0OK80RKLCmW5 SYmFh4oAqcS8/wpIbwBSiQWWSgCpxCJOBm5SYm48LTdJE/c2SSwslAHCEost RYCwxCJKS9ykwuJRRe5aYZFuddc33LXyztPyuGuFBeFCao0gum2L1j2UQFbT EjepJPIQgb6FB/sWQs9fiULWWNK3iO122C19i9ju6IWAzunC2bdsc9c9lPY1 z0y+xSDri983eaCEL+mdzSEtvaMHdz+V0G1qUpPb1DSv20zCTWrmb7xu3GR+ 48WCbF5uUqPRtRVukl72TabhJjUWv/NykxoL0c6UmUbDVlluUnuHq6jcpMFC i/NGGywqlOUmDRYeKgKkBvP+KyC9AUgNFlgqAaQGizgZuEmDufG03CRP3Ddp sLBQBggbLLYUAcIGiygtcZOjy6rfX5MBi3Wrw741eTl4p2qZRi8HLBDXJTRE bQ/DlYQAnaFJpKjR08fkoSaZoUPiyk+G08fmZ6hXY+hQRd0nSGMov8SQvW0W kRg6Ly9B16jcbInmi0Oc0pJb0t1DZTt9rLC/1Hn9ZYbTx5wM142VzW64UKto frSSp48trKQB3S9NH/KfPuZghClPH3N5UxlPH4u6O/6nj83LqOr0sSoBH1Qx WhGfj4pRbZAPqhjFii8ep4+5uKoQ8lMkbsyEckWFwSbUKyqLNqHwUGq4meP0 sSrdNdQfWt21x+lj1blrqFNU2rdcRjc1lFVmM8hqmj19bH6EoqePLXay2Olj bD19rPzpYwt7DE7bAk4fc7HHjKePzcsKPH1st8ABPqePsUGdd04gSywKA/aa qAsYcLqwAxde4+ljUWwk7elj0Wwk7uljN03k1Z0+Fs/TBp0+tgQg7J7BZjx9 LOr2+J8+Vksg4nHCdOTTx7x256oaVcidsABY1elj0YC+x+ljLlvixLupvLwb 90hGCzQFMWN7+hhXEjQFUbk8fKyls8em5LOapqB5MU2fPTY/RiDvuMw3vHjH ZcKBLLGhfIMeddmzxxzss0Rj0Ly8kmePLTapgR4EKXP0ICjsPWUtsmtkFTWd PRZ1b/zPHnMx4oxnj0X7wj3OHnPZkhA4yklaOEqwSFgXHOXMFo4KygEcHaHs Ao6qluCoKFqpIshi0sHRNKcIIY/hT21yyfZkWQa/RW1SNhBxIev9iEalIQga Pa8wBhrlOLV5C43ygzKaATRKBUCjVDyjUT1IuuQ2DVoHZ6pSbpMjbyGz6in2 0bUiLECWfaxCDEl6WyT2rrKOuyvvdwVlBcJvlGCTTZRNfvlBuIk3QCxayeZA LBrPBDXhj1Q/3R5HJ3xnd7Do5myDEAnODyRKKi6QRG7ZCvP7O+MQzE9FYsyP ec/KML+yxPxCvaCgx3xhxvyiKcyva6KgtS8Fbdn4yjIAfu3JP+cD/Dom/VwI 8GvaOuDXkbg2xwgusFUUDbvSd2+8jmZR5nzyrhi0STqrqNzdbUr1w5qcv8nr /JOwPTBdcLHcL+u2XJhy6Ej0tyNDAVMObc+EV0JRTKL3ySkKmE95hpdQ7UOY Pzm8LZggYpGqsPYhTGfibrQ1GUSwwOK+0VhQKKt9SLDwUA+uppjzX4F1TmBN EwUqq3Fd/+gUVKcdEo/rYtGk0EgdFlXKjNShkamlcV0sjFXkXrEQt7rXrO7V I2lM6QsALtgUbVqAs6kbndYXJFHWg5Ot54eoqYWWImtst4c2QwstnBG1N888 PbRwWHRjXdb0Iv7G/GohUrZLSp/AIVMbP5XQbcKRy8JuU+V1m0m4Pzid6GK8 HtxfVuPFgmze5nY44Lixr4iX727XJEd3Oxy+tDfCqC3ccNjS4U0lnSjE4l/e 5n84uXleRtnufzgGWiPugzOhK+6zGp3yjq95cB8cS40VX6wmfbHYlnjSN3Gb lcBiZRm8KbC4VARvCjQ8NUTZCSyYVeSuBRbpVnd9w10LLBBX4q6FR/JYoIVT DrZjW8y8aOFUzY5t7Wtq4dz7FkPqGtva11cOYcgK66qGHDdqe+FZpwvnaggZ v5rl2BZeDdGVVkM48haKjm3t7avOlfREkSU5IrhOogwisXdVcmzL4V3dHtvy uVGCTTZRNjn22FYlmwN7KOOZYNDYlr8NwjbDWvY5kVv2Gdty2JIQPoGZvGNb NiizBObnlpifCa0B5h/zhRnz05aOE1THmqQajonZlBxjW0dPMiUf4D/GpFIK Af7xt40D/vNbKDq2dbTnrDOObdnvjWv3xn5D5EFvhnn4RWUd27Jxt/nGtso6 f5PX+WcZ23KxXLfWjeyWC1OO+dGKjm05eKxKKAq6VCdMRVHAfMozvMQe2/KJ L9ezoflOdY1txd1o77GtgI3GgkJdY1sV4mo4trUC6yrGtmIFKp+xLYfPMKgH hOcd2yoMW+HYVlncCse2UgPXLGNbNbpXLMSt7rXk2JaLL8jI3ypbqV2qOJTa lXzJ35KG+FtNK+rZmBeT5ExIlZ69nZ8gSpJLz0nuvSMhsX0MPxES5LinBFWI gT+fCDllt/zaoZB6eSakXg+EzHAgJMeMMUIJXNFzDn8ntRTexpiPIp5X5Y9X BFOH07FJVnhFMWGGly2rQmt9leqdV1iyY1WNP76AK48XduDCqzgMUke3kAnR DtYWgiBaogy9ynhHsxDkKEhqcxSkZAftYCDk8ihItO2OVmojBINPgWf5neL9 E006xnt6jyZFgZMze4cBGAf27iqDXIvfJ3GC4pU3RiQZEdH0xtRhy++9sQhR 8SqBvHgge+XMqxxwNW8Mc8Q5eqgwFxuZj5OZ+TiPrK9ADq6t5ybIAHNwtZS+ JqKlHJxX1EM1L6bp0xfnx/CfSXuB72/OpFkAfIYssSGAT/mu7OmLDvZZ4vTF eXl5uxwktkmtNDmQ4aLJQZr0zVSLd5W19K693xXAbyb8Rgk2GaZInrscPIiB xrWyu4PFqRzgFgtAacEt04kHBLAIURm4tR0QGJEEBeBWXwwIDC2BW1VTgUk1 X2BSVRSYVA0FJrUWmAoXmFQVBSYHY8xYYFKRCkw6sMA0iaddh7+qjgITJSD/ nC7swIXXWGCKYCGJC0yxLCRygemWgby2ApOni32Zo4YVmGYfS+5a650KUyXu GiZDnhsdXBfCQmrowEPInbBQVviNYfErR+qM+e7IqbPInDpjDr+u1NkQ/7qQ 5s3WhUxNdSGjPVPnuupC58cIrAstYblXXWiByxmyxIZwOeXbwnUhe/ssUhcy kXjesLqQsWd866gLKcMv6kIiiQSHwt5VybqQw7u6XRfyuVGCTYaZjecux64L 1bI7WJwqUBdy2JIQcEtp3rqQDZwqAW6FLbjVHApHjcC41cGjXU11oV3zdaFd FXWhXQ11IbnWhQrXhXZV1IUcjDFjXWgXqS5kQutCfBiuw99dFXWhcd3yIv88 XdiBC6+xLhTBQhLXhWJZSNy60E0DeW11IU8XG3vwyMfHXk94Au7kD0JyDh7F e2NBg0cB+4xFMvc7YRGnrsGjWJjaZ/DIYUuccnCeNweHg0c2WV/+HHzcIv8C 05i/t1pgOtRUYDpozxy8rgLT+TECC0xLfO9XYJoBPkOW2BDALz94ZG+fRQpM h0iEcViB6WBPHVdSYFL6osDEkpB1CntXJQtMDu/qdoHJ50YJNhmmSJ67HLvA VMvuYHGqQIHJYUtCwO0g8xaYbOBUCXBrO3jEYX1pwsULbNvS3JEhFdWX5sU0 JfGJPEM9Cp8MWWFVAp+K7/YXZ7yeLpwFPsdPhrQt8MndP7yU5z3X5AbkK3AD qno3oFc3UIEbMP5uICcYkrZT2C+OZp6AVKNMn2EVMX3zYpo+mnl+jHo8IUNW 2JYnFHzpCXlznpAjb6Hk0cyLj64ZZk5lYOYk9q5icEaeRzMv3hUfSnJGOuXm WBNqxtuQM7KNETfH7URlNLbWxDZG84EebKPLlgSxjSIr22gF6QoAbEJtS+lX ALZcAmzVEsCWNdGN0pdnqAtgy/qoBoassC6AbfabS4A9XTgDbDaM95kBtsEB tmkDYJ/fQlGAPX90rQBsSS4ANk1CH0rsXWUtfSvvdwVK3zr8Rgk22UTZ5ODK NxYTC2NRLDoGm6AbUseiW2jDczX7nMgtW2F+f2ccgPmJNokxP+Y9K8P8tqQ6 Exq2GIz5wmKE1bSE+XVNpLrWnpjfsraYRHiBIs9QLeA/r7BhwK9F64Bfl+Ha BPbFVTRf6rA3X339dt4b8vy5P73+05WTKzhPDu+1YPvDVr/5zWNTuhik+d3D NHwtfpvEwyl3d5uwsUTX5PxNXuefhO2B6YKL5X5Zt+XClGN+tKwMBUw5HDxW JRSFkhkoCphPeYYXhKOwT5+xKBcqBbq402BjgOkyRO9YFZUMIlhgcd9oLCg4 nJ6YYp+x8FAPrqaY81+BdU5gTRMFKhvOhvpHp6A6beqzFrFoUga2UiyqFMGt FI1MDXVEUyyMVeResRC3utes7tUjaSzA31J/CcKJ+21UgtBsa+rZOC+mVQnC +QlKShAu9rGgBKFYJQjLShAujDFCCdxXgtDFGDNSxOdVBUoQbmzxCqZQIoW8 TvWeV1hUoeRIRnTyI7ywAxdeoQRhDAtJK0EYzULiShDeNJBXJkHo62IjSxB6 +djr9HjAnfxBSM6OnHhvLESCMGSfsUgWKkFYzRvDHHF+CUKXLXHi41hmPs4j 6yuQgzN/CcIpf291MHlfUw/V3peNrEqCcH6MQAnCJb73kyCcAT5DltgQwKd8 X1aC0ME+S0gQzssrKUG42KRWmhxOXb1zk8OQxEco7F0VlCB0eVc3JQi9bpRg k2GK5LnLkSUIq9kdLE4VGAp22JIAcEumgk/OoWAbOFUC3NpKEI7IFA4Fs6UG IaUNgdvNUFGBaV5MkgKTTo9r5ycI9BeMcKHYyWuwwbXAtNjH8AKTvFJgkmK6 72OBiahr1SVGl+UluR3XtFaYcleYFtYYFtsna9SSP1ujdhpCcLHGfBWmeVX+ 9QM52fXesn7AmJTTHsIElDGqr+LfeYUlE1BNBmmWCejjhR248AorTFEsZPxa DkdbC5m+Mj68tJDx4tWUIpqFIBUmZlNhEmpMqewN5HhZYSIblKIQlVoJwRBU YJo6OYipcWNyskwcpFsC5eVlr+Y8iwcSRTvEMVATGszGfZaPE3XTPh/cRh5q iWYEC7KBdbPT7gz6eXf29+YUsKgaWu0KuRPmxwu/Mcx55+hjx3xWZGqB5qUW KOYDK6MWjG3djKsX1MKFoC9viVqgFdXN5sU0XTebH8O/bvYia7lZN7NIWxiy xIbSFno0ZetmDvZZom42Ly8Gr0XNmddyqpstNim8bgZ4rUXdbPq0TrUxM3hX zCgTUixKZoRxkyQEKuw9BTM+knP99J7oPRiokVVMH3AtkmNR94bwZzaMbO5B ZCwsViU5Fu0Lt6p0YVEtLRxViU+ShRmrDQAqAEc5s650yQHCUbOsdOmW4Kio qdIlBk84ajlUSjNgUeHJj2bEoqJBCh1g0fxQ1N42i0BRYc10OatHMbbZzBo8 Uu7YPqkGj3T3UAnH8FVN/lLn9ZdJ1KOMv+F+WbfhQkwrInGZjukhxLDCntYs nx/qIUd+CKG2vRHGTYKwwFzV9FHU3XFIn2Ex57yMsvkzLO7UCPhg2WhFfDaI D5bIaoN8sFYWK7741MocXFVQrUzlrZUVBpsUi0tlNJ/Q8NSS5hMWzCpy1xSL dKu7vuGuKRaIK3HX1CN1LEF82tbhGZFQQ4qzZlv8VU11eOVbh6+mxV/FLIV6 t/grl1JomhZ/srb4l2/xV/GKmgEt/g7WmLHF/7yqwBb/Q2iLv9D8Osd6XmFZ +MPV9hL+TBd24MJrbPGPYSFpW/xjWUjkFv9bBvL6Wvw9nezVFv8nGampuVrc owVR7BTa4j/fqezp3ZAWjhbNwnr8KwlnkBb23J3YPf4BZoiFv+Ae/1reGOa9 C/CWDlvixFuSsrylTTZbgFsQyrbH3wyCQnJh2VU17mhL7MKmpraqjS9vW1eX /yYSc7tMXPyY2zlzYcgSG8pcynf529tnkdaqTaQyW1iX/8a+4Fa+i+P00eTu 8p/fU8ku//Mqquryj7k3AV3+Dkacs8s/1hfu0+XvsCUhgFSRvF3+NgAoYSEd 5q67stUegaympT53mPCeH6IisVKYSp/X2K5aaYG+J3vzLNP3tLNmfFx73Q9q z40yu+fzZtmW7ZK2DEN6wsZPpew/IjW5TdgNldptJml3h01ULsb7ZeXGiwXZ vDLCsHtqZ0/xVaIjrJZD0YLTNJQhFr/zStzCriiHt5UyJaBYDMwrs0yxUOdc C2BYZCm7zwyLMBWhSIbFnRVF3kCRDAt0laBIliha2ST9zD9EBVWhZNqkn2Eh pQx6ZVhoKYJemXdWVVH3PMPiUUXummORbnXXt2owWCCuxF1zLAiX8S0cRLdj 0QIv58hqWiIUuUAeItC3mGDfwofzVyKRNRb1LePC5YVvOV3YgQuzb9nl9i3K 1zwz+RaNrC86oXgUe0p322HmZGhaToYbdz+V0G2KoSa3KUhet5mEUBTU33jd CMXsxiuwIJuXUBRodG2FUDRLFY1UhKLA4ncUysyaUBRYiHamzAQatgYbA0zG mQnvcBWVmxRYaHHeaIlFBX0XViUdlMLCQ0WAVGLefwWkNwCpxAJLJYBUYhEn AzcpMTeelJukQ+KGJImFhTJAWGKxpQgQllhEaYmblFg8qshdKyzSre76hrtW 3nlaHnetsCBcSKLyMrptSdG6h+LIalriJpVAHiLQt6hQ3yK0Ph+MJ5E1FvUt 44/ZhW85XdiBCwV9i/I1z0y+RSPriy/sqzkTwvCZ3hnS0jvKuPuphG5TDzW5 TU3yus0k3KSm/sbrxk1mN16NBdm83KRGo2sj3KQecjQ7aix+5+UmNRainSkz jYatstyk9g5XUblJjYUW5402WFQoy00aLDxUBEgN5v1XQHoDkBossFQCSA0W cTJwkwZz42m5SZK4b9JgYaEMEDZYbCkChA0WUVriJg0Wjypy16NbXf21x7Tk 4J2pZRqXHLA4XGgWewARjhetfZCBI8tpiaAkg0CeItDD6ODqx5jOnhcpkUWW 9TCUAA8zXdiBC7OH2Wb3MMrXQnN5GI0sME0D5aAXPWgkLc8z4j93b5XSewIN ldLeE2inJPeeSXhKAlRYnAzYjajMb8AEC7d5mUpC0DjbClVJc7RREoJF8rxc JSFYsHbXISVoACvLVhLiHbii0pWEYEHGQ8QYiw9lCUtCsUBRE0ClWBxYAeot gEqxEFMLQKVY7Mmi8IY59LSsJUst8UaxAFEIGVMsypRBxhSLLS0Rl4Rikakm t82wmLe67Vtum3nnbpncNsPCcSEPAzRNtqashwESJvNymmIugRjK/BSBut7W HgbT9aYDP9dGgLTJvMiSHoYzcdwvPczjhR24MCt7H7J7GOVrobk8jEYWGF9L 0uz2+zEnnI+fP4q0xA8Qa7HyVkk1eIeqvCdQPEnuPdMwl0AXxcmA3ZjL/AbM sXCbV3mfcDTONqC9r8xDBu19wrEonllhnmOBuqz+PuFYJMx7OgHhWMArvT9Y sKoJBQosgq0o8BYKFN6RNhMKFGgQzUAPCizKpaUHeeKmRiKwqFkIfgosQpWB nwILVE3RgwILa1W5bSzmrW77ptvGQnItblt6JJQpPQwQjNnKsqfMAG2YeTmu HuYP3371+7tH/qk0z8CQZ4jSvELPzSv0TpAGiiyLvbRIAd8uU8C395pXTlmc EFPJY0oGH9tW+GMKePrVFND/ZXKM47/x4fA/T25TD2+2v+7+dvj0n8PD5w/s v5ap+/0/Pv+Wj79Vnr/V428J8fwxodOvhe+v5fRrc/nrNAYpMIOMcGyCoufu nLvHDUtvg0yaxwFhm3ld/ofHn+qF2wUguHV4PFouNGTeO42ssfAxnVqCYzq1 BMd06rMKy/LwePSMzqHWo+OBVk8MK+GS7QdlayVsGAG4fmElRJmzlQCtnmhW wgclBG4k9IaRjM940MzeSEaDXNoJxeyE1monCkNUgYe7n8L/Uy/kGP7pvV5I hUIp99PdMUTj0J/3fCt/UJI0BkC1nHhvbYTYI0Sa3po6bPndtxYhRj7fCgtr HrfCok/pt4b55BwkGBRfcdgUJxJsyEyCQRkXm5QwZYoKFVm2ZVNUqKKy1Z4p alESDIqwbCvEvFABZdsg5mWMNo16ofyLzcf37Aze/GvEv97s/rl7P7nfz57e 2/THz97/Mv3v70Yc8tmnzbv33z/9vZDqzbjKHz7998PH48MfP/7w8O1h9/Hn caVkzEL1Zz/9fPj7+E+OvxxGL6qF+uyz8YN7+PjTuHij3/z66+l51RiMj7vD 57tBqs/5QbDPt3orPt8c6UC2hh7p5jja86PtfPHw/t2nT+8PD4cP+3ebD+Pf ffj1HyleCIg5h7IFAWQxLXlCijxDWFZHrP0gktUt/CBDVhjDC/KXXpBZeEF+ UOZlUreDXnD37AU1H6hZ+EEtMEfITKWekLt/eCkPJanJDchX4AZU9W5Ar26g AjdgqnIDYLB+N5RNjQiymqZ6+ynyEIHDQyR0eIgzcc6MGLLG0s0BO9gcsIPN AWdfQBnP3RzAfc0zV0sXsr7Uff2CbbbbtG3R0t1PpXSbqiq3qfO6zTRN/cbf eL+s23gpFmTzipFQNLq2okXCcsgmUyx+55UioViIdi6+UDRslRUiod7hKqoO CcVCi/tGY1GhrAoJxcJDRYCUYt5/BaQ3ACnDAkslgJRhESdDdZVhbjxtcVUm FiBhWFgoA4QZFluKAGGGRZSWiESGxaOK3DXDIt3qrm+5a+88LZO7xoJwGd8C Rud3rGiNAkzOz6tpiZsEg/PzQwT6FhbsW7R8FjYCA/DzGsv6Fqm2F7pGjO34 ha7RdOHcg0qUtulBjehcwLy+g33mcS5gVn5eXxpykundzO/sn9RmeRp+B4zf WzmqlH5TVeU3dV6/mYScBIP6TsbrQU7mNF6BRdm85KRAw2sr5CRfao6kIicF FsDzkpMCi9HOnJlAw1ZZclJ4hyuLkTd7clJgoYXwoWTjvMBiTEVAUmCRZwWS t4CkwGJdJUBSJgpYNqSi9I9SIaSiEmlJRYlFlTIAVmLRpUxzondiVRGpKLFw VpG/llisW/31LX8tsVBci7/GwnAh5wLCmyhasQDz1vNqWmIVwcDy/BCBzoUG Oxc5POshgWHmeY2FncvlOY+cGb29rFiMF86jYOOT5a1YgLltB/PM41vAMPi8 vjSk4mG7aBrbpW0aA/PkVn4qodsEY+Wl3abK6zaTkIpgJt7JeD1IxazGiwXZ vKSiRqNrK6TiSeQvNamosfidl1TUWIh2JhU1GrbKkoraO1xFJRU1FloKk4oa izEV4UiNRZ4VR97AkRoLdZXgSJ0oXtlwisY/SIVwipNuaEpO0WBBpQx+NVhw KYJfjXdeVRGnaLBoVpG7NlioW931DXdtsEBcibs2WBCuSlPG0MFSU0YqQoGk jJELSRlGGpKU2emKJGXmxbh61r+Mf//d9//+7du7ItAivarM/BiBvnUb6ltR WZl5ic2Ka+VwrdzXPPN4VoEsLy9vI7FNaoa2YRloG4W9q7xkAvauynIJJsrm hFJaUF7FwZKhgioa18pSWlDtJJbHsBJQxSJQ2sxZm7SZM5QZscFTSc8QulzO pqzWhURWkw7fpZG7UMhz1KMXBmVFNjFz56iCYQcI8A4LwTC5hHgjFmxNMAwK o2wicZOu6iED9uE1A8poBlAGRVbmt5UVlUERk/ltlYVlUNXEc3uCxVW4tzFD zQ8sOpYWV8HiZLAdjv51zJpPG30cnfGdjcbCXFndfyiJEsun2qBWKHXisCVB qFUnFqbA4kNdnCwTlpysGAZ+yclOfO7MyXLaEie7r4mT3ftysuXO5KPIE+Q9 kY9h+1jwPD62nseX+zw+jhljBIhpfxqf8DbGlJFdIqsKPJVkZ5tWI2UTRaS+ TtvuKymbbCjIqscLO3DhVZzDp6NbSOxT+EwaC4l9Bt8NA2n+DD4MPoWmqY5H 8KHAidy1Vlg/wBBM4QPYMEiT+dQ8LKS612mwsEiF60mHWCgrfWReGihsd2Ke 95a4pM7K5E2dIcNrk6wlLPhApvdYtOADCdWjTpk86hyK0sdIbBMjXCh2+nDY cD97hNzr0Z54ups+yivpoxTTfR/TR6Ku5o7DMnmU2+NmzR8z5I+Q/T5G4oYn e5wmlp7sUd/jhoW3PeZkzs/L8k8Q5GTaR8sEgTEpH+e+LhMEpvmAsOrnJZbO IV+kCAymCOxV5JCwfhDDRsYv5mBtI9OXxoebNmLS2AiSRTKbLFKoA9P2JnK8 zCLJBu3PFJXaCSyKeHraF3nk5CMmcnbytEwc5B1PC3XYfTzt051QKGOf3qTY ZwzahEa0cZ/lY7Vz2ufDvX3GAmvZiAZl0T1350WSfdqdQT/vzv4OYQyFzQOs EIt/zkk2lOSu5Y1hzjtDkg1ltx22xCnJ1nmTbKjfbZPVFqhPc/tzqF/Up5lY 1KfHmNhOfXpPK6pPz4tpemZofozAmaFl7ctrZmhR/GLIEksnLg7FL8ouxjHR 3CXZ0JCDfZYYGpqXV3JoaLFJrfSncnnRnzrw9ENDi3cVo//Sc2jI5V0B/GbC b5RgkwkW3aI0AdtPH6FxrezuYHEq/8iQy5aEgFtFs44MWcGpAuBW2A7EXwG3 XDYLbnnZiSlkMW2D2/Nj+IPbF6z8TXBrQcszZImlwa0DK88uGdcC4NbePouA Wx6JiTnVbqk5127dwC2352TugluJgtvp0zoBWDN4w1rKxMUwPGHcZJiGX7yn QKadcMm5fnpP9B7Hqb3f021g63OjBJsMga3nLl/7GuSY6z3tMtnc2WUIbGvZ HSxGFQC2DlsSAmwnvj0nsLWBUiWALbcEtlQxoPQ0geIZ2NKhJWCramJtlS9r W8tU0fwEJaeKFvtYcKqIrlNFZaeKFsZYcKrIxRjzTRXNqwqcKtqHThVxyq/D X1VJYeWwAbnneGEHLryKjjAd3ULSThVFs5DYU0U3DOSVTRX5utjIU0ULHxs6 VVSLu4bJkOdGR54q8tqdq1NFIXfCQllVU0XRoLDHVJHLljilzipz6ow5/LpS Z0n8a0Jj2t1qTcjUVBMy2jN1rqsmdH6MwIanJSz3a3iacTlDltgQLqf7TeGa kL19FqkJmUg8b1jDk7FnfCtpeDqdBHpueGI6yfClwt5VyYYnh3d1uy7kc6ME mwwzG89djt3wVMvuYHGqQF3IYUtCwC1PfLoQTK1s4FQJcGurNkeYkQDcjsB4 AW5VS+B2V1NdaOdbFyqsEE2Rx6hHIJohK6xMH3r86i6x7fQZPutDi+GwbOc3 uD70plJWkSNvIS8YFdhH1woYJRcnrTKV5KR0ib2rrGBUeb8reM5q+I0SbLKJ ssnBWBSLiYWxKBYdg03QSRcaQmJ/G4QAt5Z9TuSWrTC/vzMOwfyUJ8b8mPes DPMb21P/iIG9YHI5wctNS5j/UBOhfdCemN/yPFWWAfCfn6FawH9eYcOAX6vW Af8hGtfmFMEF9sXV1Khlvzdfff123hvy/Lk/vf7TlZMrOLfgHeRwoLvt8OY3 j2UiMQjzu4epi1H8NomHU+7uNqFGpK7J+Zu8zj/NeWBYOLWw3C/rtlyYcsyP lpWhgCmHg8eqhKKgJgNFAfMpz/CCcBT26TMW5YJ7p+Y7FT450ztWRSWDYOdV wEZjQUHJopk4Fh7qwdUUc/4rsM6q6pkoUFmdCuYfnUI4G5b4LFuKRZNC0uZY VCkjbY5GpjTAlWSQS67SvWIhbnWvBUWTi/uCS1xwIEWbFoBS8LyadqZZgcrw /AiZx1kptpMF51nJOs+ae54VaEIvzDHrQCvQhHYxx4ya0POyAkdaD6EjrSNe va4XPS+xbO+8JkAsdLqwAxdexUwrkNmOYSOxh1qBfnc0G4k81XrLRFqfamUY jso71cpRAOU81coxIFPWZXMM2OSdauVYXHUmDHmE0Ph0JyyaFX5jWATLIeOP Oe/IhJLMSyhxzOHX1QSkmf9UqzStTrVOp/tU0wQ0L6bpqdb5MQKnWpfI3G+q dQHNkSU2hMzp+F8tOtXqYJ8lplrn5ZWcal1sUitVesIuqvQiSbuIwt5VwalW l3d1c6rV60YJNplg0a3oVGs1u4PFqfxTrS5bEgJuKcs61WoFp0qAW2WrdvoS 3I7AeKF2SloCt7KiqdZ5Me3UhyjyBCXVThf7WLA6NKzVobJqpwtjzFocEt7G mK+Jfl5VYGnI9nBjNP80TF6Hv7KSypBSIP9UoKFjvPAqKkM6uoWkVTuNZiGx 60I3DKT1uhDMnjxd7JVyRYjaqZePvZ7wnO/EtHUf+fX0pRK/D9OPeG/MTTY1 QlS82mIfcics4hR+Y5gjzpGDYy42cg4u8ubg1CPrK5CDm4AC05i/t1pg0jUV mLT2zMHrKjCdHyOwwGR9lJ4FwGfIEhsC+OULTPb2WaTApCMRxmEFJm1PHddR YFJGXRSYeIbj9BbvqmSByeFd3S4w+dwowSbDFMlzl2MXmGrZHSxOFSgwOWxJ CLg9MSAZC0w2cKoEuLUtMBEutAbo1iwrTGRgLcHbbU0lpm3SElMSsW+KPEHR EtM2eYlpokLvlJj4RY1J7ZRcy0z5y0xxDdJTnNXNIOuAvCwD5JXYu4oBxjzF WRfvig8lwZhOuTnWSNV4G3JOGH9eFrMYPFkkS1ezJfZEnI+7s51Bq7zYHoYA eZ/9uY69A+7kHw3hnTBnGioJFHInzGkEVxgC7oR9q+53ivC9XWfVA+4UzcZp NBun0WycRrNxGs3GaTQbp9FsnEazcSgD4X8nKOEQcKdoNg7FEALuFM3G4UR8 wJ2i2TicNQ+4UzQbh7PNAXeKZuNwyjbgTtFsHM7FVoIK4ZxsXFQozj2Gu3uo EI7ZBux0tO8NTsYG3Cna9wZHSwPuFO17E9G+NxHtexPRYoqIFlNENBsX0Wxc RLNxEc3GRTQbF9FsXEazcRnNxmU0G5fRbFxGs3EZzcZlNBuX0WxcRrNxGc3G VTQbV9FsXEWzcRXNxlU0G1cRbDwBKlRxWObrjRX2gycq2temInxtKfYZ+3Qz NA9o/4/9XvOA5OfmAXaSWlk2DyTujNWY57FoHkixHMx9Famda9QFNjOfqZMW K62r5zqkWpmqfM6Oa/m8QPlc1xEtdbRoqeuMlhqLlgEjn6ePZNESfnOg76nQ CTvCnxubDRZRi/aDi0GQi37w04UduPAqBj4NFvsrmvjE8EBVI583TaT1kU+D gaC8UqAGTSKdpUBNnVmkiRMXQyc1TbS4aND+InHv64V3qrVHCAthObrZB3/S yCkj1XkzUjJ45ID5+9nHZVorJjENpzVNu9Oa+5qmNffaMyOva1rz/BgB05oQ mt+e1ryDzRmyvoagORVD4VFNe+MsMqp5Xl7RUc15k1rpW1eXo5qUZxjVnN9V 1r51jb2rsn3rJsrmXCeQHCYsscDo3pKLRrWqZjVjOQyfWU2HLQkAt0RnntW0 AVMlsC2zViJhRl5i2xMwXoBb1RC4PQ4VzWrOi0kHbpPoWFPkMeo5PJIhK6zr 7EixF/oS3o4XzmdHykHtFgDX4GdHbitlFjnyFkrOUS4+ulbwqCQXeHRIMoQt sXcVA3J5zlG6vCtYsgu/UYJNNlE2OVg5BIuJhdEoFh2DTVATzp7KxsfRCd/Z HSy6hQ5RVrPPidyyFer3d8YhqF+RxKgf8561oX5bRptxOUDUzy4OATAtoX5a EaU9LybRgfEsA+Q/P0O1kP+8woYh/4ibGof81I+5u4JwnGK4wL64ihT6Hfbm q6/fzntDnj/3p9d/unJyBeeuvr3aDnu9Gd785rFQNFqn+d3D1BwpfpvEwyl3 d5uyx7gm52/yOv8kfA9MGFws98u6LRcmHfOjZeUoYNLh4LEqISmmU7eSkxQw o/IML8GFISzKhWraLO402BhguhzRO1ZFpYMIFlhC5XXmOylZNBfHwkM9uJpi zn8F1jmBNU0UqGxYG+ofnYJqtTIta0OxaFIGtlIsqhTBrRSNTGmAK0nyEFgY q8i9YiFuda9Z3atH0liCweXCtidZUP2CwV32bVDaEoMraurbEL59G7VobM9P EIgeGOFCsROGYIOrxvZiH8OHhOVllntKUaWg5yFhoq5NCNOLCWG5PW7WCeHs AtsLawxjiSdrnBDlkzVqN5bYwRozssTnVflDFjna9dZ2qJcx+YjKAWThg7l+ juu8wqKzA5JKc4FYThd24MKrGOvV8S1k/FoOtif9nr4yPrywEDZevE56x7IQ ZKiX2Qz1CnUY80trAzleDvWSDTpdIiq1EkjaezrZFxTe5CAEfQz5TBwcjyny 8rLXOfLznQpTeBioCQ1m4z7Lx5LntM8HR066kmgGCW7P3Xkx83zanUE/787+ HpGMRdVQxfeQO2F+vPAbw5x3DqIR81mRiUaVmWjEfGBl5IIg3sfTnpiJRiee j6qm9jDlS7RWNfE8P4b/xPOLvOXmxLNF4sKQJTaUuNCjKTv07GCfJYae5+XF YLaoOTNbTkPPi00K798AzNaif2P6tE49Gmbw7tygTPDlvDNh3GQ4m3bxngLT EcIl5/rpPdF7QFB7vyeoWBN+owSbDJM+z12+9jVIwp+ZNbK5B7fRmFbTvHM0 X+Ex7+yyJSHQVg1Z552toFQRaGtdN1OMQmg74uJF3WxoCdpuaqqbbQZPaFtO XpciT1DybNrFPpYU1z2s4rrlS2ebSGyjo7au8DbIjKWzTXhh5CS6RWy7fRDN LSqQytmmhsqZUUbJZQL6eGEHLrzGylkEA4muh5vGQqLK4d42kNblcGEK5elh X7a+u8nhwhRqdrHOcrgw7anEW8OMyHOjQ+VwYQbjszvXa10Bd8IiWeE3hsWv HPkz5rsj588yc/6MOfzK8mdJA0pDot3S0K6m0tBOe+bPdZWGzo8RKIa7xOVe YrgzMGfIChsC5lSQwpUhe/MsUhnaRWJ7g+RwF5vUymTvJDo9T/bSMVVJ8K4U 9q6yzptq73d1uzrkc6MEmwxTG89dDtYfQ8NaVdWhWP7CpzrksCUh6FbwvNUh GzRVBN1KS3TL+YuhqhEZL8BtS8WhoSZZrHkxTQ2YIs9Qz3wpQ1ZY1XipGVe2 v0C204XzeKkaBt32eCl3//ASTpqLmtyAfAVuQFXvBvTqBipwA8bfDWSFQ9r6 4KuXhwOMWKpRsm+oach88B4yr+pwgCHCdGJiSBR1fjWfL9SHpS80zflCjryF kocDDE6KBFWwc8JkYOck9q5i8EaehwMs3lXZw6p0ys2xJtWMtyFnZBwjbo6b pj8aW2tiHKP5QA/G0WVLghhHlpVxtIJ0JSC24rb1dKlfUo66VSX+oaZRy8F7 1NKSa0gSiynyDNXOWQ6vYM4yezHdwTZLFNMH+8EyV/H6Ixt91SwBLjWlMqkE uHT3UAm5WVWTv9R5/WUSPsL4G+6XdRsuBNeFRp8huG5q9lnSHLPPEOiXGsvF AnNVB5L57k7oaDjBQlxo+3Y1+4zFloqgI8FCzoodb2BHggW5SsAjTRSprDSl /MNTCNExlSCSakphIaWQeD0WWsqI13snUxU1FVAsHlXkrikW6VZ3fcNdUywQ 1+KusSBcikQdXpKow0SiGksSFZxlOizo0+eGzeHpr8+v/J/nvxbs6a8fxk/k fz5kfVw99PW4tmqEr+RxbSfsXsnjsr4e17be80oe11Zu6ZU8ru38wCt5XNtj xF/J49q2Q76Sx+0LVZm+UJXpC1WZvlCV6QtVmb5QlekLVZm+UJXpC1WZvlCV 6QpVkaErVEWGrlAVGbpCVWToClVNAl5dPW5XqIoMXaEqMnSFqsjQFaoaYVVX j0v6QlWkL1RF+kJVpC9URfpCVaQvVEX6QlWkL1RF+kJVpC9URftCVbQvVEX7 QlW0L1RF+0JVtC9URftCVbQvVEX7QlW0L1TF+kJVrC9UxfpCVawvVMX6QlWs L1TF+kJVrC9UxfpCVawvVMX7QlW8L1TF+0JVvC9UxftCVbwvVMX7QlW8L1TF +0JVvC9UJfpCVaIvVCX6QlWiL1Ql+kJVoi9UJfpCVaIvVCX6QlWiL1Ql+0JV si9UJftCVbIvVCX7QlWyL1Rlfd71K3ncvlCV9fGdr+Rx+0JVqi9UpfpCVaov VKX6QlXWp769ksftC1WpvlCV6gtVqb5QVV/a6qQvbXXSl7Y66UtbnfSlrU76 0lYnfWmrk7601Ulf2uqkL2110pe2OulLW530pa1O+tJWJ31pq5O+tNVJX9rq pC9tddKXtjrpS1ud9KWtTvvSVqd9aavTvrTVaV/a6rQvbXXal7Y67Utbnfal rU770lanfWmr07601Wlf2uq0L2112pe2Ou1LW532pa1O+9JWp31pq9O+tNVp X9rqtC9tddqXtjrtS1ud9qWtTvvSVqd9aavTvrTVaV/a6rQvbXXal7Y67Utb nfalrU770lanfWmr07601Wlf2uq0L2112pe2Ou1LW532pa1O+9JWp31pq9O+ tNVpX9rqtC9tddqXtjrtS1ud9qWtTvvSVqd9aavTvrTVaV/a6rQvbXXal7Y6 7UtbnfalrU770lanfWmr07601Wlf2uq0L2112pe2Ou1LW532pa1O+9JWp31p q9O+tNVpX9rqtC9tddqXtjrtS1ud9qWtTvvSVqd9aavTvrTVaV/a6rQvbXXa l7Y67UtbnfalrU770lanfWmr07601Wlf2uq0L2112pe2Ou1LW532pa1O+9JW p31pq9O+tNVpX9rqtC9tddqXtjrtS1ud9qWtTvvSVqd9aavTvrTVaV/a6qwv bXXWl7Y660tbnfWlrc760lZnfWmrs7601Vlf2uqsL2111pe2OutLW531pa3O +tJWZ31pq7O+tNVZX9rqrC9tddaXtjrrS1ud9aWtzvrSVmd9aauzvrTVWV/a 6qwvbXXWl7Y660tbnfWlrc760lZnfWmrs7601Vlf2uqsL2111pe2OutLW531 pa3O+tJWZ31pq7O+tNVZX9rqrC9tddaXtjrrS1ud9aWtzvrSVmd9aauzvrTV WV/a6qwvbXXWl7Y660tbnfWlrc760lZnfWmrs7601Vlf2uqsL2111pe2OutL W531pa3O+tJWZ31pq7O+tNVZX9rqrC9tddaXtjrrS1ud9aWtzvrSVmd9aauz vrTVWV/a6qwvbXXWl7Y660tbnfWlrc760lZnfWmrs7601Vlf2uqsL2111pe2 OutLW531pa3O+tJWZ31pq7O+tNVZX9rqrC9tddaXtjrrS1ud9aWtzvrSVmd9 aauzvrTVWV/a6qwvbXXWl7Y660tbnfWlrc770lbnfWmr87601Xlf2uq8L211 3pe2Ou9LW533pa3O+9JW531pq/O+tNV5X9rqvC9tdd6XtjrvS1ud96WtzvvS Vud9aavzvrTVeV/a6rwvbXXel7Y670tbnfelrc770lbnfWmr87601Xlf2uq8 L2113pe2Ou9LW533pa3O+9JW531pq/O+tNV5X9rqvC9tdd6XtjrvS1ud96Wt zvvSVud9aavzvrTVeV/a6rwvbXXel7Y670tbnfelrc770lbnfWmr87601Xlf 2uq8L2113pe2Ou9LW533pa3O+9JW531pq/O+tNV5X9rqvC9tdd6XtjrvS1ud 96WtzvvSVud9aavzvrTVeV/a6rwvbXXel7Y670tbnfelrc770lbnfWmr8760 1Xlf2uq8L2113pe2Ou9LW533pa3O+9JW531pq/O+tNV5X9rqvC9tdd6Xtjrv S1ud96WtzvvSVud9aavzvrTVeV/a6rwvbXXel7Y670tbnfelrc770lbnfWmr 87601Xlf2uqiL2110Ze2uuhLW130pa0u+tJWF31pq4u+tNVFX9rqoi9tddGX trroS1td9KWtLvrSVhd9aauLvrTVRV/a6qIvbXXRl7a66EtbXfSlrS760lYX fWmri7601UVf2uqiL2110Ze2uuhLW130pa0u+tJWF31pq4u+tNVFX9rqoi9t ddGXtrroS1td9KWtLvrSVhd9aauLvrTVRV/a6qIvbXXRl7a66EtbXfSlrS76 0lYXfWmri7601UVf2uqiL2110Ze2uuhLW130pa0u+tJWF31pq4u+tNVFX9rq oi9tddGXtrroS1td9KWtLvrSVhd9aauLvrTVRV/a6qIvbXXRl7a66EtbXfSl rS760lYXfWmri7601UVf2uqiL2110Ze2uuhLW130pa0u+tJWF31pq4u+tNVF X9rqoi9tddGXtrroS1td9KWtLvrSVhd9aauLvrTVRV/a6qIvbXXRl7a6eHXa 6v84/vL9+48//PTzuw/jf+OXv7376afD/kEPg3n4v4efP45/3r7/uPvbL+Bf /Om///nLu93m/cPhw3569PGfpFzX+Kek/7X/Hx27e2uDBw4A --=-kEbuFixda2EUEKhe1aeA Content-Disposition: attachment; filename=sdb-logprint-tbi.txt.gz Content-Type: application/x-gzip; name=sdb-logprint-tbi.txt.gz Content-Transfer-Encoding: base64 H4sICEKPnT8AA3NkYi1sb2dwcmludC10YmkudHh0AO1d2Y4cx5V9Zn9FAXqx AT/EvjRmBtBCGcTY1ICiZuwnI1eaIzYps1syPV8/Gdm1RObNtSojI6oyCNhq RWeJUZE3zj13/1I+/u3Dp3e/fH7/8en+blf9yZOnZJcXv73Pivsd+qIwqper h5qr1YN5/vl+R5CWWLHdh+Lju6e/3++0QOju+JGn5P2H+x0Xcvf3IsnvdxhJ vXt8Sp6q/8y/fffqzdu//sfd3d2ffvjj7s3Lb3dfv9396cfXu+xf2Ydih3fp h0/Zz/WHf4e+4D9Ufy+h8vd3/77gn7u3b75+/eP97ul9fo++ZCpRJVFot3v6 1y/F/Xc//fnPf8W73Vfvn4qHx/vqp6fPycfH6sHqiX9U/1BI04Kqu1evf7jf ZdUJkt3Tp6fkQ/XP5PBrrszR3HNrKXle0mJ396L66Hcv73dffS7ePVYf2+3e f/xUP7fblR+Sd+Yvw+atPL7/v+Ie3b349oc3L80zeXF/9+LFQ/LufXb/6vVu 92BW0BeGi3y3+634bHZbfvr8kDyZnz59/PD+48/3vPrIr9U35Yjudu/qH+Ru t//d7pfPn/7XHEP1UPL0/qG4x0hgjpVk1dMP9oqW1cey04pgTOnqY8+b/ELK 6j+afvh5f1LFl+f1arH48lR8fHo0Pyenf6k+WW31509laX6RPxS/PSSPPz9/ OH94lhbrPKof31XHh0blRltyo93LTfVan+Xmx+qXb//2P29evX15FB6xovBQ IhKEzxMghRPWFiB6FCA8IEC4U4AIZ0xiYQmQkIQr8/mstXISIJwnDOHiJEU4 T3mnIGG1gCThu29++r7vHZQV1JkDJ+y0JJ7fASaqegn1Z613UP0tn58qGfy5 fhcVmiDzLp4/UP0zfUh+2dXfozrMr//4/e6bX8uyOu7d7/5S/dvvq2+wP/zH 4h9fVbey/qDgnFZnWP3y86dPT7tvKpGhWPHqt9++flv/KKrffSh+Kz7Uv8TP vzCvCz8+ma/8IXmsX6T5ktULLj8XRX22UjJioPrju6J6gHOOTodB94dBT9+8 3B+GOiwxxNHxMI5red8BUXhAaXUJ0P6AVOOASP3Z3Xdfv/3a+qn/XTEswPZw OuNdVVuRanQr/efDCAMbIAk8H0pmnQ8W45uadD40bcsyY2j6+aA+Mf7xp/96 +Wb3TQ27e3GuJO999ulXc0qiugIVNBmRuyfaCF9eix5GGhNdy+KXp/ruPv76 8X0trY//fJ9XZGIU4iW1ID53D/H5gRq8ev31t29f/fcJ38k4vsPr1IXv+1dU 4fsJgfavCEA+PUK+EGmZ8BOy8SPkYzEF81Eb88kFmF/90UgyG/OrFWy0QNZa OWE+NQh/xPtusF+ENbx4Ya7J7vsf3vzn7uVf3r58/fbH57Opqe/93cvvXz2/ L7x/X/j0Jujxet+9qJ/bvwhzI3Yff334m7XVWmzK/Z8iTXLNNbt78btHQ6CF yIj6w67ixpj/fudRbvt5ycvvv+s7h4Pc7s/hu+M57MBB7J5PYjf5KAZUcaFU WxUXBZoMXxRdpIpFryqurm+tbjU6UwkTyiU6aWFMmUaDnESolpqhZfZ8EKLS QBMOor7xU/UcVCSEtTdw1HMTN1CL5MgG+pGTcdJGTsaTNnIygSJyroicAwIj CGAeQnplHowNMw9/kDzBzxCpxFVcCNcyVKqQ6agISIYwlkCGJJAhafuwijBk yB0dpSqzOBhdkY72y60nOtp/FBulo4pHOuqPjkbk3Bwd5SOOMH+QHAIdjRdi iQsx4kytMP/oTGXu42WUhOpM5VQWLAlF5JASmmBb5A4rWWvFEjnKwhA5N+y1 lJQUqTpQNk4TnqzGXgfk1gN7HT4Kd+w1/LgmlzPiml0M9sQHQKwTVac2JbA5 IZo4Ka7IOCC4LIX74/vwoxQO4q4D9FcxQH9VBuivJhF6w6C/mgH6q7VX+iv9 emMHMN0z/Y0X4lq8sZSF6o2tZSgNR4YkNjlHtgxJxWRThsyK5dGnJAwZcsdn 85RZJE6syGf75dYTn+0/ii3zWTknTy/y2YD4bITezfFZ5dedO4DpIfDZeCGu gc/KoP2zWUgyJBs2EZOEyUaGyvOKVeCAjSY9CBG5SUKbpchicTJ9ZnFsBULb L7ieCG3/UWyZ0CpxrYQWMpBOQnt8WeMpCBPZ6wBn1SngrAkFnDXREV4DIa0J LMZJvRbjEPNSfJLWftwOgbTGG3EVrFUH7YUtQhGisxJZQvHkuyOtaZJZTE2l 63lh++XWE2ntP4oNk1ZldhdJa6CkNaLr5jiraQDhk7P2w3YInDVeiGugrFnQ jtYyIBkijVZEQkiGeaOTzPPKSYYSosKQIXeUNUns7E+9ImXtl1tPlLX/KLZM WXH0s4ZLWSO6bo6yUs9u1n7YDoGyxgtxDZS1CNnLylEwMiSRNlGNB7CStVYs s4flYciQO8qqEzvBM1mRsvbLrSfK2n8UW6as1KGXFVcgsyplzQFl5fvrg033 RfeUNYGUNYWUNZ1IWSO6uqasKaSsmV/Kyjx7WfthOwDKGi/ENVBWhkP1suJC JiUNRYaQkpTxVkp0vZK1ViwZMlfAvQxhj5RVJccUTlwojFajrANy64my9h+F O8p6GWPFvYyV1FysJqZcc0XPZKwV2TUa80BZmSTyzIZZUw4jKQs9TggHCAaC /bLQvl0VVW2HLvz7S8bLcXI8QEgJbJdFYLssOqFdVsTOxbBzqG88bJdFvbbL IsKvD3UAlD0T0nghFrsQw+2yBLVmD0j37bIYPdhA3755+bU1WUb2CtyQOuZQ HeuZHiTSr49fNfTxq2EPktkh56i64EYt154jdtDDtSBWAPBV9ZemRgL+eZiP NDyzBepXOePbGe/PDI9LxwZKoOCQGB/cU1uT7OzBPcveXSkl5c3BPfuVrLVy urvWzUUOBz/1nzxDOWqfPGZo9OSZoLk5kaVmbp1OngycPOmZuSUUpnjeyWOE rMPvTvAnixz+8d6x/eGfSAFOYB9WDMffkL2n0ZT1H12iSd/9ZJ3oQ+Z4ZztI Mdy8IGDzQsPNSwx9y3LO5mWRsgs3D8VekTaeM6WmI94iDI3OYmhj2tUa3iZL 99pVHAhd1/A2HoCTkYXC6c7RC00nY7dq8O12P3mIrElv6oYmvSnM7agaZUMd WhBGbTREEqIhKj1NelNw0lvv0LnLJ711tBwXwCQmM0bNOQBc07XiAsBlljmj qHvAVVs3Z5JtmDM8EHNGUV7PUXwAK1lrJZozrs2Z8ZO/RnPGjJo4mjPEtznD 4eZFx+aF7jBn5mzeiTkjE2jOoJXNGbKodrXMGbWCszAN3ZwJZsDYOXqBsCKa M77NGam1bc5gFc2Z6zZnmoBL8UWAy21zxv1kaJPkuW1zRm/DnBHhmDOEy5ba qley1ko0Z1YwZ0ZO/hrNGY6tHHbv0ZnDhD07i74jOiM6ojPCe3RGwuiMXDs6 gxfVrpY5o907CzkK3ZwJZkDdOXqBmKLLaM74bodKbXMGkWjOXLc50wRcE3u7 AHCFZc5o6R5wSY85ozyYM/Wg5PPNGQHMGVF/vdqcqfsNAVvGPHg0Zsz8UZf2 jPl6akY69WL2TD1ZVZ9rz6QL6y2GGG6y6v1K1lq5AXtGVK+8KJezZ+hF9gxW 2pj3c06+bNgzOOk2aJbhDANqsMuiQdAAIAewEWK8Ww2l3ODVInpQA2Rgeg4y VFspZuhBaDXpEmwgEZAnJAU8tLR3o9BqMhudMEB95umlJbCaMr6y1YSWVOIS W0rcfU4b5wFbTW3lM9NqCkD7kFLfvNVUU6/zrSbRazVVAlRbRhqdaS8RyoUV /8GU6SGS1mkxiVPcfsJBkAkIN2SSlGADlM16E7Wr4PwN0BzYRIysbBM14BTr kSFZY3BqzatPVnBCyVB7Ht0alt5czyOpmaLq2E5diIzq1QrIB+TWQwH58FG4 KyAPWpMpNl2TXVo8frkiGageX1CVDpSPU1g+TmH5OJtQPh6Rc41+RgyWj7O1 y8dbhpzfcfMDkOy5fDxeiGvpZ2QKJrfsouebcdEnoaQcser/SfM2Pq9krZXo onfvoh87+et00U+Z9G68zbNydAaoCdcwrahc00MvJCzTKKCHXh5IPz8RXOXd Q6+gh16v7KGvB61PJ3YjLiUlLJdS4d6llKnAPfTJ2VQwAOUTPfS+PfQqeuiv y0PfhFOsR/r+jsBppdSPcJoS93BaopA99DeEpbfmoc+zrCyzFNlu6WQ9D32/ 3K7voR85iq166Gn00Pvz0EfkvH0PfduQ89vgdQCSQ/DQxwtxBR56U4u2ZQ89 24yHPg3GQ0+IgdQHsJK1VqKH3r2HfuzkvXjoO4q1ujz0M0aqGtfyZdVaEoEd SLGmE14WYAOKQye8ymHgQvdudC0nvC6AEz5hKzvh1SzuNuw1kshKk0/dt+4w FlHYTvg0HLY3X79EJ7xvJ7yMTvgrc8KrphN+pPWca3wUoea931ojuZvzqqc4 wVayN6dJud6s3wG59eBVHz4Kd1718PteaCtIPNL3YvasX0TGC37Pn/UL/d6M A0OCpXB/fM/PVW3fLtyXY8AtrzLg49AMuOV1EqE3CFrKdAa4SIJ9chGCSahc xLNbPl6Iq3HL61CzRG6tk9it8dmiUClJEnUicSlakc/2y62HOs7ho9gwn1W4 0ccNy8hnr4XPRujdHJ8lnn1r/ZgeAp+NF+Ia+GwatH827LmFgjZsoucVS4bS QGwiN/7ZgmDWIHFJsSKf7ZdbD/7Z4aPYMp8lKvLZ6+SzEXo3x2eZZ/9sP6aH wGfjhVjiQoykbxGrhjoX7tO3ilDdubeWu3Vr9LcoRJJixexKtxXpb7/c+nDn Dh7FVov+SCz681f0F5FzA0V/TfbKPXtj+yE5hKK/eCGuwBtralm2XPRHN1P0 l4VS9Fc9S5qxkf1K1lqJRX/Oi/5GTz78oj9SEbkViv5SBXaQzjEcLi76ywBh Z1kOi/5yDv3Dee9G1yr6K0RbMbBihrWxCHeTs7jbiNeIWhNFC/fDHCRFgRf9 ZcGwvTP0C6n0aiz681n0J2LR35UV/TXhlOGL4JRZ80IL9/NCJR9qZNrvzxyg 5l1wmoxTczMqHp/fj4P1E8T50EkwkpzQNnSaV5u1Vk7QqarPWQxRd9vKJrTv lCFWigqio5h+JcLPa8DEzmtAeDCvAQIU6mgQgXqHHDuetyzA9vCMccdz5y1D 1y9hYAMkgedz8BCbLtbj51PWpYFLnA8Dmp6xGZreAbyTiyZJSiYteE/dw7vq dYzSiO1nY7uJL/nFdgWwHV7NLryYdDX7g7bHYfVn1uBIfSqk5kitN0tt4CJ4 qsHpP4pN5yzKGbo95ixOz1nsmAHRkbNII5avheVMJ4DbHKZ++zJdkdco7gBG T4jiRrLiRcBdy0QSao3Mrfl6by9JsCJZRCk7My5bj2/2y60nvtl/FFtNEsQx SdBfkmBEzg0kCbYCzSOuM3+QHEKSYLwQK5S4CGuuVancu1/zoWSFGF2z5Elj 2jJqzIpl1GBk9n+MrvUYNSJG1y6Nrlm0iDPFY3RttejatPNZLrpGU0gRkFeK QPVF0TXBLHjP3MN72csoYnTtfGw3I9v8YjuMrk3Diwujazaezu0IkmBRqARZ ISW5YnSt/yJ46AgyfBSbjq6JGbo9RtdidO1qsTzA6BofmXDvD6NjdC1UAR/h u/KULEwRd853FUHdJZLSQ4lkrW3PL5Fsaluzw4onsH2JpNGyrKtKUllFkspl hWStKWf46xerkKzb7chQKiQFEqx5P/crWWvlBiokDTKiM0++q0KSXFQhKVSN g3NOHjcqJLsddGRZvQ+LA7vqIzF0uRCtjrTwsCbI9OJAgz5kDpOdVNko4OZl x+alPqV8HvlmMmPzskjZhZvvYFykjedMq5UrG8UsxjWiXRWytKt7b5JiQ6U4 nisb22rBc4jqDL1AWHbzlY3heyDMwZ88EEIPWfhd1Y2yI7rQa9Y5ji4oGF3o DXRcHl3oKL4UwMQlM8IbDgDX9EG8BHBP7nuKkXvAlVs3Z+Q2zBkVjDljHA5N tfW8krVWojnj3pwZO3kP5gzUgZ3tXvYYj603InqhpkMJzrVdBiwWCXCBSQV1 tELQM696t7yaxYKhxTID1BZRoHxJBaqxpUDdNw9QOnSLRYVjscyHfsLSaLH4 tlikZrbFwmm0WK7bYmkCLhlpuz8GuNwCXPfl/CrbusUitmGx6FAsFonqZtoP YCVrrUSLxbnFMnry1xiAaebB+g7AULh51rF51rF5PmfzTswZngBzRqCVzRm2 oHY1/+GjdiUr+AOL0M0ZHYw5c4ZeiAGYEMwZaQ+FY3RoKFw0Z67AnGkCLhKX Aa4VgCHMOeBqjGJK4nhKokIENx1F9YqVkkiQqdpaJyUxykSUiXlpqgoJC1bc D5Yzefax6nYpKTJJVEcpYr4rs2606rb600fLuhxLkJYdmm6b+s0pxGcCBxuy NHOwAzGj6/blzEukYANyRuXqxEq9gQ1IDaifLPxSv4sa05qmyieMdp/sqAWK GD0FozVCGjUSG59XLIymyDxw7IzQg9EyYvSFGC0anRFI7DseOyOsBu9YXdQZ QWGLglP3rlStYmcEB9hugtd+sf0KOyMoTvMiVVY7ALFeZ4SBi+ChM8LwUWy4 M0Kl3Gfo9tgZIXZGuFosD6IzQst09dsZYQCjo8s5VAEf4bvESsyj2j3fTbee mMe3kZiXBJKYp0llQTeatB5WstZKTMxznZg3fvIxMS8m5nlOzKOzGNeIdqVW Yh4t3GvXPPTEPEst+E3MO0cvEJbHxDzvHggTEDt5INBQb8aYmHcFiXm06b6/ qLBTUSsxjxHngJugHnNGeTBn6iEy55szApgzght+UpszWHbZMpRYxoyZzeDS njFfT41L+/L2TD11Ig/FnqEVaWyy6v1K1lq5AXumIn+oKJezZ+hF9gxW2tDB OSdfNuwZnHQbNMtwhjObIzQsmr02mDC8mlJeiKWCyBpsj5YzgKHaSjFDDUKj 6TDvxzaQCkgTuOgwmno3Co0ms9EJs6Vmnp6Q0GjKVzaayKI6XFs63H1zhoQE bDS1dY9no+kM5UNKffNGU9Dj+wSfPr6v02Dao96C0/OGLBKYD0bZrDdx4fxA mgOTiM1I2XUAp/Ky4lBm9b5m7lsvJLy3LiWEQbQ3hKW3Nog2pzRJrKwbM301 Xy0BaUBuPSQgDR+FuwSkoDWZQtM1WRxEu/Qg2oicbkloEINoW4ac9JpvNADJ E/KNIpW4igsxxl4tZwDH7tmrVJt26OPNOPSLYBz6mLYSCPcrWWslOvTdO/TH Tv46Hfod1c7dHn2+UGBbwW7Hag4yXOzRVyXYgBbQo68LeGhJ70bX8ugnJfDo p3xljz6eRQRHlDiXlhJ3n2ScJChwj34RDnWcr32iR9+3R59Fj/6VefSbcCqx X7s6663j8eyiv7Uc0Vtz0RcyZ1rq7FgYS1Oareei75fb9V30I0ex6RphK+LM K8PEoZv+8gYbnW56aBVgOmNuzNlFwB2WXgpcHIQCJ/6xFiViq2cnPoENUeja DVFatttIq1N/oO3ZiR8vxGIXwrUMlaHmlNxat/FbI6wlzwnJUmSxNLIiYe2X 2/UJ68hRbJmwatRHWGNTm4X5bFdTGwb4rE4i9IbBZ3UG+GyCffJZgjw7z/ox PQQ+Gy/EFfDZFAftgJXByJBAgjU7se9XstZKgDLkJkdaMcq5ZhaJQ+vx2QG5 9dGkcfAoNsxnFep1wEY+GzafjdC7OT6L/fpnBzA9BD4bL8Q18FkWtH/2hobb 3xqfrZ2SSNlOSbwin+2XW0/+2f6j2DKfJdE/e6V8NkLv5vgs9eufHcD0EPhs vBDXwGd1qHy2rh4IRoaEyfVr5KwcVrLWil09UIQhQ24SZHWW50TZjRtKvh6f 7ZdbDwmyw0ex0R4WUi/Tw2Ji7caFpRMEJseSVXtYcNjDgsMeFmJqD4uInI7p qIA9LMTaPSyadJR5dq/2Q3IIPSzihbgGOip6mlJsZmgO28bQnPOHWi2ci04x paAzglnJWit319+TIvShOaMnf41Dc5TN3rwPzRFw87Jj87JjaI7yPjRHwaE5 eu2hOSgoypUGMabw6hGd1uMdVsD0ke4h2hrJrdyP5E6LSxj7ZqZcVsJiPO1Z a+UkPoohYjUKcTvlMspElImVZSJDQSdx46AsewEsewEse2FZ9kYzhWDZrxIk 4DRJ09WCBANy6z9I0DqKLSe90JjEfaVJLxF6N5D00jR5hd+klwFMDyHpJV6I K4gyZDTUpJdahmhAMqRUsxBAUqlFs7DVrFguWmw06bCL9toJLVVWL7Qk36cu sxUIbb/geiK0/UexZULL9LUS2o5ZHV2EtrfZdneccQJ7HeCsCQWcNQHwytII r6GQ1hR0JK5MIK+k1ST7+iSt/bgdAmmNN+IqWCsP2gtLQhIi0xzGtnxU9b+m 5WNWrACgKU0OwfJxR1qtGXsVU8tW9ML2y60n0tp/FFsmrXav/UhaAyOtEV03 x1lNOrVPztoP2yFw1nghlrgQw/lImqBTPpJWzvORMnUwkwKcZtROcvM/zeii LLcwYfjSYUZXwLLo5IkRQwONlmQxA9FsDicaCQ7ThUWu/PC8pIBam3rV2kr7 1dqJGoDQfntrmxl8BGTwWS1aVXXZLMA0wyXcZfAN1vlASBQ3BYlkxhAdCEiH sTZrQWIOIZF2QGLqCxIzsL90RsYISUtT/HFBJXWaQEwu/WKyGsbkERZM+YkF J9I9C87Rxmsg6TZqILOAKmYEaStHAZSjsJQjijWQzmogh0/eQw3kvKnc2Hoj ohdqOpTg3ILHgTJHCadySwWVtNrvmXAr9xX3bXmtMketYZljuW6Zo+ndMkOB utaIZU9XAOVBI9Y9d87XiAJoRGE6vzxrRCw71SGy9KFpZeFSJZqvp8ZFenmV WDfpKENSicBeFGBYuKA3oBJF9cqLM0++SyXSi1QiVhoBx+bwyZcNlYiTbp24 jG/zTKXYaAyAjkpnTCdSyguxkGFINdgenaFWzFaKGYYhVMpMwqBsAZUyF1Ap i14Eg0rZbHRCK66ZpydKoJQlX1kpqyWtWmbVmqfEuVWbk9BjO1lIsZ259hih dkSxW//E4I5rT6ZpB3LyZCI2OI27I7gjIRqiXtfZAoWCA3iHFdgezue4EedN K+9oyCiAG5Gk67oRW4AryUWAy61geircAy4bigR5Btw22Q8AcGeyfdqgnLcJ uEG3l7UD6a32squA7cSOr2uA7QLdb4MDWz7SWWsMbJkFtol7sJVbj9mQbcRs 8nAcVAzkfzGQ/8Vi38pVYjYjJx9jNsvHbBprvVteLWaDYcxmBqgtokDlkgpU 4JMCzbB7BaoDtlbayO/dWpkN/SRPbt5aCd89ZAJ5R/cQVSq6h67bYmkCrukH eQngWllmGXcPuNmQPz4mCttQyk19T9ZasRKFOSos77vuSRRWMVH4QvzEdoUq lWSwQrUjUbijcgH1gpZj/BQQP2fA11z8hPqFMLCBw7wj+3womXM+k1KHpwWr UwDvDHmFd8Iug3dtwbt2D+9Fb/Umjdh+NrYr6Rvb1XnYPu1qDnWfOOHp3O4T AhUkS0/TnjnierXuEwMXwUP3ieGjGHIJ33r3CaJn6Paguk9c3ANYCgfcY8AL qxjwf6s0YvlaWM40nByoV54c2OI21G/R6gBGT2g1EcmKFwF3LBMF3npEFW8j oloEE1GtTLxW1uXzStZaiRFV9xHVsZOPEdUYUXXPksQsljTiAVL05AHK3ZeR Vxox8Iiqhfy+I6rzoZ+wIkZUvXsNsN1NiVb/oRhRveqIahNwjf1zCeBKC3BT 94Artm6xoG1YLOEUKRPKWi6C55WstRItlhUslpGTv8bZ5VRZ4Vfvs8sZ3Dzv 2DzvmF0+a/C6E3NGwNnlcuXZ5fUQjMW0q7bMmcJ9gqgJgIVtzgRUzjZfL0Rz JgBzRmppmzNs7ZK2aM44BdyavlwAuJY5U7hPEDVQGEzTJQfmjFBj5gyz7RmZ STHNpGHnmTThgxPtA6d+86orG8NFm1Z4/XkOdmC3aV08wfII0CeEPrSApVae RQdfVR18VRP43HEos7WWdHSeTTpSTVIGn0s7UmayjhTZLIfP5QI+Z6L47bWi QyMVJXyuhGEJjmBYgiMNn8MYPodhKisnBD5HUvgcpfA5msHnGIPPsRw+xzl8 jsO+R1wI+Jwo4XNSwucUgs+pXmpEu1V/etR5oiHwdMTqiT+N/TQEE/zQcPIE EzzpEIWkQxTSDlHIOkQhU/C5HEIRzyEU8QJCES8gFPESQhEvIRQJBKFIIAhF AkMoEhhCkSAQigSBUCQohCJBIRQJBqFIcAhFgkMoEgJCkRAQioSEUCQkhCKh IBQJBaFIaAhFQkMoEgmEIpH0ppH2wEQWYcI5TLStPZGClFfRob9F1tuSrifj dRlrTxw4won8inwG2zrb2DIz656NLUqbLWvRiHfLl/V0I8GgceuJlv3WU0dK d1dAqCOlu9dluoB8DwUtFAwXlRPCRfX3DiVcxIRgzaDFfiVrrYQULjoUytnh ovz6w0WjJx9EghuhMFx0oIh2gpvsDa84TnCDEaEhC7vR5j3p2/JaEaGEgIhQ olbWmWqWzhx2UGJETh5Khqh7D2UeckioBf2eQ0JnYD/hKIaEvHtdZSMkRNgQ olzfvMCpNG6hqnIJY0JyjZhQL+RidVFMCCNKLch1X1ZeIhS7hkwq1mJam2zG rLViFWsJJDOra0hPsZaOXUMuRFCBbQRFQ12XYteQ2DVkWXyX+EJ8tyl17h7f SWwb4gDcTe6aX3C/vrYhuUwrmE3sXhl0vbYhAxdh/bYhI0cx5Di+8bYhUooZ yj22DYltQ64Wy721DRkwXkdaDPvD6Ng2JFQBHyO87NQGlWH3Wa4lDyjLdf3R osQO0t70aNE0mDAsx0Q2b+h+JWuthBSGvdHRoqMnf52jRadQQzMmcym/Ooej Rfmqo0UFHC0qOkaLSphXyWTvRtcaLapkW2swla8cCJaziN2YEufYUuLuK+9N plCwgeC28vEcCD5D+5BS33wgOOhRd8yKAcdRd1c66q4fbU2S4kVoa5tMpXu0 TTaf2lqcVRh4bb1OzDfDYVhNEhEijep5ACtZa+UGrKawk1cnnHwQyauxO+MN dme0tahYVIsKctKixP14bhN5CtZmaUO/V5vlLOwnHN+8zRJ+dNYkQB+js0QP DXWI/UyuwG5pIi6/aCKS8TRYiOt+RjeK4cLxcGEFpIoY+zRrrVjhQmk6M6wU LowyEWVibgi5sm1PuJK5x5VjCDnmxF8uRsrqQ6e077TJW82J57qPmHW5jyAx O/SbWKuXE6wq6s0wd8G9RAo2IGfklU9Mox0qXNKwcKnwS/4urBWV7ATSlLgH admr6EmMDy4ZH/Roag/lodPjDZ6Zh17SVBMr+VooQsRqeegDcrt+HvrIUbjL Qw86OitIb3S2Q5l25aDPOohZ4c8ONwuDnRk7Ggvi3u49C4SH+3H1WM5m+ecJ bePqqQlFxFW/LkxGYMUdXbvirklMTPjWY1L6AGBP8ChEonEVF+L/AdrKBxhq uwIA --=-kEbuFixda2EUEKhe1aeA-- From owner-linux-xfs@oss.sgi.com Mon Oct 27 15:42:03 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 27 Oct 2003 15:42:44 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9RNg325003078 for ; Mon, 27 Oct 2003 15:42:03 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id h9S00rHc012564 for ; Mon, 27 Oct 2003 18:00:53 -0600 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 KAA08356 for ; Tue, 28 Oct 2003 10:41:54 +1100 Received: from melbourne.sgi.com (localhost [127.0.0.1]) by omen.melbourne.sgi.com (SGI-8.12.5/8.12.5) with SMTP id h9RNfsZJ064674 for ; Tue, 28 Oct 2003 10:41:54 +1100 (EST) Date: Tue, 28 Oct 2003 10:41:53 +1100 From: Ivan Rayner To: linux-xfs@oss.sgi.com Subject: Re: [PATCH] [PRELIMINARY] Add support for file flags to xfsdump #1 Message-Id: <20031028104153.2870ad87.ivanr@sgi.com> In-Reply-To: <20031024080129.GF3648@plato.local.lan> References: <20031020073151.GD3648@plato.local.lan> <20031024105919.5e22a10e.ivanr@sgi.com> <20031024080129.GF3648@plato.local.lan> Organization: SGI X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; mips-sgi-irix6.5) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 826 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ivanr@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 3520 Lines: 73 [I sent this mail yesterday but it didn't seem to go through. So, try again.] On Fri, 24 Oct 2003 00:01:29 -0800, Ethan Benson wrote: > On Fri, Oct 24, 2003 at 10:59:19AM +1000, Ivan Rayner wrote: > > On Sun, 19 Oct 2003 23:31:51 -0800, Ethan Benson wrote: > > > What I have done to fix the above problems in order: > > Thanks for your work Ethan. Although I've not looked your code, it sounds > > like you're doing the right sort of thing. > hopefully, let me know when you get a chance to look at the code. Well, I don't think I will get the time. Besides, it's been a while since I was responsible for xfsdump -- it's someone else's job now. > > > * dump/inomap.c: Add warning when SGI_XFSDUMP_SKIP_FILE xattr is > > > present, but still honor it, this attribute is deprecated in favor of > > > the new nodump file flag, support for the obsolete xattr should be > > > removed in a future xfsdump (its not that old so this shouldn't be > > > much of a problem). Add check for new nodump file flag. > > > > The SKIP_FILE attribute is still the supported mechanism in IRIX, > > therefore it'd be a good idea to keep support for it in the Linux version. > > It doesn't hurt performance, so I don't see any reason to remove it. > > well its very young, it was just added last year i think, maybe more > recently then that (by request from linux users wanting chattr +d > functionality). and the file attributes will probably end up getting > merged into irix anyway. the inode flags are really a much cleaner > way for this to work, which is why id rather see the xattr kludge go > away. A couple of things: - It's almost 2 years old (Nov 2001). - Excluding files has been an issue for xfsdump for ages (well before Linux). The original request that sparked this implementation was via an IRIX newsgroup and referred to BSD rather than Linux. It was implemented on IRIX and Linux simultaneously. - It doesn't matter how old it is, SGI has the IRIX compatibility guarantee, which means that we cannot remove this functionality from IRIX, even if it had only been in a single release. This is a good thing. And given that we'd want xfsdump to be compatible across IRIX and Linux, we wouldn't want to remove it from Linux either. - File attributes aren't in IRIX yet, and even if they were it wouldn't matter -- see previous point. I don't dispute that this solution may be better, but that doesn't mean we can or should get rid of the old solution. It's not in SGI's best interest to _force_ customers to change the way they do things simply because we have another solution that we think is better. Even worse is the idea that xfsdump will suddenly not do what they expect it to do. "But we issued warnings," we'd argue and they'll say they had xfsdump in a script and never saw the warnings and now they have a backup that contains terrabytes of temporary files which they don't want. I don't see the problem with just advertising the new feature, and those people who don't care about IRIX compatibility can simply remove the old SKIP_FILE attributes and start using the new system if and when they like. Unless there's a security or data corruption issue, it isn't up to us to determine how other people should work. If there is a definite performance or functional benefit for the user, then I suppose you could issue a notice instead of a warning, letting the user know that there is a better solution. Otherwise, I'd prefer just changing the man page. Ivan From owner-linux-xfs@oss.sgi.com Mon Oct 27 16:34:55 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 27 Oct 2003 16:35:29 -0800 (PST) Received: from mail.epost.de (mail.epost.de [193.28.100.164] (may be forged)) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9S0Ys25006703 for ; Mon, 27 Oct 2003 16:34:55 -0800 Received: from epost.de (217.110.232.6) by mail.epost.de (6.7.015) (authenticated as rainer.traut@epost.de) id 3F9967D20002C282 for linux-xfs@oss.sgi.com; Sun, 26 Oct 2003 11:47:19 +0100 Message-ID: <3F9BA636.4010603@epost.de> Date: Sun, 26 Oct 2003 11:47:18 +0100 From: Rainer Traut User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Are there xfs patches for the RH Enterprise kernels? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 827 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: rainer.traut@epost.de Precedence: bulk X-list: linux-xfs Content-Length: 463 Lines: 21 This is my second try to post this, sorry if this will show up twice then. Hi, after receiving today my new RH ES3.0 and got it up and running I wanted to ask if someone is doing patches for it with xfs support. I know that this system would be completely unsupported but I don't want to miss xfs here. kernel is: [root@notes4-ent root]# uname -a Linux notes4-ent 2.4.21-4.ELsmp #1 SMP Fri Oct 3 17:52:56 EDT 2003 i686 i686 i386 GNU/Linux Thank you Rainer From owner-linux-xfs@oss.sgi.com Mon Oct 27 16:43:46 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 27 Oct 2003 16:44:19 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9S0hk25007212 for ; Mon, 27 Oct 2003 16:43:46 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h9RMmeOO021004 for ; Mon, 27 Oct 2003 14:48:40 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h9S0heP512554938 for ; Mon, 27 Oct 2003 18:43:40 -0600 (CST) Received: from zhadum.americas.sgi.com (zhadum.americas.sgi.com [128.162.233.43]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h9S0heRn340921269 for ; Mon, 27 Oct 2003 18:43:40 -0600 (CST) Received: from zhadum.americas.sgi.com by zhadum.americas.sgi.com (SGI-8.12.5/SGI-client-1.7) via ESMTP id h9S0hd4t185331; Mon, 27 Oct 2003 18:43:39 -0600 (CST) Received: (from overby@localhost) by zhadum.americas.sgi.com (SGI-8.12.5/8.12.5/Submit) id h9S0c4MF188327; Mon, 27 Oct 2003 18:38:04 -0600 (CST) Date: Mon, 27 Oct 2003 18:38:04 -0600 (CST) Message-Id: <200310280038.h9S0c4MF188327@zhadum.americas.sgi.com> From: Glen Overby To: linux-xfs@oss.sgi.com Subject: Re: Broken Log Help Needed In-Reply-To: message from Austin Gonyou sent 27 October 2003 References: <1067291743.3277.188.camel@localhost.localdomain> X-archive-position: 828 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: overby@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1479 Lines: 43 On October 27, Austin Gonyou wrote: > The issue is that I don't see any "ERROR" statements in this output, but > trying to replay the log or mounting -oro will oops the kernel and that > one device is then unavailable and the system must be rebooted. Can you send the exact oops message.. where it occured, etc? > I would like to extract the log so I can put this server back into our > beta environment. If someone could aid me in this I'd much appreciate > it. Here's an example: [root@HOSTNAME root]# /a23/overby/bin.l/mkfs.xfs -f -b size=4096 -l size=8192b /dev/hda6 meta-data=/dev/hda6 isize=256 agcount=8, agsize=140317 blks = sectsz=512 data = bsize=4096 blocks=1122534, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=8192, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 [root@HOSTNAME root]# /a23/overby/bin.l/xfs_db /dev/hda6 xfs_db> sb 0 xfs_db> print logstart logstart = 1048580 xfs_db> print logblocks logblocks = 8192 xfs_db> convert fsb 1048580 daddr 0x4483c0 (4490176) xfs_db> convert fsb 8192 daddr 0x10000 (65536) [root@HOSTNAME root]# dd if=/dev/hda6 of=/tmp/hda6log bs=512 skip=4490176 count=65536 65536+0 records in 65536+0 records out Glen Overby From owner-linux-xfs@oss.sgi.com Mon Oct 27 18:34:35 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 27 Oct 2003 18:35:17 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10) with ESMTP id h9S2YZ25009427 for ; Mon, 27 Oct 2003 18:34:35 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id h9S2YZXq009426 for linux-xfs@oss.sgi.com; Mon, 27 Oct 2003 18:34:35 -0800 Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9S2YW25009414 for ; Mon, 27 Oct 2003 18:34:32 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id h9S0dOOO002315 for ; Mon, 27 Oct 2003 16:39:25 -0800 Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA10783 for ; Tue, 28 Oct 2003 13:34:24 +1100 Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id BC0F7C00A8; Tue, 28 Oct 2003 13:34:08 +1100 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id B933E140116; Tue, 28 Oct 2003 13:34:08 +1100 (EST) X-Mailer: exmh version 2.5 01/15/2001 with nmh-1.0.4 From: Keith Owens To: Mihai RUSU Cc: xfs-master@oss.sgi.com Subject: Re: [Bug 283] kernel-source-2.4.20-20.9.XFS1.3.1.i386.rpm fails to compile In-reply-to: Your message of "Mon, 27 Oct 2003 12:24:28 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 28 Oct 2003 13:34:07 +1100 Message-ID: <25208.1067308447@kao2.melbourne.sgi.com> X-archive-position: 829 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 562 Lines: 21 http://oss.sgi.com/bugzilla/show_bug.cgi?id=283 The RH kksymoops patch is ugly, it creates a separate file instead of putting the print_modules() function in kernel/module.c where it belongs. Then the build breaks with duplicate symbols when built with CONFIG_MODULES=n. Quick and dirty fix. --- kernel/module.c.orig 2003-10-28 13:30:48.000000000 +1100 +++ kernel/module.c 2003-10-28 13:30:56.000000000 +1100 @@ -1284,10 +1284,6 @@ int try_inc_mod_count(struct module *mod return 1; } -void print_modules(void) -{ -} - #endif /* CONFIG_MODULES */ From owner-linux-xfs@oss.sgi.com Mon Oct 27 18:35:22 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 27 Oct 2003 18:35:55 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9S2ZM25009466 for ; Mon, 27 Oct 2003 18:35:22 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h9S0eGOO002583 for ; Mon, 27 Oct 2003 16:40:16 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h9S2ZGP512591459; Mon, 27 Oct 2003 20:35:16 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h9S2ZFK24434275; Mon, 27 Oct 2003 20:35:16 -0600 (CST) Date: Mon, 27 Oct 2003 20:35:15 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Rainer Traut cc: linux-xfs@oss.sgi.com Subject: Re: Are there xfs patches for the RH Enterprise kernels? In-Reply-To: <3F9BA636.4010603@epost.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 830 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 900 Lines: 35 This is something I plan to look at (I just got our copy of RHEL today as well). Not sure when it will be done, but it is something I will do. The kernel is probably >this close< to not needing additional patches, and just distributing a module... but probably is missing a thing or two, probably requiring core kernel patches in the end. -Eric On Sun, 26 Oct 2003, Rainer Traut wrote: > This is my second try to post this, > sorry if this will show up twice then. > > Hi, > after receiving today my new RH ES3.0 and > got it up and running I wanted to ask if someone > is doing patches for it with xfs support. > > I know that this system would be completely unsupported > but I don't want to miss xfs here. > > kernel is: > [root@notes4-ent root]# uname -a > Linux notes4-ent 2.4.21-4.ELsmp #1 SMP Fri Oct 3 17:52:56 EDT 2003 i686 > i686 i386 GNU/Linux > > Thank you > Rainer > > > > From owner-linux-xfs@oss.sgi.com Mon Oct 27 21:03:24 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 27 Oct 2003 21:03:57 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9S53N25014754 for ; Mon, 27 Oct 2003 21:03:23 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h9S5MCHc029255 for ; Mon, 27 Oct 2003 23:22:14 -0600 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h9S538jj4638992; Tue, 28 Oct 2003 16:03:08 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h9S537Ul4332134; Tue, 28 Oct 2003 16:03:07 +1100 (EST) Date: Tue, 28 Oct 2003 16:03:07 +1100 (EST) From: Nathan Scott Message-Id: <200310280503.h9S537Ul4332134@snort.melbourne.sgi.com> To: sgi.bugs.xfs@engr.sgi.com, linux-xfs@oss.sgi.com Subject: TAKE 902773 - new mkfs AG size code X-archive-position: 831 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 607 Lines: 22 Rework the mkfs allocation group sizing algorithm, making better use of the available bits. This changes the maximum allocation group size enforced by mkfs to be 1TB (from 4GB), which scales alot better for very large filesystems. cheers. Date: Mon Oct 27 20:41:37 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-cmds The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:160712a xfsprogs/VERSION - 1.93 xfsprogs/doc/CHANGES - 1.130 xfsprogs/mkfs/xfs_mkfs.c - 1.52 xfsprogs/include/xfs_ag.h - 1.14 xfsprogs/debian/changelog - 1.84 From owner-linux-xfs@oss.sgi.com Mon Oct 27 23:23:33 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 27 Oct 2003 23:24:11 -0800 (PST) Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9S7NU25016197 for ; Mon, 27 Oct 2003 23:23:33 -0800 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.28]) by smtpzilla5.xs4all.nl (8.12.9/8.12.9) with ESMTP id h9S7NQA4094265; Tue, 28 Oct 2003 08:23:26 +0100 (CET) Message-Id: <4.3.2.7.2.20031028081950.03d378b8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 28 Oct 2003 08:23:24 +0100 To: Rainer Traut , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: Are there xfs patches for the RH Enterprise kernels? In-Reply-To: <3F9BA636.4010603@epost.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 832 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs Content-Length: 838 Lines: 28 At 11:47 26-10-2003 +0100, Rainer Traut wrote: >This is my second try to post this, >sorry if this will show up twice then. > >Hi, >after receiving today my new RH ES3.0 and >got it up and running I wanted to ask if someone >is doing patches for it with xfs support. Not as of yet. I don't have a Red Hat ES 3.0 box around. I can trying building kernels but I can't really test them since I don't have a ES 3.0 box. Plus, I build them on a 2.1 box. This will probably break from the get go. >I know that this system would be completely unsupported >but I don't want to miss xfs here. You're not the only one :-) I just havn't gotten the time for it yet. I am currently working on creating a weird form of route balancing which proves to be "interesting". Cheers -- Seth I don't make sense, I don't pretend to either. Questions? From owner-linux-xfs@oss.sgi.com Tue Oct 28 01:03:27 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 28 Oct 2003 01:04:10 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10) with ESMTP id h9S93R25020130 for ; Tue, 28 Oct 2003 01:03:27 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id h9S93Rrh020129 for linux-xfs@oss.sgi.com; Tue, 28 Oct 2003 01:03:27 -0800 Received: from ahriman.bucharest.roedu.net (ahriman.bucharest.roedu.net [141.85.128.71]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9S93N25020117 for ; Tue, 28 Oct 2003 01:03:24 -0800 Received: (qmail 23870 invoked by uid 1000); 28 Oct 2003 09:02:20 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 28 Oct 2003 09:02:20 -0000 Date: Tue, 28 Oct 2003 11:02:14 +0200 (EET) From: Mihai RUSU X-X-Sender: dizzy@ahriman.bucharest.roedu.net To: Keith Owens cc: xfs-master@oss.sgi.com Subject: Re: [Bug 283] kernel-source-2.4.20-20.9.XFS1.3.1.i386.rpm fails to compile In-Reply-To: <25208.1067308447@kao2.melbourne.sgi.com> Message-ID: References: <25208.1067308447@kao2.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 833 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dizzy@roedu.net Precedence: bulk X-list: linux-xfs Content-Length: 2167 Lines: 64 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Keith thank you very much! yes, that fixes that problem _but_ I got now into another one :-/ make[3]: Entering directory `/usr/src/linux-2.4.20-20.9.XFS1.3.1/fs/devfs' gcc -D__KERNEL__ -I/usr/src/linux-2.4.20-20.9.XFS1.3.1/include -Wall - -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common - -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686 - -nostdinc -iwithprefix include -DKBUILD_BASENAME=base -c -o base.o base.c base.c: In function `is_devfsd_or_child': base.c:1417: structure has no member named `p_opptr' base.c:1417: structure has no member named `p_opptr' make[3]: *** [base.o] Error 1 make[3]: Leaving directory `/usr/src/linux-2.4.20-20.9.XFS1.3.1/fs/devfs' make[2]: *** [first_rule] Error 2 make[2]: Leaving directory `/usr/src/linux-2.4.20-20.9.XFS1.3.1/fs/devfs' make[1]: *** [_subdir_devfs] Error 2 make[1]: Leaving directory `/usr/src/linux-2.4.20-20.9.XFS1.3.1/fs' make: *** [_dir_fs] Error 2 PS: i dont get it when im not compiling with devfs but I need devfs support for the moment On Tue, 28 Oct 2003, Keith Owens wrote: > http://oss.sgi.com/bugzilla/show_bug.cgi?id=283 > > The RH kksymoops patch is ugly, it creates a separate file instead of > putting the print_modules() function in kernel/module.c where it > belongs. Then the build breaks with duplicate symbols when built with > CONFIG_MODULES=n. Quick and dirty fix. > > --- kernel/module.c.orig 2003-10-28 13:30:48.000000000 +1100 > +++ kernel/module.c 2003-10-28 13:30:56.000000000 +1100 > @@ -1284,10 +1284,6 @@ int try_inc_mod_count(struct module *mod > return 1; > } > > -void print_modules(void) > -{ > -} > - > #endif /* CONFIG_MODULES */ > > > > - ---------------------------- Mihai RUSU Email: dizzy@roedu.net GPG : http://dizzy.roedu.net/dizzy-gpg.txt WWW: http://dizzy.roedu.net "Linux is obsolete" -- AST -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/njCbPZzOzrZY/1QRAmT8AJ0asSQuMzjlo1f67wvpkpv7AAb2ngCg5gvm nCp5kncwFIm1Nv4zHeVTw8k= =/QXA -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Tue Oct 28 03:35:36 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 28 Oct 2003 03:36:18 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10) with ESMTP id h9SBZa25031373 for ; Tue, 28 Oct 2003 03:35:36 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id h9SBZalH031372 for linux-xfs@oss.sgi.com; Tue, 28 Oct 2003 03:35:36 -0800 Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9SBZU25031354 for ; Tue, 28 Oct 2003 03:35:33 -0800 Received: (qmail 11349 invoked from network); 28 Oct 2003 11:35:27 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 28 Oct 2003 11:35:27 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 5E963C02C6; Tue, 28 Oct 2003 22:35:06 +1100 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id 5BE4A14014C; Tue, 28 Oct 2003 22:35:06 +1100 (EST) X-Mailer: exmh version 2.5 01/15/2001 with nmh-1.0.4 From: Keith Owens To: Mihai RUSU Cc: xfs-master@oss.sgi.com Subject: Re: [Bug 283] kernel-source-2.4.20-20.9.XFS1.3.1.i386.rpm fails to compile In-reply-to: Your message of "Tue, 28 Oct 2003 11:02:14 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 28 Oct 2003 22:35:05 +1100 Message-ID: <2723.1067340905@ocs3.intra.ocs.com.au> X-archive-position: 834 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1247 Lines: 26 On Tue, 28 Oct 2003 11:02:14 +0200 (EET), Mihai RUSU wrote: >make[3]: Entering directory `/usr/src/linux-2.4.20-20.9.XFS1.3.1/fs/devfs' >gcc -D__KERNEL__ -I/usr/src/linux-2.4.20-20.9.XFS1.3.1/include -Wall >- -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common >- -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i686 >- -nostdinc -iwithprefix include -DKBUILD_BASENAME=base -c -o base.o base.c >base.c: In function `is_devfsd_or_child': >base.c:1417: structure has no member named `p_opptr' >base.c:1417: structure has no member named `p_opptr' RH backported the new scheduler code from 2.6 and did not test it with devfs, naughty RH. p_opptr has been renamed to real_parent. --- fs/devfs/base.c.orig 2003-10-28 22:33:45.000000000 +1100 +++ fs/devfs/base.c 2003-10-28 22:34:37.000000000 +1100 @@ -1414,7 +1414,7 @@ if (current == fs_info->devfsd_task) return (TRUE); if (current->pgrp == fs_info->devfsd_pgrp) return (TRUE); #if LINUX_VERSION_CODE < KERNEL_VERSION(2,5,1) - for (p = current->p_opptr; p != &init_task; p = p->p_opptr) + for (p = current->real_parent; p != &init_task; p = p->real_parent) { if (p == fs_info->devfsd_task) return (TRUE); } From owner-linux-xfs@oss.sgi.com Tue Oct 28 04:41:20 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 28 Oct 2003 04:42:01 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10) with ESMTP id h9SCfK25003394 for ; Tue, 28 Oct 2003 04:41:20 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id h9SCfKK5003393 for linux-xfs@oss.sgi.com; Tue, 28 Oct 2003 04:41:20 -0800 Received: from ahriman.bucharest.roedu.net (ahriman.bucharest.roedu.net [141.85.128.71]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9SCfH25003381 for ; Tue, 28 Oct 2003 04:41:18 -0800 Received: (qmail 26260 invoked by uid 1000); 28 Oct 2003 12:40:13 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 28 Oct 2003 12:40:13 -0000 Date: Tue, 28 Oct 2003 14:40:09 +0200 (EET) From: Mihai RUSU X-X-Sender: dizzy@ahriman.bucharest.roedu.net To: Keith Owens cc: xfs-master@oss.sgi.com Subject: Re: [Bug 283] kernel-source-2.4.20-20.9.XFS1.3.1.i386.rpm fails to compile In-Reply-To: <2723.1067340905@ocs3.intra.ocs.com.au> Message-ID: References: <2723.1067340905@ocs3.intra.ocs.com.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 835 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dizzy@roedu.net Precedence: bulk X-list: linux-xfs Content-Length: 1262 Lines: 39 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Again I must thank you for your help, now it compiled fine and things seem ok. On Tue, 28 Oct 2003, Keith Owens wrote: > RH backported the new scheduler code from 2.6 and did not test it with > devfs, naughty RH. p_opptr has been renamed to real_parent. > > --- fs/devfs/base.c.orig 2003-10-28 22:33:45.000000000 +1100 > +++ fs/devfs/base.c 2003-10-28 22:34:37.000000000 +1100 > @@ -1414,7 +1414,7 @@ > if (current == fs_info->devfsd_task) return (TRUE); > if (current->pgrp == fs_info->devfsd_pgrp) return (TRUE); > #if LINUX_VERSION_CODE < KERNEL_VERSION(2,5,1) > - for (p = current->p_opptr; p != &init_task; p = p->p_opptr) > + for (p = current->real_parent; p != &init_task; p = p->real_parent) > { > if (p == fs_info->devfsd_task) return (TRUE); > } > > - ---------------------------- Mihai RUSU Email: dizzy@roedu.net GPG : http://dizzy.roedu.net/dizzy-gpg.txt WWW: http://dizzy.roedu.net "Linux is obsolete" -- AST -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/nmOsPZzOzrZY/1QRAm51AJ40hVbVDGBvrzSJDzDa/Ra6d1k3KgCdGTCd cLYAk+znTsvP7GiUQwjqTII= =DloR -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Tue Oct 28 13:33:53 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 28 Oct 2003 13:34:33 -0800 (PST) Received: from localhost.localdomain (host-65-120-145-91.coremetrics.com [65.120.145.91] (may be forged)) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9SLXq25028928 for ; Tue, 28 Oct 2003 13:33:53 -0800 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id h9SLXtnA007082; Tue, 28 Oct 2003 15:33:55 -0600 Received: (from austin@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id h9SLXt71007080; Tue, 28 Oct 2003 15:33:55 -0600 X-Authentication-Warning: localhost.localdomain: austin set sender to austin@coremetrics.com using -f Subject: Re: Broken Log Help Needed From: Austin Gonyou To: Glen Overby Cc: XFS List In-Reply-To: <200310280038.h9S0c4MF188327@zhadum.americas.sgi.com> References: <200310280038.h9S0c4MF188327@zhadum.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1067376834.1860.138.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Tue, 28 Oct 2003 15:33:54 -0600 X-archive-position: 836 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: austin@coremetrics.com Precedence: bulk X-list: linux-xfs Content-Length: 2005 Lines: 56 They are on this list somewhere. I've sent several over time. This has been going on for a long while, and is very reproduceable. I'd love for someone work with me on this to get this fixed, I'm sure I could aid since I have a setup which does it consistently, no matter the XFS version, but the log-replay is always affected. On Mon, 2003-10-27 at 18:38, Glen Overby wrote: > On October 27, Austin Gonyou wrote: > > The issue is that I don't see any "ERROR" statements in this output, > but > > trying to replay the log or mounting -oro will oops the kernel and > that > > one device is then unavailable and the system must be rebooted. > > Can you send the exact oops message.. where it occured, etc? > > > I would like to extract the log so I can put this server back into our > > beta environment. If someone could aid me in this I'd much appreciate > > it. > > Here's an example: > > [root@HOSTNAME root]# /a23/overby/bin.l/mkfs.xfs -f -b size=4096 -l > size=8192b /dev/hda6 > > meta-data=/dev/hda6 isize=256 agcount=8, agsize=140317 > blks > = sectsz=512 > data = bsize=4096 blocks=1122534, imaxpct=25 > = sunit=0 swidth=0 blks, unwritten=1 > naming =version 2 bsize=4096 > log =internal log bsize=4096 blocks=8192, version=1 > = sectsz=512 sunit=0 blks > realtime =none extsz=65536 blocks=0, rtextents=0 > > [root@HOSTNAME root]# /a23/overby/bin.l/xfs_db /dev/hda6 > xfs_db> sb 0 > xfs_db> print logstart > logstart = 1048580 > xfs_db> print logblocks > logblocks = 8192 > xfs_db> convert fsb 1048580 daddr > 0x4483c0 (4490176) > xfs_db> convert fsb 8192 daddr > 0x10000 (65536) > > [root@HOSTNAME root]# dd if=/dev/hda6 of=/tmp/hda6log bs=512 > skip=4490176 count=65536 > 65536+0 records in > 65536+0 records out > > Glen Overby -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Tue Oct 28 13:35:51 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 28 Oct 2003 13:36:25 -0800 (PST) Received: from localhost.localdomain (host-65-120-145-91.coremetrics.com [65.120.145.91] (may be forged)) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9SLZo25029052 for ; Tue, 28 Oct 2003 13:35:50 -0800 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id h9SLZrnA007114; Tue, 28 Oct 2003 15:35:53 -0600 Received: (from austin@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id h9SLZrLQ007112; Tue, 28 Oct 2003 15:35:53 -0600 X-Authentication-Warning: localhost.localdomain: austin set sender to austin@coremetrics.com using -f Subject: Re: Broken Log Help Needed From: Austin Gonyou To: Glen Overby Cc: XFS List In-Reply-To: <200310280038.h9S0c4MF188327@zhadum.americas.sgi.com> References: <200310280038.h9S0c4MF188327@zhadum.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1067376953.1864.140.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Tue, 28 Oct 2003 15:35:53 -0600 X-archive-position: 837 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: austin@coremetrics.com Precedence: bulk X-list: linux-xfs Content-Length: 915 Lines: 26 On Mon, 2003-10-27 at 18:38, Glen Overby wrote: > On October 27, Austin Gonyou wrote: > > The issue is that I don't see any "ERROR" statements in this output, > but > > trying to replay the log or mounting -oro will oops the kernel and > that > > one device is then unavailable and the system must be rebooted. > > Can you send the exact oops message.. where it occured, etc? > > > I would like to extract the log so I can put this server back into our > > beta environment. If someone could aid me in this I'd much appreciate > > it. > > Here's an example: > > [root@HOSTNAME root]# /a23/overby/bin.l/mkfs.xfs -f -b size=4096 -l > size=8192b /dev/hda6 Ok. missed this part, I thought it was what I'd typed. I'll do this, though the system is now back into production, I can see about trying to break a log again and then extract it. > Glen Overby -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Tue Oct 28 13:51:49 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 28 Oct 2003 13:52:22 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9SLpm25029786 for ; Tue, 28 Oct 2003 13:51:49 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h9SMAhHc013349 for ; Tue, 28 Oct 2003 16:10:43 -0600 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h9SLphP512601656; Tue, 28 Oct 2003 15:51:43 -0600 (CST) Received: from zhadum.americas.sgi.com (zhadum.americas.sgi.com [128.162.233.43]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h9SLphRn349057935; Tue, 28 Oct 2003 15:51:43 -0600 (CST) Received: from zhadum.americas.sgi.com by zhadum.americas.sgi.com (SGI-8.12.5/SGI-client-1.7) via ESMTP id h9SLpg4t139462; Tue, 28 Oct 2003 15:51:42 -0600 (CST) Received: (from overby@localhost) by zhadum.americas.sgi.com (SGI-8.12.5/8.12.5/Submit) id h9SLpaeH187546; Tue, 28 Oct 2003 15:51:36 -0600 (CST) Date: Tue, 28 Oct 2003 15:51:36 -0600 (CST) Message-Id: <200310282151.h9SLpaeH187546@zhadum.americas.sgi.com> From: Glen Overby To: austin@coremetrics.com Cc: linux-xfs@oss.sgi.com Subject: Re: Broken Log Help Needed In-Reply-To: message from Austin Gonyou sent 28 October 2003 References: <200310280038.h9S0c4MF188327@zhadum.americas.sgi.com> <1067376953.1864.140.camel@localhost.localdomain> X-archive-position: 838 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: overby@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1171 Lines: 30 On October 28, Austin Gonyou wrote: > On Mon, 2003-10-27 at 18:38, Glen Overby wrote: > > On October 27, Austin Gonyou wrote: > > > The issue is that I don't see any "ERROR" statements in this output, > > but > > > trying to replay the log or mounting -oro will oops the kernel and > > that > > > one device is then unavailable and the system must be rebooted. > > > > Can you send the exact oops message.. where it occured, etc? > > > > > I would like to extract the log so I can put this server back into our > > > beta environment. If someone could aid me in this I'd much appreciate > > > it. > > > > Here's an example: > > > > [root@HOSTNAME root]# /a23/overby/bin.l/mkfs.xfs -f -b size=4096 -l > > size=8192b /dev/hda6 > Ok. missed this part, I thought it was what I'd typed. I'll do this, > though the system is now back into production, I can see about trying to > break a log again and then extract it. er, this was just part of my example. I started with a clean filesystem. You don't have to wipe your filesystem... in fact, if you do that your log will be very clean and you don't need to bother dumping it. Data loss from mkfs "100%". Glen Overby From owner-linux-xfs@oss.sgi.com Tue Oct 28 17:57:17 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 28 Oct 2003 17:57:50 -0800 (PST) Received: from smtp5.ispsnet.net (smtp5.ispsnet.net [64.63.192.251]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9T1vE25004193 for ; Tue, 28 Oct 2003 17:57:17 -0800 Received: from client182.fbos1.hawkcommunications.com (unverified [64.63.214.182]) by smtp5.ispsnet.net (Joe1) with ESMTP id 2422564 for ; Tue, 28 Oct 2003 20:57:16 -0500 From: Glenn Burkhardt To: linux-xfs@oss.sgi.com Subject: data loss Date: Tue, 28 Oct 2003 20:56:59 -0500 User-Agent: KMail/1.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200310282056.59301.gbburkhardt@aaahawk.com> X-archive-position: 839 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: gbburkhardt@aaahawk.com Precedence: bulk X-list: linux-xfs Content-Length: 2877 Lines: 67 I'm using XFS with Mandrake 9.1, from the patched kernel file kernel-2.4.21.0.25mdk-1-1mdk.rpm. The rev that's logged during boot is "SGI XFS 1.3.0pre2 with ACLs" I've seen a couple of times that files are filled with zero's after rebooting. This time it was my ".bashrc" file. I might have just powered off the machine, but the this file wasn't open for writing at the time of shutdown. After turning the machine on last night, I noticed that my shell prompt had changed, and discovered that the file was full of ASCII null characters. I've seen this happen a couple of times before on other machines. Then the file "/usr/share/config/kdm/kdmrc" had been similiarly trashed - full of zeros. And, it seems that the file size was larger than usual. Unfortunately, this is not easily reproduced. It's happened once in the 4 or 5 months since I've had 9.1 installed. I'm not the only one who's seen this. Please see the attached emails from the Mandrake "expert" list. I can understand that if a file is being written, and the power is turned off, that the data might not make it to disk. But a file that hasn't been changed in a while shouldn't get trashed. -------------------------------------------------------------------------------------------------- From: Bryan Whitehead To: Glenn Burkhardt Re: [expert] does the XFS filesystem lose data, or is my disk broken? It seems if the file is open at all files can get trashed. Here is some other problems we've had: With ext2 we had problems with large files randomly becomming corrupt from one momment to the next. The suddenly they would be better. Then being totally bad for hours. Reboot makes the problem go away for about a day. (Basically we'd run md5sum on the same file in a loop and it would change from one moment to the next when it was set to read-only with no-one accessing it). Another problem we get (regardeless of filesystem) is randomly files will not be accessable. When we try to read them we will get an "io error". If we "mount -o remount" the parition, the problem will go away for a bit. For each problem we have been unable to find a way to trigger the bug for other people to see.... :( -- Bryan Whitehead SysAdmin - JPL - Interferometry and Large Optical Systems Phone: 818 354 2903 driver@jpl.nasa.gov -------------------------------------------------------------------------------------------- From: Luca Olivetti To: expert@linux-mandrake.com Re: [expert] does the XFS filesystem lose data, or is my disk broken? Re: [expert] does the XFS filesystem lose data, or is my disk broken? From: Luca Olivetti To: expert@linux-mandrake.com I've seen this many times (xfs too). Don't know the cause (apart from power failure/reset after a crash), but I'd like to. Bye -- From owner-linux-xfs@oss.sgi.com Tue Oct 28 18:36:53 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 28 Oct 2003 18:37:36 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9T2aq25004896 for ; Tue, 28 Oct 2003 18:36:53 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h9T0fmOO024881 for ; Tue, 28 Oct 2003 16:41:49 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h9T2aijj4822845 for ; Wed, 29 Oct 2003 13:36:44 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id h9T2ahwM4824661 for linux-xfs@oss.sgi.com; Wed, 29 Oct 2003 13:36:43 +1100 (EST) Date: Wed, 29 Oct 2003 13:36:43 +1100 (EST) From: Nathan Scott Message-Id: <200310290236.h9T2ahwM4824661@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: PARTIAL TAKE 902933 - pagebuf locking fix X-archive-position: 840 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 667 Lines: 27 Dump the pagebuf locked field for debugging purposes. Date: Sun Oct 26 16:31:54 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/clean-2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:160616a linux/fs/xfs/xfsidbg.c - 1.243 Fix a pagebuf page locking problem for filesystems with blocksizes smaller than the pagesize. Date: Tue Oct 28 18:31:10 PST 2003 Workarea: snort.melbourne.sgi.com:/home/nathans/clean-2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:160795a linux/fs/xfs/pagebuf/page_buf.c - 1.137 From owner-linux-xfs@oss.sgi.com Tue Oct 28 19:15:20 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 28 Oct 2003 19:15:58 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9T3FJ25005555 for ; Tue, 28 Oct 2003 19:15:20 -0800 Received: from flecktone.americas.sgi.com ([192.48.203.135]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h9T1KHOO028405 for ; Tue, 28 Oct 2003 17:20:18 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h9T3ErP512579729; Tue, 28 Oct 2003 21:14:53 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h9T3EkK24494863; Tue, 28 Oct 2003 21:14:48 -0600 (CST) Date: Tue, 28 Oct 2003 21:14:46 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Glenn Burkhardt cc: linux-xfs@oss.sgi.com Subject: Re: data loss In-Reply-To: <200310282056.59301.gbburkhardt@aaahawk.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 841 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 523 Lines: 14 On Tue, 28 Oct 2003, Glenn Burkhardt wrote: > I'm using XFS with Mandrake 9.1, from the patched kernel file > kernel-2.4.21.0.25mdk-1-1mdk.rpm. The rev that's logged during boot is > "SGI XFS 1.3.0pre2 with ACLs" > > I've seen a couple of times that files are filled with zero's after rebooting. some changes were made in the 1.3.0 release post pre2 which addressed this. Newer xfs code should make this better. You might check the Mandrake 9.2 kernels, perhaps they have the final 1.3.0 release in them? -Eric From owner-linux-xfs@oss.sgi.com Tue Oct 28 23:30:51 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 28 Oct 2003 23:31:27 -0800 (PST) Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9T7Un25013445 for ; Tue, 28 Oct 2003 23:30:51 -0800 Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1AEkn1-0008Vk-00 for ; Wed, 29 Oct 2003 08:30:47 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: linux-xfs@oss.sgi.com Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AEkeq-0008RB-00 for ; Wed, 29 Oct 2003 08:22:20 +0100 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 1AEkeq-00040e-00 for ; Wed, 29 Oct 2003 08:22:20 +0100 From: "Norman Zhang" Subject: Samba on XFS Freezes Date: Tue, 28 Oct 2003 23:22:25 -0800 Message-ID: X-Complaints-To: usenet@sea.gmane.org X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2800.1165 X-archive-position: 842 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nzhang@arkon-group.com Precedence: bulk X-list: linux-xfs Content-Length: 1240 Lines: 37 Hi, My Samba box stalls after some usage, mapped drives disappear and users can't write or read from drives. The stalls happen randomly. I'm running 2.4.19-16mdksmp and Samba 2.2.7a-9.2mdk with software RAID. May I ask is this a XFS bug or Samba bug? Does anyone know a fix for it? I checked the memory from BIOS, and memtest they didn't report any errors. /var/log/kernel/warnings ------------------------ Oct 27 09:19:12 smbserver kernel: xfs_force_shutdown(md(9,5),0x8) called from line 1039 of file xfs_trans.c. Return address = 0xe08ae312 Oct 27 09:19:12 smbserver kernel: Corruption of in-memory data detected. Shutting down filesystem: md(9,5) Oct 27 09:19:12 smbserver kernel: Please umount the filesystem, and rectify the problem(s) /var/log/kernel/errors ---------------------- Oct 27 10:36:44 smbserver kernel: Unknown bridge resource 2: assuming transparent Oct 27 10:36:44 smbserver kernel: PCI: Unable to handle 64-bit address space for Oct 27 10:36:44 smbserver kernel: PCI: Unable to handle 64-bit address space for Oct 27 10:36:44 smbserver kernel: Unknown bridge resource 2: assuming transparent Oct 27 10:36:44 smbserver kernel: PCI: Device 00:1f.1 not available because of resource collisions Regards, Norman From owner-linux-xfs@oss.sgi.com Wed Oct 29 06:27:11 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 29 Oct 2003 06:27:51 -0800 (PST) Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9TEQm25031339 for ; Wed, 29 Oct 2003 06:27:11 -0800 Received: from auto-nb1.xs4all.nl (a80-126-90-136.adsl.xs4all.nl [80.126.90.136]) by smtpzilla1.xs4all.nl (8.12.9/8.12.9) with ESMTP id h9TEQYhc027457; Wed, 29 Oct 2003 15:26:40 +0100 (CET) Message-Id: <4.3.2.7.2.20031029152516.035fa5f8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 29 Oct 2003 15:26:32 +0100 To: "Norman Zhang" , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: Samba on XFS Freezes In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 843 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs Content-Length: 1508 Lines: 45 At 23:22 28-10-2003 -0800, Norman Zhang wrote: >Hi, > >My Samba box stalls after some usage, mapped drives disappear and users >can't write or read from drives. The stalls happen randomly. I'm running >2.4.19-16mdksmp and Samba 2.2.7a-9.2mdk with software RAID. May I ask is >this a XFS bug or Samba bug? Does anyone know a fix for it? I checked the >memory from BIOS, and memtest they didn't report any errors. > >/var/log/kernel/warnings >------------------------ >Oct 27 09:19:12 smbserver kernel: xfs_force_shutdown(md(9,5),0x8) called >from line 1039 of file xfs_trans.c. Return address = 0xe08ae312 >Oct 27 09:19:12 smbserver kernel: Corruption of in-memory data detected. >Shutting down filesystem: md(9,5) >Oct 27 09:19:12 smbserver kernel: Please umount the filesystem, and rectify >the problem(s) > >/var/log/kernel/errors >---------------------- >Oct 27 10:36:44 smbserver kernel: Unknown bridge resource 2: assuming >transparent >Oct 27 10:36:44 smbserver kernel: PCI: Unable to handle 64-bit address >space for >Oct 27 10:36:44 smbserver kernel: PCI: Unable to handle 64-bit address >space for >Oct 27 10:36:44 smbserver kernel: Unknown bridge resource 2: assuming >transparent >Oct 27 10:36:44 smbserver kernel: PCI: Device 00:1f.1 not available >because of resource collisions Sounds a bit like IRQ sharing. You can try freeing up those by switching off things like serial and parallel ports. Cheers >Regards, >Norman -- Seth I don't make sense, I don't pretend to either. Questions? From owner-linux-xfs@oss.sgi.com Wed Oct 29 08:01:23 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 29 Oct 2003 08:02:04 -0800 (PST) Received: from allanon.amazing-internet.net (lorn.amazing-internet.net [213.210.55.94]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9TG1L25032670 for ; Wed, 29 Oct 2003 08:01:23 -0800 Received: from althea.amazing-internet.net ([172.16.1.190] helo=amazinginternet.com) by allanon.amazing-internet.net with esmtp (Exim 3.35 #1 (Debian)) id 1AEskX-0004P9-00; Wed, 29 Oct 2003 16:00:45 +0000 Message-ID: <3F9FE42D.6070306@amazinginternet.com> Date: Wed, 29 Oct 2003 16:00:45 +0000 From: Ronny Adsetts Organization: Amazing Internet Ltd User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Murthy Kambhampaty CC: linux-xfs@oss.sgi.com, linux-lvm@sistina.com Subject: Re: Error on unmounting XFS LVM snapshot References: <2D92FEBFD3BE1346A6C397223A8DD3FC092442@THOR.goeci.com> In-Reply-To: <2D92FEBFD3BE1346A6C397223A8DD3FC092442@THOR.goeci.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner: Found to be clean X-archive-position: 844 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ronny.adsetts@amazinginternet.com Precedence: bulk X-list: linux-xfs Content-Length: 2154 Lines: 62 Murthy Kambhampaty said the following on 20/10/03 18:10: >>-----Original Message----- >>From: Ronny Adsetts [mailto:ronny.adsetts@amazinginternet.com] >>Sent: Friday, October 17, 2003 12:39 >> >>Software used: >>Debian: 3.0 (Mostly) >>Kernel: 2.4.21 >>Kernel patches: Debian standard kernel patches; XFS 1.3.0 >>LVM utils: 1.0.4-4 (Debian) >>XFS utils: 2.5.6-1 (Debian) >> >>Sequence of actions: >>1: xfs_freeze -f /home >>2: lvcreate -L 1G -s -n home_lv_bak /dev/vg0/home_lv >>3: xfs_freeze -u /home >>4: mount -t xfs -onouuid,ro,usrquota /dev/vg0/home_lv_bak /mnt/home >>5: umount /mnt/home >>6: lvremove -f /dev/vg0/home_lv_bak >> >>On step 5 of above, an error is logged: >> >>Logs: >>Oct 17 17:23:44 jettero kernel: lvm - lvm_map: ll_rw_blk write for >>readonly LV /dev/vg0/home_lv_bak >>Oct 17 17:23:44 jettero kernel: xfs_force_shutdown(lvm(58,10),0x1) >>called from line 351 of file xfs_rw.c. Return address = 0xc01fd6aa >>Oct 17 17:23:44 jettero kernel: Filesystem "lvm(58,10)": I/O Error >>Detected. Shutting down filesystem: lvm(58,10) >>Oct 17 17:23:44 jettero kernel: Please umount the filesystem, and >>rectify the problem(s) > > I got these error messages on the Wolk 4.9s kernel, but not on XFS CVS > kernels (or vanilla linux with XFS patches applied). This is a somewhat > random guess, but you might try to upgrade LVM to 1.0.7, following the LVM > how-to, and see if the problem persists. > I've built a later version of LVM 1 tools, but not had a chance to try them yet (probably won't bother now). I did see this this today which appears to be the same issue: http://www.kerneltraffic.org/kernel-traffic/kt20031027_238.html#4 From Marcelo Tosatti[1]: "It seems its not safe to create snapshots of journalled fs'es without this patch[2]." Looks like the patch will show up in mainline in the 2.4.24-pre series. [1] http://marc.theaimsgroup.com/?l=linux-kernel&m=106642797513724&w=2 [2] http://marc.theaimsgroup.com/?l=linux-kernel&m=106623350522639&q=p3 Regards, Ronny -- Technical Director Amazing Internet Ltd, London t: +44 20 8607 9535 f: +44 20 8607 9536 w: www.amazinginternet.com From owner-linux-xfs@oss.sgi.com Wed Oct 29 11:09:35 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 29 Oct 2003 11:10:13 -0800 (PST) Received: from web40602.mail.yahoo.com (web40602.mail.yahoo.com [66.218.78.139]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9TJ9Z25012135 for ; Wed, 29 Oct 2003 11:09:35 -0800 Message-ID: <20031029190929.62310.qmail@web40602.mail.yahoo.com> Received: from [208.35.40.2] by web40602.mail.yahoo.com via HTTP; Wed, 29 Oct 2003 11:09:29 PST Date: Wed, 29 Oct 2003 11:09:29 -0800 (PST) From: Ravi Wijayaratne Subject: Extended attribute caching To: linux-xfs@oss.sgi.com Cc: lord@sgi.com, sandeen@sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 845 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ravi_wija@yahoo.com Precedence: bulk X-list: linux-xfs Content-Length: 1217 Lines: 38 Hi, I wanted to find out what performance impact setting/getting extended attributes would have on file I/O on XFS. Therefore for every file I/O I set a 4 byte extended attribute in "user" name space. The performance dropped approximately 30%. I have the following questions regarding this observation. 1. Are extended attributes cached ? If so I should see a performance impact of perhaps doing stat which accesses the cached inode structures if present. Substituting a stat call instead of setxattr call, only had approximately 6% drop in performance. Why is the discrepency ? 2. I know that inodes are cached. Are user name space EAs stored inside the inode ? If not, is there a user space utility or another name space, "system" or "root" that I could use to force EAs to be stored inside the inode so that I can be assured that it will be cached ? 3. Could setting extensive amounts of extended attributes disrupt the transactional operations in the log and hence cause adverse effects ? Thank you Ravi ===== ------------------------------ Ravi Wijayaratne __________________________________ Do you Yahoo!? Exclusive Video Premiere - Britney Spears http://launch.yahoo.com/promos/britneyspears/ From owner-linux-xfs@oss.sgi.com Wed Oct 29 11:27:09 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 29 Oct 2003 11:27:50 -0800 (PST) Received: from localhost.localdomain (host-65-120-145-91.coremetrics.com [65.120.145.91] (may be forged)) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9TJR825012993 for ; Wed, 29 Oct 2003 11:27:08 -0800 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id h9TJRELa005278; Wed, 29 Oct 2003 13:27:14 -0600 Received: (from austin@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id h9TJREt7005276; Wed, 29 Oct 2003 13:27:14 -0600 X-Authentication-Warning: localhost.localdomain: austin set sender to austin@coremetrics.com using -f Subject: Re: Broken Log Help Needed From: Austin Gonyou To: Glen Overby Cc: XFS List In-Reply-To: <200310282151.h9SLpaeH187546@zhadum.americas.sgi.com> References: <200310282151.h9SLpaeH187546@zhadum.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1067455634.3121.34.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Wed, 29 Oct 2003 13:27:14 -0600 X-archive-position: 846 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: austin@coremetrics.com Precedence: bulk X-list: linux-xfs Content-Length: 1437 Lines: 41 Yes..yes..I know. :) I wasn't going to kill my fs. I was just referring to xfs_repair -L. On Tue, 2003-10-28 at 15:51, Glen Overby wrote: > On October 28, Austin Gonyou wrote: > > On Mon, 2003-10-27 at 18:38, Glen Overby wrote: > > > On October 27, Austin Gonyou wrote: > > > > The issue is that I don't see any "ERROR" statements in this > output, > > > but > > > > trying to replay the log or mounting -oro will oops the kernel and > > > that > > > > one device is then unavailable and the system must be rebooted. > > > > > > Can you send the exact oops message.. where it occured, etc? > > > > > > > I would like to extract the log so I can put this server back into > our > > > > beta environment. If someone could aid me in this I'd much > appreciate > > > > it. > > > > > > Here's an example: > > > > > > [root@HOSTNAME root]# /a23/overby/bin.l/mkfs.xfs -f -b size=4096 -l > > > size=8192b /dev/hda6 > > Ok. missed this part, I thought it was what I'd typed. I'll do this, > > though the system is now back into production, I can see about trying > to > > break a log again and then extract it. > > er, this was just part of my example. I started with a clean > filesystem. You don't have to wipe your filesystem... in fact, if you > do that your log will be very clean and you don't need to bother > dumping it. Data loss from mkfs "100%". > > Glen Overby -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Wed Oct 29 11:31:14 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 29 Oct 2003 11:31:47 -0800 (PST) Received: from relay04.roc.ny.frontiernet.net (relay04.roc.ny.frontiernet.net [66.133.131.37]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9TJVD25013409 for ; Wed, 29 Oct 2003 11:31:14 -0800 Received: (qmail 20219 invoked from network); 29 Oct 2003 19:31:11 -0000 Received: from unknown (HELO [192.168.1.100]) ([208.186.10.249]) (envelope-sender ) by relay04.roc.ny.frontiernet.net (FrontierMTA 2.3.6) with SMTP for ; 29 Oct 2003 19:31:11 -0000 Subject: Re: Extended attribute caching From: Steve Lord Reply-To: lord@xfs.org To: Ravi Wijayaratne Cc: linux-xfs@oss.sgi.com, sandeen@sgi.com In-Reply-To: <20031029190929.62310.qmail@web40602.mail.yahoo.com> References: <20031029190929.62310.qmail@web40602.mail.yahoo.com> Content-Type: text/plain Organization: Message-Id: <1067455937.1304.3.camel@snafu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 29 Oct 2003 13:32:17 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 847 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 1653 Lines: 42 On Wed, 2003-10-29 at 13:09, Ravi Wijayaratne wrote: > Hi, > > I wanted to find out what performance impact setting/getting extended > attributes would have on file I/O on XFS. Therefore for every file I/O > I set a 4 byte extended attribute in "user" name space. The performance > dropped approximately 30%. > > I have the following questions regarding this observation. > > 1. Are extended attributes cached ? If so I should see a performance > impact of perhaps doing stat which accesses the cached inode structures > if present. Substituting a stat call instead of setxattr call, only had > approximately 6% drop in performance. Why is the discrepency ? Stat is a read only call, setting an extended attribute does a transaction. There may not be disk I/O on all calls, but there will be disk writes involved. > > 2. I know that inodes are cached. Are user name space EAs stored inside the inode ? > If not, is there a user space utility or another name space, "system" or "root" > that I could use to force EAs to be stored inside the inode so that I can be assured > that it will be cached ? Caching is not the issue, you are changing them so you are updating metadata. Extended attributes can be held inside the inode, but this space is shared between attributes, extent information and directory contents. If you want to be more sure of keeping them in the inode then you can make the inodes larger at mkfs time. > > 3. Could setting extensive amounts of extended attributes disrupt the transactional > operations in the log and hence cause adverse effects ? > Well yes, since you are asking the filesystem to do more. Steve From owner-linux-xfs@oss.sgi.com Wed Oct 29 12:23:38 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 29 Oct 2003 12:24:20 -0800 (PST) Received: from imo-m01.mx.aol.com (imo-m01.mx.aol.com [64.12.136.4]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9TKNV25020135 for ; Wed, 29 Oct 2003 12:23:38 -0800 Received: from AndyLiebman@aol.com by imo-m01.mx.aol.com (mail_out_v36_r1.1.) id 4.125.26e5f7ec (4254) for ; Wed, 29 Oct 2003 15:10:20 -0500 (EST) From: AndyLiebman@aol.com Message-ID: <125.26e5f7ec.2cd178ac@aol.com> Date: Wed, 29 Oct 2003 15:10:20 EST Subject: Why can't I put Log File on its own drive/partition? To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: 9.0 for Windows sub 5002 X-archive-position: 848 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: AndyLiebman@aol.com Precedence: bulk X-list: linux-xfs Content-Length: 2193 Lines: 49 According to information on the XFS home page, writing XFS files can be sped up by as much as 30 percent by having the "metadata" or "journal" file stored on a separate drive. I am trying do use that "speed up" proceedure without any success. Here's my setup. I have 6 Firewire Drives arranged into three RAID 1 arrays (md0, md1, md2). Then the 3 RAID 1 arrays are combined into one RAID 0 array (md3). The end result is a single RAID 10 array. I don't have any trouble putting XFS on the array with a simple mkfs.xfs -f -b size=4096 /dev/md3 -- and then mounting the array with mount -t xfs /dev/md3 /home/raid1 However, I have been unable to configure XFS on the array so that the journal goes on a separate drive. I am wondering if I'm doing something wrong. The place where I'm trying to put the journal file is a 4 GB partition on an internal IDE drive. The command mkfs.xfs -f -l logdev=/dev/hdb3,size=10000b -b size=4096 /dev/md3 is accepted by the system. It looks as if I formatted the RAID with XFS and put the journal on in a separate place. But when I try to mount the RAID as I did above, I get the following error: mount: wrong fs type, bad option, bad superblock on /dev/md3 or too many mounted file systems. I believe I also tried something like mount -t xfs logdev=dev/hdb3 /dev/md3. I think I also tried mount -t xfs logdev=dev/hdb3,size=10000b /dev/md3 Does anybody have any ideas about what the trouble is? Am I issuing the wrong commands? Is it impossible to put the journal on the IDE partition? It's a primary partition at the end of a drive. I've tried marking the partition with fdisk as type 83/Linux. Also tried (Raid Auto Detect). Same problem either way. I vaguely remember something about the place where I put the journal having to be exactly the same number of blocks as the size that's specified in the "logdev=dev/location,size=xxxxxb" line. If that's true, I have no idea how to accomplish that. Thanks in advance for the help. I'm about to launch into storing a lot of data on the RAID and I would like to set it up so that it works as efficiently as possible. Regards, Andy Liebman From owner-linux-xfs@oss.sgi.com Wed Oct 29 12:47:19 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 29 Oct 2003 12:48:00 -0800 (PST) Received: from mx-01-bsl.sauter-bc.com (mx-01-bsl.sauter-bc.com [213.173.165.132]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9TKlH25021036 for ; Wed, 29 Oct 2003 12:47:18 -0800 Received: from mailhub.ch.sauter-bc.com (mailhub [10.1.6.26]) by mx-01-bsl.sauter-bc.com (Postfix) with ESMTP id 8D4F632CE1; Wed, 29 Oct 2003 21:47:12 +0100 (CET) Received: from av-01.ch.sauter-bc.com (av-01.ch.sauter-bc.com [10.1.6.28]) by mailhub.ch.sauter-bc.com (Postfix) with SMTP id 46A5532CB5; Wed, 29 Oct 2003 21:47:12 +0100 (CET) Received: from mx-05-bsl.ch.sauter-bc.com ([10.1.6.20]) by av-01.ch.sauter-bc.com (SAVSMTP 3.1.2.35) with SMTP id M2003102921471106099 ; Wed, 29 Oct 2003 21:47:11 +0100 Received: from webmail.ch.sauter-bc.com (imap01.ch.sauter-bc.com [10.1.6.25]) by mx-05-bsl.ch.sauter-bc.com (Postfix) with SMTP id 37BA74E20D; Wed, 29 Oct 2003 21:47:12 +0100 (CET) Received: from 213.173.165.140 (proxying for 157.161.34.15) (SquirrelMail authenticated user mattesim) by imap01.ch.sauter-bc.com with HTTP; Wed, 29 Oct 2003 21:47:12 +0100 (CET) Message-ID: <36605.213.173.165.140.1067460432.squirrel@imap01.ch.sauter-bc.com> In-Reply-To: <125.26e5f7ec.2cd178ac@aol.com> References: <125.26e5f7ec.2cd178ac@aol.com> Date: Wed, 29 Oct 2003 21:47:12 +0100 (CET) Subject: Re: Why can't I put Log File on its own drive/partition? From: "Simon Matter" To: AndyLiebman@aol.com Cc: linux-xfs@oss.sgi.com User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h9TKlJ25021037 X-archive-position: 849 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: simon.matter@ch.sauter-bc.com Precedence: bulk X-list: linux-xfs Content-Length: 2352 Lines: 72 > According to information on the XFS home page, writing XFS files can be > sped > up by as much as 30 percent by having the "metadata" or "journal" file > stored > on a separate drive. > > I am trying do use that "speed up" proceedure without any success. > > Here's my setup. I have 6 Firewire Drives arranged into three RAID 1 > arrays > (md0, md1, md2). Then the 3 RAID 1 arrays are combined into one RAID 0 > array > (md3). The end result is a single RAID 10 array. > > I don't have any trouble putting XFS on the array with a simple > mkfs.xfs -f -b size=4096 /dev/md3 -- and then mounting the array with > mount -t xfs /dev/md3 /home/raid1 > > However, I have been unable to configure XFS on the array so that the > journal > goes on a separate drive. I am wondering if I'm doing something wrong. > > The place where I'm trying to put the journal file is a 4 GB partition on > an > internal IDE drive. > The command mkfs.xfs -f -l logdev=/dev/hdb3,size=10000b -b size=4096 > /dev/md3 is accepted by the system. It looks as if I formatted the RAID > with XFS and > put the journal on in a separate place. > > But when I try to mount the RAID as I did above, I get the following > error: > mount: wrong fs type, bad option, bad superblock on /dev/md3 > or too many mounted file systems. > > I believe I also tried something like mount -t xfs logdev=dev/hdb3 > /dev/md3. > I think I also tried mount -t xfs logdev=dev/hdb3,size=10000b /dev/md3 Hm, sorry for the spam, I meant mount -t xfs -o logdev=dev/hdb3 /dev/md3 > > Does anybody have any ideas about what the trouble is? Am I issuing the > wrong > commands? Is it impossible to put the journal on the IDE partition? It's > a > primary partition at the end of a drive. I've tried marking the partition > with > fdisk as type 83/Linux. Also tried (Raid Auto Detect). Same problem either > way. > > I vaguely remember something about the place where I put the journal > having > to be exactly the same number of blocks as the size that's specified in > the > "logdev=dev/location,size=xxxxxb" line. If that's true, I have no idea > how to > accomplish that. > > Thanks in advance for the help. I'm about to launch into storing a lot of > data on the RAID and I would like to set it up so that it works as > efficiently as > possible. > > Regards, > Andy Liebman > > > From owner-linux-xfs@oss.sgi.com Wed Oct 29 12:53:08 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 29 Oct 2003 12:53:42 -0800 (PST) Received: from shell.f2o.org (shell.f2o.org [63.237.54.245]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9TKr725021471 for ; Wed, 29 Oct 2003 12:53:08 -0800 Received: from f2o.org (gateway3.starkmedia.com [63.237.54.129] (may be forged)) (authenticated (0 bits)) by shell.f2o.org (8.12.9/8.11.6) with ESMTP id h9TKr6cu001363 for ; Wed, 29 Oct 2003 14:53:06 -0600 Message-ID: <3FA0273B.8050101@f2o.org> Date: Wed, 29 Oct 2003 14:46:51 -0600 From: "Daniel J. Cody" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Possible bug in 2.6.0-test9 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 850 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: djc@f2o.org Precedence: bulk X-list: linux-xfs Content-Length: 1606 Lines: 45 Received the following oops today when trying to mount a raid0 device /dev/md0 with a single XFS partition compromised of 2 15k seagate cheetahs attached to a vanilla adaptec AIC7xxx and thought it looked interesting. I can provide more info if it's needed. Dan http://five2one.org/ -- XFS internal error XFS_WANT_CORRUPTED_GOTO at line 1623 of file fs/xfs/xfs_alloc.c. Caller 0xc01de3e5 Call Trace: [] xfs_free_ag_extent+0x42e/0x720 [] xfs_free_extent+0xd5/0x100 [] xfs_free_extent+0xd5/0x100 [] xfs_efd_init+0x117/0x170 [] xfs_trans_get_efd+0x36/0x40 [] xlog_recover_process_efi+0x186/0x1f0 [] xlog_recover_process_efis+0x81/0x100 [] xlog_recover_finish+0x24/0xd0 [] xfs_log_mount_finish+0x2b/0x30 [] xfs_mountfs+0x84c/0xea0 [] tcp_sendmsg+0x4c/0x1350 [] xfs_setsize_buftarg+0x3d/0x80 [] xfs_ioinit+0x1f/0x30 [] xfs_mount+0x33b/0x5d0 [] vfs_mount+0x34/0x40 [] linvfs_fill_super+0xa2/0x230 [] snprintf+0x26/0x30 [] disk_name+0xa2/0xb0 [] sb_set_blocksize+0x24/0x50 [] get_sb_bdev+0x116/0x150 [] linvfs_get_sb+0x2e/0x30 [] linvfs_fill_super+0x0/0x230 [] do_kern_mount+0x56/0xd0 [] do_add_mount+0x7b/0x180 [] do_mount+0x120/0x170 [] copy_mount_options+0x9b/0x110 [] sys_mount+0xc9/0x150 [] syscall_call+0x7/0xb Ending XFS recovery on filesystem: md0 (dev: md0) From owner-linux-xfs@oss.sgi.com Wed Oct 29 12:54:08 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 29 Oct 2003 12:54:42 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9TKs725021664 for ; Wed, 29 Oct 2003 12:54:08 -0800 Received: from flecktone.americas.sgi.com ([192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h9TKs2q0004078 for ; Wed, 29 Oct 2003 12:54:02 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h9TKrrP512749329; Wed, 29 Oct 2003 14:53:54 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h9TKrrK14615265; Wed, 29 Oct 2003 14:53:53 -0600 (CST) Subject: Re: Why can't I put Log File on its own drive/partition? From: Eric Sandeen To: AndyLiebman@aol.com Cc: linux-xfs@oss.sgi.com In-Reply-To: <125.26e5f7ec.2cd178ac@aol.com> References: <125.26e5f7ec.2cd178ac@aol.com> Content-Type: text/plain Organization: Message-Id: <1067460833.1348.16.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 29 Oct 2003 14:53:53 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 851 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1144 Lines: 38 On Wed, 2003-10-29 at 14:10, AndyLiebman@aol.com wrote: > The place where I'm trying to put the journal file is a 4 GB partition on an > internal IDE drive. FWIW, that'll waste a lot of space on that partition, but ok :) > The command mkfs.xfs -f -l logdev=/dev/hdb3,size=10000b -b size=4096 > /dev/md3 is accepted by the system. It looks as if I formatted the RAID with XFS and > put the journal on in a separate place. This looks fine, if mkfs is happy then it's ok. > But when I try to mount the RAID as I did above, I get the following error: > mount: wrong fs type, bad option, bad superblock on /dev/md3 > or too many mounted file systems. look at system logs or dmesg to see what really went wrong. > I believe I also tried something like mount -t xfs logdev=dev/hdb3 > /dev/md3. mount won't parse that > I think I also tried mount -t xfs logdev=dev/hdb3,size=10000b /dev/md3 or that, either. What you want is mount -t xfs -o logdev=/dev/hdb3 /dev/md3 /mnt/md3 -Eric -- Eric Sandeen [C]XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Wed Oct 29 13:19:11 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 29 Oct 2003 13:19:50 -0800 (PST) Received: from web40612.mail.yahoo.com (web40612.mail.yahoo.com [66.218.78.149]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9TLJB25022411 for ; Wed, 29 Oct 2003 13:19:11 -0800 Message-ID: <20031029211906.4252.qmail@web40612.mail.yahoo.com> Received: from [208.35.40.2] by web40612.mail.yahoo.com via HTTP; Wed, 29 Oct 2003 13:19:06 PST Date: Wed, 29 Oct 2003 13:19:06 -0800 (PST) From: Ravi Wijayaratne Subject: Re: Extended attribute caching To: lord@xfs.org Cc: linux-xfs@oss.sgi.com, sandeen@sgi.com In-Reply-To: <1067455937.1304.3.camel@snafu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 852 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ravi_wija@yahoo.com Precedence: bulk X-list: linux-xfs Content-Length: 2161 Lines: 63 Steve Thanks for the response. Assuming there is sufficient space in the inode, is it guaranteed that the extended attribue will be stored in the inode and hence in the inode cache ? Ravi --- Steve Lord wrote: > On Wed, 2003-10-29 at 13:09, Ravi Wijayaratne wrote: > > Hi, > > > > I wanted to find out what performance impact setting/getting extended > > attributes would have on file I/O on XFS. Therefore for every file I/O > > I set a 4 byte extended attribute in "user" name space. The performance > > dropped approximately 30%. > > > > I have the following questions regarding this observation. > > > > 1. Are extended attributes cached ? If so I should see a performance > > impact of perhaps doing stat which accesses the cached inode structures > > if present. Substituting a stat call instead of setxattr call, only had > > approximately 6% drop in performance. Why is the discrepency ? > > Stat is a read only call, setting an extended attribute does a > transaction. There may not be disk I/O on all calls, but there > will be disk writes involved. > > > > > 2. I know that inodes are cached. Are user name space EAs stored inside the inode ? > > If not, is there a user space utility or another name space, "system" or "root" > > that I could use to force EAs to be stored inside the inode so that I can be assured > > that it will be cached ? > > Caching is not the issue, you are changing them so you are updating > metadata. Extended attributes can be held inside the inode, but this > space is shared between attributes, extent information and directory > contents. If you want to be more sure of keeping them in the inode > then you can make the inodes larger at mkfs time. > > > > > 3. Could setting extensive amounts of extended attributes disrupt the transactional > > operations in the log and hence cause adverse effects ? > > > > Well yes, since you are asking the filesystem to do more. > > Steve > > > ===== ------------------------------ Ravi Wijayaratne __________________________________ Do you Yahoo!? Exclusive Video Premiere - Britney Spears http://launch.yahoo.com/promos/britneyspears/ From owner-linux-xfs@oss.sgi.com Wed Oct 29 13:20:20 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 29 Oct 2003 13:20:53 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9TLKK25022605 for ; Wed, 29 Oct 2003 13:20:20 -0800 Received: from larry.melbourne.sgi.com ([134.14.52.130]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id h9TLKDq0008375 for ; Wed, 29 Oct 2003 13:20:14 -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 IAA07872; Thu, 30 Oct 2003 08:20:12 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h9TLKBUc976336; Thu, 30 Oct 2003 08:20:11 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id h9TKHEFm000785; Thu, 30 Oct 2003 07:17:14 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id h9TKHETR000783; Thu, 30 Oct 2003 07:17:14 +1100 Date: Thu, 30 Oct 2003 07:17:14 +1100 From: Nathan Scott To: AndyLiebman@aol.com Cc: linux-xfs@oss.sgi.com Subject: Re: Why can't I put Log File on its own drive/partition? Message-ID: <20031029201714.GA753@frodo> References: <125.26e5f7ec.2cd178ac@aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <125.26e5f7ec.2cd178ac@aol.com> User-Agent: Mutt/1.5.3i X-archive-position: 853 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 964 Lines: 28 On Wed, Oct 29, 2003 at 03:10:20PM -0500, AndyLiebman@aol.com wrote: > ... > The command mkfs.xfs -f -l logdev=/dev/hdb3,size=10000b -b size=4096 > /dev/md3 is accepted by the system. It looks as if I formatted the RAID with XFS and > put the journal on in a separate place. > > But when I try to mount the RAID as I did above, I get the following error: > mount: wrong fs type, bad option, bad superblock on /dev/md3 > or too many mounted file systems. > > I believe I also tried something like mount -t xfs logdev=dev/hdb3 > /dev/md3. > I think I also tried mount -t xfs logdev=dev/hdb3,size=10000b /dev/md3 > Does anybody have any ideas about what the trouble is? You need to use the -o option to mount(8), and use the full device paths -- i.e. mount -t xfs -ologdev=/dev/hdb3 /dev/md3 There is no size= mount option to XFS (mount(8) has the list), that information is obtained from the superblock. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Oct 29 13:25:56 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 29 Oct 2003 13:26:29 -0800 (PST) Received: from mx-01-bsl.sauter-bc.com (mx-01-bsl.sauter-bc.com [213.173.165.132]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9TLPj25023572 for ; Wed, 29 Oct 2003 13:25:45 -0800 Received: from mailhub.ch.sauter-bc.com (mailhub [10.1.6.26]) by mx-01-bsl.sauter-bc.com (Postfix) with ESMTP id 3E9B032CDB; Wed, 29 Oct 2003 21:45:01 +0100 (CET) Received: from av-01.ch.sauter-bc.com (av-01.ch.sauter-bc.com [10.1.6.28]) by mailhub.ch.sauter-bc.com (Postfix) with SMTP id 6EFC132CB5; Wed, 29 Oct 2003 21:45:00 +0100 (CET) Received: from mx-05-bsl.ch.sauter-bc.com ([10.1.6.20]) by av-01.ch.sauter-bc.com (SAVSMTP 3.1.2.35) with SMTP id M2003102921450006096 ; Wed, 29 Oct 2003 21:45:00 +0100 Received: from webmail.ch.sauter-bc.com (imap01.ch.sauter-bc.com [10.1.6.25]) by mx-05-bsl.ch.sauter-bc.com (Postfix) with SMTP id 51A3D4E20D; Wed, 29 Oct 2003 21:45:00 +0100 (CET) Received: from 213.173.165.140 (proxying for 157.161.34.15) (SquirrelMail authenticated user mattesim) by imap01.ch.sauter-bc.com with HTTP; Wed, 29 Oct 2003 21:45:00 +0100 (CET) Message-ID: <36592.213.173.165.140.1067460300.squirrel@imap01.ch.sauter-bc.com> In-Reply-To: <125.26e5f7ec.2cd178ac@aol.com> References: <125.26e5f7ec.2cd178ac@aol.com> Date: Wed, 29 Oct 2003 21:45:00 +0100 (CET) Subject: Re: Why can't I put Log File on its own drive/partition? From: "Simon Matter" To: AndyLiebman@aol.com Cc: linux-xfs@oss.sgi.com User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h9TLPu25023573 X-archive-position: 854 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: simon.matter@ch.sauter-bc.com Precedence: bulk X-list: linux-xfs Content-Length: 2521 Lines: 79 > According to information on the XFS home page, writing XFS files can be > sped > up by as much as 30 percent by having the "metadata" or "journal" file > stored > on a separate drive. > > I am trying do use that "speed up" proceedure without any success. > > Here's my setup. I have 6 Firewire Drives arranged into three RAID 1 > arrays > (md0, md1, md2). Then the 3 RAID 1 arrays are combined into one RAID 0 > array > (md3). The end result is a single RAID 10 array. > > I don't have any trouble putting XFS on the array with a simple > mkfs.xfs -f -b size=4096 /dev/md3 -- and then mounting the array with > mount -t xfs /dev/md3 /home/raid1 > > However, I have been unable to configure XFS on the array so that the > journal > goes on a separate drive. I am wondering if I'm doing something wrong. > > The place where I'm trying to put the journal file is a 4 GB partition on > an > internal IDE drive. > The command mkfs.xfs -f -l logdev=/dev/hdb3,size=10000b -b size=4096 > /dev/md3 is accepted by the system. It looks as if I formatted the RAID > with XFS and > put the journal on in a separate place. > > But when I try to mount the RAID as I did above, I get the following > error: > mount: wrong fs type, bad option, bad superblock on /dev/md3 > or too many mounted file systems. > > I believe I also tried something like mount -t xfs logdev=dev/hdb3 > /dev/md3. > I think I also tried mount -t xfs logdev=dev/hdb3,size=10000b /dev/md3 I may be wrong but isn't it mount -t xfs -o logdev=dev/hdb3,size=10000b /dev/md3 I've been using external logs with XFS on all kind of software RAID and LVM without any problem. So I'm sure it's no problem with IDE or software RAID. Simon > > Does anybody have any ideas about what the trouble is? Am I issuing the > wrong > commands? Is it impossible to put the journal on the IDE partition? It's > a > primary partition at the end of a drive. I've tried marking the partition > with > fdisk as type 83/Linux. Also tried (Raid Auto Detect). Same problem either > way. > > I vaguely remember something about the place where I put the journal > having > to be exactly the same number of blocks as the size that's specified in > the > "logdev=dev/location,size=xxxxxb" line. If that's true, I have no idea > how to > accomplish that. > > Thanks in advance for the help. I'm about to launch into storing a lot of > data on the RAID and I would like to set it up so that it works as > efficiently as > possible. > > Regards, > Andy Liebman > > > From owner-linux-xfs@oss.sgi.com Wed Oct 29 13:36:16 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 29 Oct 2003 13:36:49 -0800 (PST) Received: from imo-m03.mx.aol.com (imo-m03.mx.aol.com [64.12.136.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9TLaF25023992 for ; Wed, 29 Oct 2003 13:36:15 -0800 Received: from AndyLiebman@aol.com by imo-m03.mx.aol.com (mail_out_v36_r1.1.) id 5.2d.35e3d3e4 (4254); Wed, 29 Oct 2003 16:30:51 -0500 (EST) From: AndyLiebman@aol.com Message-ID: <2d.35e3d3e4.2cd18b8b@aol.com> Date: Wed, 29 Oct 2003 16:30:51 EST Subject: Re: Why can't I put Log File on its own drive/partition? To: nathans@sgi.com CC: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: 9.0 for Windows sub 5002 X-archive-position: 855 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: AndyLiebman@aol.com Precedence: bulk X-list: linux-xfs Content-Length: 1955 Lines: 51 Thanks for your reply. This list is amazing. I got responses from 3 people in about 20 minutes! Nobody really commented on my other uncertainty, though. How big of a partition do I need for the journal file? If the journal file is 10000 blocks, how does that translate into MBs? And do I want a larger journal file? I'm mostly going to be storing HUGE (i.e., 50 MB to 2 GB) video files on the RAID. The RAID is 600 GBs. So, I won't have more than a couple of thousand files. How do you calculate how big a journal partition to make? And does it matter what kind of "flag" I put on the partition with fdisk? Is 83 (Linux) fine? I don't think I need "fp" (RAID Autostart). I don't want to start my RAIDS manually anyway. Finally, should I really see a significant speed up in I/O with the journal on a separate drive? Is it only during writing that I'll see the speed up? Thanks. In a message dated 10/29/2003 4:20:33 PM Eastern Standard Time, nathans@sgi.com writes: On Wed, Oct 29, 2003 at 03:10:20PM -0500, AndyLiebman@aol.com wrote: > ... > The command mkfs.xfs -f -l logdev=/dev/hdb3,size=10000b -b size=4096 > /dev/md3 is accepted by the system. It looks as if I formatted the RAID with XFS and > put the journal on in a separate place. > > But when I try to mount the RAID as I did above, I get the following error: > mount: wrong fs type, bad option, bad superblock on /dev/md3 > or too many mounted file systems. > > I believe I also tried something like mount -t xfs logdev=dev/hdb3 > /dev/md3. > I think I also tried mount -t xfs logdev=dev/hdb3,size=10000b /dev/md3 > Does anybody have any ideas about what the trouble is? You need to use the -o option to mount(8), and use the full device paths -- i.e. mount -t xfs -ologdev=/dev/hdb3 /dev/md3 There is no size= mount option to XFS (mount(8) has the list), that information is obtained from the superblock. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Oct 29 14:29:48 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 29 Oct 2003 14:30:31 -0800 (PST) Received: from mx-01-bsl.sauter-bc.com (mx-01-bsl.sauter-bc.com [213.173.165.132]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9TMTk25025215 for ; Wed, 29 Oct 2003 14:29:47 -0800 Received: from mailhub.ch.sauter-bc.com (mailhub [10.1.6.26]) by mx-01-bsl.sauter-bc.com (Postfix) with ESMTP id C532C32CDB; Wed, 29 Oct 2003 23:29:40 +0100 (CET) Received: from av-01.ch.sauter-bc.com (av-01.ch.sauter-bc.com [10.1.6.28]) by mailhub.ch.sauter-bc.com (Postfix) with SMTP id EBA8B32CB5; Wed, 29 Oct 2003 23:29:39 +0100 (CET) Received: from mx-05-bsl.ch.sauter-bc.com ([10.1.6.20]) by av-01.ch.sauter-bc.com (SAVSMTP 3.1.2.35) with SMTP id M2003102923293906257 ; Wed, 29 Oct 2003 23:29:39 +0100 Received: from webmail.ch.sauter-bc.com (imap01.ch.sauter-bc.com [10.1.6.25]) by mx-05-bsl.ch.sauter-bc.com (Postfix) with SMTP id CEC174E20D; Wed, 29 Oct 2003 23:29:39 +0100 (CET) Received: from 213.173.165.140 (proxying for 157.161.34.15) (SquirrelMail authenticated user mattesim) by imap01.ch.sauter-bc.com with HTTP; Wed, 29 Oct 2003 23:29:39 +0100 (CET) Message-ID: <36858.213.173.165.140.1067466579.squirrel@imap01.ch.sauter-bc.com> In-Reply-To: <2d.35e3d3e4.2cd18b8b@aol.com> References: <2d.35e3d3e4.2cd18b8b@aol.com> Date: Wed, 29 Oct 2003 23:29:39 +0100 (CET) Subject: Re: Why can't I put Log File on its own drive/partition? From: "Simon Matter" To: AndyLiebman@aol.com Cc: nathans@sgi.com, linux-xfs@oss.sgi.com User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h9TMTm25025216 X-archive-position: 856 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: simon.matter@ch.sauter-bc.com Precedence: bulk X-list: linux-xfs Content-Length: 2462 Lines: 76 > Thanks for your reply. This list is amazing. I got responses from 3 people > in > about 20 minutes! > > Nobody really commented on my other uncertainty, though. How big of a > partition do I need for the journal file? If the journal file is 10000 > blocks, how > does that translate into MBs? And do I want a larger journal file? I'm > mostly > going to be storing HUGE (i.e., 50 MB to 2 GB) video files on the RAID. > The RAID > is 600 GBs. So, I won't have more than a couple of thousand files. How do > you > calculate how big a journal partition to make? IIRC I was asking the same myself until I realized that the size of the log is limited and quite small anyway. I think the size was limited to 128M or something with a filesystem size of some hundred megs. From my experience the partition type doesn't matter at all. Performance was much better with old XFS code on software RAID 5 when using external log, every other configuration didn't give me much more performance, YMMW. Simon > > And does it matter what kind of "flag" I put on the partition with fdisk? > Is > 83 (Linux) fine? I don't think I need "fp" (RAID Autostart). I don't want > to > start my RAIDS manually anyway. > > Finally, should I really see a significant speed up in I/O with the > journal > on a separate drive? Is it only during writing that I'll see the speed up? > > Thanks. > > > In a message dated 10/29/2003 4:20:33 PM Eastern Standard Time, > nathans@sgi.com writes: > On Wed, Oct 29, 2003 at 03:10:20PM -0500, AndyLiebman@aol.com wrote: >> ... >> The command mkfs.xfs -f -l logdev=/dev/hdb3,size=10000b -b size=4096 >> /dev/md3 is accepted by the system. It looks as if I formatted the RAID > with XFS and >> put the journal on in a separate place. >> >> But when I try to mount the RAID as I did above, I get the following >> error: >> mount: wrong fs type, bad option, bad superblock on /dev/md3 >> or too many mounted file systems. >> >> I believe I also tried something like mount -t xfs logdev=dev/hdb3 >> /dev/md3. >> I think I also tried mount -t xfs logdev=dev/hdb3,size=10000b >> /dev/md3 >> Does anybody have any ideas about what the trouble is? > > You need to use the -o option to mount(8), and use the full > device paths -- i.e. > > mount -t xfs -ologdev=/dev/hdb3 /dev/md3 > > There is no size= mount option to XFS (mount(8) has the list), > that information is obtained from the superblock. > > cheers. > > -- > Nathan > > > From owner-linux-xfs@oss.sgi.com Wed Oct 29 17:29:24 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 29 Oct 2003 17:30:09 -0800 (PST) Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9U1TL25030513 for ; Wed, 29 Oct 2003 17:29:23 -0800 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1AF1cm-0004LV-00 for ; Thu, 30 Oct 2003 02:29:20 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: linux-xfs@oss.sgi.com Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AF1cl-0004LN-00 for ; Thu, 30 Oct 2003 02:29:19 +0100 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 1AF1cl-0008Q0-00 for ; Thu, 30 Oct 2003 02:29:19 +0100 From: "Norman Zhang" Subject: Re: Samba on XFS Freezes Date: Wed, 29 Oct 2003 17:29:17 -0800 Message-ID: References: <4.3.2.7.2.20031029152516.035fa5f8@pop.xs4all.nl> X-Complaints-To: usenet@sea.gmane.org X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-archive-position: 857 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nzhang@arkon-group.com Precedence: bulk X-list: linux-xfs Content-Length: 2317 Lines: 54 Hi, >> /var/log/kernel/warnings >> ------------------------ >> Oct 27 09:19:12 smbserver kernel: xfs_force_shutdown(md(9,5),0x8) >> called from line 1039 of file xfs_trans.c. Return address = >> 0xe08ae312 >> Oct 27 09:19:12 smbserver kernel: Corruption of in-memory data >> detected. Shutting down filesystem: md(9,5) >> Oct 27 09:19:12 smbserver kernel: Please umount the filesystem, and >> rectify the problem(s) >> >> /var/log/kernel/errors >> ---------------------- >> Oct 27 10:36:44 smbserver kernel: Unknown bridge resource 2: assuming >> transparent >> Oct 27 10:36:44 smbserver kernel: PCI: Unable to handle 64-bit >> address space for >> Oct 27 10:36:44 smbserver kernel: PCI: Unable to handle 64-bit >> address space for >> Oct 27 10:36:44 smbserver kernel: Unknown bridge resource 2: assuming >> transparent >> Oct 27 10:36:44 smbserver kernel: PCI: Device 00:1f.1 not available >> because of resource collisions > > Sounds a bit like IRQ sharing. You can try freeing up those by > switching off things like serial and parallel ports. I disabled USB, Serial (RS232) and have no cards plug to the PCI slots of the system. The following is my /proc/interrupts. It does show anything conclusive. The XFS partitions would disappear from Samba shares. If I tried to unmount it, system says it is busy. May I ask how do I force XFS fsck equivalent on XFS paritions? Is it safe? CPU0 CPU1 CPU2 CPU3 0: 359126 0 0 0 IO-APIC-edge timer 1: 11 0 0 0 IO-APIC-edge keyboard 2: 0 0 0 0 XT-PIC cascade 8: 1 0 0 0 IO-APIC-edge rtc 12: 35 0 0 0 IO-APIC-edge PS/2 Mouse 15: 7 0 0 0 IO-APIC-edge ide1 30: 113223 0 0 0 IO-APIC-level eth1 31: 746889 0 0 0 IO-APIC-level eth0 49: 4134628 0 0 0 IO-APIC-level aic7xxx 50: 16 0 0 0 IO-APIC-level aic7xxx NMI: 0 0 0 0 LOC: 358982 358980 358980 358980 ERR: 0 MIS: 0 Regards, Norman From owner-linux-xfs@oss.sgi.com Wed Oct 29 19:12:58 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 29 Oct 2003 19:13:39 -0800 (PST) Received: from poptart.bithose.com (poptart.bithose.com [204.97.176.41]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9U3Ct25031983 for ; Wed, 29 Oct 2003 19:12:57 -0800 Received: from poptart.bithose.com (localhost [127.0.0.1]) by poptart.bithose.com (8.12.10/8.12.10) with ESMTP id h9U3Cq7X088613; Wed, 29 Oct 2003 22:12:53 -0500 (EST) Received: from localhost (jakari@localhost) by poptart.bithose.com (8.12.10/8.12.10/Submit) with ESMTP id h9U3CqvT088599; Wed, 29 Oct 2003 22:12:52 -0500 (EST) X-Authentication-Warning: poptart.bithose.com: jakari owned process doing -bs Date: Wed, 29 Oct 2003 22:12:52 -0500 (EST) From: Jameel Akari To: Norman Zhang cc: Subject: Re: Samba on XFS Freezes In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 858 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jakari@bithose.com Precedence: bulk X-list: linux-xfs Content-Length: 1887 Lines: 49 Jumping into this mid-thread... > >> Oct 27 09:19:12 smbserver kernel: xfs_force_shutdown(md(9,5),0x8) > >> called from line 1039 of file xfs_trans.c. Return address = > >> 0xe08ae312 > >> Oct 27 09:19:12 smbserver kernel: Corruption of in-memory data > >> detected. Shutting down filesystem: md(9,5) > >> Oct 27 09:19:12 smbserver kernel: Please umount the filesystem, and > >> rectify the problem(s) > >> Oct 27 10:36:44 smbserver kernel: PCI: Unable to handle 64-bit > >> address space for I think the PCI conflicts *might* be a red herring. Note the timestamps. The xfs shutdown occured an hour before these PCI errors. > >> Oct 27 10:36:44 smbserver kernel: PCI: Unable to handle 64-bit > >> address space for But out of curiosity, did you accidentally clip this line cutting-and-pasting? "address space for"... what? > >> Oct 27 10:36:44 smbserver kernel: Unknown bridge resource 2: assuming > >> transparent > >> Oct 27 10:36:44 smbserver kernel: PCI: Device 00:1f.1 not available > >> because of resource collisions Without knowing more about your hardware I'm not going to take a guess at the root cause of these messages. PCI-PCI bridges generally "just work" these days. Again, I don't see a direct corrolation between this and the xfs_force_shutdown. > conclusive. The XFS partitions would disappear from Samba shares. If I tried An XFS shutdown means all I/O is stopped so it doesn't make itself worse. Samba won't see it, and neither will anything else. So that much follows. You'll probably need to shutdown Samba and whataver else is _trying_ to access the filesystem before you can umount it. If you have 'lsof' on your system it can help track down what's holding it "busy." Then xfs_check might be worth trying out. Did I miss a message stating what kernel and XFS revision is involved? -- #!/jameel/akari sleep 4800; make clean && make breakfast From owner-linux-xfs@oss.sgi.com Wed Oct 29 19:30:31 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 29 Oct 2003 19:31:10 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9U3UU25002052 for ; Wed, 29 Oct 2003 19:30:30 -0800 Received: from flecktone.americas.sgi.com ([192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h9U3UPq0027638 for ; Wed, 29 Oct 2003 19:30:25 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h9U3UJP512781295; Wed, 29 Oct 2003 21:30:19 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h9U3UJK24602882; Wed, 29 Oct 2003 21:30:19 -0600 (CST) Date: Wed, 29 Oct 2003 21:30:19 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Norman Zhang cc: linux-xfs@oss.sgi.com Subject: Re: Samba on XFS Freezes In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 859 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 713 Lines: 20 On Wed, 29 Oct 2003, Norman Zhang wrote: > > Sounds a bit like IRQ sharing. You can try freeing up those by > > switching off things like serial and parallel ports. I'm in the camp that doesn't think irqs are the problem. :) > conclusive. The XFS partitions would disappear from Samba shares. If I tried > to unmount it, system says it is busy. May I ask how do I force XFS fsck > equivalent on XFS paritions? Is it safe? cleanly unmount* the filesystem, then point xfs_check and xfs_repair at it. xfs_repair -n will do a preliminary check without actually doing any modifications. *if you can't unmount it and have to whack the box to unbusy it, just do a quick mount/umount before you run repair. -Eric From owner-linux-xfs@oss.sgi.com Wed Oct 29 20:16:11 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 29 Oct 2003 20:16:50 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9U4G825005289 for ; Wed, 29 Oct 2003 20:16:11 -0800 Received: from stout.americas.sgi.com ([128.162.232.50]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h9U4G3q0000325 for ; Wed, 29 Oct 2003 20:16:03 -0800 Received: from stout.americas.sgi.com (localhost [127.0.0.1]) by stout.americas.sgi.com (8.12.8/8.12.8) with ESMTP id h9U4G1BS005950; Wed, 29 Oct 2003 22:16:02 -0600 Received: (from sandeen@localhost) by stout.americas.sgi.com (8.12.8/8.12.8/Submit) id h9U4G18S005948; Wed, 29 Oct 2003 22:16:01 -0600 Date: Wed, 29 Oct 2003 22:16:01 -0600 From: Eric Sandeen Message-Id: <200310300416.h9U4G18S005948@stout.americas.sgi.com> Subject: TAKE 884392 - Add a stack trace to _xfs_force_shutdown. X-archive-position: 860 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@stout.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 723 Lines: 25 Add a stack trace to _xfs_force_shutdown. modinfo got messed up, merge of: mod grove2:irix:143518a header =============================== - grove2:irix:143518a 04/03/03 - PV Incidents affected: 884392 - Inspected by: cwf@sgi.com - Files affected: kern/fs/xfs/xfs_rw.c 1.318 - Author: overby - kern/fs/xfs/xfs_rw.c: Add a stack trace to _xfs_force_shutdown. It is turned off by default, but can be turned on with xfs_error_level Date: Wed Oct 29 20:11:45 PST 2003 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:160899a linux/fs/xfs/xfs_rw.c - 1.386 From owner-linux-xfs@oss.sgi.com Wed Oct 29 20:26:26 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 29 Oct 2003 20:26:58 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9U4QQ25008450 for ; Wed, 29 Oct 2003 20:26:26 -0800 Received: from stout.americas.sgi.com ([128.162.232.50]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h9U4QKq0001597 for ; Wed, 29 Oct 2003 20:26:20 -0800 Received: from stout.americas.sgi.com (localhost [127.0.0.1]) by stout.americas.sgi.com (8.12.8/8.12.8) with ESMTP id h9U4QJBS006048; Wed, 29 Oct 2003 22:26:19 -0600 Received: (from sandeen@localhost) by stout.americas.sgi.com (8.12.8/8.12.8/Submit) id h9U4QJqR006046; Wed, 29 Oct 2003 22:26:19 -0600 Date: Wed, 29 Oct 2003 22:26:19 -0600 From: Eric Sandeen Message-Id: <200310300426.h9U4QJqR006046@stout.americas.sgi.com> Subject: PARTIAL TAKE 893355 - Fix test for large sector_t X-archive-position: 861 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@stout.americas.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 467 Lines: 16 Fix test for large sector_t when finding max file offset Date: Wed Oct 29 20:25:27 PST 2003 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:160900a linux/fs/xfs/linux/xfs_super.c - 1.274 - Test CONFIG_LBD (large sector_t turned on) not HAVE_SECTOR_T (LBD patch present) when determining max file offset. From owner-linux-xfs@oss.sgi.com Wed Oct 29 20:36:19 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 29 Oct 2003 20:36:52 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9U4aJ25009223 for ; Wed, 29 Oct 2003 20:36:19 -0800 Received: from bruce.melbourne.sgi.com (bruce.melbourne.sgi.com [134.14.54.176]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h9U4aCq0002713 for ; Wed, 29 Oct 2003 20:36:13 -0800 Received: from bruce.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by bruce.melbourne.sgi.com (8.12.8/8.12.8) with ESMTP id h9U4Xm5k030237; Thu, 30 Oct 2003 15:33:48 +1100 Received: (from nathans@localhost) by bruce.melbourne.sgi.com (8.12.8/8.12.8/Submit) id h9U4XmtZ030236; Thu, 30 Oct 2003 15:33:48 +1100 Date: Thu, 30 Oct 2003 15:33:48 +1100 From: Nathan Scott Message-Id: <200310300433.h9U4XmtZ030236@bruce.melbourne.sgi.com> Subject: TAKE 902933 - pagebuf locking fix X-archive-position: 862 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@bruce.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 411 Lines: 14 Fix a supplemental issue introduced by the last small blocksize locking fix; this would manifest itself as a second unlock_page call on an already unlocked page. Date: Wed Oct 29 20:34:42 PST 2003 Workarea: bruce.melbourne.sgi.com:/build2/clean24 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-linux:slinx:160901a linux/fs/xfs/pagebuf/page_buf.c - 1.138 From owner-linux-xfs@oss.sgi.com Wed Oct 29 20:46:46 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 29 Oct 2003 20:47:19 -0800 (PST) Received: from illusionary.com ([66.152.21.136]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9U4kj25009650 for ; Wed, 29 Oct 2003 20:46:46 -0800 Received: from zorak.illusionary.lan (6532210hfc137.tampabay.rr.com [65.32.210.137]) by illusionary.com (8.12.3/8.12.3/Debian-6.6) with ESMTP id h9U4kc1K028348 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL) for ; Wed, 29 Oct 2003 23:46:39 -0500 Received: from blackbird-wan (blackbird-wan [192.168.10.31]) by zorak.illusionary.lan (8.12.3/8.12.3/Debian-6.6) with ESMTP id h9U4kba4009296 for ; Wed, 29 Oct 2003 23:46:38 -0500 Subject: Re: TAKE 884392 - Add a stack trace to _xfs_force_shutdown. From: Derek Glidden To: linux-xfs@oss.sgi.com In-Reply-To: <200310300416.h9U4G18S005948@stout.americas.sgi.com> References: <200310300416.h9U4G18S005948@stout.americas.sgi.com> Content-Type: text/plain Organization: Message-Id: <1067489198.5605.2.camel@blackbird.illusionary.lan> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 29 Oct 2003 23:46:38 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 863 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dglidden@illusionary.com Precedence: bulk X-list: linux-xfs Content-Length: 727 Lines: 21 On Wed, 2003-10-29 at 23:16, Eric Sandeen wrote: > Add a stack trace to _xfs_force_shutdown. > Ooh! Does this mean if I try putting XFS on the big software RAID5 box I was trying to build, I might get some useful information if it xfs_force_shutdowns again instead of the totally useless to any kind of asking for help "just freezes"? If so, hurrah! -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- "We all enter this world in the | Support Electronic Freedom same way: naked; screaming; soaked | http://www.eff.org/ in blood. But if you live your | http://www.anti-dmca.org/ life right, that kind of thing |--------------------------- doesn't have to stop there." -- Dana Gould From owner-linux-xfs@oss.sgi.com Wed Oct 29 21:33:06 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 29 Oct 2003 21:33:44 -0800 (PST) Received: from tolkor.sgi.com (tolkor.SGI.COM [198.149.18.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9U5X625011042 for ; Wed, 29 Oct 2003 21:33:06 -0800 Received: from flecktone.americas.sgi.com ([192.48.203.135]) by tolkor.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h9U5q6Hc013261 for ; Wed, 29 Oct 2003 23:52:06 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h9U5X0P512849010; Wed, 29 Oct 2003 23:33:00 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h9U5X0K24662432; Wed, 29 Oct 2003 23:33:00 -0600 (CST) Date: Wed, 29 Oct 2003 23:33:00 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Derek Glidden cc: linux-xfs@oss.sgi.com Subject: Re: TAKE 884392 - Add a stack trace to _xfs_force_shutdown. In-Reply-To: <1067489198.5605.2.camel@blackbird.illusionary.lan> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 864 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 481 Lines: 17 In theory... :) Set /proc/sys/fs/xfs/error_level to 5 or higher to turn it on. -Eric On 29 Oct 2003, Derek Glidden wrote: > On Wed, 2003-10-29 at 23:16, Eric Sandeen wrote: > > Add a stack trace to _xfs_force_shutdown. > > > > Ooh! Does this mean if I try putting XFS on the big software RAID5 box > I was trying to build, I might get some useful information if it > xfs_force_shutdowns again instead of the totally useless to any kind of > asking for help "just freezes"? From owner-linux-xfs@oss.sgi.com Thu Oct 30 01:10:13 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 30 Oct 2003 01:10:51 -0800 (PST) Received: from kerberos.suse.cz (kerberos.suse.cz [195.47.106.10]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9U9A225022138 for ; Thu, 30 Oct 2003 01:10:03 -0800 Received: from chimera.suse.cz (chimera.suse.cz [10.20.0.2]) by kerberos.suse.cz (****** SuSE CR *******) with ESMTP id 9434A4FB7C; Thu, 30 Oct 2003 09:31:50 +0100 (MET) Received: from alienAngel.upjs.sk (test12.suse.cz [10.20.3.140]) by chimera.suse.cz (Postfix) with ESMTP id 963554538; Thu, 30 Oct 2003 09:31:46 +0100 (CET) Received: from localhost (ja@localhost) by alienAngel.upjs.sk (8.12.10/8.12.6/Submit) with ESMTP id h9U8YpuA007549; Thu, 30 Oct 2003 09:34:51 +0100 X-Authentication-Warning: alienAngel.home.sk: ja owned process doing -bs Date: Thu, 30 Oct 2003 09:34:51 +0100 (CET) From: Jan Derfinak X-X-Sender: ja@alienAngel.home.sk To: Nathan Scott Cc: linux-xfs@oss.sgi.com Subject: Re: TAKE - 2.6.0-test9 In-Reply-To: <200310270006.h9R06QCj4307564@snort.melbourne.sgi.com> Message-ID: References: <200310270006.h9R06QCj4307564@snort.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 865 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ja@mail.upjs.sk Precedence: bulk X-list: linux-xfs Content-Length: 339 Lines: 19 On Mon, 27 Oct 2003, Nathan Scott wrote: Hi. > Merge up to 2.6.0-test9. > > Date: Sun Oct 26 16:03:34 PST 2003 > Workarea: snort.melbourne.sgi.com:/home/nathans/clean-2.5.x-xfs > > The following file(s) were checked into: > bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Why these changes aren't visible in public CVS? jan -- From owner-linux-xfs@oss.sgi.com Thu Oct 30 01:30:25 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 30 Oct 2003 01:31:04 -0800 (PST) Received: from ncircle.nullnet.fi (ncircle.nullnet.fi [62.236.96.207]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9U9U125022711 for ; Thu, 30 Oct 2003 01:30:23 -0800 Received: from ncircle.nullnet.fi (localhost.localdomain [127.0.0.1]) by ncircle.nullnet.fi (Postfix) with SMTP id 216041CEC860 for ; Thu, 30 Oct 2003 11:29:59 +0200 (EET) Received: from cacher2-ext.wise.edt.ericsson.se ([194.237.142.13]) (SquirrelMail authenticated user tomimo) by ncircle.nullnet.fi with HTTP; Thu, 30 Oct 2003 11:29:59 +0200 (EET) Message-ID: <31452.194.237.142.13.1067506199.squirrel@ncircle.nullnet.fi> Date: Thu, 30 Oct 2003 11:29:59 +0200 (EET) Subject: What happened to bitkeeper repository ? From: "Tomi Orava" To: linux-xfs@oss.sgi.com User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h9U9UP25022717 X-archive-position: 866 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tomimo+linux-xfs@ncircle.nullnet.fi Precedence: bulk X-list: linux-xfs Content-Length: 246 Lines: 13 I haven't seen any comments on the list about the current status of bitkeeper repository for linux-2.4+xfs kernels (at xfs.org:8090) ... Has the service been discontinued for good or has it been relocated to somewhere ? Regards, Tomi Orava From owner-linux-xfs@oss.sgi.com Thu Oct 30 03:09:36 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 30 Oct 2003 03:09:49 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10) with ESMTP id h9UB9a25027775 for ; Thu, 30 Oct 2003 03:09:36 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id h9UB9asX027774 for linux-xfs@oss.sgi.com; Thu, 30 Oct 2003 03:09:36 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10) with ESMTP id h9UB9Y27027760 for ; Thu, 30 Oct 2003 03:09:35 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id h9UAUJt4025572; Thu, 30 Oct 2003 02:30:19 -0800 Date: Thu, 30 Oct 2003 02:30:19 -0800 Message-Id: <200310301030.h9UAUJt4025572@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 202] XFS data corruption (very old bug!!!) X-Bugzilla-Reason: AssignedTo X-archive-position: 867 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1765 Lines: 70 http://oss.sgi.com/bugzilla/show_bug.cgi?id=202 eumaster@mail.ru changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|critical |blocker Summary|XFS data corruption |XFS data corruption (very | |old bug!!!) ------- Additional Comments From eumaster@mail.ru 2003-30-10 02:30 PDT ------- Today I have got this bug!!! On clear host: I did: Power on login > sync > nice ls -R / > cp /etc/X11/Xmodmap /tmp/Xmodmap > vi /tmp/Xmodmap change one strings :w! donn't quit POWER OFF result: ================================ > od -c /tmp/Xmodmap 0000000 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0001560 \0 0001561 ================================ >ls -l /etc/X11/Xmodmap /tmp/Xmodmap -r--r--r-- 1 root root 881 Mar 17 2003 /etc/X11/Xmodmap -r--r--r-- 1 eu root 881 Oct 30 03:39 /tmp/Xmodmap ================================ My system: Compaq Proliant DL320 Attached scsi disk sda at scsi0, channel 0, id 0, lun 0 sym0:0: FAST-40 WIDE SCSI 80.0 MB/s ST (25.0 ns, offset 31) SCSI device sda: 35565080 512-byte hdwr sectors (18209 MB) SGI XFS 1.2.0 with ACLs, DMAPI, realtime, quota, no debug enabled OS: Suse Linux 8.2 First time I got this bug about 7 years before in Irix 5.3 XFS on my mail box (in /var/mail/...). It still exists in Irix 6.5.x. Linux version 2.4.20-4GB (root@Pentium.suse.de) (gcc version 3.3 20030226 (prerelease) (SuSE Linux)) #1 Mon Mar 17 17:54:44 UTC 2003 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Oct 30 07:09:37 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 30 Oct 2003 07:09:55 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10) with ESMTP id h9UF9b25003463 for ; Thu, 30 Oct 2003 07:09:37 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id h9UF9bp4003462 for linux-xfs@oss.sgi.com; Thu, 30 Oct 2003 07:09:37 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10) with ESMTP id h9UF9Z27003447 for ; Thu, 30 Oct 2003 07:09:35 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id h9UEGWwn002957; Thu, 30 Oct 2003 06:16:32 -0800 Date: Thu, 30 Oct 2003 06:16:32 -0800 Message-Id: <200310301416.h9UEGWwn002957@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 202] XFS data corruption (very old bug!!!) X-Bugzilla-Reason: AssignedTo X-archive-position: 868 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 675 Lines: 22 http://oss.sgi.com/bugzilla/show_bug.cgi?id=202 ------- Additional Comments From sandeen@sgi.com 2003-30-10 06:16 PDT ------- XFS 1.2.0 is pretty old by now. Please try this with an XFS 1.3.1 kernel, or even CVS. Changes have been made to how data gets synced out. On the other hand, you are abusing the system here a bit - writes are buffered, and if you do :w! you almost certainly -will- lose data. You may well have copied & modified the new file before anything ever got a chance to sync to disk. And that's not really a bug. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Oct 30 08:28:31 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 30 Oct 2003 08:29:11 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9UGSV25019277 for ; Thu, 30 Oct 2003 08:28:31 -0800 Received: from flecktone.americas.sgi.com ([192.48.203.135]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h9UEXYOO011375 for ; Thu, 30 Oct 2003 06:33:34 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h9UGSFP512870753; Thu, 30 Oct 2003 10:28:15 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h9UGSEK14679990; Thu, 30 Oct 2003 10:28:14 -0600 (CST) Subject: Re: TAKE 884392 - Add a stack trace to _xfs_force_shutdown. From: Eric Sandeen To: Derek Glidden Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Organization: Message-Id: <1067531294.7631.5.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 30 Oct 2003 10:28:14 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 869 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 502 Lines: 19 I should amend that a little, Glen points out that this only works if the shutdown is an 'in memory corruption' type. It would be trivial for you to move it in your code to hit any shutdown... we may do something similar. -Eric On Wed, 2003-10-29 at 23:33, Eric Sandeen wrote: > In theory... :) > > Set /proc/sys/fs/xfs/error_level to 5 or higher to turn it on. > > -Eric -- Eric Sandeen [C]XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Thu Oct 30 08:35:27 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 30 Oct 2003 08:36:02 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9UGZO25019695 for ; Thu, 30 Oct 2003 08:35:24 -0800 Received: from flecktone.americas.sgi.com ([192.48.203.135]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h9UEeROO012210 for ; Thu, 30 Oct 2003 06:40:27 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h9UGZDP512878330; Thu, 30 Oct 2003 10:35:14 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h9UGZCK14698824; Thu, 30 Oct 2003 10:35:13 -0600 (CST) Subject: Re: Linux 2.4.22 XFS 1.3.1 reservation ran out From: Eric Sandeen To: Soumen Chakrabarti Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Organization: Message-Id: <1067531712.7631.16.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 30 Oct 2003 10:35:12 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 870 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1374 Lines: 45 We have not been able to hit this internally yet. If those who can hit it could try these things: Use the latest CVS code, or apply this patch: --- linux/fs/xfs/xfs_rw.c_1.385 2003-10-30 10:33:20.000000000 -0600 +++ linux/fs/xfs/xfs_rw.c 2003-10-30 10:33:20.000000000 -0600 @@ -153,6 +153,9 @@ xfs_cmn_err(XFS_PTAG_SHUTDOWN_CORRUPT, CE_ALERT, mp, "Corruption of in-memory data detected. Shutting down filesystem: %s", mp->m_fsname); + if (XFS_ERRLEVEL_HIGH <= xfs_error_level) { + xfs_stack_trace(); + } } else if (!(flags & XFS_FORCE_UMOUNT)) { if (logerror) { xfs_cmn_err(XFS_PTAG_SHUTDOWN_LOGERROR, CE_ALERT, mp, and echo 5 > /proc/sys/fs/xfs/error_level This should cause a stack trace to be dumped when the filesystem shuts down. Alternately (or additionally) echo 2 > /proc/sys/fs/xfs/panic_mask and this should cause the system to panic when it hits this log reservation problem, which should also dump the stack. Also, I will open a bugzilla bug for this, if the people who have hit this could do a brain-dump to the bug, that will keep all the info in one place. Thanks, -Eric -- Eric Sandeen [C]XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Thu Oct 30 09:09:38 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 30 Oct 2003 09:10:01 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10) with ESMTP id h9UH9c25021100 for ; Thu, 30 Oct 2003 09:09:38 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id h9UH9ccx021099 for linux-xfs@oss.sgi.com; Thu, 30 Oct 2003 09:09:38 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10) with ESMTP id h9UH9Z27021085 for ; Thu, 30 Oct 2003 09:09:35 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id h9UGoG8c020359; Thu, 30 Oct 2003 08:50:16 -0800 Date: Thu, 30 Oct 2003 08:50:16 -0800 Message-Id: <200310301650.h9UGoG8c020359@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 284] New: Log reservation runs out with bonnie++ X-Bugzilla-Reason: AssignedTo X-archive-position: 871 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 4841 Lines: 129 http://oss.sgi.com/bugzilla/show_bug.cgi?id=284 Summary: Log reservation runs out with bonnie++ Product: Linux XFS Version: Current Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: High Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: sandeen@sgi.com Soumen Chakrabarti reports: Repeatable bug, here's how to create the situation: 1. Start with a fresh install of stock RedHat 9. 2. Download kernel 2.4.22. 3. Patch in XFS 1.3.1 and build new kernel. 4. Create an XFS file system and mount it on (say) /mnt/xfs. 5. Download and build bonnie++-1.03a 6. Run bonnie++ with these flags bonnie++ -d /mnt/xfs -u 0:0 -s 0 -n 16 Everything goes fine. This is a test that creates, stats, and deletes 16*1024 empty files. 7. Now up the number of files to 500*1024 bonnie++ -d /mnt/xfs -u 0:0 -s 0 -n 500 Here are the syslog entries. Filesystem "sd(8,17)": xfs_log_write: reservation ran out. Need to up reservation xfs_force_shutdown(sd(8,17),0x8) called from line 1739 of file xfs_log.c. Return address = 0xc01f4cdb Filesystem "sd(8,17)": Corruption of in-memory data detected. Shutting down filesystem: sd(8,17) Please umount the filesystem, and rectify the problem(s) xfs_force_shutdown(sd(8,17),0x2) called from line 747 of file xfs_log.c. Return address = 0xc01f4cdb 8. You can however recover and mount again: umount /mnt/xfs mount /dev/sdb1 /mnt/xfs XFS mounting filesystem sd(8,17) Starting XFS recovery on filesystem: sd(8,17) (dev: 8/17) Ending XFS recovery on filesystem: sd(8,17) (dev: 8/17) Other info: Not specific to hardware, has been reproduced on two different servers, one with SCSI, the other with SCSI RAID. On these same servers, 9. IBM JFS with this bonnie++ benchmark requires a hard reset. 10. Reiserfs survives repeated bonnie++ tests as above. Also, on a third server we have XFS 1.2.0 which works fine too. So XFS 1.3.1 seems heavily implicated. Thanks for any patches and/or fixes. Christian Guggenberger further reports: I also can verify this forced shutdown here on a debian/woody box (PIII, IDE) with XFS CVS of 20031015. After umount/mount, the forced shutdown occures again, if I try to delete the directory created by bonnie++. An xfs_repair after umount/mount/umount fixes this. However, with plain 2.4.21 + xfs-1.3.1 the bonnie++-tests complete without any errors. The forced_shutdown occures during bonnie's "deleting files in random order". It's 100% reproducible with xfs CVS of 20031015 (and NOT with 2.4.21-xfs-1.3.1). Here's the output of xfs_info: output of xfs_info: meta-data=/mnt/testxfs isize=256 agcount=11, agsize=262144 blks = sectsz=512 data = bsize=4096 blocks=2725017, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=1200, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 512 MB RAM. xfsprogs-2.3.11. no special options either at mkfs-time or at mount-time. as an update, I re-ran the described bonnie test (using 400 instead of 500). This time IO-error happens while deleting in sequential order. Here's the logs: bonnie77:~# bonnie++ -d /mnt/testxfs -u 0:0 -s 0 -n 400 Using uid:0, gid:0. Create files in sequential order...done. Stat files in sequential order...done. Delete files in sequential order...Can't delete file 0403455YEZdqfASG Cleaning up test directory after error. Bonnie: drastic I/O error (rmdir): Input/output error Filesystem "ide0(3,6)": xfs_log_write: reservation ran out. Need to up reservation xfs_force_shutdown(ide0(3,6),0x8) called from line 1739 of file xfs_log.c. Return address = 0xe091484a Filesystem "ide0(3,6)": Corruption of in-memory data detected. Shutting down filesystem: ide0(3,6) Please umount the filesystem, and rectify the problem(s) xfs_force_shutdown(ide0(3,6),0x2) called from line 1321 of file xfs_log.c. Return address = 0xe091484a the saga continues : in first tests, the Bonnie++ testdir was not removable, after the forced_shutdown (after umount/mount, of course) - a xfs_repair was needed. This time (after an xfs_repair, though), all files in the dir could be removed - at least all visible to me. The dir itself not. 'directory not empty' I decided to go ahead with xfsprogs-2.5.11, re-ran xfs_repair, and my empty bonnie++ dir could be removed. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Oct 30 09:32:45 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 30 Oct 2003 09:33:18 -0800 (PST) Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9UHWh25022284 for ; Thu, 30 Oct 2003 09:32:44 -0800 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1AFGf3-0007GV-00 for ; Thu, 30 Oct 2003 18:32:41 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: linux-xfs@oss.sgi.com Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AFGf2-0007GN-00 for ; Thu, 30 Oct 2003 18:32:40 +0100 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 1AFGf2-0004vT-00 for ; Thu, 30 Oct 2003 18:32:40 +0100 From: "Norman Zhang" Subject: Re: Samba on XFS Freezes Date: Thu, 30 Oct 2003 09:32:38 -0800 Message-ID: References: X-Complaints-To: usenet@sea.gmane.org X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-archive-position: 872 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nzhang@arkon-group.com Precedence: bulk X-list: linux-xfs Content-Length: 2345 Lines: 71 Hi, Thanks for your reply. >> Oct 27 09:19:12 smbserver kernel: xfs_force_shutdown(md(9,5),0x8) >> called from line 1039 of file xfs_trans.c. Return address = >> 0xe08ae312 >> Oct 27 09:19:12 smbserver kernel: Corruption of in-memory data >> detected. Shutting down filesystem: md(9,5) >> Oct 27 09:19:12 smbserver kernel: Please umount the filesystem, and >> rectify the problem(s) >> Oct 27 10:36:44 smbserver kernel: PCI: Unable to handle 64-bit >> address space for > > I think the PCI conflicts *might* be a red herring. Note the > timestamps. The xfs shutdown occured an hour before these PCI errors. > >> Oct 27 10:36:44 smbserver kernel: PCI: Unable to handle 64-bit >> address space for > > But out of curiosity, did you accidentally clip this line > cutting-and-pasting? "address space for"... what? I copied the /var/log/errors exactly as is. It does seem the value of the address space is missing. How can I make kernel to be more verbatim in its logs? >> Oct 27 10:36:44 smbserver kernel: Unknown bridge resource 2: >> assuming transparent >> Oct 27 10:36:44 smbserver kernel: PCI: Device 00:1f.1 not available >> because of resource collisions > > Without knowing more about your hardware I'm not going to take a > guess at the root cause of these messages. PCI-PCI bridges generally > "just work" these days. Again, I don't see a direct corrolation > between this and the xfs_force_shutdown. I'm using Intel SE7500WV2 Server Board. May I ask what additional information should I provide? >> conclusive. The XFS partitions would disappear from Samba shares. If >> I tried > > Did I miss a message stating what kernel and XFS revision is involved? I can't seem to be able to find the XFS revision included in my kernel. May I ask how can I dig out that information? # dmesg | grep XFS SGI XFS with ACLs, DMAPI, realtime, quota, no debug enabled XFS mounting filesystem md(9,4) XFS mounting filesystem md(9,1) XFS mounting filesystem md(9,5) XFS mounting filesystem md(9,7) XFS mounting filesystem md(9,0) XFS mounting filesystem md(9,6) XFS mounting filesystem md(9,3) XFS mounting filesystem md(9,2) # uname -r 2.4.19-35mdksmp # more /proc/version Linux version 2.4.19-35mdksmp (qateam@updates.mandrakesoft.com) (gcc version 3.2 (Mandrake Linux 9.0 3.2-1mdk)) #1 SMP Wed Jul 9 10:54:20 MDT 2003 Regards, Norman From owner-linux-xfs@oss.sgi.com Thu Oct 30 14:09:38 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 30 Oct 2003 14:09:43 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10) with ESMTP id h9UM9c25012497 for ; Thu, 30 Oct 2003 14:09:38 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id h9UM9cjo012496 for linux-xfs@oss.sgi.com; Thu, 30 Oct 2003 14:09:38 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10) with ESMTP id h9UM9a27012482 for ; Thu, 30 Oct 2003 14:09:36 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id h9ULFee1000438; Thu, 30 Oct 2003 13:15:40 -0800 Date: Thu, 30 Oct 2003 13:15:40 -0800 Message-Id: <200310302115.h9ULFee1000438@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 284] Log reservation runs out with bonnie++ X-Bugzilla-Reason: AssignedTo X-archive-position: 873 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1412 Lines: 33 http://oss.sgi.com/bugzilla/show_bug.cgi?id=284 ------- Additional Comments From christian.guggenberger@physik.uni-regensburg.de 2003-30-10 13:15 PDT ------- Tried again with latest cvs code, and set /proc/sys/fs/xfs/error_level to 5. Here's the logs: Ending clean XFS mount for filesystem: ide0(3,6) Filesystem "ide0(3,6)": xfs_log_write: reservation ran out. Need to up reservation xfs_force_shutdown(ide0(3,6),0x8) called from line 1715 of file xfs_log.c. Return address = 0xe0914a1a Filesystem "ide0(3,6)": Corruption of in-memory data detected. Shutting down filesystem: ide0(3,6) c37e7d6c e0908522 00000015 d901a000 00000005 00004ca4 e0914a1a d901a000 00000008 e091fc40 000006b3 e08f2757 d901a000 00000008 e091fc40 000006b3 00000002 00000001 d901a000 e091fe20 00000015 d901a000 00000005 dcb8e4a0 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Please umount the filesystem, and rectify the problem(s) xfs_force_shutdown(ide0(3,6),0x2) called from line 723 of file xfs_log.c. Return address = 0xe0914a1a ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Oct 30 14:21:57 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 30 Oct 2003 14:22:37 -0800 (PST) Received: from zok.sgi.com (zok.SGI.COM [204.94.215.101]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9UMLt25012987 for ; Thu, 30 Oct 2003 14:21:57 -0800 Received: from larry.melbourne.sgi.com ([134.14.52.130]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id h9UMLmq0000507 for ; Thu, 30 Oct 2003 14:21:49 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA12609; Fri, 31 Oct 2003 09:21:46 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id h9UMLjUc1008549; Fri, 31 Oct 2003 09:21:46 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id h9ULIkbr001008; Fri, 31 Oct 2003 08:18:46 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id h9ULIjMK001006; Fri, 31 Oct 2003 08:18:45 +1100 Date: Fri, 31 Oct 2003 08:18:45 +1100 From: Nathan Scott To: Jan Derfinak Cc: linux-xfs@oss.sgi.com Subject: Re: TAKE - 2.6.0-test9 Message-ID: <20031030211845.GA997@frodo> References: <200310270006.h9R06QCj4307564@snort.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i X-archive-position: 874 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 623 Lines: 27 On Thu, Oct 30, 2003 at 09:34:51AM +0100, Jan Derfinak wrote: > On Mon, 27 Oct 2003, Nathan Scott wrote: > > Hi. Hi Jan, > > Merge up to 2.6.0-test9. > > > > Date: Sun Oct 26 16:03:34 PST 2003 > > Workarea: snort.melbourne.sgi.com:/home/nathans/clean-2.5.x-xfs > > > > The following file(s) were checked into: > > bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs > > Why these changes aren't visible in public CVS? > It is there, I just did a cvs checkout and got it. This tree is now called linux-2.6-xfs on oss, although its still called 2.5.x-xfs in out internal tree (as you can see above). cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Fri Oct 31 00:22:30 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 31 Oct 2003 00:23:10 -0800 (PST) Received: from kerberos.suse.cz (kerberos.suse.cz [195.47.106.10]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9V8MR25022443 for ; Fri, 31 Oct 2003 00:22:30 -0800 Received: from chimera.suse.cz (chimera.suse.cz [10.20.0.2]) by kerberos.suse.cz (****** SuSE CR *******) with ESMTP id D3A3E4FB8A; Fri, 31 Oct 2003 09:22:20 +0100 (MET) Received: from alienAngel.upjs.sk (test12.suse.cz [10.20.3.140]) by chimera.suse.cz (Postfix) with ESMTP id 3B9144FAA; Fri, 31 Oct 2003 09:22:20 +0100 (CET) Received: from localhost (ja@localhost) by alienAngel.upjs.sk (8.12.10/8.12.6/Submit) with ESMTP id h9V8Oxr9001521; Fri, 31 Oct 2003 09:24:59 +0100 X-Authentication-Warning: alienAngel.home.sk: ja owned process doing -bs Date: Fri, 31 Oct 2003 09:24:58 +0100 (CET) From: Jan Derfinak X-X-Sender: ja@alienAngel.home.sk To: Nathan Scott Cc: linux-xfs@oss.sgi.com Subject: Re: TAKE - 2.6.0-test9 In-Reply-To: <20031030211845.GA997@frodo> Message-ID: References: <200310270006.h9R06QCj4307564@snort.melbourne.sgi.com> <20031030211845.GA997@frodo> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 875 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ja@mail.upjs.sk Precedence: bulk X-list: linux-xfs Content-Length: 933 Lines: 33 On Fri, 31 Oct 2003, Nathan Scott wrote: > On Thu, Oct 30, 2003 at 09:34:51AM +0100, Jan Derfinak wrote: > > On Mon, 27 Oct 2003, Nathan Scott wrote: > > > > Hi. > > Hi Jan, > > > > Merge up to 2.6.0-test9. > > > > > > Date: Sun Oct 26 16:03:34 PST 2003 > > > Workarea: snort.melbourne.sgi.com:/home/nathans/clean-2.5.x-xfs > > > > > > The following file(s) were checked into: > > > bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs > > > > Why these changes aren't visible in public CVS? > > > > It is there, I just did a cvs checkout and got it. This tree > is now called linux-2.6-xfs on oss, although its still called > 2.5.x-xfs in out internal tree (as you can see above). Now is there. I updated my cvs 12 hours ago. But in time of writing my e-mail there was no change in 2.4, 2.6 nor xfs-commands. It was 4 days after your TAKE so it was weird for me. I checked web cvs too, it was without change too. jan -- From owner-linux-xfs@oss.sgi.com Fri Oct 31 07:21:58 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 31 Oct 2003 07:22:38 -0800 (PST) Received: from rj.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9VFLv25004095 for ; Fri, 31 Oct 2003 07:21:58 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id h9VDR1OO012916 for ; Fri, 31 Oct 2003 05:27:04 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.9/generic_config-1.2) with ESMTP id h9VFLlP512829075; Fri, 31 Oct 2003 09:21:47 -0600 (CST) Received: from naboo (naboo.americas.sgi.com [128.162.233.73]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id h9VFLfRn305489486; Fri, 31 Oct 2003 09:21:47 -0600 (CST) Subject: Re: What happened to bitkeeper repository ? From: Russell Cattelan To: Tomi Orava Cc: linux-xfs@oss.sgi.com In-Reply-To: <31452.194.237.142.13.1067506199.squirrel@ncircle.nullnet.fi> References: <31452.194.237.142.13.1067506199.squirrel@ncircle.nullnet.fi> Content-Type: text/plain Message-Id: <1067613686.4242.6.camel@naboo> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4-9mdk Date: Fri, 31 Oct 2003 09:21:26 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 876 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cattelan@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 379 Lines: 19 On Thu, 2003-10-30 at 03:29, Tomi Orava wrote: > I haven't seen any comments on the list > about the current status of bitkeeper repository > for linux-2.4+xfs kernels (at xfs.org:8090) ... All up to day as of 2 days ago. > > Has the service been discontinued for good or > has it been relocated to somewhere ? Will continue as before > - > > Regards, > Tomi Orava > > > From owner-linux-xfs@oss.sgi.com Fri Oct 31 10:25:32 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 31 Oct 2003 10:26:05 -0800 (PST) Received: from mailgate.Cadence.COM (mailgate.Cadence.COM [158.140.2.1]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9VIPV25016897 for ; Fri, 31 Oct 2003 10:25:32 -0800 Received: from mail.get2chip.com (mh.get2chip.com [192.168.1.5]) by mailgate.Cadence.COM (8.9.3/8.9.3) with ESMTP id KAA12921 for ; Fri, 31 Oct 2003 10:25:30 -0800 (PST) Received: from citrix1 ([192.168.1.92]) by mail.get2chip.com (8.11.6/8.11.6) with ESMTP id h9VIPUL11749 for ; Fri, 31 Oct 2003 10:25:30 -0800 Subject: Issues with XFS From: Chris Croswhite Reply-To: csc@cadence.com To: linux-xfs@oss.sgi.com Content-Type: text/plain Organization: RC - Cadence Design Systems Message-Id: <1067624710.3529.54.camel@chrisc.laptop> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Fri, 31 Oct 2003 18:25:10 +0000 Content-Transfer-Encoding: 7bit X-Received: By mailgate.Cadence.COM as KAA12921 at Fri Oct 31 10:25:30 2003 X-archive-position: 877 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: csc@cadence.com Precedence: bulk X-list: linux-xfs Content-Length: 939 Lines: 24 Has anyone seen this behavior?: Compiling source soucer code for another application, I realized that I did not configure correctly. So I removed the src dir and untar'ed the soruces again in the exact same directory. I than proceed to change the configure and recompiled the source. However, I got the exact same code size for libs and exectuable. So I tried the process over again, erased the original source code, untar'ed to the same dir, configured and then compiled again. But yet again I got the exact same exectuable and lib sizes which did not make sense. Figuring something was up, I moved the source to a different name and untar'ed again the original source, configured, and compiled, this time I got the correct result, a binary that had debugging information and libraries that were different (and correct). So my question, why did I see this!?!?! kernel 2.4.20 with aa patches (includes XFS support). TIA, Chris From owner-linux-xfs@oss.sgi.com Fri Oct 31 10:44:47 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 31 Oct 2003 10:45:27 -0800 (PST) Received: from localhost.localdomain (host-65-120-145-91.coremetrics.com [65.120.145.91] (may be forged)) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9VIik25017436 for ; Fri, 31 Oct 2003 10:44:47 -0800 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id h9VIilmB002488 for ; Fri, 31 Oct 2003 12:44:47 -0600 Received: (from austin@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id h9VIilax002486 for linux-xfs@oss.sgi.com; Fri, 31 Oct 2003 12:44:47 -0600 X-Authentication-Warning: localhost.localdomain: austin set sender to austin@coremetrics.com using -f Subject: Kernel Crash from 2.4.20-20.9-XFS1.3.1 From: Austin Gonyou To: XFS List Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1067625885.2110.5.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Fri, 31 Oct 2003 12:44:46 -0600 X-archive-position: 878 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: austin@coremetrics.com Precedence: bulk X-list: linux-xfs Content-Length: 2815 Lines: 75 We had a crash at about 4AM this morning. It's a Dell 6650 with 8GB RAM, 2 QLA2200 HBAs usint 6.06.10 driver, and 2.4.20-20.9.XFS1.3.1 SMP. Here is my ksymoops output and the dump. I don't know if it's related to XFS, but I wanted to post and ask since we're using the kernel from SGI's site. We're not too sure why this may have occurred If anyone can aid in shedding light to help us be more sure that XFS is not the cause here, then that will help narrow the possibilities. Unfortunately, I'm missing like the first 3 lines of the oops I think, but aside from that, all the symbols are there. That's all there was on the screen, and nothing in the logs. On a side note, anyone got an RHAS 3 kernel with XFS patches? ;) TIA. EIP: 0060:[] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010007 eax: 000008c ebx: ffffffd4 ecx: c03646a8 edx: c03646ac esi: c0364680 edi: f4c9a000 ebp: f4c9be7c esp: f4c9be5c ds: 0068 es: 0068 ss: 0068 Process oracle (pid: 3334, stackpage=f4c9b000) Stack: f4c9be68 c0124d3a f6405a18 f6405a74 f6405a74 f4c9a000 c1f2e238 c881c574 f4c9be88 c01377a9 c1f2e238 00000000 f4c9a000 c881c578 c881c578 f5b4b820 c1f2e238 f4b4b8d4 00042bc4 c01383f1 c1f2e238 00042bc4 f5b4b820 c1f2e238 Call Trace: [] (0xf4c9be60)) [] (0xf4c9be80)) [] (0xf4c9bea8)) [] (0xf4c9bed4)) [] (0xf4c9bef4)) [] (0xf4c9bf04)) [] (0xf4c9bf30)) [] (0xf4c9bf64)) [] (0xf4c9bf8c)) [] (0xf4c9bfc8)) Code: 8b 53 6c 8b 47 70 85 d2 89 45 f0 0f 84 d7 00 00 00 b8 00 e9 >>EIP; c011a0e9 <===== Trace; c0124d3a <__run_task_queue+6a/80> Trace; c01377a9 <___wait_on_page+99/c0> Trace; c01383f1 Trace; c0138890 Trace; c0138a40 Trace; c0138890 Trace; c01fdd1b Trace; c01f8605 Trace; c014ed7a Trace; c01098bf Code; c011a0e9 00000000 <_EIP>: Code; c011a0e9 <===== 0: 8b 53 6c mov 0x6c(%ebx),%edx <===== Code; c011a0ec 3: 8b 47 70 mov 0x70(%edi),%eax Code; c011a0ef 6: 85 d2 test %edx,%edx Code; c011a0f1 8: 89 45 f0 mov %eax,0xfffffff0(%ebp) Code; c011a0f4 b: 0f 84 d7 00 00 00 je e8 <_EIP+0xe8> c011a1d1 Code; c011a0fa 11: b8 00 e9 00 00 mov $0xe900,%eax -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Fri Oct 31 10:46:36 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 31 Oct 2003 10:47:10 -0800 (PST) Received: from localhost.localdomain (host-65-120-145-91.coremetrics.com [65.120.145.91] (may be forged)) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9VIka25017798 for ; Fri, 31 Oct 2003 10:46:36 -0800 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id h9VIkZmB002624; Fri, 31 Oct 2003 12:46:35 -0600 Received: (from austin@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id h9VIkZEY002618; Fri, 31 Oct 2003 12:46:35 -0600 X-Authentication-Warning: localhost.localdomain: austin set sender to austin@coremetrics.com using -f Subject: Re: Issues with XFS From: Austin Gonyou To: csc@cadence.com Cc: XFS List In-Reply-To: <1067624710.3529.54.camel@chrisc.laptop> References: <1067624710.3529.54.camel@chrisc.laptop> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1067625994.2110.8.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Fri, 31 Oct 2003 12:46:35 -0600 X-archive-position: 879 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: austin@coremetrics.com Precedence: bulk X-list: linux-xfs Content-Length: 1274 Lines: 38 We had similar issues. We had to go back to our old 2.4.10 kernel which still continues to work fine. We also tried 2.4.22, with seemingly no ill effect. Just FYI. On Fri, 2003-10-31 at 12:25, Chris Croswhite wrote: > Has anyone seen this behavior?: > > Compiling source soucer code for another application, I realized that > I > did not configure correctly. So I removed the src dir and untar'ed > the > soruces again in the exact same directory. I than proceed to change > the > configure and recompiled the source. However, I got the exact same > code > size for libs and exectuable. So I tried the process over again, > erased > the original source code, untar'ed to the same dir, configured and > then > compiled again. But yet again I got the exact same exectuable and lib > sizes which did not make sense. > > Figuring something was up, I moved the source to a different name and > untar'ed again the original source, configured, and compiled, this > time > I got the correct result, a binary that had debugging information and > libraries that were different (and correct). > > So my question, why did I see this!?!?! > > kernel 2.4.20 with aa patches (includes XFS support). > > TIA, > Chris -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Fri Oct 31 13:50:39 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 31 Oct 2003 13:51:20 -0800 (PST) Received: from mail.dkp.com (hidden-user@mail.dkp.com [204.191.16.3]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9VLoI25007587 for ; Fri, 31 Oct 2003 13:50:38 -0800 Received: by mail.dkp.com (Postfix, from userid 20001) id 4526E2AD5B; Fri, 31 Oct 2003 16:50:15 -0500 (EST) Received: from wallace.dkp.com (wallace.dkp.com [10.0.0.81]) by mail.dkp.com (Postfix) with ESMTP id C42DD2AD41 for ; Fri, 31 Oct 2003 16:50:14 -0500 (EST) Received: by wallace.dkp.com (Postfix, from userid 168) id EDB116E887; Fri, 31 Oct 2003 16:50:13 -0500 (EST) Date: Fri, 31 Oct 2003 16:50:13 -0500 From: Andrew Klaassen To: linux-xfs@oss.sgi.com Subject: XFS + SMP + Software RAID 5 slow? Message-ID: <20031031215013.GB25822@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.5.4i X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: $Id: Sanitizer.pm,v 1.54 2002/02/15 16:59:07 bre Exp $ X-archive-position: 880 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ak@dkp.com Precedence: bulk X-list: linux-xfs Content-Length: 400 Lines: 11 I've been experiencing *very* slow sustained write ( < .5MB/sec) using 2.4.20-20.9.XFS1.3.1smp on a dual-Xeon box with a 3ware 7506 card in JBOD mode. Software RAID 5. No such problems with Ext3 ( > 20MB/sec sustained write) with the same kernel on the same software RAID 5 device. Obviously there's something very wrong here. Known issue? Any idea what might be causing this? Andrew Klaassen From owner-linux-xfs@oss.sgi.com Fri Oct 31 14:32:23 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 31 Oct 2003 14:33:03 -0800 (PST) Received: from mail.dkp.com (hidden-user@mail.dkp.com [204.191.16.3]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9VMWN25009963 for ; Fri, 31 Oct 2003 14:32:23 -0800 Received: by mail.dkp.com (Postfix, from userid 20001) id 567272B0CD; Fri, 31 Oct 2003 17:32:22 -0500 (EST) Received: from wallace.dkp.com (wallace.dkp.com [10.0.0.81]) by mail.dkp.com (Postfix) with ESMTP id C74192AD9A for ; Fri, 31 Oct 2003 17:32:21 -0500 (EST) Received: by wallace.dkp.com (Postfix, from userid 168) id DCC9A6E887; Fri, 31 Oct 2003 17:32:20 -0500 (EST) Date: Fri, 31 Oct 2003 17:32:20 -0500 From: Andrew Klaassen To: linux-xfs@oss.sgi.com Subject: Re: XFS + SMP + Software RAID 5 slow? Message-ID: <20031031223220.GC25822@dkp.com> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20031031215013.GB25822@dkp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031031215013.GB25822@dkp.com> User-Agent: Mutt/1.5.4i X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: $Id: Sanitizer.pm,v 1.54 2002/02/15 16:59:07 bre Exp $ X-archive-position: 881 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ak@dkp.com Precedence: bulk X-list: linux-xfs Content-Length: 681 Lines: 19 On Fri, Oct 31, 2003 at 04:50:13PM -0500, Andrew Klaassen wrote: > I've been experiencing *very* slow sustained write ( < .5MB/sec) > using 2.4.20-20.9.XFS1.3.1smp on a dual-Xeon box with a 3ware > 7506 card in JBOD mode. Software RAID 5. No such problems with > Ext3 ( > 20MB/sec sustained write) with the same kernel on the > same software RAID 5 device. Obviously there's something very > wrong here. > > Known issue? Any idea what might be causing this? By the way: Using hardware RAID 5 on exactly the same setup, the XFS and EXT3 numbers are virtually identical (~5MB/sec sustained write). Only software RAID 5 seems to cause this great divergence. Andrew Klaassen From owner-linux-xfs@oss.sgi.com Fri Oct 31 14:43:39 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 31 Oct 2003 14:44:12 -0800 (PST) Received: from mail.dkp.com (hidden-user@mail.dkp.com [204.191.16.3]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9VMhc25010444 for ; Fri, 31 Oct 2003 14:43:39 -0800 Received: by mail.dkp.com (Postfix, from userid 20001) id 240E02B0E2; Fri, 31 Oct 2003 17:43:38 -0500 (EST) Received: from wallace.dkp.com (wallace.dkp.com [10.0.0.81]) by mail.dkp.com (Postfix) with ESMTP id 940172B0D1 for ; Fri, 31 Oct 2003 17:43:37 -0500 (EST) Received: by wallace.dkp.com (Postfix, from userid 168) id AA5806E887; Fri, 31 Oct 2003 17:43:36 -0500 (EST) Date: Fri, 31 Oct 2003 17:43:36 -0500 From: Andrew Klaassen To: linux-xfs@oss.sgi.com Subject: Re: XFS + SMP + Software RAID 5 slow? Message-ID: <20031031224336.GD25822@dkp.com> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20031031215013.GB25822@dkp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031031215013.GB25822@dkp.com> User-Agent: Mutt/1.5.4i X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: $Id: Sanitizer.pm,v 1.54 2002/02/15 16:59:07 bre Exp $ X-archive-position: 882 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ak@dkp.com Precedence: bulk X-list: linux-xfs Content-Length: 544 Lines: 17 On Fri, Oct 31, 2003 at 04:50:13PM -0500, Andrew Klaassen wrote: > Obviously there's something very wrong here. Possibly something wrong with how I've set things up, I'll add. I installed Redhat9 from CDs, installed the RH9 XFS tools and SMP kernel from the FTP site, compiled the latest 3ware drivers against the kernel and remade my initrd image. Anything I'm missing from those steps? (The performance problems/symptoms were the same with the 3ware drivers that came compiled with the 2.4.20-20.9.XFS1.3.1smp kernel.) Andrew Klaassen From owner-linux-xfs@oss.sgi.com Fri Oct 31 15:14:53 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 31 Oct 2003 15:15:36 -0800 (PST) Received: from mx-01-bsl.sauter-bc.com (mx-01-bsl.sauter-bc.com [213.173.165.132]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9VNEp25011947 for ; Fri, 31 Oct 2003 15:14:52 -0800 Received: from mailhub.ch.sauter-bc.com (mailhub [10.1.6.26]) by mx-01-bsl.sauter-bc.com (Postfix) with ESMTP id DE7B432C9F; Sat, 1 Nov 2003 00:14:45 +0100 (CET) Received: from av-01.ch.sauter-bc.com (av-01.ch.sauter-bc.com [10.1.6.28]) by mailhub.ch.sauter-bc.com (Postfix) with SMTP id 19F8732CB5; Sat, 1 Nov 2003 00:14:45 +0100 (CET) Received: from mx-05-bsl.ch.sauter-bc.com ([10.1.6.20]) by av-01.ch.sauter-bc.com (SAVSMTP 3.1.2.35) with SMTP id M2003110100144517187 ; Sat, 01 Nov 2003 00:14:45 +0100 Received: from webmail.ch.sauter-bc.com (imap01.ch.sauter-bc.com [10.1.6.25]) by mx-05-bsl.ch.sauter-bc.com (Postfix) with SMTP id 053054E20D; Sat, 1 Nov 2003 00:14:45 +0100 (CET) Received: from 213.173.165.140 (proxying for 157.161.34.15) (SquirrelMail authenticated user mattesim) by imap01.ch.sauter-bc.com with HTTP; Sat, 1 Nov 2003 00:14:45 +0100 (CET) Message-ID: <38213.213.173.165.140.1067642085.squirrel@imap01.ch.sauter-bc.com> In-Reply-To: <20031031223220.GC25822@dkp.com> References: <20031031215013.GB25822@dkp.com> <20031031223220.GC25822@dkp.com> Date: Sat, 1 Nov 2003 00:14:45 +0100 (CET) Subject: Re: XFS + SMP + Software RAID 5 slow? From: "Simon Matter" To: "Andrew Klaassen" Cc: linux-xfs@oss.sgi.com User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id h9VNEr25011966 X-archive-position: 883 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: simon.matter@ch.sauter-bc.com Precedence: bulk X-list: linux-xfs Content-Length: 1063 Lines: 26 > On Fri, Oct 31, 2003 at 04:50:13PM -0500, > Andrew Klaassen wrote: > >> I've been experiencing *very* slow sustained write ( < .5MB/sec) >> using 2.4.20-20.9.XFS1.3.1smp on a dual-Xeon box with a 3ware >> 7506 card in JBOD mode. Software RAID 5. No such problems with >> Ext3 ( > 20MB/sec sustained write) with the same kernel on the >> same software RAID 5 device. Obviously there's something very >> wrong here. >> >> Known issue? Any idea what might be causing this? > > By the way: Using hardware RAID 5 on exactly the same setup, the > XFS and EXT3 numbers are virtually identical (~5MB/sec sustained > write). Only software RAID 5 seems to cause this great > divergence. Did you try your setup with an external log? IIRC the problem with bad write performance on software RAID 5 should have been adressed and mostly fixed with the XFS1.3.x release. I recommend to try with external log anyway. I never had good results on my software RAID 5 configurations until I used external log. However, I never did my tests again in the XFS1.3.x days. Simon From owner-linux-xfs@oss.sgi.com Fri Oct 31 15:19:48 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 31 Oct 2003 15:20:22 -0800 (PST) Received: from mail.dkp.com (hidden-user@mail.dkp.com [204.191.16.3]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9VNJj25012745 for ; Fri, 31 Oct 2003 15:19:48 -0800 Received: by mail.dkp.com (Postfix, from userid 20001) id C594D2B0D1; Fri, 31 Oct 2003 18:19:44 -0500 (EST) Received: from wallace.dkp.com (wallace.dkp.com [10.0.0.81]) by mail.dkp.com (Postfix) with ESMTP id 4661B2ADF9 for ; Fri, 31 Oct 2003 18:19:44 -0500 (EST) Received: by wallace.dkp.com (Postfix, from userid 168) id A0CD36E887; Fri, 31 Oct 2003 18:19:43 -0500 (EST) Date: Fri, 31 Oct 2003 18:19:43 -0500 From: Andrew Klaassen To: linux-xfs@oss.sgi.com Subject: Re: XFS + SMP + Software RAID 5 slow? Message-ID: <20031031231943.GE25822@dkp.com> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20031031215013.GB25822@dkp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031031215013.GB25822@dkp.com> User-Agent: Mutt/1.5.4i X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: $Id: Sanitizer.pm,v 1.54 2002/02/15 16:59:07 bre Exp $ X-archive-position: 884 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ak@dkp.com Precedence: bulk X-list: linux-xfs Content-Length: 1629 Lines: 42 Responding to myself again, with more details... On Fri, Oct 31, 2003 at 04:50:13PM -0500, Andrew Klaassen wrote: > I've been experiencing *very* slow sustained write ( < .5MB/sec) > using 2.4.20-20.9.XFS1.3.1smp on a dual-Xeon box with a 3ware > 7506 card in JBOD mode. Software RAID 5. No such problems with > Ext3 ( > 20MB/sec sustained write) with the same kernel on the > same software RAID 5 device. I got those results using fs-bench: http://h2np.net/tools/fs-bench.tar.gz ...using a little python script that simply monitors df -k. Bonnie++ gives very different results; still favouring Ext3, but the XFS results are at least acceptable: Ext3: Version 1.03 ------Sequential Output------ --Sequential Input- --Random- -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP thor.dkp.com 10000M 42713 44 33594 29 140724 49 215.5 1 XFS: Version 1.03 ------Sequential Output------ --Sequential Input- --Random- -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP thor.dkp.com 10000M 20418 11 29688 16 134639 45 235.0 1 Hmm... so: Would there either be 1) something about fs-bench that would cause XFS to perform poorly or 2) something about watching df -k with XFS that gives misleading results? If anyone else could try fs-bench on an XFS-over-software-RAID5 setup and let me know their results, I'd be much obliged. Andrew Klaassen From owner-linux-xfs@oss.sgi.com Fri Oct 31 15:26:51 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 31 Oct 2003 15:27:26 -0800 (PST) Received: from mail.dkp.com (hidden-user@mail.dkp.com [204.191.16.3]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9VNQp25013499 for ; Fri, 31 Oct 2003 15:26:51 -0800 Received: by mail.dkp.com (Postfix, from userid 20001) id 9C3212B0D1; Fri, 31 Oct 2003 18:26:50 -0500 (EST) Received: from wallace.dkp.com (wallace.dkp.com [10.0.0.81]) by mail.dkp.com (Postfix) with ESMTP id 2493A2ADF9 for ; Fri, 31 Oct 2003 18:26:50 -0500 (EST) Received: by wallace.dkp.com (Postfix, from userid 168) id 4CA866E887; Fri, 31 Oct 2003 18:26:49 -0500 (EST) Date: Fri, 31 Oct 2003 18:26:49 -0500 From: Andrew Klaassen To: linux-xfs@oss.sgi.com Subject: Re: XFS + SMP + Software RAID 5 slow? Message-ID: <20031031232648.GF25822@dkp.com> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20031031215013.GB25822@dkp.com> <20031031231943.GE25822@dkp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031031231943.GE25822@dkp.com> User-Agent: Mutt/1.5.4i X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: $Id: Sanitizer.pm,v 1.54 2002/02/15 16:59:07 bre Exp $ X-archive-position: 885 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ak@dkp.com Precedence: bulk X-list: linux-xfs Content-Length: 979 Lines: 30 Annnnnnd... responding to myself yet again. (Have I overflowed some sort of netiquette stack yet?) BTW, I'm not subscribed, but I am monitoring the web archive for responses. Still, CC'ing me with responses would be great. ;) On Fri, Oct 31, 2003 at 06:19:43PM -0500, Andrew Klaassen wrote: > Responding to myself again, with more details... > > On Fri, Oct 31, 2003 at 04:50:13PM -0500, > Andrew Klaassen wrote: > > > I've been experiencing *very* slow sustained write ( < .5MB/sec) > > using 2.4.20-20.9.XFS1.3.1smp on a dual-Xeon box with a 3ware > > 7506 card in JBOD mode. Software RAID 5. No such problems with > > Ext3 ( > 20MB/sec sustained write) with the same kernel on the > > same software RAID 5 device. > > I got those results using fs-bench: > > http://h2np.net/tools/fs-bench.tar.gz I notice that fs-bench works by filling the filesystem with bazillions and bazillions of ~100KB files. Would that have an impact on XFS performance? Andrew Klaassen From owner-linux-xfs@oss.sgi.com Fri Oct 31 15:31:33 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 31 Oct 2003 15:32:13 -0800 (PST) Received: from mail.dkp.com (hidden-user@mail.dkp.com [204.191.16.3]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id h9VNVW25013933 for ; Fri, 31 Oct 2003 15:31:32 -0800 Received: by mail.dkp.com (Postfix, from userid 20001) id C77E02B0D1; Fri, 31 Oct 2003 18:31:31 -0500 (EST) Received: from wallace.dkp.com (wallace.dkp.com [10.0.0.81]) by mail.dkp.com (Postfix) with ESMTP id 538F02ADF9; Fri, 31 Oct 2003 18:31:31 -0500 (EST) Received: by wallace.dkp.com (Postfix, from userid 168) id 5A9F36E887; Fri, 31 Oct 2003 18:31:30 -0500 (EST) Date: Fri, 31 Oct 2003 18:31:30 -0500 From: Andrew Klaassen To: Simon Matter Cc: linux-xfs@oss.sgi.com Subject: Re: XFS + SMP + Software RAID 5 slow? Message-ID: <20031031233130.GG25822@dkp.com> Mail-Followup-To: Simon Matter , linux-xfs@oss.sgi.com References: <20031031215013.GB25822@dkp.com> <20031031223220.GC25822@dkp.com> <38213.213.173.165.140.1067642085.squirrel@imap01.ch.sauter-bc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <38213.213.173.165.140.1067642085.squirrel@imap01.ch.sauter-bc.com> User-Agent: Mutt/1.5.4i X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: $Id: Sanitizer.pm,v 1.54 2002/02/15 16:59:07 bre Exp $ X-archive-position: 886 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ak@dkp.com Precedence: bulk X-list: linux-xfs Content-Length: 1223 Lines: 32 On Sat, Nov 01, 2003 at 12:14:45AM +0100, Simon Matter wrote: > > On Fri, Oct 31, 2003 at 04:50:13PM -0500, > > Andrew Klaassen wrote: > > > >> I've been experiencing *very* slow sustained write ( < > >> .5MB/sec) using 2.4.20-20.9.XFS1.3.1smp on a dual-Xeon box > >> with a 3ware 7506 card in JBOD mode. Software RAID 5. No > >> such problems with Ext3 ( > 20MB/sec sustained write) with > >> the same kernel on the same software RAID 5 device. > >> Obviously there's something very wrong here. > >> > >> Known issue? Any idea what might be causing this? > > > > By the way: Using hardware RAID 5 on exactly the same setup, > > the XFS and EXT3 numbers are virtually identical (~5MB/sec > > sustained write). Only software RAID 5 seems to cause this > > great divergence. > > Did you try your setup with an external log? IIRC the problem > with bad write performance on software RAID 5 should have been > adressed and mostly fixed with the XFS1.3.x release. I > recommend to try with external log anyway. I never had good > results on my software RAID 5 configurations until I used > external log. However, I never did my tests again in the > XFS1.3.x days. No, I haven't. I'll give that a try. Andrew Klaassen From owner-linux-xfs@oss.sgi.com Fri Oct 31 17:09:43 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 31 Oct 2003 17:10:05 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10) with ESMTP id hA119h25019152 for ; Fri, 31 Oct 2003 17:09:43 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hA119hkn019151 for linux-xfs@oss.sgi.com; Fri, 31 Oct 2003 17:09:43 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10) with ESMTP id hA119f27019137 for ; Fri, 31 Oct 2003 17:09:42 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hA10C9tt014666; Fri, 31 Oct 2003 16:12:09 -0800 Date: Fri, 31 Oct 2003 16:12:09 -0800 Message-Id: <200311010012.hA10C9tt014666@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 286] New: Kernel BUG at buffer.c:568 X-Bugzilla-Reason: AssignedTo X-archive-position: 887 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1906 Lines: 49 http://oss.sgi.com/bugzilla/show_bug.cgi?id=286 Summary: Kernel BUG at buffer.c:568 Product: Linux XFS Version: 1.3.x Platform: IA32 OS/Version: Linux Status: NEW Severity: critical Priority: High Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: john@geeknetau.net From the logfile: Oct 31 17:41:38 oliver kernel: kernel BUG at buffer.c:568! Oct 31 17:41:38 oliver kernel: invalid operand: 0000 Oct 31 17:41:38 oliver kernel: Oct 31 17:41:38 oliver kernel: CPU: 0 Oct 31 17:41:38 oliver kernel: EIP: 0010:[__insert_into_lru_list+28/112] Not tainted Oct 31 17:41:38 oliver kernel: EFLAGS: 00010286 Oct 31 17:41:38 oliver kernel: eax: 00000000 ebx: 00000002 ecx: c306dd40 edx: c0433b14 Oct 31 17:41:38 oliver kernel: esi: c306dd40 edi: c306dd40 ebp: 00000001 esp: c8089e4c Oct 31 17:41:38 oliver kernel: ds: 0018 es: 0018 ss: 0018 Oct 31 17:41:38 oliver kernel: Process postmaster (pid: 6999, stackpage=c8089000) Oct 31 17:41:38 oliver kernel: Stack: 00000002 c0136466 c306dd40 00000002 c306dd40 00001000 c013647a c306dd40 Oct 31 17:41:38 oliver kernel: c0136e73 c306dd40 00001000 cc62f0a0 0079a000 00000000 00001000 00000000 Oct 31 17:41:38 oliver kernel: c01374e4 cc62f0a0 c106ee8c 00000000 00001000 c106ee8c 403cb1fc c2855000 Oct 31 17:41:38 oliver kernel: Call Trace: [__refile_buffer+86/96] [refile_buffer+10/16] [__block_commit_write+131/208] [generic_commit_wri te+52/96] [do_generic_file_write+654/976] [xfs_write+1166/1952] [linvfs_write+276/336] [sys_write+150/240] [system_call+51/56] Oct 31 17:41:38 oliver kernel: Code: 0f 0b 38 02 67 10 2f c0 83 3a 00 75 05 89 0a 89 49 24 8b 02 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Fri Oct 31 18:44:30 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 31 Oct 2003 18:45:10 -0800 (PST) Received: from mail.dkp.com (hidden-user@mail.dkp.com [204.191.16.3]) by oss.sgi.com (8.12.10/8.12.10) with SMTP id hA12iR25028280 for ; Fri, 31 Oct 2003 18:44:30 -0800 Received: by mail.dkp.com (Postfix, from userid 20001) id A0FBE2B0F4; Fri, 31 Oct 2003 21:44:26 -0500 (EST) Received: from wallace.dkp.com (wallace.dkp.com [10.0.0.81]) by mail.dkp.com (Postfix) with ESMTP id 150002B0F3; Fri, 31 Oct 2003 21:44:26 -0500 (EST) Received: by wallace.dkp.com (Postfix, from userid 168) id 6EB4F6E887; Fri, 31 Oct 2003 21:44:25 -0500 (EST) Date: Fri, 31 Oct 2003 21:44:25 -0500 From: Andrew Klaassen To: Simon Matter Cc: linux-xfs@oss.sgi.com Subject: Re: XFS + SMP + Software RAID 5 slow? Message-ID: <20031101024425.GA28503@dkp.com> Mail-Followup-To: Simon Matter , linux-xfs@oss.sgi.com References: <20031031215013.GB25822@dkp.com> <20031031223220.GC25822@dkp.com> <38213.213.173.165.140.1067642085.squirrel@imap01.ch.sauter-bc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <38213.213.173.165.140.1067642085.squirrel@imap01.ch.sauter-bc.com> User-Agent: Mutt/1.5.4i X-Sanitizer: This message has been sanitized! X-Sanitizer-URL: http://mailtools.anomy.net/ X-Sanitizer-Rev: $Id: Sanitizer.pm,v 1.54 2002/02/15 16:59:07 bre Exp $ X-archive-position: 888 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ak@dkp.com Precedence: bulk X-list: linux-xfs Content-Length: 1868 Lines: 53 On Sat, Nov 01, 2003 at 12:14:45AM +0100, Simon Matter wrote: > > On Fri, Oct 31, 2003 at 04:50:13PM -0500, > > Andrew Klaassen wrote: > > > >> I've been experiencing *very* slow sustained write ( < > >> .5MB/sec) using 2.4.20-20.9.XFS1.3.1smp on a dual-Xeon box > >> with a 3ware 7506 card in JBOD mode. Software RAID 5. No > >> such problems with Ext3 ( > 20MB/sec sustained write) with > >> the same kernel on the same software RAID 5 device. > >> Obviously there's something very wrong here. > >> > >> Known issue? Any idea what might be causing this? > > > > By the way: Using hardware RAID 5 on exactly the same setup, > > the XFS and EXT3 numbers are virtually identical (~5MB/sec > > sustained write). Only software RAID 5 seems to cause this > > great divergence. > > Did you try your setup with an external log? IIRC the problem > with bad write performance on software RAID 5 should have been > adressed and mostly fixed with the XFS1.3.x release. I > recommend to try with external log anyway. I never had good > results on my software RAID 5 configurations until I used > external log. However, I never did my tests again in the > XFS1.3.x days. *Wow*, that made huge difference. From < .5MB/sec to > 10MB/sec. Still not as good as Ext3, but getting better. I've noticed the variance in amount of data going out to disk with XFS was much higher than with Ext3, too. Using the external log on XFS, as you suggested, and a default Ext3 (these both on software RAID 5, of course): Ext3: Mean: 17541.5MB/s Std. Dev: 2375.89MB/s XFS: Mean: 12960.4MB/s Std. Dev: 6535.16MB/s That's computed with a 5-second timeslices. In English, it means that XFS write rates are jumping all over the place, from .5MB/s to 20MB/s. Any reason why that would be? Again, this is with fs-bench, which fills up the filesystem with ~100KB files. Andrew Klaassen From owner-linux-xfs@oss.sgi.com Fri Oct 31 20:09:44 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 31 Oct 2003 20:10:03 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10) with ESMTP id hA149i25029747 for ; Fri, 31 Oct 2003 20:09:44 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hA149ida029746 for linux-xfs@oss.sgi.com; Fri, 31 Oct 2003 20:09:44 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10) with ESMTP id hA149g27029732 for ; Fri, 31 Oct 2003 20:09:42 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hA13cCdY029487; Fri, 31 Oct 2003 19:38:12 -0800 Date: Fri, 31 Oct 2003 19:38:12 -0800 Message-Id: <200311010338.hA13cCdY029487@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 286] Kernel BUG at buffer.c:568 X-Bugzilla-Reason: AssignedTo X-archive-position: 889 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 448 Lines: 20 http://oss.sgi.com/bugzilla/show_bug.cgi?id=286 ------- Additional Comments From sandeen@sgi.com 2003-31-10 19:38 PDT ------- For the record, looks like this bug in __insert_into_lru_list() if (bh->b_prev_free || bh->b_next_free) BUG(); Also, were you doing anything interesting at the time of the oops? -Eric ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Fri Oct 31 21:09:44 2003 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 31 Oct 2003 21:09:59 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10) with ESMTP id hA159i25001128 for ; Fri, 31 Oct 2003 21:09:44 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hA159imY001127 for linux-xfs@oss.sgi.com; Fri, 31 Oct 2003 21:09:44 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.10) with ESMTP id hA159g27001113 for ; Fri, 31 Oct 2003 21:09:42 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id hA154uoG001072; Fri, 31 Oct 2003 21:04:56 -0800 Date: Fri, 31 Oct 2003 21:04:56 -0800 Message-Id: <200311010504.hA154uoG001072@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 286] Kernel BUG at buffer.c:568 X-Bugzilla-Reason: AssignedTo X-archive-position: 890 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 306 Lines: 15 http://oss.sgi.com/bugzilla/show_bug.cgi?id=286 ------- Additional Comments From john@geeknetau.net 2003-31-10 21:04 PDT ------- was doing updates in a postgresql 7.3.4 database ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.