From owner-xfs@oss.sgi.com Sat Mar 1 03:20:56 2008 Received: with ECARTIS (v1.0.0; list xfs); Sat, 01 Mar 2008 03:21:15 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,J_CHICKENPOX_23, MIME_8BIT_HEADER,T_STOX_BOUND_090909_B autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m21BKsHC029320 for ; Sat, 1 Mar 2008 03:20:55 -0800 X-ASG-Debug-ID: 1204370480-198f02340000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from moutng.kundenserver.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 74D92F02962 for ; Sat, 1 Mar 2008 03:21:21 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.188]) by cuda.sgi.com with ESMTP id Wv0HxmUxjgp6OEQo for ; Sat, 01 Mar 2008 03:21:21 -0800 (PST) Received: from [10.17.19.2] (dslb-084-056-000-250.pools.arcor-ip.net [84.56.0.250]) by mrelayeu.kundenserver.de (node=mrelayeu1) with ESMTP (Nemesis) id 0MKwpI-1JVPmJ1qQa-0006EM; Sat, 01 Mar 2008 12:21:20 +0100 Message-ID: <47C93C32.40006@mathtm.de> Date: Sat, 01 Mar 2008 12:21:22 +0100 From: =?ISO-8859-15?Q?Thomas_M=FCller?= User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: xfs@oss.sgi.com CC: linux-kernel@vger.kernel.org, =?ISO-8859-15?Q?Thomas_M=FCller?= X-ASG-Orig-Subj: Kernel oops / XFS filesystem corruption Subject: Kernel oops / XFS filesystem corruption X-Enigmail-Version: 0.95.6 Content-Type: multipart/mixed; boundary="------------080104030007000406030106" X-Provags-ID: V01U2FsdGVkX18e837ujzL/KO8Hu8NYB0F7JzlF3Sdy48kJwMf cFERV1UOpA2pYlCzW1izw0NuItGz5K+JIW0yyVpB8T5Q5jKYPR EoD9gHwMoT9KY84mtHnuhgN14J3AbHH X-Barracuda-Connect: moutng.kundenserver.de[212.227.126.188] X-Barracuda-Start-Time: 1204370482 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.43563 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14726 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: thomas@mathtm.de Precedence: bulk X-list: xfs This is a multi-part message in MIME format. --------------080104030007000406030106 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Hello :) My system just crashed because of a power fluctuation and the root filesystem was damaged. The system booted up just fine, but when samba tried to start up the kernel oops'd. xfs_repair was apparently able to repair the damage, though I seem to have lost some files. I do realize that a lot of awful things can happen if you just cut the power, but the kernel shouldn't oops on a mounted file system, right? Please CC me, as I'm not subscribed to the lists. Regards Thomas $ rpm -q xfsprogs xfsprogs-2.9.4-4.fc8 $ uname -a Linux linux.local.loc 2.6.23.15-137.fc8 #1 SMP Sun Feb 10 17:48:34 EST 2008 i686 i686 i386 GNU/Linux --------------080104030007000406030106 Content-Type: text/plain; name="xfs_check" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="xfs_check" block 0/19018 expected type unknown got free2 agi unlinked bucket 6 is 103430 in ag 3 (inode=12686342) agi unlinked bucket 14 is 91278 in ag 3 (inode=12674190) agi unlinked bucket 23 is 106135 in ag 3 (inode=12689047) agi unlinked bucket 31 is 53279 in ag 3 (inode=12636191) agi unlinked bucket 35 is 106147 in ag 3 (inode=12689059) agi unlinked bucket 36 is 60836 in ag 3 (inode=12643748) agi unlinked bucket 39 is 60839 in ag 3 (inode=12643751) agi unlinked bucket 41 is 378537 in ag 3 (inode=12961449) agi unlinked bucket 50 is 91250 in ag 3 (inode=12674162) agi unlinked bucket 20 is 38996 in ag 4 (inode=16816212) agi unlinked bucket 57 is 95353 in ag 4 (inode=16872569) agi unlinked bucket 4 is 199940 in ag 8 (inode=33754372) agi unlinked bucket 8 is 56392 in ag 8 (inode=33610824) agi unlinked bucket 21 is 177621 in ag 8 (inode=33732053) agi unlinked bucket 22 is 56406 in ag 8 (inode=33610838) agi unlinked bucket 23 is 56407 in ag 8 (inode=33610839) agi unlinked bucket 27 is 54747 in ag 8 (inode=33609179) agi unlinked bucket 32 is 67232 in ag 8 (inode=33621664) agi unlinked bucket 37 is 54757 in ag 8 (inode=33609189) agi unlinked bucket 39 is 67239 in ag 8 (inode=33621671) agi unlinked bucket 40 is 67240 in ag 8 (inode=33621672) agi unlinked bucket 47 is 56367 in ag 8 (inode=33610799) agi unlinked bucket 0 is 34944 in ag 10 (inode=41977984) agi unlinked bucket 20 is 42516 in ag 11 (inode=46179860) agi unlinked bucket 15 is 463 in ag 13 (inode=54526415) agi unlinked bucket 62 is 154430 in ag 13 (inode=54680382) block 0/21136 type unknown not expected allocated inode 12689047 has 0 link count allocated inode 12689059 has 0 link count allocated inode 12674162 has 0 link count allocated inode 12674190 has 0 link count allocated inode 12636191 has 0 link count allocated inode 12961449 has 0 link count allocated inode 12643748 has 0 link count allocated inode 12643751 has 0 link count allocated inode 12686342 has 0 link count allocated inode 16816212 has 0 link count allocated inode 16872569 has 0 link count allocated inode 33754372 has 0 link count allocated inode 33732053 has 0 link count allocated inode 33621664 has 0 link count allocated inode 33621671 has 0 link count allocated inode 33621672 has 0 link count allocated inode 33609179 has 0 link count allocated inode 33609189 has 0 link count allocated inode 33610799 has 0 link count allocated inode 33610824 has 0 link count allocated inode 33610838 has 0 link count allocated inode 33610839 has 0 link count allocated inode 41977984 has 0 link count allocated inode 46179860 has 0 link count allocated inode 54680382 has 0 link count allocated inode 54526415 has 0 link count sb_ifree 3257, counted 3259 sb_fdblocks 7248513, counted 7248904 --------------080104030007000406030106 Content-Type: text/plain; name="xfs_oops" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="xfs_oops" Mar 1 10:32:03 linux kernel: BUG: unable to handle kernel NULL pointer dereference at virtual address 00000002 Mar 1 10:32:03 linux kernel: printing eip: f8a96141 *pde = 38ccb067 Mar 1 10:32:03 linux kernel: Oops: 0000 [#1] SMP Mar 1 10:32:03 linux kernel: Modules linked in: asb100 hwmon_vid hwmon tun sch_sfq sch_htb pppoe pppox ppp_synctty ppp_async crc_ccitt ppp_generic slhc bridge xt_NOTRACK iptable_raw ipt_MASQUERADE iptable_nat nf_nat ipt_REJECT xt_mac ipt_LOG nf_conntrack_ipv4 xt_state nf_conntrack nfnetlink iptable_filter xt_CLASSIFY xt_length ipt_owner xt_TCPMSS xt_comment xt_tcpudp iptable_mangle ip_tables x_tables ext2 mbcache dm_mirror dm_mod 8139too r8169 mii i2c_i801 iTCO_wdt iTCO_vendor_support i2c_core sg sr_mod cdrom ata_generic ata_piix libata sd_mod scsi_mod xfs ehci_hcd Mar 1 10:32:03 linux kernel: CPU: 0 Mar 1 10:32:03 linux kernel: EIP: 0060:[] Not tainted VLI Mar 1 10:32:03 linux kernel: EFLAGS: 00010292 (2.6.23.15-137.fc8 #1) Mar 1 10:32:03 linux kernel: EIP is at xfs_attr_shortform_getvalue+0x15/0xdb [xfs] Mar 1 10:32:03 linux kernel: eax: 00000000 ebx: f268cddc ecx: f8ae4d9d edx: 08d26645 Mar 1 10:32:03 linux kernel: esi: f04d1600 edi: 00000004 ebp: f8ae4d91 esp: f268cdbc Mar 1 10:32:03 linux kernel: ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 Mar 1 10:32:03 linux kernel: Process smbd (pid: 2036, ti=f268c000 task=f7207840 task.ti=f268c000) Mar 1 10:32:03 linux kernel: Stack: 00000003 f37888d4 00000003 f04d1600 f04d1600 f268ce38 f8ae4d91 f8a93a97 Mar 1 10:32:03 linux kernel: f8ae4d91 0000000c c1ba6000 00000130 00000402 275b19c4 00000000 00000000 Mar 1 10:32:03 linux kernel: f04d1600 00000000 00000000 00000000 00000000 00000001 00000000 00000000 Mar 1 10:32:03 linux kernel: Call Trace: Mar 1 10:32:03 linux kernel: [] xfs_attr_fetch+0x9e/0xee [xfs] Mar 1 10:32:03 linux kernel: [] xfs_acl_iaccess+0x59/0xc2 [xfs] Mar 1 10:32:03 linux kernel: [] xfs_iaccess+0x87/0x15c [xfs] Mar 1 10:32:03 linux kernel: [] xfs_access+0x26/0x3a [xfs] Mar 1 10:32:03 linux kernel: [] xfs_vn_permission+0x0/0x13 [xfs] Mar 1 10:32:03 linux kernel: [] xfs_vn_permission+0xf/0x13 [xfs] Mar 1 10:32:03 linux kernel: [] permission+0x9e/0xdb Mar 1 10:32:03 linux kernel: [] may_open+0x5c/0x205 Mar 1 10:32:03 linux kernel: [] open_namei+0x27d/0x576 Mar 1 10:32:03 linux kernel: [] do_filp_open+0x2a/0x3e Mar 1 10:32:03 linux kernel: [] get_unused_fd_flags+0x52/0xc5 Mar 1 10:32:03 linux kernel: [] do_sys_open+0x48/0xca Mar 1 10:32:03 linux kernel: [] sys_open+0x1c/0x1e Mar 1 10:32:03 linux kernel: [] syscall_call+0x7/0xb Mar 1 10:32:03 linux kernel: ======================= Mar 1 10:32:03 linux kernel: Code: 00 00 c6 40 02 00 66 c7 00 00 04 8b 47 2c 5b 5e 5f e9 08 bc 03 00 55 57 56 53 89 c3 83 ec 0c 8b 40 20 8b 40 4c 8b 40 14 8d 78 04 <0f> b6 40 02 c7 44 24 08 00 00 00 00 89 44 24 04 e9 96 00 00 00 Mar 1 10:32:03 linux kernel: EIP: [] xfs_attr_shortform_getvalue+0x15/0xdb [xfs] SS:ESP 0068:f268cdbc --------------080104030007000406030106-- From owner-xfs@oss.sgi.com Sat Mar 1 13:01:42 2008 Received: with ECARTIS (v1.0.0; list xfs); Sat, 01 Mar 2008 13:02:01 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,MIME_8BIT_HEADER autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m21L1dxl014791 for ; Sat, 1 Mar 2008 13:01:42 -0800 X-ASG-Debug-ID: 1204405326-444d00000000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id A9D3912458ED for ; Sat, 1 Mar 2008 13:02:06 -0800 (PST) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id N5bx7nKMaEcBvb55 for ; Sat, 01 Mar 2008 13:02:06 -0800 (PST) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 46FCB1801201B; Sat, 1 Mar 2008 15:02:05 -0600 (CST) Message-ID: <47C9C44D.8080400@sandeen.net> Date: Sat, 01 Mar 2008 15:02:05 -0600 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: =?ISO-8859-15?Q?Thomas_M=FCller?= CC: xfs@oss.sgi.com, linux-kernel@vger.kernel.org X-ASG-Orig-Subj: Re: Kernel oops / XFS filesystem corruption Subject: Re: Kernel oops / XFS filesystem corruption References: <47C93C32.40006@mathtm.de> In-Reply-To: <47C93C32.40006@mathtm.de> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1204405327 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.43601 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14727 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Thomas Müller wrote: > Hello :) > > My system just crashed because of a power fluctuation and the root > filesystem was damaged. > The system booted up just fine, but when samba tried to start up > the kernel oops'd. > > xfs_repair was apparently able to repair the damage, though I seem > to have lost some files. > > I do realize that a lot of awful things can happen if you just cut > the power, but the kernel shouldn't oops on a mounted file > system, right? right. here's the disassembly of that function in your kernrel FWIW: 0001012c : 1012c: 55 push %ebp 1012d: 57 push %edi 1012e: 56 push %esi 1012f: 53 push %ebx 10130: 89 c3 mov %eax,%ebx 10132: 83 ec 0c sub $0xc,%esp 10135: 8b 40 20 mov 0x20(%eax),%eax 10138: 8b 40 4c mov 0x4c(%eax),%eax 1013b: 8b 40 14 mov 0x14(%eax),%eax 1013e: 8d 78 04 lea 0x4(%eax),%edi 10141: 0f b6 40 02 movzbl 0x2(%eax),%eax <--- boom. 10145: c7 44 24 08 00 00 00 movl $0x0,0x8(%esp) 1014c: 00 1014d: 89 44 24 04 mov %eax,0x4(%esp) 10151: e9 96 00 00 00 jmp 101ec ... at this point eax is "sf" (0x0) and edi is "sfe" (0x04) Mar 1 10:32:03 linux kernel: eax: 00000000 ebx: f268cddc ecx: f8ae4d9d edx: 08d26645 Mar 1 10:32:03 linux kernel: esi: f04d1600 edi: 00000004 ebp: f8ae4d91 esp: f268cdbc first part of the function: int xfs_attr_shortform_getvalue(xfs_da_args_t *args) { xfs_attr_shortform_t *sf; xfs_attr_sf_entry_t *sfe; int i; ASSERT(args->dp->i_d.di_aformat == XFS_IFINLINE); sf = (xfs_attr_shortform_t *)args->dp->i_afp->if_u1.if_data; sfe = &sf->list[0]; for (i = 0; i < sf->hdr.count; <--- died here, sf is 0 sfe = XFS_ATTR_SF_NEXTENTRY(sfe), i++) { we blew up on sf->hdr.count because sf is NULL (hdr.count is 0x2 into sf) maybe the sgi guys can take it from there ;) Did you also happen to save the xfs_repair output? -Eric From owner-xfs@oss.sgi.com Sat Mar 1 16:33:24 2008 Received: with ECARTIS (v1.0.0; list xfs); Sat, 01 Mar 2008 16:33:43 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,J_CHICKENPOX_45, MIME_8BIT_HEADER,T_STOX_BOUND_090909_B autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m220XL3X032309 for ; Sat, 1 Mar 2008 16:33:24 -0800 X-ASG-Debug-ID: 1204418029-081601610000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from moutng.kundenserver.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 2E5CDE2360B for ; Sat, 1 Mar 2008 16:33:49 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.188]) by cuda.sgi.com with ESMTP id eUfSGQFv5o2zqkxQ for ; Sat, 01 Mar 2008 16:33:49 -0800 (PST) Received: from [10.17.19.2] (dslb-084-056-038-245.pools.arcor-ip.net [84.56.38.245]) by mrelayeu.kundenserver.de (node=mrelayeu5) with ESMTP (Nemesis) id 0ML25U-1JVc970FZB-0006Us; Sun, 02 Mar 2008 01:33:41 +0100 Message-ID: <47C9F5E9.70703@mathtm.de> Date: Sun, 02 Mar 2008 01:33:45 +0100 From: =?ISO-8859-15?Q?Thomas_M=FCller?= User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Eric Sandeen CC: xfs@oss.sgi.com, linux-kernel@vger.kernel.org X-ASG-Orig-Subj: Re: Kernel oops / XFS filesystem corruption Subject: Re: Kernel oops / XFS filesystem corruption References: <47C93C32.40006@mathtm.de> <47C9C44D.8080400@sandeen.net> In-Reply-To: <47C9C44D.8080400@sandeen.net> X-Enigmail-Version: 0.95.6 Content-Type: multipart/mixed; boundary="------------080300090103030503010006" X-Provags-ID: V01U2FsdGVkX1+aEmKx06ZJAj3jyd3KNc69dxwc/IXrhm67emb YiyNopPPWYP6RklBChi5iJqLjPcgV6ndyOufllxmPGv6vuLkCO YoLGiMUzZYAx2YpI1gZtMXjaVoeGLP5 X-Barracuda-Connect: moutng.kundenserver.de[212.227.126.188] X-Barracuda-Start-Time: 1204418030 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.43615 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14728 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: thomas@mathtm.de Precedence: bulk X-list: xfs This is a multi-part message in MIME format. --------------080300090103030503010006 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Eric Sandeen wrote: > Did you also happen to save the xfs_repair output? No, but I made a complete copy of the file system before repairing it, so I can easily recreate it... :) Thomas --------------080300090103030503010006 Content-Type: text/plain; name="xfs_repair" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="xfs_repair" Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 data fork in ino 128638 claims free block 19018 - agno = 1 - agno = 2 b5ac7b90: Badness in key lookup (length) bp=(bno 11701280, len 32768 bytes) key=(bno 11701280, len 8192 bytes) b5ac7b90: Badness in key lookup (length) bp=(bno 11708896, len 32768 bytes) key=(bno 11708896, len 8192 bytes) b5ac7b90: Badness in key lookup (length) bp=(bno 11739296, len 32768 bytes) key=(bno 11739296, len 8192 bytes) b5ac7b90: Badness in key lookup (length) bp=(bno 11751440, len 32768 bytes) key=(bno 11751440, len 8192 bytes) b5ac7b90: Badness in key lookup (length) bp=(bno 11754176, len 32768 bytes) key=(bno 11754176, len 8192 bytes) b5ac7b90: Badness in key lookup (length) bp=(bno 12026592, len 32768 bytes) key=(bno 12026592, len 8192 bytes) - agno = 3 b50c6b90: Badness in key lookup (length) bp=(bno 15569728, len 32768 bytes) key=(bno 15569728, len 8192 bytes) b50c6b90: Badness in key lookup (length) bp=(bno 15626080, len 32768 bytes) key=(bno 15626080, len 8192 bytes) - agno = 4 - agno = 5 - agno = 6 - agno = 7 b41ffb90: Badness in key lookup (length) bp=(bno 31116224, len 32768 bytes) key=(bno 31116224, len 8192 bytes) b41ffb90: Badness in key lookup (length) bp=(bno 31117856, len 32768 bytes) key=(bno 31117856, len 8192 bytes) b41ffb90: Badness in key lookup (length) bp=(bno 31128704, len 32768 bytes) key=(bno 31128704, len 8192 bytes) b41ffb90: Badness in key lookup (length) bp=(bno 31239104, len 32768 bytes) key=(bno 31239104, len 8192 bytes) b41ffb90: Badness in key lookup (length) bp=(bno 31261408, len 32768 bytes) key=(bno 31261408, len 8192 bytes) - agno = 8 local inode 33609156 attr too small (size = 0, min size = 4) bad attribute fork in inode 33609156, clearing attr fork clearing inode 33609156 attributes cleared inode 33609156 - agno = 9 b50c6b90: Badness in key lookup (length) bp=(bno 38861808, len 32768 bytes) key=(bno 38861808, len 8192 bytes) - agno = 10 b41ffb90: Badness in key lookup (length) bp=(bno 42752032, len 32768 bytes) key=(bno 42752032, len 8192 bytes) - agno = 11 - agno = 12 b50c6b90: Badness in key lookup (length) bp=(bno 50475360, len 32768 bytes) key=(bno 50475360, len 8192 bytes) b50c6b90: Badness in key lookup (length) bp=(bno 50629312, len 32768 bytes) key=(bno 50629312, len 8192 bytes) - agno = 13 - agno = 14 - agno = 15 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 bad bmap btree ptr 0xc3a0000100000000 in ino 33609156 bad data fork in inode 33609156 cleared inode 33609156 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - traversing filesystem ... entry "locking.tdb" in directory inode 33585205 points to free inode 33609156 bad hash table for directory inode 33585205 (no data entry): rebuilding rebuilding directory inode 33585205 - traversal finished ... - moving disconnected inodes to lost+found ... disconnected inode 12636191, moving to lost+found disconnected inode 12643748, moving to lost+found disconnected inode 12643751, moving to lost+found disconnected inode 12674162, moving to lost+found disconnected inode 12674190, moving to lost+found disconnected inode 12686342, moving to lost+found disconnected inode 12689047, moving to lost+found disconnected inode 12689059, moving to lost+found disconnected inode 12961449, moving to lost+found disconnected inode 16816212, moving to lost+found disconnected inode 16872569, moving to lost+found disconnected inode 33609179, moving to lost+found disconnected inode 33609189, moving to lost+found disconnected inode 33610799, moving to lost+found disconnected inode 33610824, moving to lost+found disconnected inode 33610838, moving to lost+found disconnected inode 33610839, moving to lost+found disconnected inode 33621664, moving to lost+found disconnected inode 33621671, moving to lost+found disconnected inode 33621672, moving to lost+found disconnected inode 33732053, moving to lost+found disconnected inode 33754372, moving to lost+found disconnected inode 41977984, moving to lost+found disconnected inode 46179860, moving to lost+found disconnected inode 54526415, moving to lost+found disconnected inode 54680382, moving to lost+found Phase 7 - verify and correct link counts... done --------------080300090103030503010006-- From owner-xfs@oss.sgi.com Sat Mar 1 17:34:29 2008 Received: with ECARTIS (v1.0.0; list xfs); Sat, 01 Mar 2008 17:34:48 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,MIME_8BIT_HEADER autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m221YS1q006273 for ; Sat, 1 Mar 2008 17:34:29 -0800 X-ASG-Debug-ID: 1204421696-79d300ff0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id B216563A621 for ; Sat, 1 Mar 2008 17:34:57 -0800 (PST) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id 9tQsP0WqoHlYyBSr for ; Sat, 01 Mar 2008 17:34:57 -0800 (PST) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id C9F4318DA0AF0; Sat, 1 Mar 2008 19:34:55 -0600 (CST) Message-ID: <47CA043F.5070202@sandeen.net> Date: Sat, 01 Mar 2008 19:34:55 -0600 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: =?ISO-8859-15?Q?Thomas_M=FCller?= CC: xfs@oss.sgi.com, linux-kernel@vger.kernel.org X-ASG-Orig-Subj: Re: Kernel oops / XFS filesystem corruption Subject: Re: Kernel oops / XFS filesystem corruption References: <47C93C32.40006@mathtm.de> <47C9C44D.8080400@sandeen.net> <47C9F5E9.70703@mathtm.de> In-Reply-To: <47C9F5E9.70703@mathtm.de> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1204421697 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.43620 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14729 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Thomas Müller wrote: > Eric Sandeen wrote: >> Did you also happen to save the xfs_repair output? > No, but I made a complete copy of the file system before > repairing it, so I can easily recreate it... :) oh, like a dd image? great. You can use xfs_metadump to make a more transportable image... xfs folks might even be able to use that to recreate the oops. -Eric From owner-xfs@oss.sgi.com Sun Mar 2 02:26:13 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 02 Mar 2008 02:26:31 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m22AQBX4017473 for ; Sun, 2 Mar 2008 02:26:12 -0800 X-ASG-Debug-ID: 1204453599-28ca00790000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from smtp-out02.alice-dsl.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id CD06B124824C for ; Sun, 2 Mar 2008 02:26:39 -0800 (PST) Received: from smtp-out02.alice-dsl.net (smtp-out02.alice-dsl.net [88.44.60.12]) by cuda.sgi.com with ESMTP id fREn2pCPaXWk1tnX for ; Sun, 02 Mar 2008 02:26:39 -0800 (PST) Received: from out.alice-dsl.de ([192.168.125.59]) by smtp-out02.alice-dsl.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 2 Mar 2008 11:19:39 +0100 Received: from basil.firstfloor.org ([78.53.157.204]) by out.alice-dsl.de with Microsoft SMTPSVC(6.0.3790.1830); Sun, 2 Mar 2008 11:19:38 +0100 Received: by basil.firstfloor.org (Postfix, from userid 1000) id 6DA8A1B4194; Sun, 2 Mar 2008 11:26:07 +0100 (CET) To: "Barry Naujok" Cc: "xfs@oss.sgi.com" X-ASG-Orig-Subj: Re: [REVIEW] Don't make lazy counters default for mkfs Subject: Re: [REVIEW] Don't make lazy counters default for mkfs References: From: Andi Kleen Date: 02 Mar 2008 11:26:07 +0100 In-Reply-To: Message-ID: <87ir05h16o.fsf@basil.nowhere.org> Lines: 8 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 02 Mar 2008 10:19:39.0084 (UTC) FILETIME=[EC1F80C0:01C87C4E] X-Barracuda-Connect: smtp-out02.alice-dsl.net[88.44.60.12] X-Barracuda-Start-Time: 1204453600 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.43655 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14730 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: andi@firstfloor.org Precedence: bulk X-list: xfs "Barry Naujok" writes: > > Lazy counters will default to on again in xfsprogs 2.10.0 (when CI > support is released). CI is what? -Andi From owner-xfs@oss.sgi.com Sun Mar 2 02:41:32 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 02 Mar 2008 02:41:52 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m22AfVUq018701 for ; Sun, 2 Mar 2008 02:41:32 -0800 X-ASG-Debug-ID: 1204454517-28ca00a30000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from filer.fsl.cs.sunysb.edu (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id EC93B124815F; Sun, 2 Mar 2008 02:41:58 -0800 (PST) Received: from filer.fsl.cs.sunysb.edu (filer.fsl.cs.sunysb.edu [130.245.126.2]) by cuda.sgi.com with ESMTP id 4I3Q7CE1qfEDmb7f; Sun, 02 Mar 2008 02:41:58 -0800 (PST) Received: from josefsipek.net (baal.fsl.cs.sunysb.edu [130.245.126.78]) by filer.fsl.cs.sunysb.edu (8.12.11.20060308/8.13.1) with ESMTP id m22Afq0B028713; Sun, 2 Mar 2008 05:41:53 -0500 Received: by josefsipek.net (Postfix, from userid 1000) id 207D61C00114; Sun, 2 Mar 2008 05:41:53 -0500 (EST) Date: Sun, 2 Mar 2008 05:41:53 -0500 From: "Josef 'Jeff' Sipek" To: Andi Kleen Cc: Barry Naujok , "xfs@oss.sgi.com" X-ASG-Orig-Subj: Re: [REVIEW] Don't make lazy counters default for mkfs Subject: Re: [REVIEW] Don't make lazy counters default for mkfs Message-ID: <20080302104153.GD2483@josefsipek.net> References: <87ir05h16o.fsf@basil.nowhere.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87ir05h16o.fsf@basil.nowhere.org> User-Agent: Mutt/1.5.16 (2007-06-11) X-Barracuda-Connect: filer.fsl.cs.sunysb.edu[130.245.126.2] X-Barracuda-Start-Time: 1204454520 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.43657 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14731 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jeffpc@josefsipek.net Precedence: bulk X-list: xfs On Sun, Mar 02, 2008 at 11:26:07AM +0100, Andi Kleen wrote: > "Barry Naujok" writes: > > > > Lazy counters will default to on again in xfsprogs 2.10.0 (when CI > > support is released). > > CI is what? Case-insensitivity aka. case-folding. Josef 'Jeff' Sipek. -- Bad pun of the week: The formula 1 control computer suffered from a race condition From owner-xfs@oss.sgi.com Sun Mar 2 08:14:46 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 02 Mar 2008 08:15:11 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m22GEjDv013265 for ; Sun, 2 Mar 2008 08:14:46 -0800 X-ASG-Debug-ID: 1204474512-062a022d0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ug-out-1314.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id A210F1249536 for ; Sun, 2 Mar 2008 08:15:12 -0800 (PST) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.170]) by cuda.sgi.com with ESMTP id Xj7wUJnrZ7THUz9H for ; Sun, 02 Mar 2008 08:15:12 -0800 (PST) Received: by ug-out-1314.google.com with SMTP id o29so2047715ugd.20 for ; Sun, 02 Mar 2008 08:15:11 -0800 (PST) Received: by 10.78.201.8 with SMTP id y8mr15643183huf.18.1204474511087; Sun, 02 Mar 2008 08:15:11 -0800 (PST) Received: from teal.hq.k1024.org ( [84.75.117.152]) by mx.google.com with ESMTPS id y37sm8564217mug.19.2008.03.02.08.15.09 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 02 Mar 2008 08:15:10 -0800 (PST) Received: by teal.hq.k1024.org (Postfix, from userid 4004) id C625C40A100; Sun, 2 Mar 2008 17:15:07 +0100 (CET) Date: Sun, 2 Mar 2008 17:15:07 +0100 From: Iustin Pop To: xfs@oss.sgi.com X-ASG-Orig-Subj: XFS_WANT_CORRUPTED_GOTO report Subject: XFS_WANT_CORRUPTED_GOTO report Message-ID: <20080302161507.GC12740@teal.hq.k1024.org> Mail-Followup-To: xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Linux: This message was written on Linux X-Header: /usr/include gives great headers User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Barracuda-Connect: ug-out-1314.google.com[66.249.92.170] X-Barracuda-Start-Time: 1204474513 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.43678 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14732 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: iusty@k1024.org Precedence: bulk X-list: xfs Hi, I searched the list but didn't find any reports of XFS_WANT_CORRUPTED_GOTO in xfs_bmap_add_extent_unwritten_real, so here it goes. My kernel is tainted as I use nvidia's binary driver, so if I'm told to go away I understand :) Otherwise it's a self compiled amd64 kernel on debian unstable. The filesystem in question was recently grown, and I did on a file: xfs_io disk0.img resvp 0 2G truncate 8G (not with G but with the actual numbers). Then I proceeded to write into this file (it was used as a qemu disk image) and at some point: XFS internal error XFS_WANT_CORRUPTED_GOTO at line 2058 of file fs/xfs/xfs_bmap_btree.c. Caller 0xffffffff80318a80 Pid: 281, comm: xfsdatad/1 Tainted: P 2.6.24.3-teal #1 Call Trace: [] xfs_bmap_add_extent_unwritten_real+0x710/0xce0 [] xfs_bmbt_insert+0x14d/0x150 [] xfs_bmap_add_extent_unwritten_real+0x710/0xce0 [] xfs_bmap_add_extent+0x147/0x440 [] xfs_iext_get_ext+0x49/0x80 [] xfs_btree_init_cursor+0x45/0x220 [] xfs_bmapi+0xc31/0x1360 [] xlog_grant_log_space+0x298/0x2e0 [] xfs_trans_reserve+0xa8/0x210 [] xfs_iomap_write_unwritten+0x14b/0x220 [] xfs_iomap+0x25a/0x390 [] thread_return+0x3a/0x56c [] xfs_end_bio_unwritten+0x0/0x40 [] xfs_end_bio_unwritten+0x2f/0x40 [] run_workqueue+0xcc/0x170 [] worker_thread+0x0/0x110 [] worker_thread+0x0/0x110 [] worker_thread+0xa3/0x110 [] autoremove_wake_function+0x0/0x30 [] worker_thread+0x0/0x110 [] worker_thread+0x0/0x110 [] kthread+0x4b/0x80 [] child_rip+0xa/0x12 [] kthread+0x0/0x80 [] child_rip+0x0/0x12 Filesystem "dm-4": XFS internal error xfs_trans_cancel at line 1163 of file fs/xfs/xfs_trans.c. Caller 0xffffffff80340a9b Pid: 281, comm: xfsdatad/1 Tainted: P 2.6.24.3-teal #1 Call Trace: [] xfs_iomap_write_unwritten+0x1fb/0x220 [] xfs_trans_cancel+0x104/0x130 [] xfs_iomap_write_unwritten+0x1fb/0x220 [] xfs_iomap+0x25a/0x390 [] thread_return+0x3a/0x56c [] xfs_end_bio_unwritten+0x0/0x40 [] xfs_end_bio_unwritten+0x2f/0x40 [] run_workqueue+0xcc/0x170 [] worker_thread+0x0/0x110 [] worker_thread+0x0/0x110 [] worker_thread+0xa3/0x110 [] autoremove_wake_function+0x0/0x30 [] worker_thread+0x0/0x110 [] worker_thread+0x0/0x110 [] kthread+0x4b/0x80 [] child_rip+0xa/0x12 [] kthread+0x0/0x80 [] child_rip+0x0/0x12 xfs_force_shutdown(dm-4,0x8) called from line 1164 of file fs/xfs/xfs_trans.c. Return address = 0xffffffff803515ed Filesystem "dm-4": Corruption of in-memory data detected. Shutting down filesystem: dm-4 Please umount the filesystem, and rectify the problem(s) xfs_repair didn't say anything related to corruption, mounting it just said starting recovery... ending recovery. After mount, the file in question is heavily fragmented (around 1600 segments). I'm not sure if this file caused the corruption, but I'm almost certain, as no other traffic should have been at that time. I also have a metadump (run before recovery) and a full copy of the filesystem if it's useful. thanks, iustin From owner-xfs@oss.sgi.com Sun Mar 2 11:02:10 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 02 Mar 2008 11:02:28 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,MIME_8BIT_HEADER autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m22J27qB028442 for ; Sun, 2 Mar 2008 11:02:10 -0800 X-ASG-Debug-ID: 1204484555-073f00030000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from moutng.kundenserver.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 7DCCF124A410 for ; Sun, 2 Mar 2008 11:02:35 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by cuda.sgi.com with ESMTP id kGFd2TwyRN80xFhk for ; Sun, 02 Mar 2008 11:02:35 -0800 (PST) Received: from [10.17.19.2] (dslb-084-056-059-096.pools.arcor-ip.net [84.56.59.96]) by mrelayeu.kundenserver.de (node=mrelayeu2) with ESMTP (Nemesis) id 0MKwtQ-1JVtSB1xqq-0005PD; Sun, 02 Mar 2008 20:02:34 +0100 Message-ID: <47CAF9C4.6090000@mathtm.de> Date: Sun, 02 Mar 2008 20:02:28 +0100 From: =?ISO-8859-15?Q?Thomas_M=FCller?= User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Eric Sandeen CC: xfs@oss.sgi.com, linux-kernel@vger.kernel.org X-ASG-Orig-Subj: Re: Kernel oops / XFS filesystem corruption Subject: Re: Kernel oops / XFS filesystem corruption References: <47C93C32.40006@mathtm.de> <47C9C44D.8080400@sandeen.net> <47C9F5E9.70703@mathtm.de> <47CA043F.5070202@sandeen.net> In-Reply-To: <47CA043F.5070202@sandeen.net> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX1/mazNlOs0mqYxoAI30gKVkCV9ng20b6cbzldd k+QE9VuQPNF/mira2XdGh4kxW+YK5zLIdLuXUkU4utPq0EnNCf McSYwpt0aYazNXr1Jzahe6d/bJIAFB1 X-Barracuda-Connect: moutng.kundenserver.de[212.227.126.186] X-Barracuda-Start-Time: 1204484556 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.43688 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14733 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: thomas@mathtm.de Precedence: bulk X-list: xfs Eric Sandeen wrote: > oh, like a dd image? great. Yup :) > You can use xfs_metadump to make a more transportable image... I will, if someone needs it. As said, I have a complete file system image, so if anyone needs more information/data, just tell me. Thomas From owner-xfs@oss.sgi.com Sun Mar 2 15:34:32 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 02 Mar 2008 15:34:53 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m22NYT6j020544 for ; Sun, 2 Mar 2008 15:34:32 -0800 X-ASG-Debug-ID: 1204500897-0882032c0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from postoffice.aconex.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 2E63F63E3AA for ; Sun, 2 Mar 2008 15:34:57 -0800 (PST) Received: from postoffice.aconex.com (prod.aconex.com [203.89.192.138]) by cuda.sgi.com with ESMTP id ZYz48CG7zGnCKmqG for ; Sun, 02 Mar 2008 15:34:57 -0800 (PST) Received: from edge.scott.net.au (unknown [203.89.192.141]) by postoffice.aconex.com (Postfix) with ESMTP id BFA3492D21B; Mon, 3 Mar 2008 10:34:55 +1100 (EST) X-ASG-Orig-Subj: Re: [REVIEW] Don't make lazy counters default for mkfs Subject: Re: [REVIEW] Don't make lazy counters default for mkfs From: Nathan Scott Reply-To: nscott@aconex.com To: Russell Cattelan Cc: Eric Sandeen , Barry Naujok , "xfs@oss.sgi.com" In-Reply-To: <47C89303.7070902@thebarn.com> References: <1204166101.13569.102.camel@edge.scott.net.au> <47C87775.2010007@thebarn.com> <47C89137.3070805@sandeen.net> <47C89303.7070902@thebarn.com> Content-Type: text/plain Organization: Aconex Date: Mon, 03 Mar 2008 10:34:55 +1100 Message-Id: <1204500895.10190.3.camel@edge.scott.net.au> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: prod.aconex.com[203.89.192.138] X-Barracuda-Start-Time: 1204500898 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.43707 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14734 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nscott@aconex.com Precedence: bulk X-list: xfs On Fri, 2008-02-29 at 17:19 -0600, Russell Cattelan wrote: > > > I thought about that; xfs *could* stick someting in /proc/fs/xfs > with > > supported features or somesuch. > > > > But, the kernel you mkfs under isn't necessarily the one you're > going to > > need to fall back to tomorrow, though... > > > > > True but at least it could make a bit of a intelligent decision. > and maybe a warning for a while about potentially incompatible flags. Might also be a good idea to require -f to force a mkfs of a filesystem which the kernel doesn't support. Would be good to get blocksize > pagesize into this scheme too btw, and unfortunately that one isn't a superblock flag) - so this scheme might need to go beyond those flags, if anyone decides to implement it. cheers. -- Nathan From owner-xfs@oss.sgi.com Sun Mar 2 15:58:46 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 02 Mar 2008 15:59:05 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m22NweNf022066 for ; Sun, 2 Mar 2008 15:58:44 -0800 Received: from pc-bnaujok.melbourne.sgi.com (pc-bnaujok.melbourne.sgi.com [134.14.55.58]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA21371; Mon, 3 Mar 2008 10:58:56 +1100 Date: Mon, 03 Mar 2008 10:59:43 +1100 To: "Eric Sandeen" , markgw@sgi.com Subject: Re: [REVIEW] Don't make lazy counters default for mkfs From: "Barry Naujok" Organization: SGI Cc: "Russell Cattelan" , nscott@aconex.com, "xfs@oss.sgi.com" Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 References: <1204166101.13569.102.camel@edge.scott.net.au> <47C87775.2010007@thebarn.com> <47C89137.3070805@sandeen.net> <47C89303.7070902@thebarn.com> <47C8997A.9030804@sgi.com> <47C89B94.4060002@sandeen.net> <47C89F17.7040307@sandeen.net> Content-Transfer-Encoding: 7bit Message-ID: In-Reply-To: <47C89F17.7040307@sandeen.net> User-Agent: Opera Mail/9.24 (Win32) X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14735 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs On Sat, 01 Mar 2008 11:11:03 +1100, Eric Sandeen wrote: > Eric Sandeen wrote: > >> maybe just 2 values, with the actual supported features (& features2) >> values anded together? Easy enough to parse in the code. >> >> i.e. >> >> # cat /proc/fs/xfs/features >> 0xffffffff >> 0x00000001 > > hm, but of course mkfs should never be checking for anything in the > first features slot; yesterday's kernels support all those flags but > don't export anything. Bzzzzt! IRIX/ASCII case-insensitive mode (or OLDCI or "V1 CI" as I'm calling it :) ) is in the first features slot - 0x4000 > wow, this is starting to feel as complex as ext4's flags ;) > > -Eric > > From owner-xfs@oss.sgi.com Sun Mar 2 16:16:00 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 02 Mar 2008 16:16:19 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_43 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m230Ftk2023782 for ; Sun, 2 Mar 2008 16:15:59 -0800 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA21931; Mon, 3 Mar 2008 11:16:11 +1100 Message-ID: <47CB434B.4040005@sgi.com> Date: Mon, 03 Mar 2008 11:16:11 +1100 From: Timothy Shimmin User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Mark Goodwin CC: nscott@aconex.com, Russell Cattelan , Eric Sandeen , Barry Naujok , "xfs@oss.sgi.com" Subject: Re: [REVIEW] Don't make lazy counters default for mkfs References: <1204166101.13569.102.camel@edge.scott.net.au> <47C87775.2010007@thebarn.com> <47C89137.3070805@sandeen.net> <47C89303.7070902@thebarn.com> <1204500895.10190.3.camel@edge.scott.net.au> In-Reply-To: <1204500895.10190.3.camel@edge.scott.net.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14736 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs Nathan Scott wrote: > On Fri, 2008-02-29 at 17:19 -0600, Russell Cattelan wrote: >>> I thought about that; xfs *could* stick someting in /proc/fs/xfs >> with >>> supported features or somesuch. >>> >>> But, the kernel you mkfs under isn't necessarily the one you're >> going to >>> need to fall back to tomorrow, though... >>> >>> >> True but at least it could make a bit of a intelligent decision. >> and maybe a warning for a while about potentially incompatible flags. > > Might also be a good idea to require -f to force a mkfs of a filesystem > which the kernel doesn't support. > 974981: mkfs.xfs should warn if it is about to create a fs that cannot be mounted Ivan was wanting this in December last year. Remember, Mark? He wanted to know what XFS features the running kernel supported? I don't think Dave (dgc) and others were not so keen on it IIRC. (Seems fine to me:) --Tim From owner-xfs@oss.sgi.com Sun Mar 2 16:18:43 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 02 Mar 2008 16:18:51 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from relay.sgi.com (netops-testserver-3.corp.sgi.com [192.26.57.72]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m230Iglo024341 for ; Sun, 2 Mar 2008 16:18:43 -0800 Received: from outhouse.melbourne.sgi.com (outhouse.melbourne.sgi.com [134.14.52.145]) by netops-testserver-3.corp.sgi.com (Postfix) with ESMTP id 233F990890; Sun, 2 Mar 2008 16:19:04 -0800 (PST) Received: from [134.15.251.5] (melb-sw-corp-251-5.corp.sgi.com [134.15.251.5]) by outhouse.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id m230ItTG2445893; Mon, 3 Mar 2008 11:18:58 +1100 (AEDT) Message-ID: <47CB43EE.3060405@sgi.com> Date: Mon, 03 Mar 2008 11:18:54 +1100 From: Donald Douwsma User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: nscott@aconex.com CC: Russell Cattelan , Eric Sandeen , Barry Naujok , "xfs@oss.sgi.com" Subject: Re: [REVIEW] Don't make lazy counters default for mkfs References: <1204166101.13569.102.camel@edge.scott.net.au> <47C87775.2010007@thebarn.com> <47C89137.3070805@sandeen.net> <47C89303.7070902@thebarn.com> <1204500895.10190.3.camel@edge.scott.net.au> In-Reply-To: <1204500895.10190.3.camel@edge.scott.net.au> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14737 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: donaldd@sgi.com Precedence: bulk X-list: xfs Nathan Scott wrote: > On Fri, 2008-02-29 at 17:19 -0600, Russell Cattelan wrote: >>> I thought about that; xfs *could* stick someting in /proc/fs/xfs >> with >>> supported features or somesuch. >>> >>> But, the kernel you mkfs under isn't necessarily the one you're >> going to >>> need to fall back to tomorrow, though... >>> >>> >> True but at least it could make a bit of a intelligent decision. >> and maybe a warning for a while about potentially incompatible flags. > > Might also be a good idea to require -f to force a mkfs of a filesystem > which the kernel doesn't support. Could work but I dont like the idea of using -f for anything but mkfsing an existing filesystem. If that becomes habit for people it could lead to disasters. Don From owner-xfs@oss.sgi.com Sun Mar 2 16:24:14 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 02 Mar 2008 16:24:21 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m230ODQ0029452 for ; Sun, 2 Mar 2008 16:24:14 -0800 X-ASG-Debug-ID: 1204503882-243600160000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from postoffice.aconex.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id BC8CC124BCC3 for ; Sun, 2 Mar 2008 16:24:42 -0800 (PST) Received: from postoffice.aconex.com (prod.aconex.com [203.89.192.138]) by cuda.sgi.com with ESMTP id 7whER3PxB6Foh4ed for ; Sun, 02 Mar 2008 16:24:42 -0800 (PST) Received: from edge.scott.net.au (unknown [203.89.192.141]) by postoffice.aconex.com (Postfix) with ESMTP id 440F592DEF0; Mon, 3 Mar 2008 11:24:10 +1100 (EST) X-ASG-Orig-Subj: Re: [REVIEW] Don't make lazy counters default for mkfs Subject: Re: [REVIEW] Don't make lazy counters default for mkfs From: Nathan Scott Reply-To: nscott@aconex.com To: Donald Douwsma Cc: Russell Cattelan , Eric Sandeen , Barry Naujok , "xfs@oss.sgi.com" In-Reply-To: <47CB43EE.3060405@sgi.com> References: <1204166101.13569.102.camel@edge.scott.net.au> <47C87775.2010007@thebarn.com> <47C89137.3070805@sandeen.net> <47C89303.7070902@thebarn.com> <1204500895.10190.3.camel@edge.scott.net.au> <47CB43EE.3060405@sgi.com> Content-Type: text/plain Organization: Aconex Date: Mon, 03 Mar 2008 11:24:09 +1100 Message-Id: <1204503849.10190.26.camel@edge.scott.net.au> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: prod.aconex.com[203.89.192.138] X-Barracuda-Start-Time: 1204503882 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.43710 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14738 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nscott@aconex.com Precedence: bulk X-list: xfs On Mon, 2008-03-03 at 11:18 +1100, Donald Douwsma wrote: > > > Could work but I dont like the idea of using -f for anything but > mkfsing an > existing filesystem. If that becomes habit for people it could lead to > disasters. Its already used for more than just overwriting existing filesystems. :) And it is already habit for some people. Which leads to disasters, yes. Its not a perfect system, but there's only so much you can do for people before they shoot themselves in the foot. -- Nathan From owner-xfs@oss.sgi.com Sun Mar 2 16:31:22 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 02 Mar 2008 16:31:41 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_43 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m230VIjx030322 for ; Sun, 2 Mar 2008 16:31:20 -0800 Received: from [134.14.55.21] (dhcp21.melbourne.sgi.com [134.14.55.21]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA22785; Mon, 3 Mar 2008 11:31:32 +1100 Message-ID: <47CB4696.1030304@sgi.com> Date: Mon, 03 Mar 2008 11:30:14 +1100 From: Mark Goodwin Reply-To: markgw@sgi.com Organization: SGI Engineering User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: Timothy Shimmin CC: nscott@aconex.com, Russell Cattelan , Eric Sandeen , Barry Naujok , "xfs@oss.sgi.com" Subject: Re: [REVIEW] Don't make lazy counters default for mkfs References: <1204166101.13569.102.camel@edge.scott.net.au> <47C87775.2010007@thebarn.com> <47C89137.3070805@sandeen.net> <47C89303.7070902@thebarn.com> <1204500895.10190.3.camel@edge.scott.net.au> <47CB434B.4040005@sgi.com> In-Reply-To: <47CB434B.4040005@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14739 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: markgw@sgi.com Precedence: bulk X-list: xfs Timothy Shimmin wrote: > Nathan Scott wrote: >> On Fri, 2008-02-29 at 17:19 -0600, Russell Cattelan wrote: >>>> I thought about that; xfs *could* stick someting in /proc/fs/xfs >>> with >>>> supported features or somesuch. >>>> >>>> But, the kernel you mkfs under isn't necessarily the one you're >>> going to >>>> need to fall back to tomorrow, though... >>>> >>>> >>> True but at least it could make a bit of a intelligent decision. >>> and maybe a warning for a while about potentially incompatible flags. >> >> Might also be a good idea to require -f to force a mkfs of a filesystem >> which the kernel doesn't support. >> > > 974981: mkfs.xfs should warn if it is about to create a fs that cannot > be mounted > > Ivan was wanting this in December last year. Remember, Mark? > He wanted to know what XFS features the running kernel supported? It was worse than that - IIRC, he wanted to know what features are supported by the XFS kernel module he just installed (this was part of an Appman upgrade scenario). I thought we rejected that bug ? > > I don't think Dave (dgc) and others were not so keen on it IIRC. anyone recall the reasons? Maybe I'm missing something, but if we export all the feature bits, both new and old, then (a) an old mkfs will continue to ignore them, and (b) future versions of mkfs will have all the information needed, but will need t be smart about how that information is used. Cheers -- Mark Goodwin markgw@sgi.com Engineering Manager for XFS and PCP Phone: +61-3-99631937 SGI Australian Software Group Cell: +61-4-18969583 ------------------------------------------------------------- From owner-xfs@oss.sgi.com Sun Mar 2 16:31:46 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 02 Mar 2008 16:31:54 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from relay.sgi.com (relay1.corp.sgi.com [192.26.58.214]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m230VkSj030411 for ; Sun, 2 Mar 2008 16:31:46 -0800 Received: from outhouse.melbourne.sgi.com (outhouse.melbourne.sgi.com [134.14.52.145]) by relay1.corp.sgi.com (Postfix) with ESMTP id 82BB98F809C; Sun, 2 Mar 2008 16:32:09 -0800 (PST) Received: from [134.15.251.5] (melb-sw-corp-251-5.corp.sgi.com [134.15.251.5]) by outhouse.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id m230W1TG2332433; Mon, 3 Mar 2008 11:32:05 +1100 (AEDT) Message-ID: <47CB4700.9090808@sgi.com> Date: Mon, 03 Mar 2008 11:32:00 +1100 From: Donald Douwsma User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Christoph Hellwig CC: xfs@oss.sgi.com Subject: Re: [PATCH] remove superflous xfs_readsb call in xfs_mountfs References: <20071218174829.GA3195@lst.de> <20080222034845.GA5354@lst.de> In-Reply-To: <20080222034845.GA5354@lst.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14740 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: donaldd@sgi.com Precedence: bulk X-list: xfs Christoph Hellwig wrote: > On Tue, Dec 18, 2007 at 06:48:29PM +0100, Christoph Hellwig wrote: >> When xfs_mountfs is called by xfs_mount xfs_readsb was called 35 lines >> above unconditionally, so there is no need to try to read the superblock >> if it's not present. If any other port doesn't have the superblock >> read at this point it should just call it directly from it's xfs_mount >> equivalent. > > Ping? Looks good, will be in shortly. Don > >> >> Signed-off-by: Christoph Hellwig >> >> Index: linux-2.6-xfs/fs/xfs/xfs_mount.c >> =================================================================== >> --- linux-2.6-xfs.orig/fs/xfs/xfs_mount.c 2007-12-17 14:34:57.000000000 +0100 >> +++ linux-2.6-xfs/fs/xfs/xfs_mount.c 2007-12-17 14:35:17.000000000 +0100 >> @@ -968,11 +968,6 @@ xfs_mountfs( >> int uuid_mounted = 0; >> int error = 0; >> >> - if (mp->m_sb_bp == NULL) { >> - error = xfs_readsb(mp, mfsi_flags); >> - if (error) >> - return error; >> - } >> xfs_mount_common(mp, sbp); >> >> /* > ---end quoted text--- > From owner-xfs@oss.sgi.com Sun Mar 2 16:42:03 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 02 Mar 2008 16:42:23 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m230fwB1031841 for ; Sun, 2 Mar 2008 16:42:01 -0800 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA23034; Mon, 3 Mar 2008 11:42:19 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 1161) id AA12358C4C0F; Mon, 3 Mar 2008 11:42:19 +1100 (EST) To: sgi.bugs.xfs@engr.sgi.com Cc: xfs@oss.sgi.com Subject: TAKE 907752 - Version bump and debian updates Message-Id: <20080303004219.AA12358C4C0F@chook.melbourne.sgi.com> Date: Mon, 3 Mar 2008 11:42:19 +1100 (EST) From: bnaujok@sgi.com (Barry Naujok) X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14741 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs Debian and version updates Date: Mon Mar 3 11:41:55 AEDT 2008 Workarea: chook.melbourne.sgi.com:/home/bnaujok/isms/xcmds-clean Inspected by: nscott@aconex.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:30604a acl/debian/control - 1.24 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/debian/control.diff?r1=text&tr1=1.24&r2=text&tr2=1.23&f=h attr/debian/control - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/debian/control.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h - Debian update for uploaders xfsprogs/VERSION - 1.179 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/VERSION.diff?r1=text&tr1=1.179&r2=text&tr2=1.178&f=h xfsprogs/doc/CHANGES - 1.251 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/doc/CHANGES.diff?r1=text&tr1=1.251&r2=text&tr2=1.250&f=h - Bump to 2.9.7 xfsprogs/debian/control - 1.23 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/debian/control.diff?r1=text&tr1=1.23&r2=text&tr2=1.22&f=h - Debian update for uploaders xfsprogs/debian/changelog - 1.153 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/debian/changelog.diff?r1=text&tr1=1.153&r2=text&tr2=1.152&f=h - Debian update xfsdump/debian/control - 1.24 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/debian/control.diff?r1=text&tr1=1.24&r2=text&tr2=1.23&f=h dmapi/debian/control - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/dmapi/debian/control.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h - Debian update for uploaders xfsprogs/fsck/xfs_fsck.sh - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/fsck/xfs_fsck.sh.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h - Execute bits changed from xxx to --- Ignore another option From owner-xfs@oss.sgi.com Sun Mar 2 16:41:42 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 02 Mar 2008 16:57:44 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m230fbhJ031823 for ; Sun, 2 Mar 2008 16:41:41 -0800 Received: from linuxbuild.melbourne.sgi.com (linuxbuild.melbourne.sgi.com [134.14.54.115]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA23025; Mon, 3 Mar 2008 11:42:02 +1100 From: donaldd@sgi.com Received: by linuxbuild.melbourne.sgi.com (Postfix, from userid 16365) id C3753323900C; Mon, 3 Mar 2008 11:42:01 +1100 (EST) To: sgi.bugs.xfs@engr.sgi.com, xfs@oss.sgi.com Subject: TAKE 976035 - Remove superflous xfs_readsb call in xfs_mountfs. Message-Id: <20080303004201.C3753323900C@linuxbuild.melbourne.sgi.com> Date: Mon, 3 Mar 2008 11:42:01 +1100 (EST) X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14742 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: donaldd@sgi.com Precedence: bulk X-list: xfs Remove superflous xfs_readsb call in xfs_mountfs. When xfs_mountfs is called by xfs_mount xfs_readsb was called 35 lines above unconditionally, so there is no need to try to read the superblock if it's not present. If any other port doesn't have the superblock read at this point it should just call it directly from it's xfs_mount equivalent. Signed-off-by: Christoph Hellwig Date: Mon Mar 3 11:41:13 AEDT 2008 Workarea: linuxbuild.melbourne.sgi.com:/home/donaldd/isms/2.6.x-xfs Inspected by: donaldd The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:30603a fs/xfs/xfs_mount.c - 1.420 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_mount.c.diff?r1=text&tr1=1.420&r2=text&tr2=1.419&f=h - Remove superflous xfs_readsb call in xfs_mountfs. From owner-xfs@oss.sgi.com Sun Mar 2 17:01:30 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 02 Mar 2008 17:01:50 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,MIME_8BIT_HEADER autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m2311QtF001645 for ; Sun, 2 Mar 2008 17:01:28 -0800 Received: from pc-bnaujok.melbourne.sgi.com (pc-bnaujok.melbourne.sgi.com [134.14.55.58]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA23630; Mon, 3 Mar 2008 12:01:41 +1100 To: =?utf-8?Q?Thomas_M=C3=BCller?= , "Eric Sandeen" Subject: Re: Kernel oops / XFS filesystem corruption From: "Barry Naujok" Organization: SGI Cc: xfs@oss.sgi.com, linux-kernel@vger.kernel.org Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 References: <47C93C32.40006@mathtm.de> <47C9C44D.8080400@sandeen.net> <47C9F5E9.70703@mathtm.de> <47CA043F.5070202@sandeen.net> <47CAF9C4.6090000@mathtm.de> Content-Transfer-Encoding: 8bit Date: Mon, 03 Mar 2008 12:02:43 +1100 Message-ID: In-Reply-To: <47CAF9C4.6090000@mathtm.de> User-Agent: Opera Mail/9.24 (Win32) X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14743 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs On Mon, 03 Mar 2008 06:02:28 +1100, Thomas MÃŒller wrote: > Eric Sandeen wrote: >> oh, like a dd image? great. > Yup :) > > > You can use xfs_metadump to make a more transportable image... > I will, if someone needs it. > > As said, I have a complete file system image, so if anyone needs > more information/data, just tell me. I could use the metadump image for the badness in key lookups that xfs_repair was reporting. Thanks, Barry. From owner-xfs@oss.sgi.com Sun Mar 2 17:03:28 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 02 Mar 2008 17:03:35 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m2313M5U002093 for ; Sun, 2 Mar 2008 17:03:27 -0800 Received: from [134.14.55.21] (dhcp21.melbourne.sgi.com [134.14.55.21]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA23702; Mon, 3 Mar 2008 12:03:44 +1100 Message-ID: <47CB4E20.5070808@sgi.com> Date: Mon, 03 Mar 2008 12:02:24 +1100 From: Mark Goodwin Reply-To: markgw@sgi.com Organization: SGI Engineering User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: Eric Sandeen CC: =?ISO-8859-15?Q?Thomas_M=FCller?= , xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: Kernel oops / XFS filesystem corruption References: <47C93C32.40006@mathtm.de> <47C9C44D.8080400@sandeen.net> <47C9F5E9.70703@mathtm.de> <47CA043F.5070202@sandeen.net> In-Reply-To: <47CA043F.5070202@sandeen.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14744 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: markgw@sgi.com Precedence: bulk X-list: xfs Eric Sandeen wrote: > Thomas Müller wrote: >> Eric Sandeen wrote: >>> Did you also happen to save the xfs_repair output? >> No, but I made a complete copy of the file system before >> repairing it, so I can easily recreate it... :) > > oh, like a dd image? great. You can use xfs_metadump to make a more > transportable image... xfs folks might even be able to use that to > recreate the oops. YES PLEASE. See the xfs_metadump man page for instructions. It will obfuscate filenames by default (but please only do so if you need to). Please make it available for Barry, thanks. Cheers -- Mark From owner-xfs@oss.sgi.com Sun Mar 2 17:34:09 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 02 Mar 2008 17:34:26 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m231Y68A004401 for ; Sun, 2 Mar 2008 17:34:09 -0800 X-ASG-Debug-ID: 1204508074-0c5102e40000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from filer.fsl.cs.sunysb.edu (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 46EF9F02C70 for ; Sun, 2 Mar 2008 17:34:34 -0800 (PST) Received: from filer.fsl.cs.sunysb.edu (filer.fsl.cs.sunysb.edu [130.245.126.2]) by cuda.sgi.com with ESMTP id r1IJ0a6tCkeMoR5a for ; Sun, 02 Mar 2008 17:34:34 -0800 (PST) Received: from josefsipek.net (baal.fsl.cs.sunysb.edu [130.245.126.78]) by filer.fsl.cs.sunysb.edu (8.12.11.20060308/8.13.1) with ESMTP id m231FwSA003215; Sun, 2 Mar 2008 20:16:01 -0500 Received: by josefsipek.net (Postfix, from userid 1000) id CDCF91C21D25; Sun, 2 Mar 2008 20:15:59 -0500 (EST) Date: Sun, 2 Mar 2008 20:15:59 -0500 From: "Josef 'Jeff' Sipek" To: Mark Goodwin Cc: Timothy Shimmin , nscott@aconex.com, Russell Cattelan , Eric Sandeen , Barry Naujok , "xfs@oss.sgi.com" X-ASG-Orig-Subj: Re: [REVIEW] Don't make lazy counters default for mkfs Subject: Re: [REVIEW] Don't make lazy counters default for mkfs Message-ID: <20080303011559.GB13879@josefsipek.net> References: <1204166101.13569.102.camel@edge.scott.net.au> <47C87775.2010007@thebarn.com> <47C89137.3070805@sandeen.net> <47C89303.7070902@thebarn.com> <1204500895.10190.3.camel@edge.scott.net.au> <47CB434B.4040005@sgi.com> <47CB4696.1030304@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47CB4696.1030304@sgi.com> User-Agent: Mutt/1.5.16 (2007-06-11) X-Barracuda-Connect: filer.fsl.cs.sunysb.edu[130.245.126.2] X-Barracuda-Start-Time: 1204508075 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.43714 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14745 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jeffpc@josefsipek.net Precedence: bulk X-list: xfs On Mon, Mar 03, 2008 at 11:30:14AM +1100, Mark Goodwin wrote: ... > Maybe I'm missing something, but if we export all the feature bits, > both new and old, then (a) an old mkfs will continue to ignore them, > and (b) future versions of mkfs will have all the information needed, > but will need t be smart about how that information is used. IMHO: 1) mkfs should make a filesystem, the defaults should be conservative (say using features that have been around >1 year) 2) xfs should export supported features to userspace 3) if you want to make sure that the fs you create will be mountable with your current kernel, write a small shell script or something along those lines that reads the features from some kernel interface, and based on those passes the right options to mkfs 4) if you just use mkfs and it creates a fs that's incompatible with your current kernel, the mount will fail - as it does today, but perhaps a less cryptic error message would be in order Since installers are just gigantic wrappers around basic commands like mkfs, #3 gets nicely covered. Josef 'Jeff' Sipek. -- The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. - George Bernard Shaw From owner-xfs@oss.sgi.com Sun Mar 2 17:40:41 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 02 Mar 2008 17:40:48 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m231eZMe005029 for ; Sun, 2 Mar 2008 17:40:39 -0800 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA24849; Mon, 3 Mar 2008 12:40:56 +1100 Message-ID: <47CB587E.8020602@sgi.com> Date: Mon, 03 Mar 2008 12:46:38 +1100 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.12 (X11/20080213) MIME-Version: 1.0 To: iusty@k1024.org CC: xfs-oss Subject: Re: XFS_WANT_CORRUPTED_GOTO report References: <20080302161507.GC12740@teal.hq.k1024.org> In-Reply-To: <20080302161507.GC12740@teal.hq.k1024.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14746 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs Iustin Pop wrote: > Hi, > > I searched the list but didn't find any reports of > XFS_WANT_CORRUPTED_GOTO in xfs_bmap_add_extent_unwritten_real, so here > it goes. My kernel is tainted as I use nvidia's binary driver, so if I'm > told to go away I understand :) Otherwise it's a self compiled amd64 > kernel on debian unstable. > > The filesystem in question was recently grown, and I did on a file: > xfs_io disk0.img > resvp 0 2G > truncate 8G > > (not with G but with the actual numbers). Then I proceeded to write into > this file (it was used as a qemu disk image) and at some point: > > XFS internal error XFS_WANT_CORRUPTED_GOTO at line 2058 of file fs/xfs/xfs_bmap_btree.c. Caller 0xffffffff80318a80 > Pid: 281, comm: xfsdatad/1 Tainted: P 2.6.24.3-teal #1 > > Call Trace: > [] xfs_bmap_add_extent_unwritten_real+0x710/0xce0 > [] xfs_bmbt_insert+0x14d/0x150 > [] xfs_bmap_add_extent_unwritten_real+0x710/0xce0 > [] xfs_bmap_add_extent+0x147/0x440 > [] xfs_iext_get_ext+0x49/0x80 > [] xfs_btree_init_cursor+0x45/0x220 > [] xfs_bmapi+0xc31/0x1360 > [] xlog_grant_log_space+0x298/0x2e0 > [] xfs_trans_reserve+0xa8/0x210 > [] xfs_iomap_write_unwritten+0x14b/0x220 > [] xfs_iomap+0x25a/0x390 > [] thread_return+0x3a/0x56c > [] xfs_end_bio_unwritten+0x0/0x40 > [] xfs_end_bio_unwritten+0x2f/0x40 > [] run_workqueue+0xcc/0x170 > [] worker_thread+0x0/0x110 > [] worker_thread+0x0/0x110 > [] worker_thread+0xa3/0x110 > [] autoremove_wake_function+0x0/0x30 > [] worker_thread+0x0/0x110 > [] worker_thread+0x0/0x110 > [] kthread+0x4b/0x80 > [] child_rip+0xa/0x12 > [] kthread+0x0/0x80 > [] child_rip+0x0/0x12 > > Filesystem "dm-4": XFS internal error xfs_trans_cancel at line 1163 of file fs/xfs/xfs_trans.c. Caller 0xffffffff80340a9b > Pid: 281, comm: xfsdatad/1 Tainted: P 2.6.24.3-teal #1 > > Call Trace: > [] xfs_iomap_write_unwritten+0x1fb/0x220 > [] xfs_trans_cancel+0x104/0x130 > [] xfs_iomap_write_unwritten+0x1fb/0x220 > [] xfs_iomap+0x25a/0x390 > [] thread_return+0x3a/0x56c > [] xfs_end_bio_unwritten+0x0/0x40 > [] xfs_end_bio_unwritten+0x2f/0x40 > [] run_workqueue+0xcc/0x170 > [] worker_thread+0x0/0x110 > [] worker_thread+0x0/0x110 > [] worker_thread+0xa3/0x110 > [] autoremove_wake_function+0x0/0x30 > [] worker_thread+0x0/0x110 > [] worker_thread+0x0/0x110 > [] kthread+0x4b/0x80 > [] child_rip+0xa/0x12 > [] kthread+0x0/0x80 > [] child_rip+0x0/0x12 > > xfs_force_shutdown(dm-4,0x8) called from line 1164 of file fs/xfs/xfs_trans.c. Return address = 0xffffffff803515ed > Filesystem "dm-4": Corruption of in-memory data detected. Shutting down filesystem: dm-4 > Please umount the filesystem, and rectify the problem(s) > > > xfs_repair didn't say anything related to corruption, mounting it just > said starting recovery... ending recovery. That reinforces the message above that the corruption was in-memory and that the on-disk version is good. > > After mount, the file in question is heavily fragmented (around 1600 > segments). I'm not sure if this file caused the corruption, but I'm > almost certain, as no other traffic should have been at that time. The file being written to (that caused the panic) has unwritten extents and we were trying to convert the extents from unwritten to real after writing to them. These XFS_WANT_CORRUPTED_GOTO bugs often occur with extent tree corruption so this is not surprising. Could we get output from xfs_bmap -v on this file? > > I also have a metadump (run before recovery) and a full copy of the > filesystem if it's useful. Can we get a copy of that metadump? I don't hold high hopes for it though - the filesystem can be inconsistent until the log is replayed but after the log was replayed the problem was gone. I don't suppose you have a copy of the log? From owner-xfs@oss.sgi.com Sun Mar 2 19:56:27 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 02 Mar 2008 19:56:51 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_43 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m233uP5T001060 for ; Sun, 2 Mar 2008 19:56:27 -0800 X-ASG-Debug-ID: 1204516613-54a500160000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 7E61CF031B3 for ; Sun, 2 Mar 2008 19:56:53 -0800 (PST) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id bI40NENoumDNtDkB for ; Sun, 02 Mar 2008 19:56:53 -0800 (PST) Received: from Liberator.local (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id C5E3F18004EC4; Sun, 2 Mar 2008 21:56:50 -0600 (CST) Message-ID: <47CB7702.5080905@sandeen.net> Date: Sun, 02 Mar 2008 21:56:50 -0600 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: "Josef 'Jeff' Sipek" CC: Mark Goodwin , Timothy Shimmin , nscott@aconex.com, Russell Cattelan , Barry Naujok , "xfs@oss.sgi.com" X-ASG-Orig-Subj: Re: [REVIEW] Don't make lazy counters default for mkfs Subject: Re: [REVIEW] Don't make lazy counters default for mkfs References: <1204166101.13569.102.camel@edge.scott.net.au> <47C87775.2010007@thebarn.com> <47C89137.3070805@sandeen.net> <47C89303.7070902@thebarn.com> <1204500895.10190.3.camel@edge.scott.net.au> <47CB434B.4040005@sgi.com> <47CB4696.1030304@sgi.com> <20080303011559.GB13879@josefsipek.net> In-Reply-To: <20080303011559.GB13879@josefsipek.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1204516614 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.43724 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14747 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Josef 'Jeff' Sipek wrote: > On Mon, Mar 03, 2008 at 11:30:14AM +1100, Mark Goodwin wrote: > ... >> Maybe I'm missing something, but if we export all the feature bits, >> both new and old, then (a) an old mkfs will continue to ignore them, >> and (b) future versions of mkfs will have all the information needed, >> but will need t be smart about how that information is used. > > IMHO: > > 1) mkfs should make a filesystem, the defaults should be conservative (say > using features that have been around >1 year) I suppose I have to agree, unfortunately that means most competetive benchmarks will be using sub-optimal mkfs's, but... > 2) xfs should export supported features to userspace > > 3) if you want to make sure that the fs you create will be mountable with > your current kernel, write a small shell script or something along those > lines that reads the features from some kernel interface, and based on > those passes the right options to mkfs > 4) if you just use mkfs and it creates a fs that's incompatible with your > current kernel, the mount will fail - as it does today, but perhaps a > less cryptic error message would be in order Ya know, good point. We already have "running kernel compatibility checks" built in; it's called "see what happens when you mount it" It's not like we're running mkfs.ext3 here... ;) mkfs; mount will tell you quickly if there's a problem, won't it. Adding complexity to mkfs might not make a lot of sense. And I still am not a huge fan of checking the currently-running kernel; that's just a point in time, and not necessarily what you're gonna mount it with. (heck maybe you're mkfs'ing a san filesystem?) it's unix, after all. hand out the hangin' rope... just make the kernel explain exactly how & why you've just hung yourself at mount time, in that case.... -Eric From owner-xfs@oss.sgi.com Sun Mar 2 20:04:38 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 02 Mar 2008 20:04:45 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m2344ZAC001986 for ; Sun, 2 Mar 2008 20:04:38 -0800 X-ASG-Debug-ID: 1204517098-41b000210000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id B5E7663F390; Sun, 2 Mar 2008 20:04:59 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id zTcq5f7jxxdlu8VD; Sun, 02 Mar 2008 20:04:59 -0800 (PST) Received: from hch by bombadil.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1JW1v8-0002hy-Bd; Mon, 03 Mar 2008 04:04:58 +0000 Date: Sun, 2 Mar 2008 23:04:58 -0500 From: Christoph Hellwig To: David Chinner Cc: xfs-dev , xfs-oss X-ASG-Orig-Subj: Re: [patch] fix inode leak in xfs_iget_core() Subject: Re: [patch] fix inode leak in xfs_iget_core() Message-ID: <20080303040458.GA3177@infradead.org> References: <20080223061924.GI155259@sgi.com> <20080223092255.GA21453@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080223092255.GA21453@infradead.org> User-Agent: Mutt/1.5.17 (2007-11-01) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1204517103 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.43725 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14748 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs On Sat, Feb 23, 2008 at 04:22:55AM -0500, Christoph Hellwig wrote: > On Sat, Feb 23, 2008 at 05:19:24PM +1100, David Chinner wrote: > > If the radix_tree_preload() fails, we need to destroy the > > inode we just read in before trying again. This could leak > > xfs_vnode structures when there is memory pressure. Noticed > > by Christoph Hellwig. > > What we're leaking would be the xfs_inode. But this is exactly > the patch I had so OK from me :) Now that you're hopefully safe home can you commit it and push it for .25? From owner-xfs@oss.sgi.com Sun Mar 2 20:15:51 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 02 Mar 2008 20:16:12 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m234FjJP003479 for ; Sun, 2 Mar 2008 20:15:50 -0800 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA28768; Mon, 3 Mar 2008 15:16:10 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 44625) id 80A3D58C4C0F; Mon, 3 Mar 2008 15:16:10 +1100 (EST) To: sgi.bugs.xfs@engr.sgi.com, xfs@oss.sgi.com Subject: PARTIAL TAKE 977823 - fix inode leak in xfs_iget_core() Message-Id: <20080303041610.80A3D58C4C0F@chook.melbourne.sgi.com> Date: Mon, 3 Mar 2008 15:16:10 +1100 (EST) From: lachlan@sgi.com (Lachlan McIlroy) X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14749 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs fix inode leak in xfs_iget_core() If the radix_tree_preload() fails, we need to destroy the inode we just read in before trying again. This could leak xfs_vnode structures when there is memory pressure. Noticed by Christoph Hellwig. Signed-off-by: Dave Chinner Date: Mon Mar 3 15:15:23 AEDT 2008 Workarea: redback.melbourne.sgi.com:/home/lachlan/isms/2.6.x-xfs Inspected by: hch Author: lachlan The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:30606a fs/xfs/xfs_iget.c - 1.240 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_iget.c.diff?r1=text&tr1=1.240&r2=text&tr2=1.239&f=h - fix inode leak in xfs_iget_core() From owner-xfs@oss.sgi.com Sun Mar 2 20:17:51 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 02 Mar 2008 20:18:00 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m234Hmux003913 for ; Sun, 2 Mar 2008 20:17:50 -0800 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA28958; Mon, 3 Mar 2008 15:18:03 +1100 Message-ID: <47CB7D52.2030704@sgi.com> Date: Mon, 03 Mar 2008 15:23:46 +1100 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.12 (X11/20080213) MIME-Version: 1.0 To: Marc Dietrich CC: Barry Naujok , xfs@oss.sgi.com Subject: Re: filesystem corruption in linus tree References: <03F8FD43-322F-41E3-A7A0-CD4E9AD8B4DE@ap.physik.uni-giessen.de> <200802252347.50576.marc.dietrich@ap.physik.uni-giessen.de> <47C3C20A.90603@sgi.com> <200802262100.18631.marc.dietrich@ap.physik.uni-giessen.de> In-Reply-To: <200802262100.18631.marc.dietrich@ap.physik.uni-giessen.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14750 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs Marc Dietrich wrote: > Hi again, > > On Tuesday 26 February 2008 08:38:50 Lachlan McIlroy wrote: >> Marc Dietrich wrote: >>> Hi, >>> >>> On Monday 25 February 2008 01:36:28 Barry Naujok wrote: >>>> On Sun, 24 Feb 2008 20:58:26 +1100, Marc Dietrich >>>> >>>> wrote: >>>>> Hi, >>>>> >>>>> somewhere after the release of 2.6.24 my xfs filesystem got corrupted. >>>>> Initialy I thought it was only related to the readdir bug. >>>>> (http://oss.sgi.com/archives/xfs/2008-02/msg00027.html) So I waited for >>>>> the fix to go into mainline. Yesterday I tried again, but got this >>>>> error during boot: > > > >> We've had a few problems reported with XFS on 32-bit powermacs and the >> culprit appears to be some changes to bit manipulation routines. Could you >> please try reverse applying the attached patches and see if the problem is >> resolved? > > I saw, that you already pushed it into mainline - for a good reason ;-) Works > as expeted. > > Please also don't forget 2.6.24-stable ! The changes that caused this regression went into 2.6.25-rc1 so no need for a 2.6.24 stable fix. From owner-xfs@oss.sgi.com Sun Mar 2 20:19:21 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 02 Mar 2008 20:19:29 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_52 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m234JJPc008659 for ; Sun, 2 Mar 2008 20:19:21 -0800 X-ASG-Debug-ID: 1204517987-5499004f0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 4DDE1F03727 for ; Sun, 2 Mar 2008 20:19:48 -0800 (PST) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id f2F3OcpDO8FwuXXn for ; Sun, 02 Mar 2008 20:19:48 -0800 (PST) Received: from Liberator.local (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id D2EEA18004EDA; Sun, 2 Mar 2008 22:19:16 -0600 (CST) Message-ID: <47CB7C44.2030508@sandeen.net> Date: Sun, 02 Mar 2008 22:19:16 -0600 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: "Josef 'Jeff' Sipek" CC: Mark Goodwin , Timothy Shimmin , nscott@aconex.com, Russell Cattelan , Barry Naujok , "xfs@oss.sgi.com" X-ASG-Orig-Subj: Re: [REVIEW] Don't make lazy counters default for mkfs Subject: Re: [REVIEW] Don't make lazy counters default for mkfs References: <1204166101.13569.102.camel@edge.scott.net.au> <47C87775.2010007@thebarn.com> <47C89137.3070805@sandeen.net> <47C89303.7070902@thebarn.com> <1204500895.10190.3.camel@edge.scott.net.au> <47CB434B.4040005@sgi.com> <47CB4696.1030304@sgi.com> <20080303011559.GB13879@josefsipek.net> <47CB7702.5080905@sandeen.net> <20080303041409.GC13879@josefsipek.net> In-Reply-To: <20080303041409.GC13879@josefsipek.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1204517988 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.43726 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14751 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Josef 'Jeff' Sipek wrote: > On Sun, Mar 02, 2008 at 09:56:50PM -0600, Eric Sandeen wrote: >> Josef 'Jeff' Sipek wrote: >>> On Mon, Mar 03, 2008 at 11:30:14AM +1100, Mark Goodwin wrote: >>> ... >>>> Maybe I'm missing something, but if we export all the feature bits, >>>> both new and old, then (a) an old mkfs will continue to ignore them, >>>> and (b) future versions of mkfs will have all the information needed, >>>> but will need t be smart about how that information is used. >>> IMHO: >>> >>> 1) mkfs should make a filesystem, the defaults should be conservative (say >>> using features that have been around >1 year) >> I suppose I have to agree, unfortunately that means most competetive >> benchmarks will be using sub-optimal mkfs's, but... > > Benchmarks that use default mkfs options on xfs, but non-default on other > fs? most benchmarks I see tune the heck out of "the home team" and leave the rest ;) > If you want, have a simple printf in mkfs that tells the user that he's not > using the latest and greatest features (e.g., lazy-count); that should be > enough to make it obvious that there're better options than the default. eh, nobody reads that stuff :) -Eric From owner-xfs@oss.sgi.com Sun Mar 2 20:34:04 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 02 Mar 2008 20:34:23 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_52 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m234Y2f3009897 for ; Sun, 2 Mar 2008 20:34:04 -0800 X-ASG-Debug-ID: 1204518871-544f00890000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from filer.fsl.cs.sunysb.edu (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id C5551F0381C for ; Sun, 2 Mar 2008 20:34:31 -0800 (PST) Received: from filer.fsl.cs.sunysb.edu (filer.fsl.cs.sunysb.edu [130.245.126.2]) by cuda.sgi.com with ESMTP id TRh6VWXj2n2TZkkv for ; Sun, 02 Mar 2008 20:34:31 -0800 (PST) Received: from josefsipek.net (baal.fsl.cs.sunysb.edu [130.245.126.78]) by filer.fsl.cs.sunysb.edu (8.12.11.20060308/8.13.1) with ESMTP id m234E7Am018300; Sun, 2 Mar 2008 23:14:07 -0500 Received: by josefsipek.net (Postfix, from userid 1000) id 9E2D21C00124; Sun, 2 Mar 2008 23:14:09 -0500 (EST) Date: Sun, 2 Mar 2008 23:14:09 -0500 From: "Josef 'Jeff' Sipek" To: Eric Sandeen Cc: Mark Goodwin , Timothy Shimmin , nscott@aconex.com, Russell Cattelan , Barry Naujok , "xfs@oss.sgi.com" X-ASG-Orig-Subj: Re: [REVIEW] Don't make lazy counters default for mkfs Subject: Re: [REVIEW] Don't make lazy counters default for mkfs Message-ID: <20080303041409.GC13879@josefsipek.net> References: <1204166101.13569.102.camel@edge.scott.net.au> <47C87775.2010007@thebarn.com> <47C89137.3070805@sandeen.net> <47C89303.7070902@thebarn.com> <1204500895.10190.3.camel@edge.scott.net.au> <47CB434B.4040005@sgi.com> <47CB4696.1030304@sgi.com> <20080303011559.GB13879@josefsipek.net> <47CB7702.5080905@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47CB7702.5080905@sandeen.net> User-Agent: Mutt/1.5.16 (2007-06-11) X-Barracuda-Connect: filer.fsl.cs.sunysb.edu[130.245.126.2] X-Barracuda-Start-Time: 1204518871 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.43726 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14752 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jeffpc@josefsipek.net Precedence: bulk X-list: xfs On Sun, Mar 02, 2008 at 09:56:50PM -0600, Eric Sandeen wrote: > Josef 'Jeff' Sipek wrote: > > On Mon, Mar 03, 2008 at 11:30:14AM +1100, Mark Goodwin wrote: > > ... > >> Maybe I'm missing something, but if we export all the feature bits, > >> both new and old, then (a) an old mkfs will continue to ignore them, > >> and (b) future versions of mkfs will have all the information needed, > >> but will need t be smart about how that information is used. > > > > IMHO: > > > > 1) mkfs should make a filesystem, the defaults should be conservative (say > > using features that have been around >1 year) > > I suppose I have to agree, unfortunately that means most competetive > benchmarks will be using sub-optimal mkfs's, but... Benchmarks that use default mkfs options on xfs, but non-default on other fs? If you want, have a simple printf in mkfs that tells the user that he's not using the latest and greatest features (e.g., lazy-count); that should be enough to make it obvious that there're better options than the default. > It's not like we're running mkfs.ext3 here... ;) mkfs; mount will tell > you quickly if there's a problem, won't it. Adding complexity to mkfs > might not make a lot of sense. Exactly :) Josef 'Jeff' Sipek. -- I already backed up the [server] once, I can do it again. - a sysadmin threatening to do more frequent backups From owner-xfs@oss.sgi.com Sun Mar 2 20:48:09 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 02 Mar 2008 20:48:28 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_43 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m234m7m8011242 for ; Sun, 2 Mar 2008 20:48:09 -0800 X-ASG-Debug-ID: 1204519716-549400b00000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.sceen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 18E1CF035CF for ; Sun, 2 Mar 2008 20:48:36 -0800 (PST) Received: from mail.sceen.net (sceen.net [213.41.243.68]) by cuda.sgi.com with ESMTP id WdYDvQQgXa8Or2ms for ; Sun, 02 Mar 2008 20:48:36 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sceen.net (Postfix) with ESMTP id C61E71E25B; Mon, 3 Mar 2008 05:48:03 +0100 (CET) Received: from mail.sceen.net ([127.0.0.1]) by localhost (mail.sceen.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05834-09; Mon, 3 Mar 2008 05:47:56 +0100 (CET) Received: from itchy (cesrt42.asia.info.net [61.14.27.42]) by mail.sceen.net (Postfix) with ESMTP id E2FD01C5DB; Mon, 3 Mar 2008 05:47:47 +0100 (CET) From: Niv Sardi To: markgw@sgi.com Cc: Timothy Shimmin , nscott@aconex.com, Russell Cattelan , Eric Sandeen , Barry Naujok , "xfs@oss.sgi.com" X-ASG-Orig-Subj: Re: [REVIEW] Don't make lazy counters default for mkfs Subject: Re: [REVIEW] Don't make lazy counters default for mkfs References: <1204166101.13569.102.camel@edge.scott.net.au> <47C87775.2010007@thebarn.com> <47C89137.3070805@sandeen.net> <47C89303.7070902@thebarn.com> <1204500895.10190.3.camel@edge.scott.net.au> <47CB434B.4040005@sgi.com> <47CB4696.1030304@sgi.com> Date: Mon, 03 Mar 2008 15:47:39 +1100 In-Reply-To: <47CB4696.1030304@sgi.com> (Mark Goodwin's message of "Mon, 03 Mar 2008 11:30:14 +1100") Message-ID: User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/23.0.60 (i486-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at sceen.net X-Barracuda-Connect: sceen.net[213.41.243.68] X-Barracuda-Start-Time: 1204519717 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.43728 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Status: Clean X-archive-position: 14753 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: xaiki@cxhome.ath.cx Precedence: bulk X-list: xfs Mark Goodwin writes: > Timothy Shimmin wrote: >> Nathan Scott wrote: >>> On Fri, 2008-02-29 at 17:19 -0600, Russell Cattelan wrote: >>>>> I thought about that; xfs *could* stick someting in /proc/fs/xfs >>>> with >>>>> supported features or somesuch. >>>>> >>>>> But, the kernel you mkfs under isn't necessarily the one you're >>>> going to >>>>> need to fall back to tomorrow, though... >>>>> >>>>> >>>> True but at least it could make a bit of a intelligent decision. >>>> and maybe a warning for a while about potentially incompatible >>>> flags. >>> >>> Might also be a good idea to require -f to force a mkfs of a filesystem >>> which the kernel doesn't support. >>> >> 974981: mkfs.xfs should warn if it is about to create a fs that >> cannot be mounted >> >> Ivan was wanting this in December last year. Remember, Mark? >> He wanted to know what XFS features the running kernel supported? > > It was worse than that - IIRC, he wanted to know what features are > supported by the XFS kernel module he just installed (this was part > of an Appman upgrade scenario). I thought we rejected that bug ? > >> >> I don't think Dave (dgc) and others were not so keen on it IIRC. > > anyone recall the reasons? Yes, we got to the consensus that having mkfs check for kernel stuff is plain wrong, and there are a load of reasons to that, the most convincing is that you can have no XFS support in the kernel at mkfs time (i.e. module, that'll be loaded only on mount). Others reasons go along the line of: * You could be mkfsing for another box/kernel. * We want people to run latest kernels if they run latest xfsprogs =) Cheers, -- Niv Sardi From owner-xfs@oss.sgi.com Sun Mar 2 22:32:18 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 02 Mar 2008 22:32:40 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m236WG38019256 for ; Sun, 2 Mar 2008 22:32:18 -0800 X-ASG-Debug-ID: 1204525963-218000bf0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from nf-out-0910.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 867AEDAEFF3 for ; Sun, 2 Mar 2008 22:32:44 -0800 (PST) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by cuda.sgi.com with ESMTP id JEeYzmeeCHWsRvfn for ; Sun, 02 Mar 2008 22:32:44 -0800 (PST) Received: by nf-out-0910.google.com with SMTP id e27so3486885nfd.42 for ; Sun, 02 Mar 2008 22:32:43 -0800 (PST) Received: by 10.82.112.3 with SMTP id k3mr2019385buc.33.1204525961751; Sun, 02 Mar 2008 22:32:41 -0800 (PST) Received: from teal.hq.k1024.org ( [84.75.117.152]) by mx.google.com with ESMTPS id t10sm9190270muh.13.2008.03.02.22.32.39 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 02 Mar 2008 22:32:40 -0800 (PST) Received: by teal.hq.k1024.org (Postfix, from userid 4004) id E74DC40A06D; Mon, 3 Mar 2008 07:32:37 +0100 (CET) Date: Mon, 3 Mar 2008 07:32:37 +0100 From: Iustin Pop To: Lachlan McIlroy Cc: xfs-oss X-ASG-Orig-Subj: Re: XFS_WANT_CORRUPTED_GOTO report Subject: Re: XFS_WANT_CORRUPTED_GOTO report Message-ID: <20080303063237.GB21775@teal.hq.k1024.org> Mail-Followup-To: Lachlan McIlroy , xfs-oss References: <20080302161507.GC12740@teal.hq.k1024.org> <47CB587E.8020602@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47CB587E.8020602@sgi.com> X-Linux: This message was written on Linux X-Header: /usr/include gives great headers User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Barracuda-Connect: nf-out-0910.google.com[64.233.182.184] X-Barracuda-Start-Time: 1204525965 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.43734 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14754 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: iusty@k1024.org Precedence: bulk X-list: xfs On Mon, Mar 03, 2008 at 12:46:38PM +1100, Lachlan McIlroy wrote: >> After mount, the file in question is heavily fragmented (around 1600 >> segments). I'm not sure if this file caused the corruption, but I'm >> almost certain, as no other traffic should have been at that time. > The file being written to (that caused the panic) has unwritten extents > and we were trying to convert the extents from unwritten to real after > writing to them. These XFS_WANT_CORRUPTED_GOTO bugs often occur with > extent tree corruption so this is not surprising. Could we get output > from xfs_bmap -v on this file? http://www.k1024.org/iusty/plains.bmap >> I also have a metadump (run before recovery) and a full copy of the >> filesystem if it's useful. > Can we get a copy of that metadump? I don't hold high hopes for it > though - the filesystem can be inconsistent until the log is replayed > but after the log was replayed the problem was gone. I don't suppose > you have a copy of the log? The metadump is here http://www.k1024.org/iusty/plains.metadump.bz2 (~80MB), done with default options. Warning, the server is somewhat slow :) The copy of the log, done with xfs_logprint -t, is here http://www.k1024.org/iusty/plains.logprint The inode of the file in question is 96424401. Let me know if I can give more information. thanks, iustin From owner-xfs@oss.sgi.com Mon Mar 3 05:15:40 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 03 Mar 2008 05:15:47 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: *** X-Spam-Status: No, score=3.2 required=5.0 tests=AWL,BAYES_50,HTML_MESSAGE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m23DFd4D026989 for ; Mon, 3 Mar 2008 05:15:40 -0800 X-ASG-Debug-ID: 1204550167-3b7b01dc0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from wf-out-1314.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 5DB06639D82 for ; Mon, 3 Mar 2008 05:16:07 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by cuda.sgi.com with ESMTP id pihDvcLYTeQOkc1M for ; Mon, 03 Mar 2008 05:16:07 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 29so62wff.32 for ; Mon, 03 Mar 2008 05:16:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=55aeZUuSrIo1HDzWTg4sTnjYsfaHlXyUmvtYPxzQmRQ=; b=JWyS25N5m/ehrmhMrFCCXBtoq0JQ9Siq0HOGP16sDkUC+3G++tyo3gaY7L0nKAN6yN9JZxH7c++mlnP5WVzHWTGbf3kYqo/SMwRNeEx5P91sRE2YHg/4elotajwpb0VI1nxPx0qc+KXU2PHM1/UiKlSF1iP0aRR+hw5QKXyYsOA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=OIXSRFLQE/ulDppbxYofxBNtGWFeDrCs/IHqGFK9N/eLkOXKQKmom74gDKp/Y7EFDYIFClEJ6H9z48puU77VFnNx52K+lTBd4/46HTSFjhTanu5BTOt0z5Ff61eJIeEa97X3ebmKY39pZn2gQMIB6CsSX2aT6SHPlFcruPcVGWc= Received: by 10.142.128.6 with SMTP id a6mr9027579wfd.135.1204550167673; Mon, 03 Mar 2008 05:16:07 -0800 (PST) Received: by 10.142.180.7 with HTTP; Mon, 3 Mar 2008 05:16:07 -0800 (PST) Message-ID: Date: Mon, 3 Mar 2008 21:16:07 +0800 From: cgxu To: xfs@oss.sgi.com, xfscn@googlegroups.com X-ASG-Orig-Subj: Will this functon be used? Subject: Will this functon be used? MIME-Version: 1.0 X-Barracuda-Connect: wf-out-1314.google.com[209.85.200.169] X-Barracuda-Start-Time: 1204550168 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0027 1.0000 -2.0031 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.06 X-Barracuda-Spam-Status: No, SCORE=-1.06 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests=HTML_10_20, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.43758 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message 0.94 HTML_10_20 BODY: Message is 10% to 20% HTML X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-length: 408 X-archive-position: 14756 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: cgxu.gg@gmail.com Precedence: bulk X-list: xfs Hi I found a function which never been used in the shortform directory format. It named xfs_dir2_sf_addname_hard(). The purpose of this function is to insert a new entry to the existent entry's hole. While you remove a entry in shortform format, the residual entrys will move forward, so it will never make a hole in the shortform format entrys. Best Regards Kevin Xu [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Mon Mar 3 05:14:13 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 03 Mar 2008 05:14:32 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,SUBJECT_FUZZY_TION autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m23DEC1Q026610 for ; Mon, 3 Mar 2008 05:14:13 -0800 X-ASG-Debug-ID: 1204550079-303103e30000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from nf-out-0910.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 43A14124C97A for ; Mon, 3 Mar 2008 05:14:40 -0800 (PST) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by cuda.sgi.com with ESMTP id JLqMhCeqSVxEm8QX for ; Mon, 03 Mar 2008 05:14:40 -0800 (PST) Received: by nf-out-0910.google.com with SMTP id e27so3601236nfd.42 for ; Mon, 03 Mar 2008 05:14:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; bh=TLMCxsWBImz6zXuYu7yQHgWjepUZhw7n720+TX49dUg=; b=a8eL30nViynHmvxGF9m3XM2+IKsfsrQoLWTEqMSuhmvjQF8K5egRuMmdTZIv57dcC24p90eHC11p8I/r9CyHAIbZ/2fkjQ+OGcp6TYh9Mf520DWYtCHBRwG43pZLIPnJvKPWhnX7qMxEyV1DxbXFnSQTd196Ue8aPFRocB8XkPc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=Vv9HRqWSR74AXxHP6YjFesfc8s7SmG65KL3E8wbUmBneH2F+ekTRzSwT/gasQMnCHbTsUPx+mp3sU2Cx8pISSMbI8S66fXtWHuBojh9JjJyfs2lv/AGzR4kDWTP14U2/UypYjgUgtd59JsqnfnTpXKbPJ5gkHQvv4oriqjlzvts= Received: by 10.78.81.20 with SMTP id e20mr18747462hub.19.1204550078638; Mon, 03 Mar 2008 05:14:38 -0800 (PST) Received: by 10.78.184.20 with HTTP; Mon, 3 Mar 2008 05:14:38 -0800 (PST) Message-ID: Date: Mon, 3 Mar 2008 05:14:38 -0800 From: "Jeff Breidenbach" To: xfs@oss.sgi.com X-ASG-Orig-Subj: disappearing xfs partition Subject: disappearing xfs partition MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: 573d54696549fa11 X-Barracuda-Connect: nf-out-0910.google.com[64.233.182.184] X-Barracuda-Start-Time: 1204550081 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.43762 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14755 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jeff@jab.org Precedence: bulk X-list: xfs I have no special reason to believe this is xfs specific, but is it common for partitions to vanish from the face of the earth, at least as far as mount is concerned? I usually mount by UUID, but here's a sightly interesting transcript by drive letters. If this is not xfs relevant, any suggestions where to start digging? This is a standard format XFS partition, created with an xfsprogs that I compiled a couple weeks ago from a source code download. Note that other xfs partitions are mounting fine on the same machine. -- after a fresh reboot --- # cfdisk /dev/sde Name Flags Part Type FS Type [Label] Size (MB) ------------------------------------------------------------------------------ sde1 Primary Linux XFS 1000202.28 # mount /dev/sde1 /mnt mount: special device /dev/sde1 does not exist # xfs_check /dev/sde1 /dev/sde1: No such file or directory fatal error -- couldn't initialize XFS library # fdisk /dev/sde The number of cylinders for this disk is set to 121601. There is nothing wrong with that, but this is larger than 1024, and could in certain setups cause problems with: 1) software that runs at boot time (e.g., old versions of LILO) 2) booting and partitioning software from other OSs (e.g., DOS FDISK, OS/2 FDISK) Command (m for help): p Disk /dev/sde: 1000.2 GB, 1000204886016 bytes 255 heads, 63 sectors/track, 121601 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk identifier: 0x00000000 Device Boot Start End Blocks Id System /dev/sde1 1 121601 976760001 83 Linux # cat /proc/version Linux version 2.6.24-8-server (buildd@yellow) (gcc version 4.2.3 (Ubuntu 4.2.3-1ubuntu2)) #1 SMP Thu Feb 14 20:42:20 UTC 2008 # dpkg -l xfsprogs Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-f/Unpacked/Failed-cfg/Half-inst/t-aWait/T-pend |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version Description +++-==============-==============-============================================ ii xfsprogs 2.9.5-1 Utilities for managing the XFS filesystem From owner-xfs@oss.sgi.com Mon Mar 3 05:57:53 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 03 Mar 2008 05:58:12 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_00, SUBJECT_FUZZY_TION autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m23Dvq5k030763 for ; Mon, 3 Mar 2008 05:57:52 -0800 X-ASG-Debug-ID: 1204552696-0bce004e0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from lucidpixels.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 09B21642436 for ; Mon, 3 Mar 2008 05:58:16 -0800 (PST) Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by cuda.sgi.com with ESMTP id LMZlQHMGhmfUtkWA for ; Mon, 03 Mar 2008 05:58:16 -0800 (PST) Received: by lucidpixels.com (Postfix, from userid 1001) id 5D00D1C00026B; Mon, 3 Mar 2008 08:58:16 -0500 (EST) Date: Mon, 3 Mar 2008 08:58:16 -0500 (EST) From: Justin Piszcz To: Jeff Breidenbach cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: disappearing xfs partition Subject: Re: disappearing xfs partition In-Reply-To: Message-ID: References: User-Agent: Alpine 1.00 (DEB 882 2007-12-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Barracuda-Connect: lucidpixels.com[75.144.35.66] X-Barracuda-Start-Time: 1204552701 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.43765 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14757 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs Looks like a udev problem or something is not making /dev/sde1? Have you tried a manual mknod of the device? On Mon, 3 Mar 2008, Jeff Breidenbach wrote: > I have no special reason to believe this is xfs specific, but > is it common for partitions to vanish from the face of the > earth, at least as far as mount is concerned? I usually mount > by UUID, but here's a sightly interesting transcript by drive > letters. If this is not xfs relevant, any suggestions where > to start digging? > > This is a standard format XFS partition, created with an > xfsprogs that I compiled a couple weeks ago from a source > code download. Note that other xfs partitions are mounting > fine on the same machine. > > > -- after a fresh reboot --- > > # cfdisk /dev/sde > > Name Flags Part Type FS Type [Label] Size (MB) > ------------------------------------------------------------------------------ > sde1 Primary Linux XFS 1000202.28 > > # mount /dev/sde1 /mnt > mount: special device /dev/sde1 does not exist > > # xfs_check /dev/sde1 > /dev/sde1: No such file or directory > > fatal error -- couldn't initialize XFS library > > # fdisk /dev/sde > > The number of cylinders for this disk is set to 121601. > There is nothing wrong with that, but this is larger than 1024, > and could in certain setups cause problems with: > 1) software that runs at boot time (e.g., old versions of LILO) > 2) booting and partitioning software from other OSs > (e.g., DOS FDISK, OS/2 FDISK) > > Command (m for help): p > > Disk /dev/sde: 1000.2 GB, 1000204886016 bytes > 255 heads, 63 sectors/track, 121601 cylinders > Units = cylinders of 16065 * 512 = 8225280 bytes > Disk identifier: 0x00000000 > > Device Boot Start End Blocks Id System > /dev/sde1 1 121601 976760001 83 Linux > > # cat /proc/version > Linux version 2.6.24-8-server (buildd@yellow) (gcc version 4.2.3 > (Ubuntu 4.2.3-1ubuntu2)) #1 SMP Thu Feb 14 20:42:20 UTC 2008 > > # dpkg -l xfsprogs > Desired=Unknown/Install/Remove/Purge/Hold > | Status=Not/Installed/Config-f/Unpacked/Failed-cfg/Half-inst/t-aWait/T-pend > |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) > ||/ Name Version Description > +++-==============-==============-============================================ > ii xfsprogs 2.9.5-1 Utilities for managing the XFS filesystem > > From owner-xfs@oss.sgi.com Mon Mar 3 08:19:43 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 03 Mar 2008 08:20:04 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00, SUBJECT_FUZZY_TION autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m23GJgDL013174 for ; Mon, 3 Mar 2008 08:19:43 -0800 X-ASG-Debug-ID: 1204561207-38fb00410000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 5E6DBF084D5 for ; Mon, 3 Mar 2008 08:20:08 -0800 (PST) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id GucNplOQSdaDSxCU for ; Mon, 03 Mar 2008 08:20:08 -0800 (PST) Received: from Liberator.local (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id EA35418004EDB; Mon, 3 Mar 2008 10:20:06 -0600 (CST) Message-ID: <47CC2536.7080205@sandeen.net> Date: Mon, 03 Mar 2008 10:20:06 -0600 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Justin Piszcz CC: Jeff Breidenbach , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: disappearing xfs partition Subject: Re: disappearing xfs partition References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1204561211 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.43774 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14758 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Justin Piszcz wrote: > Looks like a udev problem or something is not making /dev/sde1? Have you > tried a manual mknod of the device? but... it is not an xfs problem. :) (also check /proc/partitions for sde1...) -Eric From owner-xfs@oss.sgi.com Mon Mar 3 09:25:17 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 03 Mar 2008 09:25:36 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,SUBJECT_FUZZY_TION autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m23HPG3U017651 for ; Mon, 3 Mar 2008 09:25:17 -0800 X-ASG-Debug-ID: 1204565144-2adc00150000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from nf-out-0910.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id CDE2F644095 for ; Mon, 3 Mar 2008 09:25:44 -0800 (PST) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188]) by cuda.sgi.com with ESMTP id 8BF3lonYvNhMti05 for ; Mon, 03 Mar 2008 09:25:44 -0800 (PST) Received: by nf-out-0910.google.com with SMTP id e27so95784nfd.42 for ; Mon, 03 Mar 2008 09:25:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=DIMBF5R6+iTL3ZZDtwdp45IjxgPfLj+6jBmTkLSqfps=; b=c9fbdsZSO5cWUle+xrUX6fkx+lCbkF7+Ey75SySVlJ0LoFyL7bpZR6f4LcqwpvNXV14ywCs1nsAQ15QvW3KGyPiTnsZ16kUEH6VxoOl5Gy6GSYqPT5b/x6G88bUJdWd7VUCPxILKY6EY54Zeyf7RfVSdox0FDZ55mSj+8ZUFkuo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=nD7BD8jLtva7d0u2qAvLgb+NMJu70VYYqUXDnmS3O4i/eh+oz/dAfDoVmbGVk/SR+eyRWOh21WoxjMu8RnFssmezcR1bhsJmuuq3B/QneWkClDcmac0N8WqcgGYfDda5p3AGhrrtzw+Qhx6/TMFnAqtLgmS+SwVugR2foxJidUA= Received: by 10.78.77.9 with SMTP id z9mr298907hua.45.1204563668653; Mon, 03 Mar 2008 09:01:08 -0800 (PST) Received: by 10.78.184.20 with HTTP; Mon, 3 Mar 2008 09:01:08 -0800 (PST) Message-ID: Date: Mon, 3 Mar 2008 09:01:08 -0800 From: "Jeff Breidenbach" To: "Eric Sandeen" X-ASG-Orig-Subj: Re: disappearing xfs partition Subject: Re: disappearing xfs partition Cc: "Justin Piszcz" , xfs@oss.sgi.com In-Reply-To: <47CC2536.7080205@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <47CC2536.7080205@sandeen.net> X-Google-Sender-Auth: 632bb0dff25a8e86 X-Barracuda-Connect: nf-out-0910.google.com[64.233.182.188] X-Barracuda-Start-Time: 1204565145 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.43779 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14759 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jeff@jab.org Precedence: bulk X-list: xfs On Mon, Mar 3, 2008 at 8:20 AM, Eric Sandeen wrote: > Justin Piszcz wrote: > > Looks like a udev problem or something is not making /dev/sde1? Have you > > tried a manual mknod of the device? # mknod /dev/sde1 b 8 65 # mount /dev/sde1 /data2 mount: /dev/sde1 is not a valid block device > but... it is not an xfs problem. :) Sorry for posting. > (also check /proc/partitions for sde1...) Not present. # grep sde /proc/partitions 8 64 976762584 sde From owner-xfs@oss.sgi.com Mon Mar 3 17:29:30 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 03 Mar 2008 17:30:11 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m241TLRF028264 for ; Mon, 3 Mar 2008 17:29:30 -0800 X-ASG-Debug-ID: 1204594168-069400050000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from toro.qb3.berkeley.edu (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 19969647FC4 for ; Mon, 3 Mar 2008 17:29:28 -0800 (PST) Received: from toro.qb3.berkeley.edu (toro.QB3.Berkeley.EDU [169.229.244.93]) by cuda.sgi.com with ESMTP id 1OcC32XEhA5hUHL3 for ; Mon, 03 Mar 2008 17:29:28 -0800 (PST) Received: by toro.qb3.berkeley.edu (Postfix, from userid 14019) id 760B12393B1; Mon, 3 Mar 2008 17:29:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by toro.qb3.berkeley.edu (Postfix) with ESMTP id 6F8232393AE; Mon, 3 Mar 2008 17:29:27 -0800 (PST) Date: Mon, 3 Mar 2008 17:29:27 -0800 (PST) From: slaton X-X-Sender: slaton@toro.qb3.berkeley.edu To: Barry Naujok cc: xfs-oss X-ASG-Orig-Subj: Re: Linux XFS filesystem corruption (XFS_WANT_CORRUPTED_GOTO) Subject: Re: Linux XFS filesystem corruption (XFS_WANT_CORRUPTED_GOTO) In-Reply-To: Message-ID: References: <47C343D1.30304@sandeen.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Barracuda-Connect: toro.QB3.Berkeley.EDU[169.229.244.93] X-Barracuda-Start-Time: 1204594171 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.43811 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14760 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: slaton@berkeley.edu Precedence: bulk X-list: xfs Barry, I ran xfs_metadump (with -g -o -w options) on the partition and in addition to the file output this was written to stder: xfs_metadump: suspicious count 22 in bmap extent 9 in dir2 ino 940064492 xfs_metadump: suspicious count 21 in bmap extent 8 in dir2 ino 1348807890 xfs_metadump: suspicious count 29 in bmap extent 9 in dir2 ino 2826081099 xfs_metadump: suspicious count 23 in bmap extent 54 in dir2 ino 3093231364 xfs_metadump: suspicious count 106 in bmap extent 4 in dir2 ino 3505884782 Should i go ahead and do a mount/umount (to replay log) and then xfs_repair, or would another course of action be recommended, given these potential problem inodes? thanks slaton Slaton Lipscomb Nogales Lab, Howard Hughes Medical Institute http://cryoem.berkeley.edu On Thu, 28 Feb 2008, Barry Naujok wrote: > On Thu, 28 Feb 2008 09:44:04 +1100, slaton wrote: > > > Hi, > > > > I'm still hoping for some help with this. Is any more information needed > > in addition to the ksymoops output previously posted? > > > > In particular i'd like to know if just remounting the filesystem (to > > replay the journal), then unmounting and running xfs_repair is the best > > course of action. In addition, i'd like to know what recommended > > kernel/xfsprogs versions to use for best results. > > I would get xfsprogs 2.9.4 (2.9.6 is not a good version with your kernel), > ftp://oss.sgi.com/projects/xfs/previous/cmd_tars/xfsprogs_2.9.4-1.tar.gz > > To be on the safe side, either make an entire copy of your drive to > another device, or run "xfs_metadump -o /dev/sda1" to capture > a metadata (no file data) of your filesystem. > > Then run xfs_repair (mount/unmount maybe required if the log is dirty). > > If the filesystem is in a bad state after the repair (eg. everything in > lost+found), email the xfs_repair log and request further advise. > > Regards, > Barry. > > > > thanks > > slaton > > > > Slaton Lipscomb > > Nogales Lab, Howard Hughes Medical Institute > > http://cryoem.berkeley.edu > > > > On Mon, 25 Feb 2008, slaton wrote: > > > > > Thanks for the reply. > > > > > > > Are you hitting http://oss.sgi.com/projects/xfs/faq.html#dir2 ? > > > > > > Presumably not - i'm using 2.6.17.11, and that information indicates the > > > bug was fixed in 2.6.17.7. > > > > > > I've attached the output from running ksymoops on messages.1. First > > > crash/trace (Feb 21 19:xx) corresponds to the original XFS event; the > > > second (Feb 22 15:xx) is the system going down when i tried to unmount the > > > volume. > > > > > > Here are the additional syslog msgs corresponding to the Feb 22 15:xx > > > crash. > > > > > > Feb 22 15:47:13 qln01 kernel: grsec: From 10.0.2.93: unmount of /dev/sda1 > > > by /bin/umount[umount:18604] uid/euid:0/0 gid/egid:0/0, parent > > > /bin/bash[bash:31972] uid/euid:0/0 gid/egid:0/0 > > > Feb 22 15:47:14 qln01 kernel: xfs_force_shutdown(sda1,0x1) called from > > > line 338 of file fs/xfs/xfs_rw.c. Return address = 0xffffffff88173ce4 > > > Feb 22 15:47:14 qln01 kernel: xfs_force_shutdown(sda1,0x1) called from > > > line 338 of file fs/xfs/xfs_rw.c. Return address = 0xffffffff88173ce4 > > > Feb 22 15:47:28 qln01 kernel: BUG: soft lockup detected on CPU#0! > > > > > > thanks > > > slaton > > > > > From owner-xfs@oss.sgi.com Mon Mar 3 17:42:37 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 03 Mar 2008 17:42:58 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m241gZex029390 for ; Mon, 3 Mar 2008 17:42:37 -0800 X-ASG-Debug-ID: 1204594984-5a0802170000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from toro.qb3.berkeley.edu (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id A8C8A6480CE for ; Mon, 3 Mar 2008 17:43:04 -0800 (PST) Received: from toro.qb3.berkeley.edu (toro.QB3.Berkeley.EDU [169.229.244.93]) by cuda.sgi.com with ESMTP id pQRikbRjjIINKlUT for ; Mon, 03 Mar 2008 17:43:04 -0800 (PST) Received: by toro.qb3.berkeley.edu (Postfix, from userid 14019) id 05B942393B1; Mon, 3 Mar 2008 17:43:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by toro.qb3.berkeley.edu (Postfix) with ESMTP id 038E02393AE; Mon, 3 Mar 2008 17:43:04 -0800 (PST) Date: Mon, 3 Mar 2008 17:43:03 -0800 (PST) From: slaton X-X-Sender: slaton@toro.qb3.berkeley.edu To: Barry Naujok cc: xfs-oss X-ASG-Orig-Subj: Re: Linux XFS filesystem corruption (XFS_WANT_CORRUPTED_GOTO) Subject: Re: Linux XFS filesystem corruption (XFS_WANT_CORRUPTED_GOTO) In-Reply-To: Message-ID: References: <47C343D1.30304@sandeen.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Barracuda-Connect: toro.QB3.Berkeley.EDU[169.229.244.93] X-Barracuda-Start-Time: 1204594984 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.43811 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14761 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: slaton@berkeley.edu Precedence: bulk X-list: xfs Unfortunately, mounting triggered another XFS_WANT_CORRUPTED_GOTO error: XFS mounting filesystem sda1 Starting XFS recovery on filesystem: sda1 (logdev: internal) XFS internal error XFS_WANT_CORRUPTED_GOTO at line 1546 of file fs/xfs/xfs_alloc.c. Caller 0xffffffff882c3be6 Call Trace: [] :xfs:xfs_free_ag_extent+0x18a/0x690 [] :xfs:xfs_free_extent+0xa9/0xc9 [] :xfs:xlog_recover_process_efi+0x117/0x149 [] :xfs:xlog_recover_process_efis+0x46/0x6f [] :xfs:xlog_recover_finish+0x16/0x98 [] :xfs:xfs_log_mount_finish+0x19/0x1c [] :xfs:xfs_mountfs+0x892/0x99a [] :xfs:kmem_alloc+0x67/0xcd [] :xfs:kmem_zalloc+0x9/0x21 [] :xfs:xfs_mru_cache_create+0x127/0x188 [] :xfs:xfs_mount+0x333/0x3b4 [] :xfs:xfs_fs_fill_super+0x0/0x1ab [] :xfs:xfs_fs_fill_super+0x7e/0x1ab [] __down_write_nested+0x12/0x9a [] get_filesystem+0x12/0x35 [] sget+0x379/0x38e [] set_bdev_super+0x0/0xf [] get_sb_bdev+0x11d/0x168 [] vfs_kern_mount+0x94/0x124 [] do_kern_mount+0x3d/0xee [] do_mount+0x6e5/0x738 [] handle_mm_fault+0x385/0x789 [] __up_read+0x10/0x8a [] do_page_fault+0x453/0x7a3 [] handle_mm_fault+0x3ff/0x789 [] zone_statistics+0x41/0x63 [] __alloc_pages+0x6a/0x2d4 [] sys_mount+0x8b/0xce [] system_call+0x7e/0x83 Ending XFS recovery on filesystem: sda1 (logdev: internal) Haven't tried to unmount or anything else, yet. How to proceed? Just to reiterate, currently using kernel 2.6.23.16 and xfsprogs 2.9.4-1. thanks slaton Slaton Lipscomb Nogales Lab, Howard Hughes Medical Institute http://cryoem.berkeley.edu On Tue, 4 Mar 2008, Barry Naujok wrote: > On Tue, 04 Mar 2008 12:29:27 +1100, slaton wrote: > > > Barry, > > > > I ran xfs_metadump (with -g -o -w options) on the partition and in > > addition to the file output this was written to stder: > > > > xfs_metadump: suspicious count 22 in bmap extent 9 in dir2 ino 940064492 > > xfs_metadump: suspicious count 21 in bmap extent 8 in dir2 ino 1348807890 > > xfs_metadump: suspicious count 29 in bmap extent 9 in dir2 ino 2826081099 > > xfs_metadump: suspicious count 23 in bmap extent 54 in dir2 ino 3093231364 > > xfs_metadump: suspicious count 106 in bmap extent 4 in dir2 ino 3505884782 > > > > Should i go ahead and do a mount/umount (to replay log) and then > > xfs_repair, or would another course of action be recommended, given these > > potential problem inodes? > > Depending on the size of the directories, these numbers are probably fine. > I believe a mount/unmount/repair is the best course of action from here. > > So be extra safe, run another metadump after mount/unmount before running > repair. > > Barry. > > > thanks > > slaton > > > > Slaton Lipscomb > > Nogales Lab, Howard Hughes Medical Institute > > http://cryoem.berkeley.edu > > > > On Thu, 28 Feb 2008, Barry Naujok wrote: > > > > > On Thu, 28 Feb 2008 09:44:04 +1100, slaton wrote: > > > > > > > Hi, > > > > > > > > I'm still hoping for some help with this. Is any more information needed > > > > in addition to the ksymoops output previously posted? > > > > > > > > In particular i'd like to know if just remounting the filesystem (to > > > > replay the journal), then unmounting and running xfs_repair is the best > > > > course of action. In addition, i'd like to know what recommended > > > > kernel/xfsprogs versions to use for best results. > > > > > > I would get xfsprogs 2.9.4 (2.9.6 is not a good version with your kernel), > > > ftp://oss.sgi.com/projects/xfs/previous/cmd_tars/xfsprogs_2.9.4-1.tar.gz > > > > > > To be on the safe side, either make an entire copy of your drive to > > > another device, or run "xfs_metadump -o /dev/sda1" to capture > > > a metadata (no file data) of your filesystem. > > > > > > Then run xfs_repair (mount/unmount maybe required if the log is dirty). > > > > > > If the filesystem is in a bad state after the repair (eg. everything in > > > lost+found), email the xfs_repair log and request further advise. > > > > > > Regards, > > > Barry. > > > > > > > > > > thanks > > > > slaton > > > > > > > > Slaton Lipscomb > > > > Nogales Lab, Howard Hughes Medical Institute > > > > http://cryoem.berkeley.edu > > > > > > > > On Mon, 25 Feb 2008, slaton wrote: > > > > > > > > > Thanks for the reply. > > > > > > > > > > > Are you hitting http://oss.sgi.com/projects/xfs/faq.html#dir2 ? > > > > > > > > > > Presumably not - i'm using 2.6.17.11, and that information indicates > > > > the > > > > > bug was fixed in 2.6.17.7. > > > > > > > > > > I've attached the output from running ksymoops on messages.1. First > > > > > crash/trace (Feb 21 19:xx) corresponds to the original XFS event; the > > > > > second (Feb 22 15:xx) is the system going down when i tried to unmount > > > > the > > > > > volume. > > > > > > > > > > Here are the additional syslog msgs corresponding to the Feb 22 15:xx > > > > > crash. > > > > > > > > > > Feb 22 15:47:13 qln01 kernel: grsec: From 10.0.2.93: unmount of > > > > /dev/sda1 > > > > > by /bin/umount[umount:18604] uid/euid:0/0 gid/egid:0/0, parent > > > > > /bin/bash[bash:31972] uid/euid:0/0 gid/egid:0/0 > > > > > Feb 22 15:47:14 qln01 kernel: xfs_force_shutdown(sda1,0x1) called from > > > > > line 338 of file fs/xfs/xfs_rw.c. Return address = 0xffffffff88173ce4 > > > > > Feb 22 15:47:14 qln01 kernel: xfs_force_shutdown(sda1,0x1) called from > > > > > line 338 of file fs/xfs/xfs_rw.c. Return address = 0xffffffff88173ce4 > > > > > Feb 22 15:47:28 qln01 kernel: BUG: soft lockup detected on CPU#0! > > > > > > > > > > thanks > > > > > slaton > > > > > > > > > > > > From owner-xfs@oss.sgi.com Mon Mar 3 17:35:25 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 03 Mar 2008 17:51:26 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m241ZLHb028896 for ; Mon, 3 Mar 2008 17:35:23 -0800 Received: from pc-bnaujok.melbourne.sgi.com (pc-bnaujok.melbourne.sgi.com [134.14.55.58]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA09273; Tue, 4 Mar 2008 12:35:47 +1100 Date: Tue, 04 Mar 2008 12:36:57 +1100 To: slaton Subject: Re: Linux XFS filesystem corruption (XFS_WANT_CORRUPTED_GOTO) From: "Barry Naujok" Organization: SGI Cc: xfs-oss Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 References: <47C343D1.30304@sandeen.net> Message-ID: In-Reply-To: User-Agent: Opera Mail/9.24 (Win32) X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from Quoted-Printable to 8bit by oss.sgi.com id m241ZPHb028905 X-archive-position: 14762 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs On Tue, 04 Mar 2008 12:29:27 +1100, slaton wrote: > Barry, > > I ran xfs_metadump (with -g -o -w options) on the partition and in > addition to the file output this was written to stder: > > xfs_metadump: suspicious count 22 in bmap extent 9 in dir2 ino 940064492 > xfs_metadump: suspicious count 21 in bmap extent 8 in dir2 ino 1348807890 > xfs_metadump: suspicious count 29 in bmap extent 9 in dir2 ino 2826081099 > xfs_metadump: suspicious count 23 in bmap extent 54 in dir2 ino > 3093231364 > xfs_metadump: suspicious count 106 in bmap extent 4 in dir2 ino > 3505884782 > > Should i go ahead and do a mount/umount (to replay log) and then > xfs_repair, or would another course of action be recommended, given these > potential problem inodes? Depending on the size of the directories, these numbers are probably fine. I believe a mount/unmount/repair is the best course of action from here. So be extra safe, run another metadump after mount/unmount before running repair. Barry. > thanks > slaton > > Slaton Lipscomb > Nogales Lab, Howard Hughes Medical Institute > http://cryoem.berkeley.edu > > On Thu, 28 Feb 2008, Barry Naujok wrote: > >> On Thu, 28 Feb 2008 09:44:04 +1100, slaton wrote: >> >> > Hi, >> > >> > I'm still hoping for some help with this. Is any more information >> needed >> > in addition to the ksymoops output previously posted? >> > >> > In particular i'd like to know if just remounting the filesystem (to >> > replay the journal), then unmounting and running xfs_repair is the >> best >> > course of action. In addition, i'd like to know what recommended >> > kernel/xfsprogs versions to use for best results. >> >> I would get xfsprogs 2.9.4 (2.9.6 is not a good version with your >> kernel), >> ftp://oss.sgi.com/projects/xfs/previous/cmd_tars/xfsprogs_2.9.4-1.tar.gz >> >> To be on the safe side, either make an entire copy of your drive to >> another device, or run "xfs_metadump -o /dev/sda1" to capture >> a metadata (no file data) of your filesystem. >> >> Then run xfs_repair (mount/unmount maybe required if the log is dirty). >> >> If the filesystem is in a bad state after the repair (eg. everything in >> lost+found), email the xfs_repair log and request further advise. >> >> Regards, >> Barry. >> >> >> > thanks >> > slaton >> > >> > Slaton Lipscomb >> > Nogales Lab, Howard Hughes Medical Institute >> > http://cryoem.berkeley.edu >> > >> > On Mon, 25 Feb 2008, slaton wrote: >> > >> > > Thanks for the reply. >> > > >> > > > Are you hitting http://oss.sgi.com/projects/xfs/faq.html#dir2 ? >> > > >> > > Presumably not - i'm using 2.6.17.11, and that information >> indicates the >> > > bug was fixed in 2.6.17.7. >> > > >> > > I've attached the output from running ksymoops on messages.1. First >> > > crash/trace (Feb 21 19:xx) corresponds to the original XFS event; >> the >> > > second (Feb 22 15:xx) is the system going down when i tried to >> unmount the >> > > volume. >> > > >> > > Here are the additional syslog msgs corresponding to the Feb 22 >> 15:xx >> > > crash. >> > > >> > > Feb 22 15:47:13 qln01 kernel: grsec: From 10.0.2.93: unmount of >> /dev/sda1 >> > > by /bin/umount[umount:18604] uid/euid:0/0 gid/egid:0/0, parent >> > > /bin/bash[bash:31972] uid/euid:0/0 gid/egid:0/0 >> > > Feb 22 15:47:14 qln01 kernel: xfs_force_shutdown(sda1,0x1) called >> from >> > > line 338 of file fs/xfs/xfs_rw.c. Return address = >> 0xffffffff88173ce4 >> > > Feb 22 15:47:14 qln01 kernel: xfs_force_shutdown(sda1,0x1) called >> from >> > > line 338 of file fs/xfs/xfs_rw.c. Return address = >> 0xffffffff88173ce4 >> > > Feb 22 15:47:28 qln01 kernel: BUG: soft lockup detected on CPU#0! >> > > >> > > thanks >> > > slaton >> > >> > >> From owner-xfs@oss.sgi.com Mon Mar 3 19:02:31 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 03 Mar 2008 19:02:52 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,SUBJECT_FUZZY_TION autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m2432Tq1002004 for ; Mon, 3 Mar 2008 19:02:31 -0800 X-ASG-Debug-ID: 1204599778-5a1102c70000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from nf-out-0910.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 3AD3A648470 for ; Mon, 3 Mar 2008 19:02:58 -0800 (PST) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.191]) by cuda.sgi.com with ESMTP id 035xufRQN95Wuot2 for ; Mon, 03 Mar 2008 19:02:58 -0800 (PST) Received: by nf-out-0910.google.com with SMTP id e27so313040nfd.42 for ; Mon, 03 Mar 2008 19:02:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=M/GXK6+o0FtTeNIfsKUN8GJNRzTiSAHFEh7JhvWRg9g=; b=rZi9aJgCFPMNU0rMMMr47/oUnV5qf7HVuBuLi5Wk+fQdW9tKPMzJc1pHVjP8opfADCfnuQLJZKbkuWAycohwzW2RT5XfKrw0JmqxUaaeIXqMxGWnCZEfhW3gzqmcCloYw0kngULWdWn8qCA8TJkN5VFMhcQQBFQTuFUWR89LhgE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=HR2u77M5tAQzMSL1hDTJutndFrXj5sReAysLTjDXPieoqbUKZebIOqT2OIcVZfMr8g63gr2BJ4Y/EmCJrtUFvC5rPQ4rpOx0Ya6B4zj92qm8s0o8oT7uTWGCq1T8KMq26+nw5jr2JeruMW9wfE8Hy7BnoZ/1s4Cviw6Yph3uKYI= Received: by 10.78.157.19 with SMTP id f19mr1699195hue.48.1204599406220; Mon, 03 Mar 2008 18:56:46 -0800 (PST) Received: by 10.78.184.20 with HTTP; Mon, 3 Mar 2008 18:56:46 -0800 (PST) Message-ID: Date: Mon, 3 Mar 2008 18:56:46 -0800 From: "Jeff Breidenbach" To: "Eric Sandeen" , "Jeff Marshall" , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: disappearing xfs partition Subject: Re: disappearing xfs partition In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <47CC3444.4070902@sandeen.net> <47CC56CC.4020504@sandeen.net> X-Google-Sender-Auth: 8bc213df28c984d6 X-Barracuda-Connect: nf-out-0910.google.com[64.233.182.191] X-Barracuda-Start-Time: 1204599779 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.43817 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14763 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jeff@jab.org Precedence: bulk X-list: xfs Following up and close out the topic, I got this comment from Eric. >So parted has this bad habit of making partition tables that cannot >actually be read from the disk, and poking the supposedly values >directly into the kernel. Then things work fine until reboot, at which >time the partition table cannot be properly read. Usually this turns >into a truncated size due to an overflow.... I'd been using cfdisk and not parted, but that's apparently what happened. Rewriting the partition table with cfdisk fixed everything and allowed the partition to mount. At least for this boot. Thanks all. From owner-xfs@oss.sgi.com Mon Mar 3 21:37:36 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 03 Mar 2008 21:37:59 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_32, J_CHICKENPOX_43 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m245bYsB016598 for ; Mon, 3 Mar 2008 21:37:36 -0800 X-ASG-Debug-ID: 1204609082-5842001e0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.sceen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 3634A649524 for ; Mon, 3 Mar 2008 21:38:02 -0800 (PST) Received: from mail.sceen.net (sceen.net [213.41.243.68]) by cuda.sgi.com with ESMTP id Y6bONUG0Abz58wwZ for ; Mon, 03 Mar 2008 21:38:02 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sceen.net (Postfix) with ESMTP id 634ED1C530; Tue, 4 Mar 2008 06:37:29 +0100 (CET) Received: from mail.sceen.net ([127.0.0.1]) by localhost (mail.sceen.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22431-08; Tue, 4 Mar 2008 06:37:20 +0100 (CET) Received: from itchy (cesrt42.asia.info.net [61.14.27.42]) by mail.sceen.net (Postfix) with ESMTP id A1EF01C4C1; Tue, 4 Mar 2008 06:37:16 +0100 (CET) From: Niv Sardi To: xfs@oss.sgi.com Cc: xfs-dev@sgi.com X-ASG-Orig-Subj: [REVIEW] mkfs.xfs man page needs the default settings updated. Subject: [REVIEW] mkfs.xfs man page needs the default settings updated. Date: Tue, 04 Mar 2008 16:36:59 +1100 Message-ID: User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/23.0.60 (i486-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at sceen.net X-Barracuda-Connect: sceen.net[213.41.243.68] X-Barracuda-Start-Time: 1204609083 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.43827 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Status: Clean X-archive-position: 14764 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: xaiki@cxhome.ath.cx Precedence: bulk X-list: xfs --=-=-= Manpages update for the new defaults, please review, I believe I got'em all. --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=0001-Update-mkfs-manpage-for-new-defaults.patch >From 71011d480d52aaefe99ef252dfff513bf77f209e Mon Sep 17 00:00:00 2001 From: Niv Sardi Date: Fri, 22 Feb 2008 16:48:32 +1100 Subject: [PATCH] Update mkfs manpage for new defaults: log, attr and inodes v2, Drop the ability to turn unwritten extents off completly, reduce imaxpct for big filesystems, less AGs for single disks configs. --- xfsprogs/man/man8/mkfs.xfs.8 | 44 +++++------------------------------------ 1 files changed, 6 insertions(+), 38 deletions(-) diff --git a/xfsprogs/man/man8/mkfs.xfs.8 b/xfsprogs/man/man8/mkfs.xfs.8 index b6024c3..f9a89af 100644 --- a/xfsprogs/man/man8/mkfs.xfs.8 +++ b/xfsprogs/man/man8/mkfs.xfs.8 @@ -304,7 +304,8 @@ bits. This specifies the maximum percentage of space in the filesystem that can be allocated to inodes. The default .I value -is 25%. Setting the +is 25% for filesystems under 1TB, 5% for filesystems under 50TB and 1% +for filesystems over 50TB. Setting the .I value to 0 means that essentially all of the filesystem can become inode blocks. @@ -327,16 +328,10 @@ that does not have the inode alignment feature .BI attr[= value ] This is used to specify the version of extended attribute inline allocation policy to be used. -By default, this is zero. Once extended attributes are used for the +By default, this is 2. Once extended attributes are used for the first time, the version will be set to either one or two. The current version (two) uses a more efficient algorithm for managing -the available inline inode space than version one does, however, for -backward compatibility reasons (and in the absence of the -.B attr=2 -mkfs option, or the -.B attr2 -mount option), version one will be selected -by default when attributes are first used on a filesystem. +the available inline inode space than version one does. .RE .TP .BI \-l " log_section_options" @@ -389,15 +384,9 @@ and directory block size, the minimum log size is larger than 512 blocks. .BI version= value This specifies the version of the log. The .I value -is either 1 or 2. Specifying +is either 1 or 2 (the default is 2). .B version=2 -enables the -.B sunit -suboption, and allows the logbsize to be increased beyond 32K. -Version 2 logs are automatically selected if a log stripe unit -is specified. See -.BR sunit " and " su -suboptions, below. +allows the logbsize to be increased beyond 32K. .TP .BI sunit= value This specifies the alignment to be used for log writes. The @@ -430,27 +419,6 @@ suffixes). This value must be a multiple of the filesystem block size. Version 2 logs are automatically selected if the log .B su suboption is specified. -.TP -.BI lazy-count= value -This changes the method of logging various persistent counters -in the superblock. Under metadata intensive workloads, these -counters are updated and logged frequently enough that the superblock -updates become a serialisation point in the filesystem. The -.I value -can be either 0 or 1. -.IP -With -.BR lazy-count=1 , -the superblock is not modified or logged on every change of the -persistent counters. Instead, enough information is kept in -other parts of the filesystem to be able to maintain the persistent -counter values without needed to keep them in the superblock. -This gives significant improvements in performance on some configurations. -The default -.I value -is 0 (off) so you must specify -.B lazy-count=1 -if you want to make use of this feature. .RE .TP .BI \-n " naming_options" -- 1.5.4.1 --=-=-= -- Niv Sardi --=-=-=-- From owner-xfs@oss.sgi.com Tue Mar 4 07:38:31 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 04 Mar 2008 07:38:51 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_32, J_CHICKENPOX_43 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m24FcUf9029632 for ; Tue, 4 Mar 2008 07:38:31 -0800 X-ASG-Debug-ID: 1204645138-6e38037e0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 629ABF135CB for ; Tue, 4 Mar 2008 07:38:58 -0800 (PST) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id pGa93fKLGXAWBOsp for ; Tue, 04 Mar 2008 07:38:58 -0800 (PST) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 855E218DA0AF5; Tue, 4 Mar 2008 09:38:54 -0600 (CST) Message-ID: <47CD6D0E.3090301@sandeen.net> Date: Tue, 04 Mar 2008 09:38:54 -0600 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Niv Sardi CC: xfs@oss.sgi.com, xfs-dev@sgi.com X-ASG-Orig-Subj: Re: [REVIEW] mkfs.xfs man page needs the default settings updated. Subject: Re: [REVIEW] mkfs.xfs man page needs the default settings updated. References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1204645139 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.43868 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14765 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Niv Sardi wrote: > Manpages update for the new defaults, please review, I believe I got'em all. (hmm attachments make it slightly trickier to reply inline...) >>From 71011d480d52aaefe99ef252dfff513bf77f209e Mon Sep 17 00:00:00 2001 > From: Niv Sardi > Date: Fri, 22 Feb 2008 16:48:32 +1100 > Subject: [PATCH] Update mkfs manpage for new defaults: > > log, attr and inodes v2, > Drop the ability to turn unwritten extents off completly, > reduce imaxpct for big filesystems, less AGs for single disks configs. > --- > xfsprogs/man/man8/mkfs.xfs.8 | 44 +++++------------------------------------ > 1 files changed, 6 insertions(+), 38 deletions(-) > > diff --git a/xfsprogs/man/man8/mkfs.xfs.8 b/xfsprogs/man/man8/mkfs.xfs.8 > index b6024c3..f9a89af 100644 > --- a/xfsprogs/man/man8/mkfs.xfs.8 > +++ b/xfsprogs/man/man8/mkfs.xfs.8 > @@ -304,7 +304,8 @@ bits. > This specifies the maximum percentage of space in the filesystem that > can be allocated to inodes. The default > .I value > -is 25%. Setting the > +is 25% for filesystems under 1TB, 5% for filesystems under 50TB and 1% > +for filesystems over 50TB. Setting the > .I value > to 0 means that essentially all of the filesystem can > become inode blocks. Is it worth saying why you might want to override this? (i.e. why was it reduced for large filesystems, what was detrimental about having 25% at 50T?) > @@ -327,16 +328,10 @@ that does not have the inode alignment feature > .BI attr[= value ] > This is used to specify the version of extended attribute inline allocation > policy to be used. > -By default, this is zero. Once extended attributes are used for the > +By default, this is 2. Once extended attributes are used for the > first time, the version will be set to either one or two. well, it will be set to what is specified, or the default, right? Again, why would I choose one over the other? > The current version (two) uses a more efficient algorithm for managing > -the available inline inode space than version one does, however, for > -backward compatibility reasons (and in the absence of the > -.B attr=2 > -mkfs option, or the > -.B attr2 > -mount option), version one will be selected > -by default when attributes are first used on a filesystem. > +the available inline inode space than version one does. ah so I would never want to use 1? Or might I want to use it for backwards compatibility? or? > .RE > .TP > .BI \-l " log_section_options" > @@ -389,15 +384,9 @@ and directory block size, the minimum log size is larger than 512 blocks. > .BI version= value > This specifies the version of the log. The > .I value > -is either 1 or 2. Specifying > +is either 1 or 2 (the default is 2). > .B version=2 > -enables the > -.B sunit > -suboption, and allows the logbsize to be increased beyond 32K. > -Version 2 logs are automatically selected if a log stripe unit > -is specified. See > -.BR sunit " and " su > -suboptions, below. > +allows the logbsize to be increased beyond 32K. and it allows the sunit/su suboptions? And what's this 32K thing, and what's logbsize? The first-time reader may wonder what's special about 32K. Why would one want to use logv1 at this point, any reason? Perhaps it would be better to document limitations of v1 rather than the non-limitations of v2? Or just drop v1 altogether? > .TP > .BI sunit= value > This specifies the alignment to be used for log writes. The > @@ -430,27 +419,6 @@ suffixes). This value must be a multiple of the filesystem block size. > Version 2 logs are automatically selected if the log > .B su > suboption is specified. > -.TP > -.BI lazy-count= value > -This changes the method of logging various persistent counters > -in the superblock. Under metadata intensive workloads, these > -counters are updated and logged frequently enough that the superblock > -updates become a serialisation point in the filesystem. The > -.I value > -can be either 0 or 1. > -.IP > -With > -.BR lazy-count=1 , > -the superblock is not modified or logged on every change of the > -persistent counters. Instead, enough information is kept in > -other parts of the filesystem to be able to maintain the persistent > -counter values without needed to keep them in the superblock. > -This gives significant improvements in performance on some configurations. > -The default > -.I value > -is 0 (off) so you must specify > -.B lazy-count=1 > -if you want to make use of this feature. lazy-count is no longer a configurable option? -Eric > .RE > .TP > .BI \-n " naming_options" > -- 1.5.4.1 > > > > > -- Niv Sardi From owner-xfs@oss.sgi.com Tue Mar 4 07:46:05 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 04 Mar 2008 07:46:12 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_32, J_CHICKENPOX_43 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m24Fk5v1030487 for ; Tue, 4 Mar 2008 07:46:05 -0800 X-ASG-Debug-ID: 1204645592-4c7c02210000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id A127C64D006 for ; Tue, 4 Mar 2008 07:46:32 -0800 (PST) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id Ve2XMOmcOE9bwfYH for ; Tue, 04 Mar 2008 07:46:32 -0800 (PST) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 9D1C918004EFE; Tue, 4 Mar 2008 09:46:31 -0600 (CST) Message-ID: <47CD6ED7.5050505@sandeen.net> Date: Tue, 04 Mar 2008 09:46:31 -0600 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Niv Sardi CC: xfs@oss.sgi.com, xfs-dev@sgi.com X-ASG-Orig-Subj: Re: [REVIEW] mkfs.xfs man page needs the default settings updated. Subject: Re: [REVIEW] mkfs.xfs man page needs the default settings updated. References: <47CD6D0E.3090301@sandeen.net> In-Reply-To: <47CD6D0E.3090301@sandeen.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1204645594 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.43867 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14766 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Eric Sandeen wrote: > Niv Sardi wrote: >> Manpages update for the new defaults, please review, I believe I got'em all. > (btw review was a bit pedantic becase there are always a million questions about tuning & options. Let's try to be as clear as we can in the manpage at least...) -Eric From owner-xfs@oss.sgi.com Tue Mar 4 08:30:55 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 04 Mar 2008 08:31:13 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00,MIME_8BIT_HEADER autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m24GUsvd005661 for ; Tue, 4 Mar 2008 08:30:55 -0800 X-ASG-Debug-ID: 1204648282-3fe4005a0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ti-out-0910.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id C45F564D5A7 for ; Tue, 4 Mar 2008 08:31:23 -0800 (PST) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.191]) by cuda.sgi.com with ESMTP id FmQKtoholXYeRcFp for ; Tue, 04 Mar 2008 08:31:23 -0800 (PST) Received: by ti-out-0910.google.com with SMTP id d10so1204261tib.18 for ; Tue, 04 Mar 2008 08:31:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:subject:content-type:content-transfer-encoding; bh=0qmogXXSvrGI+4QZv8oYc26LNe9+HixUt5siDIbf2ms=; b=oyqcWA7h/ZDMrkKNGNd4c7QTJpzb7CqSzBhB+hW/fwGr4tI/iT0921kl0wBTSXr1Pd9A09zrtAWETrgRBRXONm1REE8pFxiint8LpbzfMqh1ZOjznaIxkWnka00SOcq/gORtonAY6iGVblDwiRD/G8RxZYXMvGtC/MCXqfuqFnY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:content-type:content-transfer-encoding; b=EzimavExLjLGoR2gv2ffjfWgayAoFH5e6SlELNhcJFL8g79No69ryn6lXpXLgANWSuCkKNABxCLhcePXOPPb3jjxjK+BVyhXHqgISQfcc+wFF5iHYIfQ4oh+Lfd8kDk+Otnsa/fgvM+ibUxIH6SuqAqVCuB4hMOi0SF3SsL2hfs= Received: by 10.150.195.21 with SMTP id s21mr597416ybf.114.1204648279440; Tue, 04 Mar 2008 08:31:19 -0800 (PST) Received: from ?89.174.127.38? ( [89.174.127.38]) by mx.google.com with ESMTPS id f4sm665472nfh.26.2008.03.04.08.31.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 04 Mar 2008 08:31:17 -0800 (PST) Message-ID: <47CD7950.9040001@gmail.com> Date: Tue, 04 Mar 2008 17:31:12 +0100 From: =?UTF-8?B?QXJ0dXIgTWFrw7N3a2E=?= User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: xfs@oss.sgi.com X-ASG-Orig-Subj: creating new array Subject: creating new array Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: ti-out-0910.google.com[209.85.142.191] X-Barracuda-Start-Time: 1204648283 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.43871 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14767 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: artur.makowka@gmail.com Precedence: bulk X-list: xfs i want to create new array, because my last one (raid 0) is gone... now it is going to be raid 5. this will be on xfs fs of course. now the problem is i don't really know what chunk size i should use, to get the best performance, but i can still mount old array read-only and check what is average file size there - just don't know how. (doing ls -lR * , adding sizes and dividing by number is probably going to take days to complete) there was some xfs command that showed it, but i really have no idea what it was, xfs_info doesnt give me much information the currect situation is like this: meta-data=/dev/md0 isize=256 agcount=32, agsize=5723342 blks = sectsz=512 attr=0 data = bsize=4096 blocks=183146912, imaxpct=25 = sunit=2 swidth=6 blks naming =version 2 bsize=4096 log =internal bsize=4096 blocks=32768, version=2 = sectsz=512 sunit=0 blks, lazy-count=0 realtime =none extsz=24576 blocks=0, rtextents=0 some of the files are not on it anymore, as i said, it is damaged RAID 0 the system is going to have millions of small files, (up to 3MB), or even hundreds of millions (very popular free hosting) could you advice me any xfs and mdadm options? i plan to use lazyblocks option with latest 2.6.24 kernel. any other ideas? this is going to be RAID 5, the stability is NOT very important, i will have full backups, the most important thing is performance. i can get hundreds of hits per second at peak times, i was planning to build it from 5 * 500GB disks and it will be just partition for users file, system is on another disk. (probably on lvm to give me option to resize it in future) fs performance is critical, as i have many thousands of accounts, mostly with just small websites, so it's impossible to put it all in RAM. if you have any xfs/mdadm creating advice (or mounting options), please share with me. i installed xfsprogs 2.9.7, and i will compile 2.6.24 kernel for creation time ( i can even risk using 2.6.25-rcX if there is some important thing changed that i need durning array/filesystem creation, just not -mm as XFS version from -mm once corrupted some of my users files ) From owner-xfs@oss.sgi.com Tue Mar 4 14:05:32 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 04 Mar 2008 14:05:53 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,J_CHICKENPOX_57 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m24M5VBS001732 for ; Tue, 4 Mar 2008 14:05:32 -0800 X-ASG-Debug-ID: 1204668360-6ae101390000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from web32504.mail.mud.yahoo.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with SMTP id 1D48D650992 for ; Tue, 4 Mar 2008 14:06:00 -0800 (PST) Received: from web32504.mail.mud.yahoo.com (web32504.mail.mud.yahoo.com [68.142.207.214]) by cuda.sgi.com with SMTP id pERavPbWZQ7iWdsY for ; Tue, 04 Mar 2008 14:06:00 -0800 (PST) Received: (qmail 73982 invoked by uid 60001); 4 Mar 2008 22:05:59 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=Tk43Q2OHx9+EB80rvbpOdjIh1F4xJ/zjWAanSKLhAWOk7ec9uXsVJoelfuz93DG2sHUojU2+6kIYHzWpl/lNvF0bHkpttIwmLGai7eo7WjLnVBtpbxR8zkj0V8vrM1qsNOT6E5puhnRc5tM/FF18JKYQsEbZLnJn0xCiRgR8a8U=; X-YMail-OSG: 6LFdT4sVM1koSjSG4jYlof98KOPGRa8CyxbSpZo7QFnOnP8sCTzblNbC8KmXHDhYaAuMyAz03ifSdQ5AgQwuL9UUwvqNNdGVuXXOBfLIW6Rxslu1wpo- Received: from [162.62.93.100] by web32504.mail.mud.yahoo.com via HTTP; Tue, 04 Mar 2008 14:05:59 PST Date: Tue, 4 Mar 2008 14:05:59 -0800 (PST) From: Ravi Wijayaratne X-ASG-Orig-Subj: corruption in xfs_end_bio_unwritten Subject: corruption in xfs_end_bio_unwritten To: xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <629727.55106.qm@web32504.mail.mud.yahoo.com> X-Barracuda-Connect: web32504.mail.mud.yahoo.com[68.142.207.214] X-Barracuda-Start-Time: 1204668361 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.43893 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14768 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: ravi_wija@yahoo.com Precedence: bulk X-list: xfs Hi all, I am seeing data corruption in xfs_end_bio_unwritten. Possibly the corruption is happening before. Here is what I see. The ioend->io_offset and ioend->io_size is completely beyond the range of the size of the file or the device altogether. The problem occurs under heavy I/O stress on 4 20GB files that was created using XFS_IOC_RESVSP64 ioctl. For a sparse file of the same size the problem does not occur. Also the problem is not seen on moderate the low system I/O loads(Created by I/O meter) It trips on the VOP_BMP(..) call that eventually calls xfs_btree_check_lblock. I am aware that this function has changed in the tip to call xfs_iomap_write_unwritten directly instead of calling xfs_iomap via VOP_BMAP. I believe that even if I change the code to what is in the tip I would still stumble some where on the fact that a write to a undefined range was completed. The call stack that was dumped by XFS_ERROR_REPORT was as follows Any thoughts how I could fix this? Thanks in advance Ravi 1> Oct 22 21:12:57 Foo kernel: Filesystem "dm-0": XFS internal error xfs_btree_check_lblock at line 215 of file fs/xfs/xfs_btree.c. Caller 0x781f907a <4> Oct 22 21:12:57 Foo kernel: [<781fc212>] xfs_btree_check_lblock+0x52/0x1c0 <4> Oct 22 21:12:57 Foo kernel: [<781f907a>] xfs_bmbt_lookup+0x1fa/0x5f0 <4> Oct 22 21:12:57 Foo kernel: [<781f907a>] xfs_bmbt_lookup+0x1fa/0x5f0 <4> Oct 22 21:12:57 Foo kernel: [<781ed172>] xfs_bmap_add_extent_unwritten_real+0xd62/0xfd0 <4> Oct 22 21:12:57 Foo kernel: [<781ee030>] xfs_bmap_add_extent+0x6f0/0x1f10 <4> Oct 22 21:12:57 Foo kernel: [<78324250>] dm_request+0xf0/0x13c <4> Oct 22 21:12:57 Foo kernel: [<78324160>] dm_request+0x0/0x13c <4> Oct 22 21:12:57 Foo kernel: [<78263561>] generic_make_request+0x161/0x210 <4> Oct 22 21:12:57 Foo kernel: [<782c97e5>] scsi_delete_timer+0x15/0x60 <4> Oct 22 21:12:57 Foo kernel: [<781150b6>] find_busiest_group+0x256/0x310 <4> Oct 22 21:12:57 Foo kernel: [<782653f5>] submit_bio+0x55/0x100 <4> Oct 22 21:12:57 Foo kernel: [<781678a7>] bio_add_page+0x37/0x50 <4> Oct 22 21:12:57 Foo kernel: [<781f6a54>] xfs_bmbt_get_state+0x14/0x30 <4> Oct 22 21:12:57 Foo kernel: [<781f02de>] xfs_bmap_do_search_extents+0x2fe/0x480 <4> Oct 22 21:12:57 Foo kernel: [<782462b7>] xfs_buf_iorequest+0x347/0x440 <4> Oct 22 21:12:57 Foo kernel: [<78247538>] kmem_zone_alloc+0x58/0xd0 <4> Oct 22 21:12:57 Foo kernel: [<781f1f73>] xfs_bmapi+0x19b3/0x2e20 <4> Oct 22 21:12:57 Foo kernel: [<78220466>] xlog_write+0x6e6/0x800 <4> Oct 22 21:12:57 Foo kernel: [<78228158>] xfs_icsb_modify_counters_locked+0x18/0x20 <4> Oct 22 21:12:57 Foo kernel: [<7822db93>] xfs_trans_tail_ail+0x13/0x30 <4> Oct 22 21:12:58 Foo kernel: [<7821f2d8>] xlog_assign_tail_lsn+0x28/0x60 <4> Oct 22 21:12:58 Foo kernel: [<7821f337>] xlog_state_release_iclog+0x27/0x530 <4> Oct 22 21:12:58 Foo kernel: [<7822f069>] xfs_trans_unlock_items+0xa9/0xb0 <4> Oct 22 21:12:58 Foo kernel: [<78221861>] xfs_log_release_iclog+0x11/0x40 <4> Oct 22 21:12:58 Foo kernel: [<7822d8b9>] _xfs_trans_commit+0x8e9/0xa60 <4> Oct 22 21:12:58 Foo kernel: [<782207bc>] xlog_grant_push_ail+0x3c/0x150 <4> Oct 22 21:12:58 Foo kernel: [<78220ece>] xfs_log_reserve+0x5fe/0x780 <4> Oct 22 21:12:58 Foo kernel: [<7822eb41>] xfs_trans_ijoin+0x31/0x70 <4> Oct 22 21:12:58 Foo kernel: [<7823ad6d>] xfs_iomap_write_unwritten+0x1bd/0x300 <4> Oct 22 21:12:58 Foo kernel: [<7823a633>] xfs_iomap+0x513/0x850 <4> Oct 22 21:12:58 Foo kernel: [<78149631>] test_clear_page_writeback+0x51/0xc0 <4> Oct 22 21:12:58 Foo kernel: [<78166059>] end_buffer_async_write+0xa9/0x140 <4> Oct 22 21:12:58 Foo kernel: [<7823ca58>] xfs_end_bio_unwritten+0x48/0x60 <4> Oct 22 21:12:58 Foo kernel: [<7812c712>] run_workqueue+0x72/0xf0 <4> Oct 22 21:12:58 Foo kernel: [<7823ca10>] xfs_end_bio_unwritten+0x0/0x60 <4> Oct 22 21:12:58 Foo kernel: [<7812cf5b>] worker_thread+0x13b/0x160 <4> Oct 22 21:12:58 Foo kernel: [<78115b40>] default_wake_function+0x0/0x10 <4> Oct 22 21:12:58 Foo kernel: [<7812ce20>] worker_thread+0x0/0x160 <4> Oct 22 21:12:58 Foo kernel: [<7812fd7b>] kthread+0xab/0xe0 <4> Oct 22 21:12:58 Foo kernel: [<7812fcd0>] kthread+0x0/0xe0 <4> Oct 22 21:12:58 Foo kernel: [<78100df5>] kernel_thread_helper+0x5/0x10 ------------------------------ Ravi Wijayaratne ____________________________________________________________________________________ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping From owner-xfs@oss.sgi.com Tue Mar 4 14:15:51 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 04 Mar 2008 14:16:11 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_57 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m24MFnAd002936 for ; Tue, 4 Mar 2008 14:15:51 -0800 X-ASG-Debug-ID: 1204668978-0b3200310000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 54BB4650A89 for ; Tue, 4 Mar 2008 14:16:19 -0800 (PST) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id ZN2u6mViTEoEgMhu for ; Tue, 04 Mar 2008 14:16:19 -0800 (PST) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 0A5D418004EE3; Tue, 4 Mar 2008 16:15:47 -0600 (CST) Message-ID: <47CDCA12.5060107@sandeen.net> Date: Tue, 04 Mar 2008 16:15:46 -0600 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Ravi Wijayaratne CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: corruption in xfs_end_bio_unwritten Subject: Re: corruption in xfs_end_bio_unwritten References: <629727.55106.qm@web32504.mail.mud.yahoo.com> In-Reply-To: <629727.55106.qm@web32504.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1204668979 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.43893 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14769 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Ravi Wijayaratne wrote: > Hi all, > > I am seeing data corruption in xfs_end_bio_unwritten. Possibly the corruption is happening before. > Here is what I see. what kernel, for starters? > The ioend->io_offset and ioend->io_size is completely beyond the range of the size of the file or > the device altogether. The problem occurs under heavy I/O stress on 4 20GB files that was created > using XFS_IOC_RESVSP64 ioctl. For a sparse file of the same size the problem does not occur. Also > the problem is not seen on moderate the low system I/O loads(Created by I/O meter) > > It trips on the VOP_BMP(..) call that eventually calls xfs_btree_check_lblock. I am aware that > this function has changed in the tip to call xfs_iomap_write_unwritten directly instead of calling > xfs_iomap via VOP_BMAP. I believe that even if I change the code to what is in the tip I would > still stumble some where on the fact that a write to a undefined range was completed. The call > stack that was dumped by XFS_ERROR_REPORT was as follows > > Any thoughts how I could fix this? > > Thanks in advance > From owner-xfs@oss.sgi.com Tue Mar 4 19:52:40 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 04 Mar 2008 19:52:48 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_33 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m253qdam014414 for ; Tue, 4 Mar 2008 19:52:40 -0800 X-ASG-Debug-ID: 1204689188-79c100230000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 63821652FA2 for ; Tue, 4 Mar 2008 19:53:08 -0800 (PST) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id KUyUB1mFC4DTOQNg for ; Tue, 04 Mar 2008 19:53:08 -0800 (PST) Received: from liberator.sandeen.net (sandeen.net [209.173.210.139]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id AFA7718004EE3; Tue, 4 Mar 2008 21:53:06 -0600 (CST) Message-ID: <47CE1921.9000708@sandeen.net> Date: Tue, 04 Mar 2008 21:53:05 -0600 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Ravi Wijayaratne CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: corruption in xfs_end_bio_unwritten Subject: Re: corruption in xfs_end_bio_unwritten References: <629727.55106.qm@web32504.mail.mud.yahoo.com> <47CDCA12.5060107@sandeen.net> In-Reply-To: <47CDCA12.5060107@sandeen.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1204689189 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.43916 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14770 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Eric Sandeen wrote: > Ravi Wijayaratne wrote: >> Hi all, >> >> I am seeing data corruption in xfs_end_bio_unwritten. Possibly the corruption is happening before. >> Here is what I see. > > what kernel, for starters? 2.6.16 + XFS from SLES10 I hear... :) So for starters, I'd bug SuSE.... otherwise I'd see if it persists upstream. Is AIO+DIO in the mix? perhaps it is related to https://bugzilla.redhat.com/show_bug.cgi?id=217098 -Eric From owner-xfs@oss.sgi.com Tue Mar 4 20:34:50 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 04 Mar 2008 20:35:09 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_43 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m254Yfsj020186 for ; Tue, 4 Mar 2008 20:34:45 -0800 Received: from pc-bnaujok.melbourne.sgi.com (pc-bnaujok.melbourne.sgi.com [134.14.55.58]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA26650 for ; Wed, 5 Mar 2008 15:35:10 +1100 Date: Wed, 05 Mar 2008 15:37:07 +1100 To: "xfs@oss.sgi.com" Subject: [REVIEW #4] bad_features2 support in userspace From: "Barry Naujok" Organization: SGI Content-Type: multipart/mixed; boundary=----------ypN4flJIlmhdmVY5eNxenW MIME-Version: 1.0 Message-ID: User-Agent: Opera Mail/9.24 (Win32) X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14771 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs ------------ypN4flJIlmhdmVY5eNxenW Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 Content-Transfer-Encoding: Base64 RHVlIHRvIHRoZSBpc3N1ZSBvZiBtb3VudGluZyBmaWxlc3lzdGVtIHdpdGgg b2xkZXIga2VybmVscyBhbmQNCnBvdGVudGlhbGx5IHJlYWRpbmcgc2JfZmVh dHVyZXMyIGZyb20gdGhlIHdyb25nIGxvY2F0aW9uLiBJdA0Kc2VlbXMgdGhl IGJlc3QgY291cnNlIG9mIGFjdGlvbiBpcyB0byBhbHdheXMgbWFrZSBzYl9m ZWF0dXJlczINCmFuZCBzYl9iYWRfZmVhdHVyZXMyIHRoZSBzYW1lLiBUaGlz IGlzIHByZXR0eSBpbXBvcnRhbnQgYXMNCm5ldyBiaXRzIGluIHRoaXMgYXJl IHN1cHBvc2VkIHRvIHN0b3Agb2xkZXIga2VybmVscyBmcm9tDQptb3VudGlu ZyBmaWxlc3lzdGVtcyB3aXRoIHVuc3VwcG9ydGVkIGZlYXR1cmVzLg0KDQpJ ZiBzYl9iYWRfZmVhdHVyZXMyIGlzIHplcm8sIGFuZCB0aGUgb2xkIGtlcm5l bCB0cmllcyB0byByZWFkDQpzYl9mZWF0dXJlczIgZnJvbSB0aGlzIGxvY2F0 aW9uIGR1cmluZyBtb3VudCwgaXQgd2lsbCBzdWNjZWVkDQphcyBpdCB3aWxs IHJlYWQgemVyby4NCg0KU28sIHRoaXMgcGF0Y2ggY2hhbmdlcyBta2ZzLnhm cyB0byBzZXQgc2JfYmFkX2ZlYXR1cmVzMiB0bw0KdGhlIHNhbWUgYXMgc2Jf ZmVhdHVyZXMyLCB4ZnNfY2hlY2sgYW5kIHhmc19yZXBhaXIgbm93IGFsc28N Cm1ha2VzIHN1cmUgdGhleSBhcmUgdGhlIHNhbWUuDQoNCkJhcnJ5Lg0KDQot LQ0KDQoNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KeGZzcHJv Z3MvZGIvY2hlY2suYw0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 DQoNCi0tLSBhL3hmc3Byb2dzL2RiL2NoZWNrLmMJMjAwOC0wMy0wNSAxNToz MDo1NC4wMDAwMDAwMDAgKzExMDANCisrKyBiL3hmc3Byb2dzL2RiL2NoZWNr LmMJMjAwOC0wMy0wNSAxNToyODo1OC42MzgwOTc1MTEgKzExMDANCkBAIC04 NjksNiArODY5LDE0IEBAIGJsb2NrZ2V0X2YoDQogIAkJCQltcC0+bV9zYi5z Yl9mcmV4dGVudHMsIGZyZXh0ZW50cyk7DQogIAkJZXJyb3IrKzsNCiAgCX0N CisJaWYgKG1wLT5tX3NiLnNiX2JhZF9mZWF0dXJlczIgIT0gbXAtPm1fc2Iu c2JfZmVhdHVyZXMyKSB7DQorCQlpZiAoIXNmbGFnKQ0KKwkJCWRicHJpbnRm KCJzYl9mZWF0dXJlczIgKDB4JXgpIG5vdCBzYW1lIGFzICINCisJCQkJInNi X2JhZF9mZWF0dXJlczIgKDB4JXgpXG4iLA0KKwkJCQltcC0+bV9zYi5zYl9m ZWF0dXJlczIsDQorCQkJCW1wLT5tX3NiLnNiX2JhZF9mZWF0dXJlczIpOw0K KwkJZXJyb3IrKzsNCisJfQ0KICAJaWYgKChzYnZlcnNpb24gJiBYRlNfU0Jf VkVSU0lPTl9BVFRSQklUKSAmJg0KICAJICAgICFYRlNfU0JfVkVSU0lPTl9I QVNBVFRSKCZtcC0+bV9zYikpIHsNCiAgCQlpZiAoIXNmbGFnKQ0KDQo9PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT0NCnhmc3Byb2dzL2RiL3NiLmMN Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KDQotLS0gYS94ZnNw cm9ncy9kYi9zYi5jCTIwMDgtMDMtMDUgMTU6MzA6NTQuMDAwMDAwMDAwICsx MTAwDQorKysgYi94ZnNwcm9ncy9kYi9zYi5jCTIwMDgtMDItMjkgMTc6MTY6 MzMuNzcwNDIzMjk2ICsxMTAwDQpAQCAtMTA4LDYgKzEwOCw3IEBAIGNvbnN0 IGZpZWxkX3QJc2JfZmxkc1tdID0gew0KICAJeyAibG9nc2VjdHNpemUiLCBG TERUX1VJTlQxNkQsIE9JKE9GRihsb2dzZWN0c2l6ZSkpLCBDMSwgMCwgVFlQ X05PTkUgfSwNCiAgCXsgImxvZ3N1bml0IiwgRkxEVF9VSU5UMzJELCBPSShP RkYobG9nc3VuaXQpKSwgQzEsIDAsIFRZUF9OT05FIH0sDQogIAl7ICJmZWF0 dXJlczIiLCBGTERUX1VJTlQzMlgsIE9JKE9GRihmZWF0dXJlczIpKSwgQzEs IDAsIFRZUF9OT05FIH0sDQorCXsgImJhZF9mZWF0dXJlczIiLCBGTERUX1VJ TlQzMlgsIE9JKE9GRihiYWRfZmVhdHVyZXMyKSksIEMxLCAwLCBUWVBfTk9O RSAgDQp9LA0KICAJeyBOVUxMIH0NCiAgfTsNCg0KDQo9PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT0NCnhmc3Byb2dzL2luY2x1ZGUveGZzX3NiLmgN Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KDQotLS0gYS94ZnNw cm9ncy9pbmNsdWRlL3hmc19zYi5oCTIwMDgtMDMtMDUgMTU6MzA6NTQuMDAw MDAwMDAwICsxMTAwDQorKysgYi94ZnNwcm9ncy9pbmNsdWRlL3hmc19zYi5o CTIwMDgtMDItMjkgMTc6MTY6MzMuODE0NDE3Njg3ICsxMTAwDQpAQCAtMTUx LDYgKzE1MSw3IEBAIHR5cGVkZWYgc3RydWN0IHhmc19zYg0KICAJX191aW50 MTZfdAlzYl9sb2dzZWN0c2l6ZTsJLyogc2VjdG9yIHNpemUgZm9yIHRoZSBs b2csIGJ5dGVzICovDQogIAlfX3VpbnQzMl90CXNiX2xvZ3N1bml0OwkvKiBz dHJpcGUgdW5pdCBzaXplIGZvciB0aGUgbG9nICovDQogIAlfX3VpbnQzMl90 CXNiX2ZlYXR1cmVzMjsJLyogYWRkaXRpb25hbCBmZWF0dXJlIGJpdHMgKi8N CisJX191aW50MzJfdAlzYl9iYWRfZmVhdHVyZXMyOyAvKiB1bnVzYWJsZSBz cGFjZSAqLw0KICB9IHhmc19zYl90Ow0KDQogIC8qDQpAQCAtMTY5LDcgKzE3 MCw3IEBAIHR5cGVkZWYgZW51bSB7DQogIAlYRlNfU0JTX0dRVU9USU5PLCBY RlNfU0JTX1FGTEFHUywgWEZTX1NCU19GTEFHUywgWEZTX1NCU19TSEFSRURf Vk4sDQogIAlYRlNfU0JTX0lOT0FMSUdOTVQsIFhGU19TQlNfVU5JVCwgWEZT X1NCU19XSURUSCwgWEZTX1NCU19ESVJCTEtMT0csDQogIAlYRlNfU0JTX0xP R1NFQ1RMT0csIFhGU19TQlNfTE9HU0VDVFNJWkUsIFhGU19TQlNfTE9HU1VO SVQsDQotCVhGU19TQlNfRkVBVFVSRVMyLA0KKwlYRlNfU0JTX0ZFQVRVUkVT MiwgWEZTX1NCU19CQURfRkVBVFVSRVMyLA0KICAJWEZTX1NCU19GSUVMRENP VU5UDQogIH0geGZzX3NiX2ZpZWxkX3Q7DQoNCg0KPT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09DQp4ZnNwcm9ncy9saWJ4ZnMveGZzX21vdW50LmMN Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KDQotLS0gYS94ZnNw cm9ncy9saWJ4ZnMveGZzX21vdW50LmMJMjAwOC0wMy0wNSAxNTozMDo1NC4w MDAwMDAwMDAgKzExMDANCisrKyBiL3hmc3Byb2dzL2xpYnhmcy94ZnNfbW91 bnQuYwkyMDA4LTAyLTI5IDE3OjE2OjMzLjgzNDQxNTEzOCArMTEwMA0KQEAg LTE0MCw2ICsxNDAsNyBAQCBzdGF0aWMgc3RydWN0IHsNCiAgICAgIHsgb2Zm c2V0b2YoeGZzX3NiX3QsIHNiX2xvZ3NlY3RzaXplKSwwIH0sDQogICAgICB7 IG9mZnNldG9mKHhmc19zYl90LCBzYl9sb2dzdW5pdCksCSAwIH0sDQogICAg ICB7IG9mZnNldG9mKHhmc19zYl90LCBzYl9mZWF0dXJlczIpLAkgMCB9LA0K KyAgICB7IG9mZnNldG9mKHhmc19zYl90LCBzYl9iYWRfZmVhdHVyZXMyKSwg MCB9LA0KICAgICAgeyBzaXplb2YoeGZzX3NiX3QpLAkJCSAwIH0NCiAgfTsN Cg0KDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCnhmc3Byb2dz L21rZnMveGZzX21rZnMuYw0KPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09DQoNCi0tLSBhL3hmc3Byb2dzL21rZnMveGZzX21rZnMuYwkyMDA4LTAz LTA1IDE1OjMwOjU0LjAwMDAwMDAwMCArMTEwMA0KKysrIGIveGZzcHJvZ3Mv bWtmcy94ZnNfbWtmcy5jCTIwMDgtMDMtMDUgMTU6Mjc6MzcuNTY4NDYxNzg3 ICsxMTAwDQpAQCAtMjEwMyw2ICsyMTAzLDEzIEBAIGFuIEFHIHNpemUgdGhh dCBpcyBvbmUgc3RyaXBlIHVuaXQgc21hbGwNCiAgCQkJZGlydmVyc2lvbiA9 PSAyLCBsb2d2ZXJzaW9uID09IDIsIGF0dHJ2ZXJzaW9uID09IDEsDQogIAkJ CShzZWN0b3JzaXplICE9IEJCU0laRSB8fCBsc2VjdG9yc2l6ZSAhPSBCQlNJ WkUpLA0KICAJCQlzYnAtPnNiX2ZlYXR1cmVzMiAhPSAwKTsNCisJLyoNCisJ ICogRHVlIHRvIGEgc3RydWN0dXJlIGFsaWdubWVudCBpc3N1ZSwgc2JfZmVh dHVyZXMyIGVuZGVkIHVwIGluIG9uZQ0KKwkgKiBvZiB0d28gbG9jYXRpb25z LCB0aGUgc2Vjb25kICJpbmNvcnJlY3QiIGxvY2F0aW9uIHJlcHJlc2VudGVk IGJ5DQorCSAqIHRoZSBzYl9iYWRfZmVhdHVyZXMyIGZpZWxkLiBUbyBhdm9p ZCBvbGRlciBrZXJuZWxzIG1vdW50aW5nDQorCSAqIGZpbGVzeXN0ZW1zIHRo ZXkgc2hvdWxkbid0LCBzZXQgYm90aCBmaWVsZCB0byB0aGUgc2FtZSB2YWx1 ZS4NCisJICovDQorCXNicC0+c2JfYmFkX2ZlYXR1cmVzMiA9IHNicC0+c2Jf ZmVhdHVyZXMyOw0KDQogIAlpZiAoZm9yY2Vfb3ZlcndyaXRlKQ0KICAJCXpl cm9fb2xkX3hmc19zdHJ1Y3R1cmVzKCZ4aSwgc2JwKTsNCg0KPT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09DQp4ZnNwcm9ncy9yZXBhaXIvcGhhc2Ux LmMNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KDQotLS0gYS94 ZnNwcm9ncy9yZXBhaXIvcGhhc2UxLmMJMjAwOC0wMy0wNSAxNTozMDo1NC4w MDAwMDAwMDAgKzExMDANCisrKyBiL3hmc3Byb2dzL3JlcGFpci9waGFzZTEu YwkyMDA4LTAzLTA1IDE1OjE5OjA5LjUxMzQxNTQxMyArMTEwMA0KQEAgLTkx LDYgKzkxLDE5IEBAIHBoYXNlMSh4ZnNfbW91bnRfdCAqbXApDQogIAkJcHJp bWFyeV9zYl9tb2RpZmllZCA9IDE7DQogIAl9DQoNCisJLyoNCisJICogQ2hl Y2sgYmFkX2ZlYXR1cmVzMiBhbmQgbWFrZSBzdXJlIGZlYXR1cmVzMiB0aGUg c2FtZSBhcw0KKwkgKiBiYWRfZmVhdHVyZXMgKE9SaW5nIHRoZSB0d28gdG9n ZXRoZXIpLiBMZWF2ZSBiYWRfZmVhdHVyZXMyDQorCSAqIHNldCBzbyBvbGRl ciBrZXJuZWxzIGNhbiBzdGlsbCB1c2UgaXQgYW5kIG5vdCBtb3VudCB1bnN1 cHBvcnRlZA0KKwkgKiBmaWxlc3lzdGVtcyB3aGVuIGl0IHJlYWRzIGJhZF9m ZWF0dXJlczIuDQorCSAqLw0KKwlpZiAoc2ItPnNiX2JhZF9mZWF0dXJlczIg IT0gc2ItPnNiX2ZlYXR1cmVzMikgew0KKwkJc2ItPnNiX2ZlYXR1cmVzMiB8 PSBzYi0+c2JfYmFkX2ZlYXR1cmVzMjsNCisJCXNiLT5zYl9iYWRfZmVhdHVy ZXMyID0gc2ItPnNiX2ZlYXR1cmVzMjsNCisJCXByaW1hcnlfc2JfbW9kaWZp ZWQgPSAxOw0KKwkJZG9fd2FybihfKCJzdXBlcmJsb2NrIGhhcyBhIGZlYXR1 cmVzMiBtaXNtYXRjaCwgY29ycmVjdGluZ1xuIikpOw0KKwl9DQorDQogIAlp ZiAocHJpbWFyeV9zYl9tb2RpZmllZCkgIHsNCiAgCQlpZiAoIW5vX21vZGlm eSkgIHsNCiAgCQkJZG9fd2FybihfKCJ3cml0aW5nIG1vZGlmaWVkIHByaW1h cnkgc3VwZXJibG9ja1xuIikpOw0K ------------ypN4flJIlmhdmVY5eNxenW Content-Disposition: attachment; filename=bad_features2.patch Content-Type: text/x-patch; name=bad_features2.patch Content-Transfer-Encoding: Base64 Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQp4ZnNwcm9ncy9kYi9j aGVjay5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQoKLS0tIGEv eGZzcHJvZ3MvZGIvY2hlY2suYwkyMDA4LTAzLTA1IDE1OjMwOjU0LjAwMDAw MDAwMCArMTEwMAorKysgYi94ZnNwcm9ncy9kYi9jaGVjay5jCTIwMDgtMDMt MDUgMTU6Mjg6NTguNjM4MDk3NTExICsxMTAwCkBAIC04NjksNiArODY5LDE0 IEBAIGJsb2NrZ2V0X2YoCiAJCQkJbXAtPm1fc2Iuc2JfZnJleHRlbnRzLCBm cmV4dGVudHMpOwogCQllcnJvcisrOwogCX0KKwlpZiAobXAtPm1fc2Iuc2Jf YmFkX2ZlYXR1cmVzMiAhPSBtcC0+bV9zYi5zYl9mZWF0dXJlczIpIHsKKwkJ aWYgKCFzZmxhZykKKwkJCWRicHJpbnRmKCJzYl9mZWF0dXJlczIgKDB4JXgp IG5vdCBzYW1lIGFzICIKKwkJCQkic2JfYmFkX2ZlYXR1cmVzMiAoMHgleClc biIsCisJCQkJbXAtPm1fc2Iuc2JfZmVhdHVyZXMyLAorCQkJCW1wLT5tX3Ni LnNiX2JhZF9mZWF0dXJlczIpOworCQllcnJvcisrOworCX0KIAlpZiAoKHNi dmVyc2lvbiAmIFhGU19TQl9WRVJTSU9OX0FUVFJCSVQpICYmCiAJICAgICFY RlNfU0JfVkVSU0lPTl9IQVNBVFRSKCZtcC0+bV9zYikpIHsKIAkJaWYgKCFz ZmxhZykKCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQp4ZnNwcm9n cy9kYi9zYi5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQoKLS0t IGEveGZzcHJvZ3MvZGIvc2IuYwkyMDA4LTAzLTA1IDE1OjMwOjU0LjAwMDAw MDAwMCArMTEwMAorKysgYi94ZnNwcm9ncy9kYi9zYi5jCTIwMDgtMDItMjkg MTc6MTY6MzMuNzcwNDIzMjk2ICsxMTAwCkBAIC0xMDgsNiArMTA4LDcgQEAg Y29uc3QgZmllbGRfdAlzYl9mbGRzW10gPSB7CiAJeyAibG9nc2VjdHNpemUi LCBGTERUX1VJTlQxNkQsIE9JKE9GRihsb2dzZWN0c2l6ZSkpLCBDMSwgMCwg VFlQX05PTkUgfSwKIAl7ICJsb2dzdW5pdCIsIEZMRFRfVUlOVDMyRCwgT0ko T0ZGKGxvZ3N1bml0KSksIEMxLCAwLCBUWVBfTk9ORSB9LAogCXsgImZlYXR1 cmVzMiIsIEZMRFRfVUlOVDMyWCwgT0koT0ZGKGZlYXR1cmVzMikpLCBDMSwg MCwgVFlQX05PTkUgfSwKKwl7ICJiYWRfZmVhdHVyZXMyIiwgRkxEVF9VSU5U MzJYLCBPSShPRkYoYmFkX2ZlYXR1cmVzMikpLCBDMSwgMCwgVFlQX05PTkUg fSwKIAl7IE5VTEwgfQogfTsKIAoKPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09Cnhmc3Byb2dzL2luY2x1ZGUveGZzX3NiLmgKPT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09CgotLS0gYS94ZnNwcm9ncy9pbmNsdWRlL3hm c19zYi5oCTIwMDgtMDMtMDUgMTU6MzA6NTQuMDAwMDAwMDAwICsxMTAwCisr KyBiL3hmc3Byb2dzL2luY2x1ZGUveGZzX3NiLmgJMjAwOC0wMi0yOSAxNzox NjozMy44MTQ0MTc2ODcgKzExMDAKQEAgLTE1MSw2ICsxNTEsNyBAQCB0eXBl ZGVmIHN0cnVjdCB4ZnNfc2IKIAlfX3VpbnQxNl90CXNiX2xvZ3NlY3RzaXpl OwkvKiBzZWN0b3Igc2l6ZSBmb3IgdGhlIGxvZywgYnl0ZXMgKi8KIAlfX3Vp bnQzMl90CXNiX2xvZ3N1bml0OwkvKiBzdHJpcGUgdW5pdCBzaXplIGZvciB0 aGUgbG9nICovCiAJX191aW50MzJfdAlzYl9mZWF0dXJlczI7CS8qIGFkZGl0 aW9uYWwgZmVhdHVyZSBiaXRzICovCisJX191aW50MzJfdAlzYl9iYWRfZmVh dHVyZXMyOyAvKiB1bnVzYWJsZSBzcGFjZSAqLwogfSB4ZnNfc2JfdDsKIAog LyoKQEAgLTE2OSw3ICsxNzAsNyBAQCB0eXBlZGVmIGVudW0gewogCVhGU19T QlNfR1FVT1RJTk8sIFhGU19TQlNfUUZMQUdTLCBYRlNfU0JTX0ZMQUdTLCBY RlNfU0JTX1NIQVJFRF9WTiwKIAlYRlNfU0JTX0lOT0FMSUdOTVQsIFhGU19T QlNfVU5JVCwgWEZTX1NCU19XSURUSCwgWEZTX1NCU19ESVJCTEtMT0csCiAJ WEZTX1NCU19MT0dTRUNUTE9HLCBYRlNfU0JTX0xPR1NFQ1RTSVpFLCBYRlNf U0JTX0xPR1NVTklULAotCVhGU19TQlNfRkVBVFVSRVMyLAorCVhGU19TQlNf RkVBVFVSRVMyLCBYRlNfU0JTX0JBRF9GRUFUVVJFUzIsCiAJWEZTX1NCU19G SUVMRENPVU5UCiB9IHhmc19zYl9maWVsZF90OwogCgo9PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT0KeGZzcHJvZ3MvbGlieGZzL3hmc19tb3VudC5j Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQoKLS0tIGEveGZzcHJv Z3MvbGlieGZzL3hmc19tb3VudC5jCTIwMDgtMDMtMDUgMTU6MzA6NTQuMDAw MDAwMDAwICsxMTAwCisrKyBiL3hmc3Byb2dzL2xpYnhmcy94ZnNfbW91bnQu YwkyMDA4LTAyLTI5IDE3OjE2OjMzLjgzNDQxNTEzOCArMTEwMApAQCAtMTQw LDYgKzE0MCw3IEBAIHN0YXRpYyBzdHJ1Y3QgewogICAgIHsgb2Zmc2V0b2Yo eGZzX3NiX3QsIHNiX2xvZ3NlY3RzaXplKSwwIH0sCiAgICAgeyBvZmZzZXRv Zih4ZnNfc2JfdCwgc2JfbG9nc3VuaXQpLAkgMCB9LAogICAgIHsgb2Zmc2V0 b2YoeGZzX3NiX3QsIHNiX2ZlYXR1cmVzMiksCSAwIH0sCisgICAgeyBvZmZz ZXRvZih4ZnNfc2JfdCwgc2JfYmFkX2ZlYXR1cmVzMiksIDAgfSwKICAgICB7 IHNpemVvZih4ZnNfc2JfdCksCQkJIDAgfQogfTsKIAoKPT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09Cnhmc3Byb2dzL21rZnMveGZzX21rZnMuYwo9 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KCi0tLSBhL3hmc3Byb2dz L21rZnMveGZzX21rZnMuYwkyMDA4LTAzLTA1IDE1OjMwOjU0LjAwMDAwMDAw MCArMTEwMAorKysgYi94ZnNwcm9ncy9ta2ZzL3hmc19ta2ZzLmMJMjAwOC0w My0wNSAxNToyNzozNy41Njg0NjE3ODcgKzExMDAKQEAgLTIxMDMsNiArMjEw MywxMyBAQCBhbiBBRyBzaXplIHRoYXQgaXMgb25lIHN0cmlwZSB1bml0IHNt YWxsCiAJCQlkaXJ2ZXJzaW9uID09IDIsIGxvZ3ZlcnNpb24gPT0gMiwgYXR0 cnZlcnNpb24gPT0gMSwKIAkJCShzZWN0b3JzaXplICE9IEJCU0laRSB8fCBs c2VjdG9yc2l6ZSAhPSBCQlNJWkUpLAogCQkJc2JwLT5zYl9mZWF0dXJlczIg IT0gMCk7CisJLyoKKwkgKiBEdWUgdG8gYSBzdHJ1Y3R1cmUgYWxpZ25tZW50 IGlzc3VlLCBzYl9mZWF0dXJlczIgZW5kZWQgdXAgaW4gb25lCisJICogb2Yg dHdvIGxvY2F0aW9ucywgdGhlIHNlY29uZCAiaW5jb3JyZWN0IiBsb2NhdGlv biByZXByZXNlbnRlZCBieQorCSAqIHRoZSBzYl9iYWRfZmVhdHVyZXMyIGZp ZWxkLiBUbyBhdm9pZCBvbGRlciBrZXJuZWxzIG1vdW50aW5nCisJICogZmls ZXN5c3RlbXMgdGhleSBzaG91bGRuJ3QsIHNldCBib3RoIGZpZWxkIHRvIHRo ZSBzYW1lIHZhbHVlLgorCSAqLworCXNicC0+c2JfYmFkX2ZlYXR1cmVzMiA9 IHNicC0+c2JfZmVhdHVyZXMyOwogCiAJaWYgKGZvcmNlX292ZXJ3cml0ZSkK IAkJemVyb19vbGRfeGZzX3N0cnVjdHVyZXMoJnhpLCBzYnApOwoKPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09Cnhmc3Byb2dzL3JlcGFpci9waGFz ZTEuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KCi0tLSBhL3hm c3Byb2dzL3JlcGFpci9waGFzZTEuYwkyMDA4LTAzLTA1IDE1OjMwOjU0LjAw MDAwMDAwMCArMTEwMAorKysgYi94ZnNwcm9ncy9yZXBhaXIvcGhhc2UxLmMJ MjAwOC0wMy0wNSAxNToxOTowOS41MTM0MTU0MTMgKzExMDAKQEAgLTkxLDYg KzkxLDE5IEBAIHBoYXNlMSh4ZnNfbW91bnRfdCAqbXApCiAJCXByaW1hcnlf c2JfbW9kaWZpZWQgPSAxOwogCX0KIAorCS8qCisJICogQ2hlY2sgYmFkX2Zl YXR1cmVzMiBhbmQgbWFrZSBzdXJlIGZlYXR1cmVzMiB0aGUgc2FtZSBhcwor CSAqIGJhZF9mZWF0dXJlcyAoT1JpbmcgdGhlIHR3byB0b2dldGhlcikuIExl YXZlIGJhZF9mZWF0dXJlczIKKwkgKiBzZXQgc28gb2xkZXIga2VybmVscyBj YW4gc3RpbGwgdXNlIGl0IGFuZCBub3QgbW91bnQgdW5zdXBwb3J0ZWQKKwkg KiBmaWxlc3lzdGVtcyB3aGVuIGl0IHJlYWRzIGJhZF9mZWF0dXJlczIuCisJ ICovCisJaWYgKHNiLT5zYl9iYWRfZmVhdHVyZXMyICE9IHNiLT5zYl9mZWF0 dXJlczIpIHsKKwkJc2ItPnNiX2ZlYXR1cmVzMiB8PSBzYi0+c2JfYmFkX2Zl YXR1cmVzMjsKKwkJc2ItPnNiX2JhZF9mZWF0dXJlczIgPSBzYi0+c2JfZmVh dHVyZXMyOworCQlwcmltYXJ5X3NiX21vZGlmaWVkID0gMTsKKwkJZG9fd2Fy bihfKCJzdXBlcmJsb2NrIGhhcyBhIGZlYXR1cmVzMiBtaXNtYXRjaCwgY29y cmVjdGluZ1xuIikpOworCX0KKwogCWlmIChwcmltYXJ5X3NiX21vZGlmaWVk KSAgewogCQlpZiAoIW5vX21vZGlmeSkgIHsKIAkJCWRvX3dhcm4oXygid3Jp dGluZyBtb2RpZmllZCBwcmltYXJ5IHN1cGVyYmxvY2tcbiIpKTsK ------------ypN4flJIlmhdmVY5eNxenW-- From owner-xfs@oss.sgi.com Tue Mar 4 20:45:13 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 04 Mar 2008 20:45:29 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_43 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m254jBCp020692 for ; Tue, 4 Mar 2008 20:45:13 -0800 X-ASG-Debug-ID: 1204692340-1387004f0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from filer.fsl.cs.sunysb.edu (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id ED0E565342B; Tue, 4 Mar 2008 20:45:40 -0800 (PST) Received: from filer.fsl.cs.sunysb.edu (filer.fsl.cs.sunysb.edu [130.245.126.2]) by cuda.sgi.com with ESMTP id UNxvDMfQkaSjbMdY; Tue, 04 Mar 2008 20:45:40 -0800 (PST) Received: from josefsipek.net (baal.fsl.cs.sunysb.edu [130.245.126.78]) by filer.fsl.cs.sunysb.edu (8.12.11.20060308/8.13.1) with ESMTP id m254jb3H013530; Tue, 4 Mar 2008 23:45:37 -0500 Received: by josefsipek.net (Postfix, from userid 1000) id 6694B1C00124; Tue, 4 Mar 2008 23:45:39 -0500 (EST) Date: Tue, 4 Mar 2008 23:45:39 -0500 From: "Josef 'Jeff' Sipek" To: Barry Naujok Cc: "xfs@oss.sgi.com" X-ASG-Orig-Subj: Re: [REVIEW #4] bad_features2 support in userspace Subject: Re: [REVIEW #4] bad_features2 support in userspace Message-ID: <20080305044539.GC19104@josefsipek.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.16 (2007-06-11) X-Barracuda-Connect: filer.fsl.cs.sunysb.edu[130.245.126.2] X-Barracuda-Start-Time: 1204692340 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.43918 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14772 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jeffpc@josefsipek.net Precedence: bulk X-list: xfs On Wed, Mar 05, 2008 at 03:37:07PM +1100, Barry Naujok wrote: > Due to the issue of mounting filesystem with older kernels and > potentially reading sb_features2 from the wrong location. It > seems the best course of action is to always make sb_features2 > and sb_bad_features2 the same. This is pretty important as > new bits in this are supposed to stop older kernels from > mounting filesystems with unsupported features. > > If sb_bad_features2 is zero, and the old kernel tries to read > sb_features2 from this location during mount, it will succeed > as it will read zero. > > So, this patch changes mkfs.xfs to set sb_bad_features2 to > the same as sb_features2, xfs_check and xfs_repair now also > makes sure they are the same. Idea: good Implementation: I didn't see anything wrong. Josef 'Jeff' Sipek. P.S. Any reason why you inline the patch _and_ attach? -- I think there is a world market for maybe five computers. - Thomas Watson, chairman of IBM, 1943. From owner-xfs@oss.sgi.com Tue Mar 4 20:49:57 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 04 Mar 2008 20:50:04 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m254nnwj021005 for ; Tue, 4 Mar 2008 20:49:56 -0800 Received: from pc-bnaujok.melbourne.sgi.com (pc-bnaujok.melbourne.sgi.com [134.14.55.58]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA27068; Wed, 5 Mar 2008 15:50:12 +1100 Date: Wed, 05 Mar 2008 15:52:13 +1100 To: "Josef 'Jeff' Sipek" Subject: Re: [REVIEW #4] bad_features2 support in userspace From: "Barry Naujok" Organization: SGI Cc: "xfs@oss.sgi.com" Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 References: <20080305044539.GC19104@josefsipek.net> Content-Transfer-Encoding: 7bit Message-ID: In-Reply-To: <20080305044539.GC19104@josefsipek.net> User-Agent: Opera Mail/9.24 (Win32) X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14773 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs On Wed, 05 Mar 2008 15:45:39 +1100, Josef 'Jeff' Sipek wrote: > P.S. Any reason why you inline the patch _and_ attach? Inline for review, attach for actually applying the patch as my mailer mangles leading spaces for the inline patch :( Barry. From owner-xfs@oss.sgi.com Tue Mar 4 22:27:23 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 04 Mar 2008 22:27:45 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_43 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m256RGDi023443 for ; Tue, 4 Mar 2008 22:27:21 -0800 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA29875; Wed, 5 Mar 2008 17:27:40 +1100 Message-ID: <47CE3EBA.2040900@sgi.com> Date: Wed, 05 Mar 2008 17:33:30 +1100 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.12 (X11/20080213) MIME-Version: 1.0 To: Barry Naujok CC: "xfs@oss.sgi.com" Subject: Re: [REVIEW #4] bad_features2 support in userspace References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14774 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs Looks good to me. Barry Naujok wrote: > Due to the issue of mounting filesystem with older kernels and > potentially reading sb_features2 from the wrong location. It > seems the best course of action is to always make sb_features2 > and sb_bad_features2 the same. This is pretty important as > new bits in this are supposed to stop older kernels from > mounting filesystems with unsupported features. > > If sb_bad_features2 is zero, and the old kernel tries to read > sb_features2 from this location during mount, it will succeed > as it will read zero. > > So, this patch changes mkfs.xfs to set sb_bad_features2 to > the same as sb_features2, xfs_check and xfs_repair now also > makes sure they are the same. > > Barry. > > -- > > > =========================================================================== > xfsprogs/db/check.c > =========================================================================== > > --- a/xfsprogs/db/check.c 2008-03-05 15:30:54.000000000 +1100 > +++ b/xfsprogs/db/check.c 2008-03-05 15:28:58.638097511 +1100 > @@ -869,6 +869,14 @@ blockget_f( > mp->m_sb.sb_frextents, frextents); > error++; > } > + if (mp->m_sb.sb_bad_features2 != mp->m_sb.sb_features2) { > + if (!sflag) > + dbprintf("sb_features2 (0x%x) not same as " > + "sb_bad_features2 (0x%x)\n", > + mp->m_sb.sb_features2, > + mp->m_sb.sb_bad_features2); > + error++; > + } > if ((sbversion & XFS_SB_VERSION_ATTRBIT) && > !XFS_SB_VERSION_HASATTR(&mp->m_sb)) { > if (!sflag) > > =========================================================================== > xfsprogs/db/sb.c > =========================================================================== > > --- a/xfsprogs/db/sb.c 2008-03-05 15:30:54.000000000 +1100 > +++ b/xfsprogs/db/sb.c 2008-02-29 17:16:33.770423296 +1100 > @@ -108,6 +108,7 @@ const field_t sb_flds[] = { > { "logsectsize", FLDT_UINT16D, OI(OFF(logsectsize)), C1, 0, > TYP_NONE }, > { "logsunit", FLDT_UINT32D, OI(OFF(logsunit)), C1, 0, TYP_NONE }, > { "features2", FLDT_UINT32X, OI(OFF(features2)), C1, 0, TYP_NONE }, > + { "bad_features2", FLDT_UINT32X, OI(OFF(bad_features2)), C1, 0, > TYP_NONE }, > { NULL } > }; > > > =========================================================================== > xfsprogs/include/xfs_sb.h > =========================================================================== > > --- a/xfsprogs/include/xfs_sb.h 2008-03-05 15:30:54.000000000 +1100 > +++ b/xfsprogs/include/xfs_sb.h 2008-02-29 17:16:33.814417687 +1100 > @@ -151,6 +151,7 @@ typedef struct xfs_sb > __uint16_t sb_logsectsize; /* sector size for the log, bytes */ > __uint32_t sb_logsunit; /* stripe unit size for the log */ > __uint32_t sb_features2; /* additional feature bits */ > + __uint32_t sb_bad_features2; /* unusable space */ > } xfs_sb_t; > > /* > @@ -169,7 +170,7 @@ typedef enum { > XFS_SBS_GQUOTINO, XFS_SBS_QFLAGS, XFS_SBS_FLAGS, XFS_SBS_SHARED_VN, > XFS_SBS_INOALIGNMT, XFS_SBS_UNIT, XFS_SBS_WIDTH, XFS_SBS_DIRBLKLOG, > XFS_SBS_LOGSECTLOG, XFS_SBS_LOGSECTSIZE, XFS_SBS_LOGSUNIT, > - XFS_SBS_FEATURES2, > + XFS_SBS_FEATURES2, XFS_SBS_BAD_FEATURES2, > XFS_SBS_FIELDCOUNT > } xfs_sb_field_t; > > > =========================================================================== > xfsprogs/libxfs/xfs_mount.c > =========================================================================== > > --- a/xfsprogs/libxfs/xfs_mount.c 2008-03-05 15:30:54.000000000 +1100 > +++ b/xfsprogs/libxfs/xfs_mount.c 2008-02-29 17:16:33.834415138 +1100 > @@ -140,6 +140,7 @@ static struct { > { offsetof(xfs_sb_t, sb_logsectsize),0 }, > { offsetof(xfs_sb_t, sb_logsunit), 0 }, > { offsetof(xfs_sb_t, sb_features2), 0 }, > + { offsetof(xfs_sb_t, sb_bad_features2), 0 }, > { sizeof(xfs_sb_t), 0 } > }; > > > =========================================================================== > xfsprogs/mkfs/xfs_mkfs.c > =========================================================================== > > --- a/xfsprogs/mkfs/xfs_mkfs.c 2008-03-05 15:30:54.000000000 +1100 > +++ b/xfsprogs/mkfs/xfs_mkfs.c 2008-03-05 15:27:37.568461787 +1100 > @@ -2103,6 +2103,13 @@ an AG size that is one stripe unit small > dirversion == 2, logversion == 2, attrversion == 1, > (sectorsize != BBSIZE || lsectorsize != BBSIZE), > sbp->sb_features2 != 0); > + /* > + * Due to a structure alignment issue, sb_features2 ended up in one > + * of two locations, the second "incorrect" location represented by > + * the sb_bad_features2 field. To avoid older kernels mounting > + * filesystems they shouldn't, set both field to the same value. > + */ > + sbp->sb_bad_features2 = sbp->sb_features2; > > if (force_overwrite) > zero_old_xfs_structures(&xi, sbp); > > =========================================================================== > xfsprogs/repair/phase1.c > =========================================================================== > > --- a/xfsprogs/repair/phase1.c 2008-03-05 15:30:54.000000000 +1100 > +++ b/xfsprogs/repair/phase1.c 2008-03-05 15:19:09.513415413 +1100 > @@ -91,6 +91,19 @@ phase1(xfs_mount_t *mp) > primary_sb_modified = 1; > } > > + /* > + * Check bad_features2 and make sure features2 the same as > + * bad_features (ORing the two together). Leave bad_features2 > + * set so older kernels can still use it and not mount unsupported > + * filesystems when it reads bad_features2. > + */ > + if (sb->sb_bad_features2 != sb->sb_features2) { > + sb->sb_features2 |= sb->sb_bad_features2; > + sb->sb_bad_features2 = sb->sb_features2; > + primary_sb_modified = 1; > + do_warn(_("superblock has a features2 mismatch, correcting\n")); > + } > + > if (primary_sb_modified) { > if (!no_modify) { > do_warn(_("writing modified primary superblock\n")); > From owner-xfs@oss.sgi.com Tue Mar 4 23:12:23 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 04 Mar 2008 23:12:41 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m257CK5D024448 for ; Tue, 4 Mar 2008 23:12:23 -0800 X-ASG-Debug-ID: 1204701166-1387015e0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 60318653F98 for ; Tue, 4 Mar 2008 23:12:46 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id aFVShyKH1HKUAi2h for ; Tue, 04 Mar 2008 23:12:46 -0800 (PST) Received: from hch by bombadil.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1JWnnu-00025D-3t; Wed, 05 Mar 2008 07:12:42 +0000 Date: Wed, 5 Mar 2008 02:12:42 -0500 From: Christoph Hellwig To: Eric Sandeen Cc: Ravi Wijayaratne , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: corruption in xfs_end_bio_unwritten Subject: Re: corruption in xfs_end_bio_unwritten Message-ID: <20080305071242.GA30439@infradead.org> References: <629727.55106.qm@web32504.mail.mud.yahoo.com> <47CDCA12.5060107@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47CDCA12.5060107@sandeen.net> User-Agent: Mutt/1.5.17 (2007-11-01) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1204701170 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.43928 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14775 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs On Tue, Mar 04, 2008 at 04:15:46PM -0600, Eric Sandeen wrote: > Ravi Wijayaratne wrote: > > Hi all, > > > > I am seeing data corruption in xfs_end_bio_unwritten. Possibly the corruption is happening before. > > Here is what I see. > > what kernel, for starters? Yeah, VOP_BMAP doesn't sound like anything recent ;-) From owner-xfs@oss.sgi.com Wed Mar 5 02:38:26 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 05 Mar 2008 02:38:47 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m25AcNAl002746 for ; Wed, 5 Mar 2008 02:38:26 -0800 X-ASG-Debug-ID: 1204713530-794e03220000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from merkurneu.hrz.uni-giessen.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 5C1E211F8F00 for ; Wed, 5 Mar 2008 02:38:50 -0800 (PST) Received: from merkurneu.hrz.uni-giessen.de (merkurneu.hrz.uni-giessen.de [134.176.2.3]) by cuda.sgi.com with ESMTP id jwMQE8SBmsegnMtL for ; Wed, 05 Mar 2008 02:38:50 -0800 (PST) Received: from [134.176.2.169] by merkurneu.hrz.uni-giessen.de with ESMTP; Wed, 5 Mar 2008 09:34:32 +0100 Received: from hermes.hrz.uni-giessen.de (hermes.hrz.uni-giessen.de [134.176.2.15]) by mailgw32.hrz.uni-giessen.de (Postfix) with ESMTP id E513696D988; Wed, 5 Mar 2008 09:34:04 +0100 (CET) Received: from fb07-iapwap2.physik.uni-giessen.de by hermes.hrz.uni-giessen.de with ESMTP; Wed, 5 Mar 2008 09:34:05 +0100 From: Marc To: lachlan@sgi.com X-ASG-Orig-Subj: Re: filesystem corruption in linus tree Subject: Re: filesystem corruption in linus tree Date: Wed, 5 Mar 2008 09:33:57 +0100 User-Agent: KMail/1.9.6 (enterprise 20070904.708012) Cc: Barry Naujok , xfs@oss.sgi.com References: <03F8FD43-322F-41E3-A7A0-CD4E9AD8B4DE@ap.physik.uni-giessen.de> <200802262100.18631.marc.dietrich@ap.physik.uni-giessen.de> <47CB7D52.2030704@sgi.com> In-Reply-To: <47CB7D52.2030704@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Message-Id: <200803050934.00814.marc.dietrich@ap.physik.uni-giessen.de> X-HRZ-JLUG-MailScanner-Information: Passed JLUG virus check X-HRZ-JLUG-MailScanner: No virus found X-MailScanner-From: marc.dietrich@ap.physik.uni-giessen.de X-Barracuda-Connect: merkurneu.hrz.uni-giessen.de[134.176.2.3] X-Barracuda-Start-Time: 1204713533 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests=UNPARSEABLE_RELAY X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.43942 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 UNPARSEABLE_RELAY Informational: message has unparseable relay lines X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id m25AcQAl002748 X-archive-position: 14776 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Marc.Dietrich@ap.physik.uni-giessen.de Precedence: bulk X-list: xfs Hi, Am Montag 03 MÀrz 2008 05:23:46 schrieb Lachlan McIlroy: > Marc Dietrich wrote: > > Hi again, > > > > On Tuesday 26 February 2008 08:38:50 Lachlan McIlroy wrote: > >> Marc Dietrich wrote: > >>> Hi, > >>> > >>> On Monday 25 February 2008 01:36:28 Barry Naujok wrote: > >>>> On Sun, 24 Feb 2008 20:58:26 +1100, Marc Dietrich > >>>> > >>>> wrote: > >>>>> Hi, > >>>>> > >>>>> somewhere after the release of 2.6.24 my xfs filesystem got > >>>>> corrupted. Initialy I thought it was only related to the readdir bug. > >>>>> (http://oss.sgi.com/archives/xfs/2008-02/msg00027.html) So I waited > >>>>> for the fix to go into mainline. Yesterday I tried again, but got > >>>>> this error during boot: > > > > > > > >> We've had a few problems reported with XFS on 32-bit powermacs and the > >> culprit appears to be some changes to bit manipulation routines. Could > >> you please try reverse applying the attached patches and see if the > >> problem is resolved? > > > > I saw, that you already pushed it into mainline - for a good reason ;-) > > Works as expeted. > > > > Please also don't forget 2.6.24-stable ! > > The changes that caused this regression went into 2.6.25-rc1 so no need for > a 2.6.24 stable fix. yes - and I could have sworn, that 2.6.24 is also affected. My fault. Thanks Marc -- "Those who question our statements are traitors", Lord Arthur Ponsonby, "Falsehood in Wartime: Propaganda Lies of the First World War", 1928 From owner-xfs@oss.sgi.com Wed Mar 5 03:23:13 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 05 Mar 2008 03:23:32 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00, SUBJECT_FUZZY_TION autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m25BNC0D004294 for ; Wed, 5 Mar 2008 03:23:13 -0800 X-ASG-Debug-ID: 1204716218-424501ed0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from filer.fsl.cs.sunysb.edu (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 195C7655182 for ; Wed, 5 Mar 2008 03:23:38 -0800 (PST) Received: from filer.fsl.cs.sunysb.edu (filer.fsl.cs.sunysb.edu [130.245.126.2]) by cuda.sgi.com with ESMTP id lhBubU0wHu92GdqJ for ; Wed, 05 Mar 2008 03:23:38 -0800 (PST) Received: from josefsipek.net (baal.fsl.cs.sunysb.edu [130.245.126.78]) by filer.fsl.cs.sunysb.edu (8.12.11.20060308/8.13.1) with ESMTP id m23KVgrC019646; Mon, 3 Mar 2008 15:31:43 -0500 Received: by josefsipek.net (Postfix, from userid 1000) id B5AE71C00124; Mon, 3 Mar 2008 15:31:43 -0500 (EST) Date: Mon, 3 Mar 2008 15:31:43 -0500 From: "Josef 'Jeff' Sipek" To: Jeff Breidenbach Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: disappearing xfs partition Subject: Re: disappearing xfs partition Message-ID: <20080303203143.GA21086@josefsipek.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.16 (2007-06-11) X-Barracuda-Connect: filer.fsl.cs.sunysb.edu[130.245.126.2] X-Barracuda-Start-Time: 1204716222 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.43944 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14777 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jeffpc@josefsipek.net Precedence: bulk X-list: xfs On Mon, Mar 03, 2008 at 05:14:38AM -0800, Jeff Breidenbach wrote: ... > # dpkg -l xfsprogs > Desired=Unknown/Install/Remove/Purge/Hold > | Status=Not/Installed/Config-f/Unpacked/Failed-cfg/Half-inst/t-aWait/T-pend > |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) > ||/ Name Version Description > +++-==============-==============-============================================ > ii xfsprogs 2.9.5-1 Utilities for managing the XFS filesystem As others have already pointed out, the problem you have is not with XFS, but probably with udev. You may want to upgrade your xfsprogs. Version 2.9.5 has a buggy mkfs (the fs it makes uses only about 3/4 of the partition). Josef 'Jeff' Sipek. -- Computer Science is no more about computers than astronomy is about telescopes. - Edsger Dijkstra From owner-xfs@oss.sgi.com Wed Mar 5 05:52:59 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 05 Mar 2008 05:53:17 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,MIME_8BIT_HEADER autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m25DqurT011261 for ; Wed, 5 Mar 2008 05:52:59 -0800 X-ASG-Debug-ID: 1204725203-3131003c0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ti-out-0910.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 036DB655FD2 for ; Wed, 5 Mar 2008 05:53:23 -0800 (PST) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.185]) by cuda.sgi.com with ESMTP id 9HNvOPA3rZDYOSsw for ; Wed, 05 Mar 2008 05:53:23 -0800 (PST) Received: by ti-out-0910.google.com with SMTP id d10so1998157tib.18 for ; Wed, 05 Mar 2008 05:53:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=gPA1zcrjYOYq58dB15MUQ8RlSnfGJBFsVvErME4Bk7s=; b=vaCMkG3beJt9YGU1TmEjIlNchpnRibPde/Q0VpB347ef4cJCnxc/JQ+vztos9yNsw7kbedopvYMJ47ZcCV9qWcRvBRebfFhBc3gSTtoxjaqBGDHoJeQiCDQvVhtKR/i0LyVzdeQ18KYMKMkOAFNEusiY4pbUPylkyXWARNywF28= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=rHuIf5k0b9zjJ3w6yfvxZpjAUr2E3HHV2DnaIAGcX/rgSBTdfFk/I+ONZnpOwrVpOIEZUK4pPC7MhmN9p0s+0OAVRTNUzS1D6VNxMcRSHiD4nAsqRcLOa2Bafn8k2sk6YoN9AA9o7bJGhnodCwaq17oWSXT7nkZCb04oeu9M8Sc= Received: by 10.150.155.1 with SMTP id c1mr1190380ybe.85.1204725198680; Wed, 05 Mar 2008 05:53:18 -0800 (PST) Received: by 10.150.96.5 with HTTP; Wed, 5 Mar 2008 05:53:18 -0800 (PST) Message-ID: <1a4a774c0803050553h7f6294cfq41c38f34ea92ceae@mail.gmail.com> Date: Wed, 5 Mar 2008 14:53:18 +0100 From: "=?ISO-8859-1?Q?Christian_R=F8snes?=" To: "David Chinner" X-ASG-Orig-Subj: Re: XFS internal error xfs_trans_cancel at line 1150 of file fs/xfs/xfs_trans.c Subject: Re: XFS internal error xfs_trans_cancel at line 1150 of file fs/xfs/xfs_trans.c Cc: xfs@oss.sgi.com In-Reply-To: <20080213214551.GR155407@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <1a4a774c0802130251h657a52f7lb97942e7afdf6e3f@mail.gmail.com> <20080213214551.GR155407@sgi.com> X-Barracuda-Connect: ti-out-0910.google.com[209.85.142.185] X-Barracuda-Start-Time: 1204725206 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.43954 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id m25DqxrT011263 X-archive-position: 14778 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: christian.rosnes@gmail.com Precedence: bulk X-list: xfs On Wed, Feb 13, 2008 at 10:45 PM, David Chinner wrote: > On Wed, Feb 13, 2008 at 11:51:51AM +0100, Christian Røsnes wrote: > > Over the past month I've been hit with two cases of "xfs_trans_cancel > > at line 1150" > > The two errors occurred on different raid sets. In both cases the > > error happened during > > rsync from a remote server to this server, and the local partition > > which reported > > the error was 99% full (as reported by df -k, see below for details). > > > > System: Dell 2850 > > Mem: 4GB RAM > > OS: Debian 3 (32-bit) > > Kernel: 2.6.17.7 (custom compiled) > > > > I've been running this kernel since Aug 2006 without any of these > > problems, until a month ago. > > > > I've not used any of the previous kernel in the 2.6.17 series. > > > > /usr/src/linux-2.6.17.7# grep 4K .config > > # CONFIG_4KSTACKS is not set > > > > > > Are there any known XFS problems with this kernel version and nearly > > full partitions ? > > Yes. Deadlocks that weren't properly fixed until 2.6.18 (partially > fixed in 2.6.17) and an accounting problem in the transaction code > that leads to the shutdown you are seeing. The accounting problem is > fixed by this commit: > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=45c34141126a89da07197d5b89c04c6847f1171a > > which I think went into 2.6.22. > > Luckily, neither of these problems result in corruption. > > > > I'm thinking about upgrading the kernel to a newer version, to see if > > it fixes this problem. > > Are there any known XFS problems with version 2.6.24.2 ? > > Yes - a problem with readdir. The fix is currently in the stable > queue (i.e for 2.6.24.3): > > http://git.kernel.org/?p=linux/kernel/git/stable/stable-queue.git;a=commit;h=ee864b866419890b019352412c7bc9634d96f61b > > So we are just waiting for Greg to release 2.6.24.3 now. > > Cheers, > > Dave. > -- > Dave Chinner > Principal Engineer > SGI Australian Software Group > After being hit several times by the problem mentioned above (running kernel 2.6.17.7), I upgraded the kernel to version 2.6.24.3. I then ran a rsync test to a 99% full partition: df -k: /dev/sdb1 286380096 282994528 3385568 99% /data The rsync application will probably fail because it will most likely run out of space, but I got another xfs_trans_cancel kernel message: Filesystem "sdb1": XFS internal error xfs_trans_cancel at line 1163 of file fs/xfs/xfs_trans.c. Caller 0xc021a010 Pid: 11642, comm: rsync Not tainted 2.6.24.3FC #1 [] xfs_trans_cancel+0x5d/0xe6 [] xfs_mkdir+0x45a/0x493 [] xfs_mkdir+0x45a/0x493 [] xfs_acl_vhasacl_default+0x33/0x44 [] xfs_vn_mknod+0x165/0x243 [] xfs_access+0x2f/0x35 [] xfs_vn_mkdir+0x12/0x14 [] vfs_mkdir+0xa3/0xe2 [] sys_mkdirat+0x8a/0xc3 [] sys_mkdir+0x1f/0x23 [] syscall_call+0x7/0xb ======================= xfs_force_shutdown(sdb1,0x8) called from line 1164 of file fs/xfs/xfs_trans.c. Return address = 0xc0212690 Filesystem "sdb1": Corruption of in-memory data detected. Shutting down filesystem: sdb1 Please umount the filesystem, and rectify the problem(s) Trying to umount /dev/sdb1 fails (umount just hangs) . Rebooting the system seems to hang also - and I believe the kernel outputs this message when trying to umount /dev/sdb1: xfs_force_shutdown(sdb1,0x1) called from line 420 of file fs/xfs/xfs_rw.c. Return address = 0xc021cb21 After waiting 5 minutes I power-cycle the system to bring it back up. After the restart, I ran: xfs_check /dev/sdb1 (there was no output from xfs_check). Could this be the same problem I experienced with 2.6.17.7 ? Thanks Christian btw - I've previously run memtest overnight and not found any memory problems. From owner-xfs@oss.sgi.com Wed Mar 5 12:42:54 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 05 Mar 2008 12:43:13 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m25KgpLi000435 for ; Wed, 5 Mar 2008 12:42:54 -0800 X-ASG-Debug-ID: 1204749799-44e301d10000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 76594659C06 for ; Wed, 5 Mar 2008 12:43:19 -0800 (PST) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id YofWkuE0wJW3BIa2 for ; Wed, 05 Mar 2008 12:43:19 -0800 (PST) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 8014D18004EFE; Wed, 5 Mar 2008 14:43:17 -0600 (CST) Message-ID: <47CF05E5.90409@sandeen.net> Date: Wed, 05 Mar 2008 14:43:17 -0600 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: David Chinner CC: sgi.bugs.xfs@engr.sgi.com, xfs@oss.sgi.com X-ASG-Orig-Subj: Re: TAKE 977545 - xfsaild causing too many wakeups Subject: Re: TAKE 977545 - xfsaild causing too many wakeups References: <20080222041525.37EA858C4C0F@chook.melbourne.sgi.com> In-Reply-To: <20080222041525.37EA858C4C0F@chook.melbourne.sgi.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1204749801 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.43980 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14779 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs David Chinner wrote: > xfsaild causing too many wakeups > > Idle state is not being detected properly by the xfsaild push code. > The current idle state is detected by an empty list which may never > happen with mostly idle filesystem or one using lazy superblock > counters. A single dirty item in the list that exists beyond the > push target can result repeated looping attempting to push > up to the target because it fails to check if the push target > has been acheived or not. > > Fix by considering a dirty list with everything past the target > as an idle state and set the timeout appropriately. Will this go to 2.6.25? -Eric From owner-xfs@oss.sgi.com Wed Mar 5 13:00:23 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 05 Mar 2008 13:00:42 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m25L0H1u001139 for ; Wed, 5 Mar 2008 13:00:22 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA27019; Thu, 6 Mar 2008 08:00:38 +1100 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 m25L0aLF87068048; Thu, 6 Mar 2008 08:00:37 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id m25L0Z2h87034150; Thu, 6 Mar 2008 08:00:35 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Thu, 6 Mar 2008 08:00:35 +1100 From: David Chinner To: Eric Sandeen Cc: xfs-dev , xfs@oss.sgi.com Subject: Re: TAKE 977545 - xfsaild causing too many wakeups Message-ID: <20080305210035.GA155407@sgi.com> References: <20080222041525.37EA858C4C0F@chook.melbourne.sgi.com> <47CF05E5.90409@sandeen.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47CF05E5.90409@sandeen.net> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14780 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Wed, Mar 05, 2008 at 02:43:17PM -0600, Eric Sandeen wrote: > David Chinner wrote: > > xfsaild causing too many wakeups > > > > Idle state is not being detected properly by the xfsaild push code. > > The current idle state is detected by an empty list which may never > > happen with mostly idle filesystem or one using lazy superblock > > counters. A single dirty item in the list that exists beyond the > > push target can result repeated looping attempting to push > > up to the target because it fails to check if the push target > > has been acheived or not. > > > > Fix by considering a dirty list with everything past the target > > as an idle state and set the timeout appropriately. > > Will this go to 2.6.25? Yes, it certainly should. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Wed Mar 5 20:41:43 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 05 Mar 2008 20:41:53 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_43 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m264fdfN023764 for ; Wed, 5 Mar 2008 20:41:42 -0800 X-ASG-Debug-ID: 1204778525-4c6402880000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.sceen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id A133165CF7D for ; Wed, 5 Mar 2008 20:42:05 -0800 (PST) Received: from mail.sceen.net (sceen.net [213.41.243.68]) by cuda.sgi.com with ESMTP id 5eRPcUCBTwamdpNy for ; Wed, 05 Mar 2008 20:42:05 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sceen.net (Postfix) with ESMTP id F3D631E010; Thu, 6 Mar 2008 05:42:03 +0100 (CET) Received: from mail.sceen.net ([127.0.0.1]) by localhost (mail.sceen.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18660-08; Thu, 6 Mar 2008 05:41:55 +0100 (CET) Received: from itchy (cesrt42.asia.info.net [61.14.27.42]) by mail.sceen.net (Postfix) with ESMTP id 5A0571CB8C; Thu, 6 Mar 2008 05:41:51 +0100 (CET) From: Niv Sardi To: Eric Sandeen Cc: xfs@oss.sgi.com, xfs-dev@sgi.com X-ASG-Orig-Subj: Re: [REVIEW] mkfs.xfs man page needs the default settings updated, TAKE 2. Subject: Re: [REVIEW] mkfs.xfs man page needs the default settings updated, TAKE 2. In-Reply-To: <47CD6ED7.5050505@sandeen.net> (Eric Sandeen's message of "Tue, 04 Mar 2008 09:46:31 -0600") References: <47CD6D0E.3090301@sandeen.net> <47CD6ED7.5050505@sandeen.net> User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/23.0.60 (i486-pc-linux-gnu) Date: Thu, 06 Mar 2008 15:41:29 +1100 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at sceen.net X-Barracuda-Connect: sceen.net[213.41.243.68] X-Barracuda-Start-Time: 1204778529 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.44008 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Status: Clean X-archive-position: 14781 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: xaiki@sgi.com Precedence: bulk X-list: xfs --=-=-= Thanks to Eric for the comments, is this better ? Cheers, -- Niv Sardi --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=0001-Update-mkfs-manpage-for-new-defaults.patch From 7e0e328663858ecf13f35678f1a6d349c3d4dd5a Mon Sep 17 00:00:00 2001 From: Niv Sardi Date: Fri, 22 Feb 2008 16:48:32 +1100 Subject: [PATCH] Update mkfs manpage for new defaults: log, attr and inodes v2, Drop the ability to turn unwritten extents off completly, reduce imaxpct for big filesystems, less AGs for single disks configs. --- xfsprogs/man/man8/mkfs.xfs.8 | 41 ++++++++++++++++++----------------------- 1 files changed, 18 insertions(+), 23 deletions(-) diff --git a/xfsprogs/man/man8/mkfs.xfs.8 b/xfsprogs/man/man8/mkfs.xfs.8 index b6024c3..afc284c 100644 --- a/xfsprogs/man/man8/mkfs.xfs.8 +++ b/xfsprogs/man/man8/mkfs.xfs.8 @@ -304,10 +304,16 @@ bits. This specifies the maximum percentage of space in the filesystem that can be allocated to inodes. The default .I value -is 25%. Setting the +is 25% for filesystems under 1TB, 5% for filesystems under 50TB and 1% +for filesystems over 50TB. Setting the .I value -to 0 means that essentially all of the filesystem can -become inode blocks. +to 0 means that essentially all of the filesystem can become inode +blocks. Note that this is only used by inode32 (on 32bits platforms), +and is ignored on 64bits platforms. On 32 bits platforms, we can only +use the first TB of disk space for inodes, so the allocator will try +to avoid this region, hence miss-using the first AG if this is set to +high (the worst case is a 4TB filesystem where a full AG will be +untouched by anything but inodes with a 25% maxpct). .TP .BI align[= value ] This is used to specify that inode allocation is or is not aligned. The @@ -325,18 +331,11 @@ that does not have the inode alignment feature (any release of IRIX before 6.2, and IRIX 6.2 without XFS patches). .TP .BI attr[= value ] -This is used to specify the version of extended attribute inline allocation -policy to be used. -By default, this is zero. Once extended attributes are used for the -first time, the version will be set to either one or two. -The current version (two) uses a more efficient algorithm for managing -the available inline inode space than version one does, however, for -backward compatibility reasons (and in the absence of the -.B attr=2 -mkfs option, or the -.B attr2 -mount option), version one will be selected -by default when attributes are first used on a filesystem. +This is used to specify the version of extended attribute inline +allocation policy to be used. By default, this is 2. The current +version (two) uses a more efficient algorithm for managing the +available inline inode space than version one does. This option is +kept for backward compatibility, attr2 was added in kernel 2.6.16. .RE .TP .BI \-l " log_section_options" @@ -389,15 +388,11 @@ and directory block size, the minimum log size is larger than 512 blocks. .BI version= value This specifies the version of the log. The .I value -is either 1 or 2. Specifying +is either 1 or 2 (the default is 2). .B version=2 -enables the -.B sunit -suboption, and allows the logbsize to be increased beyond 32K. -Version 2 logs are automatically selected if a log stripe unit -is specified. See -.BR sunit " and " su -suboptions, below. +allows bigger log buffer size (version 1 had a limit at 32K), and the +use of the sunit and su options. Possibility to use version=1 is left +for backward compatibility only. .TP .BI sunit= value This specifies the alignment to be used for log writes. The -- 1.5.4.3 --=-=-=-- From owner-xfs@oss.sgi.com Wed Mar 5 21:29:18 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 05 Mar 2008 21:29:27 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_43 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m265THoo025180 for ; Wed, 5 Mar 2008 21:29:18 -0800 X-ASG-Debug-ID: 1204781384-43e303400000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id D0D3811FAB43 for ; Wed, 5 Mar 2008 21:29:45 -0800 (PST) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id RT2IPUsqN1GEhOO9 for ; Wed, 05 Mar 2008 21:29:45 -0800 (PST) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id DFAD118004EFE; Wed, 5 Mar 2008 23:29:11 -0600 (CST) Message-ID: <47CF8127.40900@sandeen.net> Date: Wed, 05 Mar 2008 23:29:11 -0600 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Niv Sardi CC: xfs@oss.sgi.com, xfs-dev@sgi.com X-ASG-Orig-Subj: Re: [REVIEW] mkfs.xfs man page needs the default settings updated, TAKE 2. Subject: Re: [REVIEW] mkfs.xfs man page needs the default settings updated, TAKE 2. References: <47CD6D0E.3090301@sandeen.net> <47CD6ED7.5050505@sandeen.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1204781386 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.44011 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14782 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Niv Sardi wrote: > Thanks to Eric for the comments, is this better ? > > Cheers, > > -- Niv Sardi > > > > From 7e0e328663858ecf13f35678f1a6d349c3d4dd5a Mon Sep 17 00:00:00 2001 > From: Niv Sardi > Date: Fri, 22 Feb 2008 16:48:32 +1100 > Subject: [PATCH] Update mkfs manpage for new defaults: > > log, attr and inodes v2, > Drop the ability to turn unwritten extents off completly, > reduce imaxpct for big filesystems, less AGs for single disks configs. > --- > xfsprogs/man/man8/mkfs.xfs.8 | 41 ++++++++++++++++++----------------------- > 1 files changed, 18 insertions(+), 23 deletions(-) > > diff --git a/xfsprogs/man/man8/mkfs.xfs.8 b/xfsprogs/man/man8/mkfs.xfs.8 > index b6024c3..afc284c 100644 > --- a/xfsprogs/man/man8/mkfs.xfs.8 > +++ b/xfsprogs/man/man8/mkfs.xfs.8 > @@ -304,10 +304,16 @@ bits. > This specifies the maximum percentage of space in the filesystem that > can be allocated to inodes. The default > .I value > -is 25%. Setting the > +is 25% for filesystems under 1TB, 5% for filesystems under 50TB and 1% > +for filesystems over 50TB. Setting the > .I value > -to 0 means that essentially all of the filesystem can > -become inode blocks. > +to 0 means that essentially all of the filesystem can become inode > +blocks. Note that this is only used by inode32 (on 32bits platforms), > +and is ignored on 64bits platforms. Really? The m_maxicount tests in xfs_ialloc_ag_alloc and xfs_dialloc don't seem to care about inode32 or not, unless I'm missing something. > +On 32 bits platforms, we can only > +use the first TB of disk space for inodes, well, that depends on the inode size... > +so the allocator will try the data allocator... > +to avoid this region, hence miss-using the first AG if this is set to > +high (the worst case is a 4TB filesystem where a full AG will be > +untouched by anything but inodes with a 25% maxpct). ah, ok. It becomes slightly clearer. :) How about... maxpct=value This specifies the maximum percentage of space in the filesystem that can be allocated to inodes. The default value is 25% for filesystems under 1TB, 5% for filesystems under 50TB and 1% for filesystems over 50TB. In the default inode allocation mode, inode blocks are chosen such that inode numbers will not exceed 32 bits, which restricts the inode blocks to the lower portion of the filesystem. The data block allocator will avoid these low blocks to accommodate the specified maxpct, so a high value may result in a filesystem with nothing but inodes in a significant portion of the lower blocks of the filesystem. (This restriction is not present when the filesystem is mounted with the "inode64" option on 64-bit platforms). Setting the value to 0 means that essentially all of the filesystem can become inode blocks, subject to inode32 restrictions. This value can be modified with xfs_growfs(8). eh... could be better... but how's it sound? > .TP > .BI align[= value ] > This is used to specify that inode allocation is or is not aligned. The > @@ -325,18 +331,11 @@ that does not have the inode alignment feature > (any release of IRIX before 6.2, and IRIX 6.2 without XFS patches). > .TP > .BI attr[= value ] > -This is used to specify the version of extended attribute inline allocation > -policy to be used. > -By default, this is zero. Once extended attributes are used for the > -first time, the version will be set to either one or two. > -The current version (two) uses a more efficient algorithm for managing > -the available inline inode space than version one does, however, for > -backward compatibility reasons (and in the absence of the > -.B attr=2 > -mkfs option, or the > -.B attr2 > -mount option), version one will be selected > -by default when attributes are first used on a filesystem. > +This is used to specify the version of extended attribute inline > +allocation policy to be used. By default, this is 2. The current > +version (two) uses a more efficient algorithm for managing the > +available inline inode space than version one does. This option is > +kept for backward compatibility, attr2 was added in kernel 2.6.16. attr[=value] (hmm why the brackets; is value really optional?) This is used to specify the version of extended attribute inline allocation policy to be used. By default, this is 2, which uses an efficient algorithm for managing the available inline inode space between attribute and extent data. The previous version 1, which has fixed regions for attribute and extent data, is kept for backwards compatibility with kernels older than version 2.6.16. (aside: will older kernels refuse to mount attr2 filesystems? I suppose they will but I'm not sure they need to?) -Eric > .RE > .TP > .BI \-l " log_section_options" > @@ -389,15 +388,11 @@ and directory block size, the minimum log size is larger than 512 blocks. > .BI version= value > This specifies the version of the log. The > .I value > -is either 1 or 2. Specifying > +is either 1 or 2 (the default is 2). > .B version=2 > -enables the > -.B sunit > -suboption, and allows the logbsize to be increased beyond 32K. > -Version 2 logs are automatically selected if a log stripe unit > -is specified. See > -.BR sunit " and " su > -suboptions, below. > +allows bigger log buffer size (version 1 had a limit at 32K), and the > +use of the sunit and su options. Possibility to use version=1 is left > +for backward compatibility only. version=value This specifies the version of the log. The current default is 2, which allows for larger log buffer sizes, as well as supporting stripe-aligned log writes (see the sunit and su options, below). The previous version 1, which is limited to 32k log buffers and does not support stripe-aligned writes, is kept for backwards compatibility with kernels older than version 2.XX.XX > .TP > .BI sunit= value > This specifies the alignment to be used for log writes. The > -- 1.5.4.3 From owner-xfs@oss.sgi.com Wed Mar 5 21:59:29 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 05 Mar 2008 21:59:48 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m265xJUp026311 for ; Wed, 5 Mar 2008 21:59:23 -0800 Received: from pc-bnaujok.melbourne.sgi.com (pc-bnaujok.melbourne.sgi.com [134.14.55.58]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA16464; Thu, 6 Mar 2008 16:59:49 +1100 Date: Thu, 06 Mar 2008 17:02:07 +1100 To: "xfs@oss.sgi.com" , xfs-dev Subject: Final call for review of sb_bad_features2 in userspace From: "Barry Naujok" Organization: SGI Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 Message-ID: User-Agent: Opera Mail/9.24 (Win32) X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from Base64 to 8bit by oss.sgi.com id m265xTUp026346 X-archive-position: 14783 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs I think the attached patch maybe the least offensive for past kernels, and XFSQA! xfs_check and xfs_repair will ignore sb_bad_features2 if it is zero, and if not, makes sure it's the same as sb_features2. mkfs.xfs will set sb_bad_features2 to be the same. Maybe if we change the behaviour of the kernel mount code with respects of sb_bad_features2, this can be revisited. (An intermediate solution I has was if "xfs_repair -n" is run AND sb_bad_features is zero, then ignore it to let xfs_repair continue, otherwise duplicate it, but doing that requires a golden output change to QA 030 and 033 unless the kernel mount code is changed... ARGH!) -- =========================================================================== xfsprogs/db/check.c =========================================================================== --- a/xfsprogs/db/check.c 2008-03-06 16:59:31.000000000 +1100 +++ b/xfsprogs/db/check.c 2008-03-06 12:32:54.664882390 +1100 @@ -869,6 +869,15 @@ blockget_f( mp->m_sb.sb_frextents, frextents); error++; } + if (mp->m_sb.sb_bad_features2 != 0 && + mp->m_sb.sb_bad_features2 != mp->m_sb.sb_features2) { + if (!sflag) + dbprintf("sb_features2 (0x%x) not same as " + "sb_bad_features2 (0x%x)\n", + mp->m_sb.sb_features2, + mp->m_sb.sb_bad_features2); + error++; + } if ((sbversion & XFS_SB_VERSION_ATTRBIT) && !XFS_SB_VERSION_HASATTR(&mp->m_sb)) { if (!sflag) =========================================================================== xfsprogs/db/sb.c =========================================================================== --- a/xfsprogs/db/sb.c 2008-03-06 16:59:31.000000000 +1100 +++ b/xfsprogs/db/sb.c 2008-02-29 17:16:33.770423296 +1100 @@ -108,6 +108,7 @@ const field_t sb_flds[] = { { "logsectsize", FLDT_UINT16D, OI(OFF(logsectsize)), C1, 0, TYP_NONE }, { "logsunit", FLDT_UINT32D, OI(OFF(logsunit)), C1, 0, TYP_NONE }, { "features2", FLDT_UINT32X, OI(OFF(features2)), C1, 0, TYP_NONE }, + { "bad_features2", FLDT_UINT32X, OI(OFF(bad_features2)), C1, 0, TYP_NONE }, { NULL } }; =========================================================================== xfsprogs/include/xfs_sb.h =========================================================================== --- a/xfsprogs/include/xfs_sb.h 2008-03-06 16:59:31.000000000 +1100 +++ b/xfsprogs/include/xfs_sb.h 2008-02-29 17:16:33.814417687 +1100 @@ -151,6 +151,7 @@ typedef struct xfs_sb __uint16_t sb_logsectsize; /* sector size for the log, bytes */ __uint32_t sb_logsunit; /* stripe unit size for the log */ __uint32_t sb_features2; /* additional feature bits */ + __uint32_t sb_bad_features2; /* unusable space */ } xfs_sb_t; /* @@ -169,7 +170,7 @@ typedef enum { XFS_SBS_GQUOTINO, XFS_SBS_QFLAGS, XFS_SBS_FLAGS, XFS_SBS_SHARED_VN, XFS_SBS_INOALIGNMT, XFS_SBS_UNIT, XFS_SBS_WIDTH, XFS_SBS_DIRBLKLOG, XFS_SBS_LOGSECTLOG, XFS_SBS_LOGSECTSIZE, XFS_SBS_LOGSUNIT, - XFS_SBS_FEATURES2, + XFS_SBS_FEATURES2, XFS_SBS_BAD_FEATURES2, XFS_SBS_FIELDCOUNT } xfs_sb_field_t; =========================================================================== xfsprogs/libxfs/xfs_mount.c =========================================================================== --- a/xfsprogs/libxfs/xfs_mount.c 2008-03-06 16:59:31.000000000 +1100 +++ b/xfsprogs/libxfs/xfs_mount.c 2008-02-29 17:16:33.834415138 +1100 @@ -140,6 +140,7 @@ static struct { { offsetof(xfs_sb_t, sb_logsectsize),0 }, { offsetof(xfs_sb_t, sb_logsunit), 0 }, { offsetof(xfs_sb_t, sb_features2), 0 }, + { offsetof(xfs_sb_t, sb_bad_features2), 0 }, { sizeof(xfs_sb_t), 0 } }; =========================================================================== xfsprogs/mkfs/xfs_mkfs.c =========================================================================== --- a/xfsprogs/mkfs/xfs_mkfs.c 2008-03-06 16:59:31.000000000 +1100 +++ b/xfsprogs/mkfs/xfs_mkfs.c 2008-03-05 15:27:37.568461787 +1100 @@ -2103,6 +2103,13 @@ an AG size that is one stripe unit small dirversion == 2, logversion == 2, attrversion == 1, (sectorsize != BBSIZE || lsectorsize != BBSIZE), sbp->sb_features2 != 0); + /* + * Due to a structure alignment issue, sb_features2 ended up in one + * of two locations, the second "incorrect" location represented by + * the sb_bad_features2 field. To avoid older kernels mounting + * filesystems they shouldn't, set both field to the same value. + */ + sbp->sb_bad_features2 = sbp->sb_features2; if (force_overwrite) zero_old_xfs_structures(&xi, sbp); =========================================================================== xfsprogs/repair/phase1.c =========================================================================== --- a/xfsprogs/repair/phase1.c 2008-03-06 16:59:31.000000000 +1100 +++ b/xfsprogs/repair/phase1.c 2008-03-06 16:57:40.021125442 +1100 @@ -91,6 +91,20 @@ phase1(xfs_mount_t *mp) primary_sb_modified = 1; } + /* + * Check bad_features2 and make sure features2 the same as + * bad_features (ORing the two together). Leave bad_features2 + * set so older kernels can still use it and not mount unsupported + * filesystems when it reads bad_features2. + */ + if (sb->sb_bad_features2 != 0 && + sb->sb_bad_features2 != sb->sb_features2) { + sb->sb_features2 |= sb->sb_bad_features2; + sb->sb_bad_features2 = sb->sb_features2; + primary_sb_modified = 1; + do_warn(_("superblock has a features2 mismatch, correcting\n")); + } + if (primary_sb_modified) { if (!no_modify) { do_warn(_("writing modified primary superblock\n")); From owner-xfs@oss.sgi.com Wed Mar 5 22:12:48 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 05 Mar 2008 22:13:16 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_00,WEIRD_PORT autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m266Ch6Z027608 for ; Wed, 5 Mar 2008 22:12:47 -0800 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA16904; Thu, 6 Mar 2008 17:13:08 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 44625) id 0808658C4C0F; Thu, 6 Mar 2008 17:13:07 +1100 (EST) Date: Thu, 06 Mar 2008 17:13:07 +1100 To: torvalds@linux-foundation.org Cc: linux-kernel@vger.kernel.org, xfs@oss.sgi.com, akpm@linux-foundation.org Subject: [GIT PULL] XFS update for 2.6.25-rc5 User-Agent: nail 11.25 7/29/05 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20080306061308.0808658C4C0F@chook.melbourne.sgi.com> From: lachlan@sgi.com (Lachlan McIlroy) X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14785 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs Please pull from the for-linus branch: git pull git://oss.sgi.com:8090/xfs/xfs-2.6.git for-linus This will update the following files: fs/xfs/xfs_iget.c | 1 + fs/xfs/xfs_trans_ail.c | 17 ++++++++++------- 2 files changed, 11 insertions(+), 7 deletions(-) through these commits: commit 72772a3b5b158cddcfbbff3ef13b26b03a905158 Author: David Chinner Date: Thu Mar 6 13:49:43 2008 +1100 [XFS] fix inode leak in xfs_iget_core() If the radix_tree_preload() fails, we need to destroy the inode we just read in before trying again. This could leak xfs_vnode structures when there is memory pressure. Noticed by Christoph Hellwig. SGI-PV: 977823 SGI-Modid: xfs-linux-melb:xfs-kern:30606a Signed-off-by: David Chinner Signed-off-by: Lachlan McIlroy Signed-off-by: Christoph Hellwig commit 92d9cd1059f80b9c89dee191ffb88b0872e6a7ae Author: David Chinner Date: Thu Mar 6 13:45:10 2008 +1100 [XFS] 977545 977545 977545 977545 977545 977545 xfsaild causing too many wakeups Idle state is not being detected properly by the xfsaild push code. The current idle state is detected by an empty list which may never happen with mostly idle filesystem or one using lazy superblock counters. A single dirty item in the list that exists beyond the push target can result repeated looping attempting to push up to the target because it fails to check if the push target has been acheived or not. Fix by considering a dirty list with everything past the target as an idle state and set the timeout appropriately. SGI-PV: 977545 SGI-Modid: xfs-linux-melb:xfs-kern:30532a Signed-off-by: David Chinner Signed-off-by: Christoph Hellwig Signed-off-by: Lachlan McIlroy From owner-xfs@oss.sgi.com Wed Mar 5 22:12:35 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 05 Mar 2008 22:13:14 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_43 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m266CSXW027587 for ; Wed, 5 Mar 2008 22:12:33 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA16886; Thu, 6 Mar 2008 17:12:47 +1100 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 m266CkLF84978843; Thu, 6 Mar 2008 17:12:46 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id m266Cg7o83606445; Thu, 6 Mar 2008 17:12:42 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Thu, 6 Mar 2008 17:12:42 +1100 From: David Chinner To: Niv Sardi Cc: Eric Sandeen , xfs@oss.sgi.com, xfs-dev@sgi.com Subject: Re: [REVIEW] mkfs.xfs man page needs the default settings updated, TAKE 2. Message-ID: <20080306061242.GG155407@sgi.com> References: <47CD6D0E.3090301@sandeen.net> <47CD6ED7.5050505@sandeen.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14784 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Thu, Mar 06, 2008 at 03:41:29PM +1100, Niv Sardi wrote: > Thanks to Eric for the comments, is this better ? Not much of a changelog.... > diff --git a/xfsprogs/man/man8/mkfs.xfs.8 b/xfsprogs/man/man8/mkfs.xfs.8 > index b6024c3..afc284c 100644 > --- a/xfsprogs/man/man8/mkfs.xfs.8 > +++ b/xfsprogs/man/man8/mkfs.xfs.8 > @@ -304,10 +304,16 @@ bits. > This specifies the maximum percentage of space in the filesystem that > can be allocated to inodes. The default > .I value > -is 25%. Setting the > +is 25% for filesystems under 1TB, 5% for filesystems under 50TB and 1% > +for filesystems over 50TB. Setting the > .I value > -to 0 means that essentially all of the filesystem can > -become inode blocks. > +to 0 means that essentially all of the filesystem can become inode > +blocks. Note that this is only used by inode32 (on 32bits platforms), > +and is ignored on 64bits platforms. On 32 bits platforms, we can only This is wrong. inode32 is the default on 64 bit platforms as well, and it matters then as well. > +use the first TB of disk space for inodes, so the allocator will try That's not strictly true, either - it depends on inode size; 2k inodes stratch this to 8TB. > +to avoid this region, hence miss-using the first AG if this is set to > +high (the worst case is a 4TB filesystem where a full AG will be > +untouched by anything but inodes with a 25% maxpct). No, it doesn't "miss-use" this space - it reserves it for inodes and metadata and prevents data allocation in those AGs until all other space is consumed. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Wed Mar 5 22:19:30 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 05 Mar 2008 22:19:36 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_43, J_CHICKENPOX_65 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m266JNsU028769 for ; Wed, 5 Mar 2008 22:19:27 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA17212; Thu, 6 Mar 2008 17:19:46 +1100 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 m266JjLF87309214; Thu, 6 Mar 2008 17:19:46 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id m266Jfek87293730; Thu, 6 Mar 2008 17:19:41 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Thu, 6 Mar 2008 17:19:41 +1100 From: David Chinner To: Eric Sandeen Cc: Niv Sardi , xfs@oss.sgi.com, xfs-dev@sgi.com Subject: Re: [REVIEW] mkfs.xfs man page needs the default settings updated, TAKE 2. Message-ID: <20080306061941.GH155407@sgi.com> References: <47CD6D0E.3090301@sandeen.net> <47CD6ED7.5050505@sandeen.net> <47CF8127.40900@sandeen.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47CF8127.40900@sandeen.net> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14786 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Wed, Mar 05, 2008 at 11:29:11PM -0600, Eric Sandeen wrote: > Niv Sardi wrote: > > Thanks to Eric for the comments, is this better ? > > > > Cheers, > > > > -- Niv Sardi > > > > > > > > From 7e0e328663858ecf13f35678f1a6d349c3d4dd5a Mon Sep 17 00:00:00 2001 > > From: Niv Sardi > > Date: Fri, 22 Feb 2008 16:48:32 +1100 > > Subject: [PATCH] Update mkfs manpage for new defaults: > > > > log, attr and inodes v2, > > Drop the ability to turn unwritten extents off completly, > > reduce imaxpct for big filesystems, less AGs for single disks configs. > > --- > > xfsprogs/man/man8/mkfs.xfs.8 | 41 ++++++++++++++++++----------------------- > > 1 files changed, 18 insertions(+), 23 deletions(-) > > > > diff --git a/xfsprogs/man/man8/mkfs.xfs.8 b/xfsprogs/man/man8/mkfs.xfs.8 > > index b6024c3..afc284c 100644 > > --- a/xfsprogs/man/man8/mkfs.xfs.8 > > +++ b/xfsprogs/man/man8/mkfs.xfs.8 > > @@ -304,10 +304,16 @@ bits. > > This specifies the maximum percentage of space in the filesystem that > > can be allocated to inodes. The default > > .I value > > -is 25%. Setting the > > +is 25% for filesystems under 1TB, 5% for filesystems under 50TB and 1% > > +for filesystems over 50TB. Setting the > > .I value > > -to 0 means that essentially all of the filesystem can > > -become inode blocks. > > +to 0 means that essentially all of the filesystem can become inode > > +blocks. Note that this is only used by inode32 (on 32bits platforms), > > +and is ignored on 64bits platforms. > > Really? The m_maxicount tests in xfs_ialloc_ag_alloc and xfs_dialloc > don't seem to care about inode32 or not, unless I'm missing something. See xfs_set_maxicount() and then how it is used in xfs_initialize_perag() to set up pag->pagi_inodeok, pag->pagf_metadata and mp->m_maxagi which are used by the allocator.... > How about... > > maxpct=value > This specifies the maximum percentage of space in the > filesystem that can be allocated to inodes. The > default value is 25% for filesystems under 1TB, 5% for > filesystems under 50TB and 1% for filesystems over 50TB. > > In the default inode allocation mode, inode blocks are > chosen such that inode numbers will not exceed 32 bits, > which restricts the inode blocks to the lower portion of > the filesystem. The data block allocator will avoid these > low blocks to accommodate the specified maxpct, so a high > value may result in a filesystem with nothing but inodes > in a significant portion of the lower blocks of the > filesystem. (This restriction is not present when > the filesystem is mounted with the "inode64" option on > 64-bit platforms). > > Setting the value to 0 means that essentially all of the > filesystem can become inode blocks, subject to inode32 > restrictions. > > This value can be modified with xfs_growfs(8). > > eh... could be better... but how's it sound? Much better. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Thu Mar 6 03:10:08 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 06 Mar 2008 03:10:24 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,MIME_8BIT_HEADER autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m26BA7cq017274 for ; Thu, 6 Mar 2008 03:10:08 -0800 X-ASG-Debug-ID: 1204801835-584f01e30000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ti-out-0910.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 42D9065F041 for ; Thu, 6 Mar 2008 03:10:35 -0800 (PST) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.184]) by cuda.sgi.com with ESMTP id dEl8L5FemDiuCkVF for ; Thu, 06 Mar 2008 03:10:35 -0800 (PST) Received: by ti-out-0910.google.com with SMTP id d10so2606410tib.18 for ; Thu, 06 Mar 2008 03:10:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=n+fhSAm+DLNnIZ4bydPpj+yzn+KtZQq/g3HlgFCpIFQ=; b=rFebC9NOA5nt94u+KycpIjg7JnJB+BIcR1ZXcB+r1Ctrp6l5wIii3yZgJ0RdAZeXCs7lK1/9MiBxTbhp1e5FVqDPlu2hcRTukbchlWYY/hJTRI78gRxSk/46GNgLFI47myThxCugFJz8T3VtA1zj81iNgws5shswetwoBpuO5Fo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ahPk6NoF68Znqz8Ne12QZaLmRwIO1z0vfu0y3anucTIrs6K5W+rLP30PmaitK63WyvEDyvV7s7x7ruyaPbg94GxMs4hR7WSQfMCLB7R2/WlnzPlbEC+5Y3iKAXddzSHsi3EtRtZNo6QnIQ9if/ukekI4xpMvTsR5//aiGzO9Ux4= Received: by 10.150.195.21 with SMTP id s21mr1871319ybf.87.1204801832206; Thu, 06 Mar 2008 03:10:32 -0800 (PST) Received: by 10.150.96.5 with HTTP; Thu, 6 Mar 2008 03:10:32 -0800 (PST) Message-ID: <1a4a774c0803060310w2642224w690ac8fa13f96ec@mail.gmail.com> Date: Thu, 6 Mar 2008 12:10:32 +0100 From: "=?ISO-8859-1?Q?Christian_R=F8snes?=" To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS internal error xfs_trans_cancel at line 1150 of file fs/xfs/xfs_trans.c Subject: Re: XFS internal error xfs_trans_cancel at line 1150 of file fs/xfs/xfs_trans.c In-Reply-To: <1a4a774c0803050553h7f6294cfq41c38f34ea92ceae@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <1a4a774c0802130251h657a52f7lb97942e7afdf6e3f@mail.gmail.com> <20080213214551.GR155407@sgi.com> <1a4a774c0803050553h7f6294cfq41c38f34ea92ceae@mail.gmail.com> X-Barracuda-Connect: ti-out-0910.google.com[209.85.142.184] X-Barracuda-Start-Time: 1204801837 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.44034 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id m26BA8cq017278 X-archive-position: 14787 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: christian.rosnes@gmail.com Precedence: bulk X-list: xfs On Wed, Mar 5, 2008 at 2:53 PM, Christian Røsnes wrote: > > On Wed, Feb 13, 2008 at 11:51:51AM +0100, Christian Røsnes wrote: > > > Over the past month I've been hit with two cases of "xfs_trans_cancel > > > at line 1150" > > > The two errors occurred on different raid sets. In both cases the > > > error happened during > > > rsync from a remote server to this server, and the local partition > > > which reported > > > the error was 99% full (as reported by df -k, see below for details). > > > > > > System: Dell 2850 > > > Mem: 4GB RAM > > > OS: Debian 3 (32-bit) > > > Kernel: 2.6.17.7 (custom compiled) > > > > > After being hit several times by the problem mentioned above (running > kernel 2.6.17.7), > I upgraded the kernel to version 2.6.24.3. I then ran a rsync test to > a 99% full partition: > > df -k: > /dev/sdb1 286380096 282994528 3385568 99% /data > > The rsync application will probably fail because it will most likely > run out of space, > but I got another xfs_trans_cancel kernel message: > > Filesystem "sdb1": XFS internal error xfs_trans_cancel at line 1163 of > file fs/xfs/xfs_trans.c. Caller 0xc021a010 > Pid: 11642, comm: rsync Not tainted 2.6.24.3FC #1 > [] xfs_trans_cancel+0x5d/0xe6 > [] xfs_mkdir+0x45a/0x493 > [] xfs_mkdir+0x45a/0x493 > [] xfs_acl_vhasacl_default+0x33/0x44 > [] xfs_vn_mknod+0x165/0x243 > [] xfs_access+0x2f/0x35 > [] xfs_vn_mkdir+0x12/0x14 > [] vfs_mkdir+0xa3/0xe2 > [] sys_mkdirat+0x8a/0xc3 > [] sys_mkdir+0x1f/0x23 > [] syscall_call+0x7/0xb > ======================= > xfs_force_shutdown(sdb1,0x8) called from line 1164 of file > fs/xfs/xfs_trans.c. Return address = 0xc0212690 > > Filesystem "sdb1": Corruption of in-memory data detected. Shutting > down filesystem: sdb1 > Please umount the filesystem, and rectify the problem(s) > Actually, a single mkdir command is enough to trigger the filesystem shutdown when its 99% full (according to df -k): /data# mkdir test mkdir: cannot create directory `test': No space left on device Filesystem "sdb1": XFS internal error xfs_trans_cancel at line 1163 of file fs/xfs/xfs_trans.c. Caller 0xc021a010 Pid: 23380, comm: mkdir Not tainted 2.6.24.3FC #1 [] xfs_trans_cancel+0x5d/0xe6 [] xfs_mkdir+0x45a/0x493 [] xfs_mkdir+0x45a/0x493 [] xfs_acl_vhasacl_default+0x33/0x44 [] xfs_vn_mknod+0x165/0x243 [] xfs_access+0x2f/0x35 [] xfs_vn_mkdir+0x12/0x14 [] vfs_mkdir+0xa3/0xe2 [] sys_mkdirat+0x8a/0xc3 [] sys_mkdir+0x1f/0x23 [] syscall_call+0x7/0xb [] atm_reset_addr+0xd/0x83 ======================= xfs_force_shutdown(sdb1,0x8) called from line 1164 of file fs/xfs/xfs_trans.c. Return address = 0xc0212690 Filesystem "sdb1": Corruption of in-memory data detected. Shutting down filesystem: sdb1 Please umount the filesystem, and rectify the problem(s) df -k ----- /dev/sdb1 286380096 282994528 3385568 99% /data df -i ----- /dev/sdb1 10341248 3570112 6771136 35% /data xfs_info -------- meta-data=/dev/sdb1 isize=512 agcount=16, agsize=4476752 blks = sectsz=512 attr=0 data = bsize=4096 blocks=71627792, imaxpct=25 = sunit=16 swidth=32 blks, unwritten=1 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=32768, version=2 = sectsz=512 sunit=16 blks, lazy-count=0 realtime =none extsz=65536 blocks=0, rtextents=0 xfs_db -r -c 'sb 0' -c p /dev/sdb1 ---------------------------------- magicnum = 0x58465342 blocksize = 4096 dblocks = 71627792 rblocks = 0 rextents = 0 uuid = d16489ab-4898-48c2-8345-6334af943b2d logstart = 67108880 rootino = 128 rbmino = 129 rsumino = 130 rextsize = 16 agblocks = 4476752 agcount = 16 rbmblocks = 0 logblocks = 32768 versionnum = 0x3584 sectsize = 512 inodesize = 512 inopblock = 8 fname = "\000\000\000\000\000\000\000\000\000\000\000\000" blocklog = 12 sectlog = 9 inodelog = 9 inopblog = 3 agblklog = 23 rextslog = 0 inprogress = 0 imax_pct = 25 icount = 3570112 ifree = 0 fdblocks = 847484 frextents = 0 uquotino = 0 gquotino = 0 qflags = 0 flags = 0 shared_vn = 0 inoalignmt = 2 unit = 16 width = 32 dirblklog = 0 logsectlog = 0 logsectsize = 0 logsunit = 65536 features2 = 0 Christian From owner-xfs@oss.sgi.com Thu Mar 6 08:09:37 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 06 Mar 2008 08:09:54 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m26G9ZAB025720 for ; Thu, 6 Mar 2008 08:09:36 -0800 X-ASG-Debug-ID: 1204819803-09e6018a0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.pawisda.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 91918F2A75F for ; Thu, 6 Mar 2008 08:10:04 -0800 (PST) Received: from mail.pawisda.de (mail.pawisda.de [213.157.4.156]) by cuda.sgi.com with ESMTP id nRVxdO3g7rsyeaRU for ; Thu, 06 Mar 2008 08:10:04 -0800 (PST) Received: from localhost (localhost.intra.frontsite.de [127.0.0.1]) by mail.pawisda.de (Postfix) with ESMTP id AB41C11132; Thu, 6 Mar 2008 17:10:03 +0100 (CET) Received: from mail.pawisda.de ([127.0.0.1]) by localhost (ndb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30446-04; Thu, 6 Mar 2008 17:09:52 +0100 (CET) Received: from [192.168.51.99] (lw-lap099.intra.frontsite.de [192.168.51.99]) by mail.pawisda.de (Postfix) with ESMTP id 53FB51114A; Thu, 6 Mar 2008 17:09:52 +0100 (CET) X-ASG-Orig-Subj: Re: REVIEW: xfs_reno #2 Subject: Re: REVIEW: xfs_reno #2 From: Ruben Porras To: Barry Naujok Cc: "xfs@oss.sgi.com" In-Reply-To: References: Content-Type: text/plain Date: Thu, 06 Mar 2008 17:10:35 +0100 Message-Id: <1204819835.4002.36.camel@tecra.thekeening.homeunix.org> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Scanned: by amavisd-new at pawisda.de X-Barracuda-Connect: mail.pawisda.de[213.157.4.156] X-Barracuda-Start-Time: 1204819804 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.44055 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Status: Clean X-archive-position: 14788 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: ruben.porras@linworks.de Precedence: bulk X-list: xfs Am Donnerstag, den 04.10.2007, 14:25 +1000 schrieb Barry Naujok: > A couple changes from the first xfs_reno: > > - Major one is that symlinks are now supported, but only > owner, group and extended attributes are copied for them > (not times or inode attributes). > > - Man page! > > > To make this better, ideally we need some form of > "swap inodes" function in the kernel, where the entire > contents of the inode themselves are swapped. This form > can handle any inode and without any of the dir/file/attr/etc > copy/swap mechanisms we have in xfs_reno. > > Barry. +static int +process_slink( + bignode_t *node) +{ + int i = 0; + int rval = 0; + struct stat64 st; + char *srcname = NULL; + char *pname = NULL; + char target[PATH_MAX] = ""; + char linkbuf[PATH_MAX]; + + SET_PHASE(SLINK_PHASE); + + dump_node("symlink", node); + + cur_node = node; + srcname = node->paths[0]; + + if (lstat64(srcname, &st) < 0) { + if (errno != ENOENT) { + err_stat(srcname); + global_rval |= 2; + } + goto quit; + } + if (st.st_ino <= XFS_MAXINUMBER_32 && !force_all) + /* this file has changed, and no longer needs processing */ + goto quit; This check need to go out, the same in functions process_dir and process_file. + rval = 1; + + i = readlink(srcname, linkbuf, sizeof(linkbuf) - 1); + if (i < 0) { + err_message(_("unable to read symlink: %s"), srcname); + goto quit; + } + linkbuf[i] = '\0'; + + if (realuid != 0 && realuid != st.st_uid) { + errno = EACCES; + err_open(srcname); + goto quit; + } + + /* create target */ + pname = strdup(srcname); + if (pname == NULL) { + err_nomem(); + goto quit; + } + dirname(pname); + + sprintf(target, "%s/%sXXXXXX", pname, cmd_prefix); + if (mktemp(target) == NULL) { + err_message(_("unable to create temp symlink name")); + goto quit; + } do not create the file, it is done later with symlink, if the file exists, symlink is going to fail. + cur_target = strdup(target); + if (cur_target == NULL) { + err_nomem(); + goto quit; + } cur_target is not needed. + + if (symlink(linkbuf, target) != 0) { + err_message(_("unable to create symlink: %s"), target); + goto quit; + } [...] + free(cur_target); + + cur_target = NULL; again, both are unnecesary. + numslinksdone++; + return rval; +} From owner-xfs@oss.sgi.com Thu Mar 6 08:36:48 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 06 Mar 2008 08:37:08 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_31, J_CHICKENPOX_42,J_CHICKENPOX_44,J_CHICKENPOX_45,J_CHICKENPOX_46, J_CHICKENPOX_47,J_CHICKENPOX_48,J_CHICKENPOX_52,J_CHICKENPOX_57, J_CHICKENPOX_62,J_CHICKENPOX_63,J_CHICKENPOX_64,J_CHICKENPOX_66, J_CHICKENPOX_73,J_CHICKENPOX_74,J_CHICKENPOX_83,J_CHICKENPOX_93 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m26GajIM032508 for ; Thu, 6 Mar 2008 08:36:48 -0800 X-ASG-Debug-ID: 1204821430-0a2701d30000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.pawisda.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id B83C5F2AC2F for ; Thu, 6 Mar 2008 08:37:10 -0800 (PST) Received: from mail.pawisda.de (mail.pawisda.de [213.157.4.156]) by cuda.sgi.com with ESMTP id 9yr4RmE2NqfN4kkY for ; Thu, 06 Mar 2008 08:37:10 -0800 (PST) Received: from localhost (localhost.intra.frontsite.de [127.0.0.1]) by mail.pawisda.de (Postfix) with ESMTP id 1277411154; Thu, 6 Mar 2008 17:11:12 +0100 (CET) Received: from mail.pawisda.de ([127.0.0.1]) by localhost (ndb [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30257-09; Thu, 6 Mar 2008 17:11:01 +0100 (CET) Received: from [192.168.51.99] (lw-lap099.intra.frontsite.de [192.168.51.99]) by mail.pawisda.de (Postfix) with ESMTP id AF48611113; Thu, 6 Mar 2008 17:11:01 +0100 (CET) X-ASG-Orig-Subj: Re: REVIEW: xfs_reno #2 Subject: Re: REVIEW: xfs_reno #2 From: Ruben Porras To: David Chinner Cc: Barry Naujok , "xfs@oss.sgi.com" In-Reply-To: <20071120013651.GR995458@sgi.com> References: <20071120013651.GR995458@sgi.com> Content-Type: multipart/mixed; boundary="=-4Da9GvHld0Grtgo95r+H" Date: Thu, 06 Mar 2008 17:11:46 +0100 Message-Id: <1204819906.4002.40.camel@tecra.thekeening.homeunix.org> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Scanned: by amavisd-new at pawisda.de X-Barracuda-Connect: mail.pawisda.de[213.157.4.156] X-Barracuda-Start-Time: 1204821432 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.44057 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Status: Clean X-archive-position: 14789 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: ruben.porras@linworks.de Precedence: bulk X-list: xfs --=-4Da9GvHld0Grtgo95r+H Content-Type: text/plain Content-Transfer-Encoding: 7bit Am Dienstag, den 20.11.2007, 12:36 +1100 schrieb David Chinner: > On Thu, Oct 04, 2007 at 02:25:16PM +1000, Barry Naujok wrote: > > To make this better, ideally we need some form of > > "swap inodes" function in the kernel, where the entire > > contents of the inode themselves are swapped. This form > > can handle any inode and without any of the dir/file/attr/etc > > copy/swap mechanisms we have in xfs_reno. > > Something like the attached patch? > > This is proof-of-concept. I've compiled it but I haven't tested > it. Your mission, Barry, should you choose to accept it, it to Hello again, I have this week again time to at xfs_reno and xfs_swapino and xfs_swap_extents functions. I adapted xfs_reno to use these ioctl instead of the user space dir/file/attr/..., and I move successfully files and directories (see the problem description later). Then I run into two problems, one processing directories, and one processing symlinks, where I do not now how to proceed, and I would like to have advice. Firsts, directories: At this moment it is not possible to use xfs_swap_extents to for directories: (extract from xfs_dfrag.c) if (VN_CACHED(tvp) != 0) { xfs_inval_cached_trace(tip, 0, -1, 0, -1); error = xfs_flushinval_pages(tip, 0, -1, FI_REMAPF_LOCKED); if (error) goto error0; } /* Verify O_DIRECT for ftmp */ if (VN_CACHED(tvp) != 0) { error = XFS_ERROR(EINVAL); goto error0; } But it is not posible to do an open(2) on a directory with O_DIRECT. I was unable to find out if this restriction comes from the kernel or from the glibc, neither why open on dirs with O_DIRECT needs to be forbidden (hints would be appreciated ;), but changing this snippet to /* There is no O_DIRECT for directories */ if (VN_CACHED(tvp) != 0 && VN_ISDIR(tvp) == 0) { error = XFS_ERROR(EINVAL); goto error0; } does the trick. Can we do that? Second, symlinks: xfs_swapino and xfs_swap_extents, require the file descriptors of the related files. However, it is not possible to get from user space the fd of a symlink, because open(2) follow always the symlinks. I would change this functions to accept xfs_inode as parameters instead of file descriptors, and get them in xfs_reno with stat und lstat, but I would like to get your opinion before changing the ioctls. Attached the modified xfs_reno.c (process_slink not working). Regards. --=-4Da9GvHld0Grtgo95r+H Content-Disposition: attachment; filename=xfs_reno.c Content-Type: text/x-csrc; name=xfs_reno.c; charset=UTF-8 Content-Transfer-Encoding: 7bit /* * Copyright (c) 2007 Silicon Graphics, Inc. * All Rights Reserved. * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License as * published by the Free Software Foundation. * * This program is distributed in the hope that it would be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program; if not, write the Free Software Foundation, * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA */ /* * xfs_reno - renumber 64-bit inodes * * xfs_reno [-f] [-n] [-p] [-q] [-v] [-P seconds] path ... * xfs_reno [-r] path ... * * Renumbers all inodes > 32 bits into 32 bit space. Requires the filesytem * to be mounted with inode32. * * -f force conversion on all inodes rather than just * those with a 64bit inode number. * -n nothing, do not renumber inodes * -p show progress status. * -q quiet, do not report progress, only errors. * -v verbose, more -v's more verbose. * -P seconds set the interval for the progress status in seconds. * -r recover from an interrupted run. */ #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #define SCAN_PHASE 0x00 #define DIR_PHASE 0x10 /* nothing done or all done */ #define DIR_PHASE_1 0x11 /* temp dir created */ #define DIR_PHASE_2 0x12 /* swapped extents and inodes */ #define DIR_PHASE_3 0x13 /* src dir removed */ #define DIR_PHASE_MAX 0x13 /* renamed temp to source name */ #define FILE_PHASE 0x20 /* nothing done or all done */ #define FILE_PHASE_1 0x21 /* temp file created */ #define FILE_PHASE_2 0x22 /* swapped extents and inodes */ #define FILE_PHASE_3 0x23 /* unlinked source */ #define FILE_PHASE_4 0x24 /* hard links copied */ #define FILE_PHASE_MAX 0x24 /* renamed temp to source name */ #define SLINK_PHASE 0x30 /* nothing done or all done */ #define SLINK_PHASE_1 0x31 /* temp symlink created */ #define SLINK_PHASE_2 0x32 /* symlink attrs copied */ #define SLINK_PHASE_3 0x33 /* unlinked source */ #define SLINK_PHASE_4 0x34 /* hard links copied */ #define SLINK_PHASE_MAX 0x34 /* renamed temp to source name */ static void update_recoverfile(void); #define SET_PHASE(x) (cur_phase = x, update_recoverfile()) #define LOG_ERR 0 #define LOG_NORMAL 1 #define LOG_INFO 2 #define LOG_DEBUG 3 #define LOG_NITTY 4 #define NH_BUCKETS 65536 #define NH_HASH(ino) (nodehash + ((ino) % NH_BUCKETS)) typedef struct { xfs_ino_t ino; int ftw_flags; nlink_t numpaths; char **paths; } bignode_t; typedef struct { bignode_t *nodes; uint64_t listlen; uint64_t lastnode; } nodelist_t; static const char *cmd_prefix = "xfs_reno_"; static char *progname; static int log_level = LOG_NORMAL; static int force_all; static nodelist_t *nodehash; static int realuid; static uint64_t numdirnodes; static uint64_t numfilenodes; static uint64_t numslinknodes; static uint64_t numdirsdone; static uint64_t numfilesdone; static uint64_t numslinksdone; static int poll_interval; static time_t starttime; static bignode_t *cur_node; static char *cur_target; static int cur_phase; static int highest_numpaths; static char *recover_file; static int recover_fd; static volatile int poll_output; static int global_rval; static int *agmask; /* * message handling */ static void log_message( int level, char *fmt, ...) { char buf[1024]; va_list ap; if (log_level < level) return; va_start(ap, fmt); vsnprintf(buf, 1024, fmt, ap); va_end(ap); printf("%c%s: %s\n", poll_output ? '\n' : '\r', progname, buf); poll_output = 0; } static void err_message( char *fmt, ...) { char buf[1024]; va_list ap; va_start(ap, fmt); vsnprintf(buf, 1024, fmt, ap); va_end(ap); fprintf(stderr, "%c%s: %s\n", poll_output ? '\n' : '\r', progname, buf); poll_output = 0; } static void err_nomem(void) { err_message(_("Out of memory")); } static void err_open( const char *s) { err_message(_("Cannot open %s: %s"), s, strerror(errno)); } static void err_not_xfs( const char *s) { err_message(_("%s is not on an XFS filesystem"), s); } static void err_stat( const char *s) { err_message(_("Cannot stat %s: %s\n"), s, strerror(errno)); } static void err_swapino( int err, const char *srcname) { if (log_level >= LOG_DEBUG) { switch (err) { case EIO: err_message(_("Filesystem is going down: %s: %s"), srcname, strerror(err)); break; default: err_message(_("Swap inode failed: %s: %s"), srcname, strerror(err)); break; } } else err_message(_("Swap inode failed: %s: %s"), srcname, strerror(err)); } static void err_swapext( int err, const char *srcname, xfs_off_t bs_size) { if (log_level >= LOG_DEBUG) { switch (err) { case ENOTSUP: err_message("%s: file type not supported", srcname); break; case EFAULT: /* The file has changed since we started the copy */ err_message("%s: file modified, " "inode renumber aborted: %ld", srcname, bs_size); break; case EBUSY: /* Timestamp has changed or mmap'ed file */ err_message("%s: file busy", srcname); break; default: err_message(_("Swap extents failed: %s: %s"), srcname, strerror(errno)); break; } } else err_message(_("Swap extents failed: %s: %s"), srcname, strerror(errno)); } /* * usage message */ static void usage(void) { fprintf(stderr, _("%s [-fnpqv] [-P ] [-r] \n"), progname); exit(1); } /* * XFS interface functions */ static int xfs_bulkstat_single(int fd, xfs_ino_t *lastip, xfs_bstat_t *ubuffer) { xfs_fsop_bulkreq_t bulkreq; bulkreq.lastip = (__u64 *)lastip; bulkreq.icount = 1; bulkreq.ubuffer = ubuffer; bulkreq.ocount = NULL; return ioctl(fd, XFS_IOC_FSBULKSTAT_SINGLE, &bulkreq); } static int xfs_swapext(int fd, xfs_swapext_t *sx) { return ioctl(fd, XFS_IOC_SWAPEXT, sx); } static int xfs_get_agflags(const char *filepath) { xfs_fsop_geom_t fsgeo; xfs_ioc_agflags_t ioc_flags; int error = 0; xfs_agnumber_t agno; int fd; if ((fd = open(filepath, O_RDONLY /* | O_DIRECT | O_NOATIME */)) == -1) { err_open(filepath); return -1; } if ((error = xfsctl(filepath, fd, XFS_IOC_FSGEOMETRY, &fsgeo)) < 0) { fprintf(stderr, _("cannot get geometry of fs: %s\n"), strerror(errno)); goto error0; } agmask = (int *) calloc(fsgeo.agcount, sizeof(int)); for (agno = 0; agno < fsgeo.agcount ; agno++) { ioc_flags.ag = agno; if ((error = xfsctl(filepath, fd, XFS_IOC_GET_AGF_FLAGS, &ioc_flags)) < 0) { fprintf(stderr, _("cannot get flags %d on ag %d at %s: %s\n"), ioc_flags.flags, ioc_flags.ag, filepath, strerror(errno)); return error; } agmask[agno] = ioc_flags.flags & XFS_AGF_FLAGS_ALLOC_DENY; } error0: close(fd); return error; } static int xfs_swapino(int fd, xfs_swapino_t *iu) { return ioctl(fd, XFS_IOC_SWAPINO, iu); } static int xfs_getxattr(int fd, struct fsxattr *attr) { return ioctl(fd, XFS_IOC_FSGETXATTR, attr); } /* * A hash table of inode numbers and associated paths. */ static nodelist_t * init_nodehash(void) { nodehash = calloc(NH_BUCKETS, sizeof(nodelist_t)); if (nodehash == NULL) { err_nomem(); return NULL; } return nodehash; } static int in_ag_to_free(const char *filepath) { xfs_ioc_fileag_t fileag; int error; if ((fileag.fd = open(filepath, O_RDONLY /* | O_DIRECT | O_NOATIME */)) == -1) { err_open(filepath); return -1; } if ((error = xfsctl(filepath, fileag.fd, XFS_IOC_GETFILEAG, &fileag)) < 0) { fprintf(stderr, _("%s: cannot get the AG of the file: %s\n"), filepath, strerror(errno)); close(fileag.fd); return error; } close(fileag.fd); if (agmask[fileag.ag] == 1) printf("AG: %d, MASK: %d\t", fileag.ag, agmask[fileag.ag]); return agmask[fileag.ag]; } static void free_nodehash(void) { int i, j, k; for (i = 0; i < NH_BUCKETS; i++) { bignode_t *nodes = nodehash[i].nodes; for (j = 0; j < nodehash[i].lastnode; j++) { for (k = 0; k < nodes[j].numpaths; k++) { free(nodes[j].paths[k]); } free(nodes[j].paths); } free(nodes); } free(nodehash); } static nlink_t add_path( bignode_t *node, const char *path) { node->paths = realloc(node->paths, sizeof(char *) * (node->numpaths + 1)); if (node->paths == NULL) { err_nomem(); exit(1); } node->paths[node->numpaths] = strdup(path); if (node->paths[node->numpaths] == NULL) { err_nomem(); exit(1); } node->numpaths++; if (node->numpaths > highest_numpaths) highest_numpaths = node->numpaths; return node->numpaths; } static bignode_t * add_node( nodelist_t *list, xfs_ino_t ino, int ftw_flags, const char *path) { bignode_t *node; if (list->lastnode >= list->listlen) { list->listlen += 500; list->nodes = realloc(list->nodes, sizeof(bignode_t) * list->listlen); if (list->nodes == NULL) { err_nomem(); return NULL; } } node = list->nodes + list->lastnode; node->ino = ino; node->ftw_flags = ftw_flags; node->paths = NULL; node->numpaths = 0; add_path(node, path); list->lastnode++; return node; } static bignode_t * find_node( xfs_ino_t ino) { int i; nodelist_t *nodelist; bignode_t *nodes; nodelist = NH_HASH(ino); nodes = nodelist->nodes; for(i = 0; i < nodelist->lastnode; i++) { if (nodes[i].ino == ino) { return &nodes[i]; } } return NULL; } static bignode_t * add_node_path( xfs_ino_t ino, int ftw_flags, const char *path) { nodelist_t *nodelist; bignode_t *node; log_message(LOG_NITTY, "add_node_path: ino %llu, path %s", ino, path); node = find_node(ino); if (node == NULL) { nodelist = NH_HASH(ino); return add_node(nodelist, ino, ftw_flags, path); } add_path(node, path); return node; } static void dump_node( char *msg, bignode_t *node) { int k; if (log_level < LOG_DEBUG) return; log_message(LOG_DEBUG, "%s: %llu %llu %s", msg, node->ino, node->numpaths, node->paths[0]); for (k = 1; k < node->numpaths; k++) log_message(LOG_DEBUG, "\t%s", node->paths[k]); } static void dump_nodehash(void) { int i, j; if (log_level < LOG_NITTY) return; for (i = 0; i < NH_BUCKETS; i++) { bignode_t *nodes = nodehash[i].nodes; for (j = 0; j < nodehash[i].lastnode; j++, nodes++) dump_node("nodehash", nodes); } } static int for_all_nodes( int (*fn)(bignode_t *node), int ftw_flags, int quit_on_error) { int i; int j; int rval = 0; for (i = 0; i < NH_BUCKETS; i++) { bignode_t *nodes = nodehash[i].nodes; for (j = 0; j < nodehash[i].lastnode; j++, nodes++) { if (nodes->ftw_flags == ftw_flags) { rval = fn(nodes); if (rval && quit_on_error) goto quit; } } } quit: return rval; } /* * Adds appropriate files to the inode hash table */ static int nftw_addnodes( const char *path, const struct stat64 *st, int flags, struct FTW *sntfw) { if (flags == FTW_F || flags == FTW_D) if (!in_ag_to_free(path) && !force_all) return 0; printf("%s\n", path); if (flags == FTW_F) numfilenodes++; else if (flags == FTW_D) numdirnodes++; else if (flags == FTW_SL) numslinknodes++; else return 0; add_node_path(st->st_ino, flags, path); return 0; } static int process_dir( bignode_t *node) { int sfd = -1; int tfd = -1; int rval = 0; struct stat64 st; char *srcname = NULL; char *pname = NULL; xfs_swapino_t si; xfs_swapext_t sx; xfs_bstat_t bstatbuf; struct fsxattr fsx; char target[PATH_MAX] = ""; SET_PHASE(DIR_PHASE); dump_node("directory", node); cur_node = node; srcname = node->paths[0]; bzero(&st, sizeof(st)); bzero(&bstatbuf, sizeof(bstatbuf)); bzero(&si, sizeof(si)); bzero(&sx, sizeof(sx)); if (stat64(srcname, &st) < 0) { if (errno != ENOENT) { err_stat(srcname); global_rval |= 2; } goto quit; } if (!in_ag_to_free(srcname) && !force_all) { /* * This directory has already changed ino's, probably due * to being moved during processing of a parent directory. */ log_message(LOG_DEBUG, "process_dir: skipping %s", srcname); goto quit; } rval = 1; sfd = open(srcname, O_RDONLY); if (sfd == -1) { err_open(srcname); goto quit; } if (!platform_test_xfs_fd(sfd)) { err_not_xfs(srcname); goto quit; } if (xfs_getxattr(sfd, &fsx) < 0) { err_message(_("failed to get inode attrs: %s"), srcname); goto quit; } if (fsx.fsx_xflags & (XFS_XFLAG_IMMUTABLE | XFS_XFLAG_APPEND)) { err_message(_("%s: immutable/append, ignoring"), srcname); global_rval |= 2; goto quit; } if (realuid != 0 && realuid != st.st_uid) { errno = EACCES; err_open(srcname); goto quit; } /* mkdir parent/target */ pname = strdup(srcname); if (pname == NULL) { err_nomem(); goto quit; } dirname(pname); sprintf(target, "%s/%sXXXXXX", pname, cmd_prefix); if (mkdtemp(target) == NULL) { err_message(_("Unable to create directory copy: %s, %s"), srcname, strerror(errno)); goto quit; } tfd = open(target, O_RDONLY); if (tfd == -1) { err_open(target); goto quit; } cur_target = strdup(target); if (!cur_target) { err_nomem(); goto quit; } SET_PHASE(DIR_PHASE_1); /* swapino src target */ si.si_version = XFS_SI_VERSION; si.si_fdtarget = tfd; si.si_fdtmp = sfd; /* swap the inodes */ rval = xfs_swapino(tfd, &si); if (rval < 0) { err_swapino(rval, srcname); goto quit_unlink; } if (xfs_bulkstat_single(sfd, &st.st_ino, &bstatbuf) < 0) { err_message(_("unable to bulkstat source file: %s"), srcname); unlink(target); goto quit; } if (bstatbuf.bs_ino != st.st_ino) { err_message(_("bulkstat of source file returned wrong inode: %s"), srcname); unlink(target); goto quit; } ftruncate64(tfd, bstatbuf.bs_size); /* swapextents src target */ sx.sx_stat = bstatbuf; /* struct copy */ sx.sx_version = XFS_SX_VERSION; sx.sx_fdtarget = sfd; sx.sx_fdtmp = tfd; sx.sx_offset = 0; sx.sx_length = bstatbuf.bs_size; /* Swap the extents */ rval = xfs_swapext(sfd, &sx); if (rval < 0) { err_swapext(rval, srcname, bstatbuf.bs_size); goto quit_unlink; } SET_PHASE(DIR_PHASE_2); /* rmdir src */ rval = rmdir(srcname); if (rval != 0) { err_message(_("unable to remove directory: %s, %s"), srcname, strerror(errno)); goto quit; } SET_PHASE(DIR_PHASE_3); /* rename cur_target src */ rval = rename(target, srcname); if (rval != 0) { /* * we can't abort since the src dir is now gone. * let the admin clean this one up */ err_message(_("unable to rename directory: %s to %s, %s"), cur_target, srcname, strerror(errno)); } goto quit; quit_unlink: rval = rmdir(target); if (rval != 0) err_message(_("unable to remove directory: %s, %s"), target, strerror(errno)); quit: SET_PHASE(DIR_PHASE); if (sfd >= 0) close(sfd); if (tfd >= 0) close(tfd); free(pname); free(cur_target); cur_target = NULL; cur_node = NULL; numdirsdone++; return rval; } static int process_file( bignode_t *node) { int sfd = -1; int tfd = -1; int i = 0; int rval = 0; struct stat64 st; char *srcname = NULL; char *pname = NULL; xfs_swapino_t si; xfs_swapext_t sx; xfs_bstat_t bstatbuf; struct fsxattr fsx; char target[PATH_MAX] = ""; SET_PHASE(FILE_PHASE); dump_node("file", node); cur_node = node; srcname = node->paths[0]; bzero(&st, sizeof(st)); bzero(&bstatbuf, sizeof(bstatbuf)); bzero(&si, sizeof(si)); bzero(&sx, sizeof(sx)); if (stat64(srcname, &st) < 0) { if (errno != ENOENT) { err_stat(srcname); global_rval |= 2; } goto quit; } if (!in_ag_to_free(srcname) && !force_all) /* this file has changed, and no longer needs processing */ goto quit; rval = 1; /* open and sync source */ sfd = open(srcname, O_RDWR | O_DIRECT); if (sfd < 0) { err_open(srcname); goto quit; } if (!platform_test_xfs_fd(sfd)) { err_not_xfs(srcname); goto quit; } if (fsync(sfd) < 0) { err_message(_("sync failed: %s: %s"), srcname, strerror(errno)); goto quit; } /* * Check if a mandatory lock is set on the file to try and * avoid blocking indefinitely on the reads later. Note that * someone could still set a mandatory lock after this check * but before all reads have completed to block xfs_reno reads. * This change just closes the window a bit. */ if ((st.st_mode & S_ISGID) && !(st.st_mode & S_IXGRP)) { struct flock fl; fl.l_type = F_RDLCK; fl.l_whence = SEEK_SET; fl.l_start = (off_t)0; fl.l_len = 0; if (fcntl(sfd, F_GETLK, &fl) < 0 ) { if (log_level >= LOG_DEBUG) err_message("locking check failed: %s", srcname); global_rval |= 2; goto quit; } if (fl.l_type != F_UNLCK) { if (log_level >= LOG_DEBUG) err_message("mandatory lock: %s: ignoring", srcname); global_rval |= 2; goto quit; } } if (xfs_getxattr(sfd, &fsx) < 0) { err_message(_("failed to get inode attrs: %s"), srcname); goto quit; } if (fsx.fsx_xflags & (XFS_XFLAG_IMMUTABLE | XFS_XFLAG_APPEND)) { err_message(_("%s: immutable/append, ignoring"), srcname); global_rval |= 2; goto quit; } if (realuid != 0 && realuid != st.st_uid) { errno = EACCES; err_open(srcname); goto quit; } /* creat target */ pname = strdup(srcname); if (pname == NULL) { err_nomem(); goto quit; } dirname(pname); sprintf(target, "%s/%sXXXXXX", pname, cmd_prefix); tfd = mkstemp(target); if (tfd == -1) { err_message("unable to create file copy: %s", strerror(errno)); goto quit; } cur_target = strdup(target); if (cur_target == NULL) { err_nomem(); goto quit; } SET_PHASE(FILE_PHASE_1); /* swapino src target */ si.si_version = XFS_SI_VERSION; si.si_fdtarget = sfd; si.si_fdtmp = tfd; /* swap the inodes */ rval = xfs_swapino(sfd, &si); if (rval < 0) { err_swapino(rval, srcname); goto quit_unlink; } if (xfs_bulkstat_single(sfd, &st.st_ino, &bstatbuf) < 0) { err_message(_("unable to bulkstat source file: %s"), srcname); unlink(target); goto quit; } if (bstatbuf.bs_ino != st.st_ino) { err_message(_("bulkstat of source file returned wrong inode: %s"), srcname); unlink(target); goto quit; } ftruncate64(tfd, bstatbuf.bs_size); /* swapextents src target */ sx.sx_stat = bstatbuf; /* struct copy */ sx.sx_version = XFS_SX_VERSION; sx.sx_fdtarget = sfd; sx.sx_fdtmp = tfd; sx.sx_offset = 0; sx.sx_length = bstatbuf.bs_size; /* Swap the extents */ rval = xfs_swapext(sfd, &sx); if (rval < 0) { err_swapext(rval, srcname, bstatbuf.bs_size); goto quit_unlink; } SET_PHASE(FILE_PHASE_2); /* unlink src */ rval = unlink(srcname); if (rval != 0) { err_message(_("unable to remove file: %s, %s"), srcname, strerror(errno)); goto quit; } SET_PHASE(FILE_PHASE_3); /* rename target src */ rval = rename(target, srcname); if (rval != 0) { /* * we can't abort since the src file is now gone. * let the admin clean this one up */ err_message(_("unable to rename file: %s to %s, %s"), target, srcname, strerror(errno)); goto quit; } SET_PHASE(FILE_PHASE_4); /* for each hardlink, unlink and creat pointing to target */ for (i = 1; i < node->numpaths; i++) { /* unlink src */ rval = unlink(node->paths[i]); if (rval != 0) { err_message(_("unable to remove file: %s, %s"), node->paths[i], strerror(errno)); goto quit; } rval = link(srcname, node->paths[i]); if (rval != 0) { err_message("unable to link to file: %s, %s", srcname, strerror(errno)); goto quit; } numfilesdone++; } quit_unlink: rval = unlink(target); if (rval != 0) err_message(_("unable to remove file: %s, %s"), target, strerror(errno)); quit: SET_PHASE(FILE_PHASE); if (sfd >= 0) close(sfd); if (tfd >= 0) close(tfd); free(pname); free(cur_target); cur_target = NULL; cur_node = NULL; numfilesdone++; return rval; } static int process_slink( bignode_t *node) { int i = 0; int sfd = -1; int tfd = -1; int rval = 0; struct stat64 st; char *srcname = NULL; char *pname = NULL; char target[PATH_MAX] = ""; char linkbuf[PATH_MAX]; xfs_swapino_t si; SET_PHASE(SLINK_PHASE); dump_node("symlink", node); cur_node = node; srcname = node->paths[0]; bzero(&st, sizeof(st)); bzero(&si, sizeof(si)); if (lstat64(srcname, &st) < 0) { if (errno != ENOENT) { err_stat(srcname); global_rval |= 2; } goto quit; } rval = 1; /* open source */ sfd = open(srcname, O_RDWR | O_DIRECT); if (sfd < 0) { err_open(srcname); goto quit; } i = readlink(srcname, linkbuf, sizeof(linkbuf) - 1); if (i < 0) { err_message(_("unable to read symlink: %s, %s"), srcname, strerror(errno)); goto quit; } linkbuf[i] = '\0'; if (realuid != 0 && realuid != st.st_uid) { errno = EACCES; err_open(srcname); goto quit; } /* create target */ pname = strdup(srcname); if (pname == NULL) { err_nomem(); goto quit; } dirname(pname); sprintf(target, "%s/%sXXXXXX", pname, cmd_prefix); tfd = mkstemp(target); if (tfd == -1) { err_message(_("unable to create temp symlink name: %s"), strerror(errno)); goto quit; } cur_target = strdup(target); if (cur_target == NULL) { err_nomem(); goto quit; } if (symlink(linkbuf, target) != 0) { err_message(_("unable to create symlink: %s, %s"), target, strerror(errno)); goto quit; } SET_PHASE(SLINK_PHASE_1); /* swapino src target */ si.si_version = XFS_SI_VERSION; si.si_fdtarget = sfd; si.si_fdtmp = tfd; /* swap the inodes */ rval = xfs_swapino(sfd, &si); if (rval < 0) { err_swapino(rval, srcname); goto quit; } SET_PHASE(SLINK_PHASE_2); /* unlink src */ rval = unlink(srcname); if (rval != 0) { err_message(_("unable to remove symlink: %s, %s"), srcname, strerror(errno)); goto quit; } SET_PHASE(SLINK_PHASE_3); /* rename target src */ rval = rename(target, srcname); if (rval != 0) { /* * we can't abort since the src file is now gone. * let the admin clean this one up */ err_message(_("unable to rename symlink: %s to %s, %s"), target, srcname, strerror(errno)); goto quit; } SET_PHASE(SLINK_PHASE_4); /* for each hardlink, unlink and creat pointing to target */ for (i = 1; i < node->numpaths; i++) { /* unlink src */ rval = unlink(node->paths[i]); if (rval != 0) { err_message(_("unable to remove symlink: %s, %s"), node->paths[i], strerror(errno)); goto quit; } rval = link(srcname, node->paths[i]); if (rval != 0) { err_message("unable to link to symlink: %s, %s", srcname, strerror(errno)); goto quit; } numslinksdone++; } quit: cur_node = NULL; SET_PHASE(SLINK_PHASE); free(pname); free(cur_target); cur_target = NULL; numslinksdone++; return rval; } static int open_recoverfile(void) { recover_fd = open(recover_file, O_RDWR | O_SYNC | O_CREAT | O_EXCL, 0600); if (recover_fd < 0) { if (errno == EEXIST) err_message(_("Recovery file already exists, either " "run '%s -r %s' or remove the file."), progname, recover_file); else err_open(recover_file); return 1; } if (!platform_test_xfs_fd(recover_fd)) { err_not_xfs(recover_file); close(recover_fd); return 1; } return 0; } static void update_recoverfile(void) { static const char null_file[] = "0\n0\n0\n\ntarget: \ntemp: \nend\n"; static size_t buf_size = 0; static char *buf = NULL; int i, len; if (recover_fd <= 0) return; if (cur_node == NULL || cur_phase == 0) { /* inbetween processing or still scanning */ lseek(recover_fd, 0, SEEK_SET); write(recover_fd, null_file, sizeof(null_file)); return; } ASSERT(highest_numpaths > 0); if (buf == NULL) { buf_size = (highest_numpaths + 3) * PATH_MAX; buf = malloc(buf_size); if (buf == NULL) { err_nomem(); exit(1); } } len = sprintf(buf, "%d\n%llu\n%d\n", cur_phase, (long long)cur_node->ino, cur_node->ftw_flags); for (i = 0; i < cur_node->numpaths; i++) len += sprintf(buf + len, "%s\n", cur_node->paths[i]); /* len += sprintf(buf + len, "target: %s\ntemp: %s\nend\n", */ /* cur_target, cur_temp); */ ASSERT(len < buf_size); lseek(recover_fd, 0, SEEK_SET); ftruncate(recover_fd, 0); write(recover_fd, buf, len); } static void cleanup(void) { log_message(LOG_NORMAL, _("Interrupted -- cleaning up...")); free_nodehash(); log_message(LOG_NORMAL, _("Done.")); } static void sighandler(int sig) { static char cycle[4] = "-\\|/"; static uint64_t cur_cycle = 0; double percent; char *typename; uint64_t nodes, done; alarm(0); if (sig != SIGALRM) { cleanup(); exit(1); } if (cur_phase == SCAN_PHASE) { if (log_level >= LOG_INFO) fprintf(stderr, _("\r%llu files, %llu dirs and %llu " "symlinks to renumber found... %c"), (long long)numfilenodes, (long long)numdirnodes, (long long)numslinknodes, cycle[cur_cycle % 4]); else fprintf(stderr, "\r%c", cycle[cur_cycle % 4]); cur_cycle++; } else { if (cur_phase >= DIR_PHASE && cur_phase <= DIR_PHASE_MAX) { nodes = numdirnodes; done = numdirsdone; typename = _("dirs"); } else if (cur_phase >= FILE_PHASE && cur_phase <= FILE_PHASE_MAX) { nodes = numfilenodes; done = numfilesdone; typename = _("files"); } else { nodes = numslinknodes; done = numslinksdone; typename = _("symlinks"); } percent = 100.0 * (double)done / (double)nodes; if (percent > 100.0) percent = 100.0; if (log_level >= LOG_INFO) fprintf(stderr, _("\r%.1f%%, %llu of %llu %s, " "%u seconds elapsed"), percent, (long long)done, (long long)nodes, typename, (int)(time(0) - starttime)); else fprintf(stderr, "\r%.1f%%", percent); } poll_output = 1; signal(SIGALRM, sighandler); if (poll_interval) alarm(poll_interval); } static int read_recover_file( char *recover_file, bignode_t **node, char **target, char **temp, int *phase) { FILE *file; int rval = 1; ino_t ino; int ftw_flags; char buf[PATH_MAX + 10]; /* path + "target: " */ struct stat64 st; int first_path; /* A recovery file should look like: target: temp: end */ file = fopen(recover_file, "r"); if (file == NULL) { err_open(recover_file); return 1; } /* read phase */ *phase = 0; if (fgets(buf, PATH_MAX + 10, file) == NULL) { err_message("Recovery failed: unable to read phase"); goto quit; } buf[strlen(buf) - 1] = '\0'; *phase = atoi(buf); if (*phase == SCAN_PHASE) { fclose(file); return 0; } if ((*phase < DIR_PHASE || *phase > DIR_PHASE_MAX) && (*phase < FILE_PHASE || *phase > FILE_PHASE_MAX)) { err_message("Recovery failed: failed to read valid recovery phase"); goto quit; } /* read inode number */ if (fgets(buf, PATH_MAX + 10, file) == NULL) { err_message("Recovery failed: unable to read inode number"); goto quit; } buf[strlen(buf) - 1] = '\0'; ino = strtoull(buf, NULL, 10); if (ino == 0) { err_message("Recovery failed: unable to read inode number"); goto quit; } /* read ftw_flags */ if (fgets(buf, PATH_MAX + 10, file) == NULL) { err_message("Recovery failed: unable to read flags"); goto quit; } buf[strlen(buf) - 1] = '\0'; if (buf[1] != '\0' || (buf[0] != '0' && buf[0] != '1')) { err_message("Recovery failed: unable to read flags: '%s'", buf); goto quit; } ftw_flags = atoi(buf); /* read paths and target path */ *node = NULL; *target = NULL; first_path = 1; while (fgets(buf, PATH_MAX + 10, file) != NULL) { buf[strlen(buf) - 1] = '\0'; log_message(LOG_DEBUG, "path: '%s'", buf); if (buf[0] == '/') { if (stat64(buf, &st) < 0) { err_message(_("Recovery failed: cannot " "stat '%s'"), buf); goto quit; } if (st.st_ino != ino) { err_message(_("Recovery failed: inode " "number for '%s' does not " "match recorded number"), buf); goto quit; } if (first_path) { first_path = 0; *node = add_node_path(ino, ftw_flags, buf); } else { add_path(*node, buf); } } else if (strncmp(buf, "target: ", 8) == 0) { *target = strdup(buf + 8); if (*target == NULL) { err_nomem(); goto quit; } if (stat64(*target, &st) < 0) { err_message(_("Recovery failed: cannot " "stat '%s'"), *target); goto quit; } } else if (strncmp(buf, "temp: ", 6) == 0) { *temp = strdup(buf + 6); if (*temp == NULL) { err_nomem(); goto quit; } } else if (strcmp(buf, "end") == 0) { rval = 0; goto quit; } else { err_message(_("Recovery failed: unrecognised " "string: '%s'"), buf); goto quit; } } err_message(_("Recovery failed: end of recovery file not found")); quit: if (*node == NULL) { err_message(_("Recovery failed: no valid inode or paths " "specified")); rval = 1; } if (*target == NULL) { err_message(_("Recovery failed: no inode target specified")); rval = 1; } fclose(file); return rval; } int recover( bignode_t *node, char *target, char *tname, int phase) { char *srcname = NULL; int rval = 0; int i; int dir; dump_node("recover", node); log_message(LOG_DEBUG, "target: %s, phase: %x", target, phase); if (node) srcname = node->paths[0]; dir = (phase < DIR_PHASE || phase > DIR_PHASE_MAX); switch (phase) { case DIR_PHASE_1: case FILE_PHASE_1: case SLINK_PHASE_1: log_message(LOG_NORMAL, _("Unlinking temporary %s: \'%s\'"), dir ? "directory" : "file", target); rval = dir ? rmdir(target) : unlink(target); if ( rval < 0 && errno != ENOENT) err_message(_("unable to remove %s: %s, %s"), dir ? "directory" : "file", target, strerror(errno)); break; case DIR_PHASE_2: case FILE_PHASE_2: case SLINK_PHASE_2: log_message(LOG_NORMAL, _("Unlinking old %s: \'%s\'"), dir ? "directory" : "file", srcname); rval = dir ? rmdir(target) : unlink(srcname); if (rval < 0 && errno != ENOENT) { err_message(_("unable to remove %s: %s, %s"), dir ? "directory" : "file", srcname, strerror(errno)); break; } /* FALL THRU */ case DIR_PHASE_3: case FILE_PHASE_3: case SLINK_PHASE_3: log_message(LOG_NORMAL, _("Renaming: " "\'%s\' -> \'%s\'"), target, srcname); rval = rename(target, srcname); if (rval != 0) { /* we can't abort since the src file is now gone. * let the admin clean this one up */ err_message(_("unable to rename: %s to %s, %s"), target, srcname, strerror(errno)); break; } if (dir) break; /* FALL THRU */ case FILE_PHASE_4: case SLINK_PHASE_4: /* for each hardlink, unlink and creat pointing to target */ for (i = 1; i < node->numpaths; i++) { if (i == 1) log_message(LOG_NORMAL, _("Resetting hardlinks " "to new file")); rval = unlink(node->paths[i]); if (rval != 0) { err_message(_("unable to remove file: %s, %s"), node->paths[i], strerror(errno)); break; } rval = link(srcname, node->paths[i]); if (rval != 0) { err_message(_("unable to link to file: %s, %s"), srcname, strerror(errno)); break; } } break; } if (rval == 0) { log_message(LOG_NORMAL, _("Removing recover file: \'%s\'"), recover_file); unlink(recover_file); log_message(LOG_NORMAL, _("Recovery done.")); } else { log_message(LOG_NORMAL, _("Leaving recover file: \'%s\'"), recover_file); log_message(LOG_NORMAL, _("Recovery failed.")); } return rval; } int main( int argc, char *argv[]) { int c = 0; int rval = 0; int q_opt = 0; int v_opt = 0; int p_opt = 0; int n_opt = 0; char pathname[PATH_MAX]; struct stat64 st; progname = basename(argv[0]); setlocale(LC_ALL, ""); bindtextdomain(PACKAGE, LOCALEDIR); textdomain(PACKAGE); while ((c = getopt(argc, argv, "fnpqvP:r:")) != -1) { switch (c) { case 'f': force_all = 1; break; case 'n': n_opt++; break; case 'p': p_opt++; break; case 'q': if (v_opt) err_message(_("'q' option incompatible " "with 'v' option")); q_opt++; log_level=0; break; case 'v': if (q_opt) err_message(_("'v' option incompatible " "with 'q' option")); v_opt++; log_level++; break; case 'P': poll_interval = atoi(optarg); break; case 'r': recover_file = optarg; break; default: err_message(_("%s: illegal option -- %c\n"), c); usage(); /* NOTREACHED */ break; } } if (optind != argc - 1 && recover_file == NULL) { usage(); exit(1); } realuid = getuid(); starttime = time(0); init_nodehash(); signal(SIGALRM, sighandler); signal(SIGABRT, sighandler); signal(SIGHUP, sighandler); signal(SIGINT, sighandler); signal(SIGQUIT, sighandler); signal(SIGTERM, sighandler); if (p_opt && poll_interval == 0) { poll_interval = 1; } if (poll_interval) alarm(poll_interval); if (recover_file) { bignode_t *node = NULL; char *target = NULL; char *tname = NULL; int phase = 0; if (n_opt) goto quit; /* read node info from recovery file */ if (read_recover_file(recover_file, &node, &target, &tname, &phase) != 0) exit(1); rval = recover(node, target, tname, phase); free(target); free(tname); return rval; } recover_file = malloc(PATH_MAX); if (recover_file == NULL) { err_nomem(); exit(1); } recover_file[0] = '\0'; strcpy(pathname, argv[optind]); if (pathname[0] != '/') { err_message(_("pathname must begin with a slash ('/')")); exit(1); } if (stat64(pathname, &st) < 0) { err_stat(pathname); exit(1); } if (S_ISREG(st.st_mode)) { /* single file specified */ if (st.st_nlink > 1) { err_message(_("cannot process single file with a " "link count greater than 1")); exit(1); } strcpy(recover_file, pathname); dirname(recover_file); strcpy(recover_file + strlen(recover_file), "/xfs_reno.recover"); if (!n_opt) { if (open_recoverfile() != 0) exit(1); } add_node_path(st.st_ino, FTW_F, pathname); } else if (S_ISDIR(st.st_mode)) { /* directory tree specified */ strcpy(recover_file, pathname); strcpy(recover_file + strlen(recover_file), "/xfs_reno.recover"); if (!n_opt) { if (open_recoverfile() != 0) exit(1); } /* directory scan */ log_message(LOG_INFO, _("\rScanning directory tree...")); SET_PHASE(SCAN_PHASE); if (xfs_get_agflags(pathname) != 0) { err_message(_("Could not get non-allocatable AGs info\n")); exit(1); } nftw64(pathname, nftw_addnodes, 100, FTW_PHYS | FTW_MOUNT); } else { err_message(_("pathname must be either a regular file " "or directory")); exit(1); } dump_nodehash(); if (n_opt) { /* n flag set, don't do anything */ if (numdirnodes) log_message(LOG_NORMAL, "\rWould process %d %s", numdirnodes, numdirnodes == 1 ? "directory" : "directories"); else log_message(LOG_NORMAL, "\rNo directories to process"); if (numfilenodes) /* process files */ log_message(LOG_NORMAL, "\rWould process %d %s", numfilenodes, numfilenodes == 1 ? "file" : "files"); else log_message(LOG_NORMAL, "\rNo files to process"); if (numslinknodes) /* process files */ log_message(LOG_NORMAL, "\rWould process %d %s", numslinknodes, numslinknodes == 1 ? "symlinx" : "symlinks"); else log_message(LOG_NORMAL, "\rNo symlinks to process"); } else { /* process directories */ if (numdirnodes) { log_message(LOG_INFO, _("\rProcessing %d %s..."), numdirnodes, numdirnodes == 1 ? _("directory") : _("directories")); cur_phase = DIR_PHASE; rval = for_all_nodes(process_dir, FTW_D, 1); if (rval != 0) goto quit; } else log_message(LOG_INFO, _("\rNo directories to process...")); if (numfilenodes) { /* process files */ log_message(LOG_INFO, _("\rProcessing %d %s..."), numfilenodes, numfilenodes == 1 ? _("file") : _("files")); cur_phase = FILE_PHASE; for_all_nodes(process_file, FTW_F, 0); } else log_message(LOG_INFO, _("\rNo files to process...")); if (numslinknodes) { /* process symlinks */ log_message(LOG_INFO, _("\rProcessing %d %s..."), numslinknodes, numslinknodes == 1 ? _("symlink") : _("symlinks")); cur_phase = SLINK_PHASE; for_all_nodes(process_slink, FTW_SL, 0); } else log_message(LOG_INFO, _("\rNo symlinks to process...")); } quit: free_nodehash(); close(recover_fd); if (rval == 0) unlink(recover_file); log_message(LOG_DEBUG, "\r%u seconds elapsed", time(0) - starttime); log_message(LOG_INFO, _("\rDone. ")); return rval | global_rval; } --=-4Da9GvHld0Grtgo95r+H-- From owner-xfs@oss.sgi.com Thu Mar 6 13:42:32 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 06 Mar 2008 13:42:51 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_50, T_STOX_BOUND_090909_B,UPPERCASE_50_75 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m26LgSMT019589 for ; Thu, 6 Mar 2008 13:42:32 -0800 X-ASG-Debug-ID: 1204839777-145902c90000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from steelboxtech.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 012CDF30187 for ; Thu, 6 Mar 2008 13:42:57 -0800 (PST) Received: from steelboxtech.com (steelb0x.securesites.net [161.58.192.27]) by cuda.sgi.com with ESMTP id 8AX3LWD3AHIBDPlu for ; Thu, 06 Mar 2008 13:42:57 -0800 (PST) Received: from [192.168.1.152] (cromo.steelbox.com [199.72.224.67]) (authenticated bits=0) by steelboxtech.com (8.13.6.20060614/8.13.6) with ESMTP id m26LSwMv000950; Thu, 6 Mar 2008 21:28:58 GMT Message-ID: <47D062AF.80501@steelbox.com> Date: Thu, 06 Mar 2008 16:31:27 -0500 From: Kris Kersey User-Agent: Thunderbird 2.0.0.6 (X11/20071004) MIME-Version: 1.0 To: xfs@oss.sgi.com CC: Bill Vaughan X-ASG-Orig-Subj: pdflush hang on xlog_grant_log_space() Subject: pdflush hang on xlog_grant_log_space() X-Enigmail-Version: 0.95.3 Content-Type: multipart/mixed; boundary="------------090008060702010503060703" X-Barracuda-Connect: steelb0x.securesites.net[161.58.192.27] X-Barracuda-Start-Time: 1204839779 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1001.00 X-Barracuda-Spam-Status: No, SCORE=-1001.00 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14790 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: kkersey@steelbox.com Precedence: bulk X-list: xfs This is a multi-part message in MIME format. --------------090008060702010503060703 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello, I'm working on a NAS product and we're currently having lock-ups that seem to be hanging in XFS code. We're running a NAS that has 1024 NFSD threads accessing three RAID mounts. All three mounts are running XFS file systems. Lately we've had random lockups on these boxes and I am now running a kernel with KDB built-in. The lock-up takes the form of all NFSD threads in D state with one out of three pdflush threads in D state. The assumption can be made that all NFSD threads are waiting on the one pdflush thread to complete. So two times now when an NAS has gotten in this state I have accessed KDB and ran a stack trace on the pdflush thread. Both times the thread was stuck on xlog_grant_log_space+0xdb. So now I'm turning to you to help me figure out why XFS is locking up. The box has been left in this state so I can run and KDB commands you wish or if you have any questions about the setup, let me know. The system is running a mostly stock 2.6.23.12 kernel. My config file as well as photos taken of the stack dump are attached. Thanks, Kris --------------090008060702010503060703 Content-Type: image/jpeg; name="stacktrace-01.jpg" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="stacktrace-01.jpg" /9j/4AAQSkZJRgABAQEASABIAAD/4STnRXhpZgAATU0AKgAAAAgABQEaAAUAAAABAAAASgEb AAUAAAABAAAAUgEoAAMAAAABAAIAAAITAAMAAAABAAEAAIdpAAQAAAABAAAAWgAAAKgAAABI AAAAAQAAAEgAAAABAAaQAAAHAAAABDAyMTCRAQAHAAAABAECAwCgAAAHAAAABAAAAACgAQAD AAAAAQABAACgAgAEAAAAAQAAAoCgAwAEAAAAAQAAAeAAAAAAAAYBAwADAAAAAQAGAAABGgAF AAAAAQAAAPYBGwAFAAAAAQAAAP4BKAADAAAAAQACAAACAQAEAAAAAQAAAQYCAgAEAAAAAQAA I9kAAAAAAAAASAAAAAEAAABIAAAAAf/Y/+AAEEpGSUYAAQEAAAEAAQAA/9sAQwAIBgYHBgUI BwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04Mjwu MzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAkwDEAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAA AAAAAAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQci cRQygZGhCCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldY WVpjZGVmZ2hpanN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrC w8TFxsfIycrS09TV1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEA AAAAAAABAgMEBQYHCAkKC//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXET IjKBCBRCkaGxwQkjM1LwFWJy0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZX WFlaY2RlZmdoaWpzdHV2d3h5eoKDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5 usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A8Xcb XZfQ4pME1PfKFvpgvTecVY0wKzSq1o1wCmSF6jnrSQFHafSjafSuhhWFo8JpErAr1J7c/wCf wqLyoyoddNkzjCZIwAcgZH17n0pgYeD6UvPpWwgU3V1u0x2Uor+WMAoMdfx61bVMxoRo55wQ SF+bigDnOaUMa6G4icFHGkeWp4AOzDHB/wARWds8y8nAsSXLAgKeEGPy560AUA9KJa0CtpLM mywlTyzukjGSWU4A756n9aVDCk20aTIZB8yqSenGOMeoP50WAzxORTxckVbggaHeJNNnmVjk bkK7Tzxx1/TpU8FmJLsqmlzOsoLRq424+U457jv+FFgM77WaUXjD1q7LHthkmGkeWiFcmQnA 5z7HngVbQzFI7hNIVj8qhlbJOcMO3p/OjlAyRfP6mlGoOORmrlol1atLJ/Z37t9xw4wAMZxz 7CtBNOuzE6rpdtszjlu4yM/+PD/PQ5bgYn9oyHuaQ38mcc81qWt3cXpaS3sYCYMYHcA9APyp n2e9vbuG5EEYKbCrZO09Dj/x4UuUDN+3SZxzmg3U2M4bHrWhdzXMNwsUlpbLJMozhf72Rgn1 61JM99ZJKJIIGVm3YILbix7f57UWAymnmUZKMB6kVGbtz3Navk6hfadG0ccTJIcYH3uuMnPu Kq/2LN8gDoWfBwOwOB+mR+dOwFM3LUglL960RoMhkKCZOOpxwKy4xjikwLsK7o8+9FWLGHzI CcfxUUgMYmrNncXFtMGtpNjsMZ46fjxVU1b066jtLyOaa3WdFzmNuhyCKoDetJpp7aKVtaii Zs70baGB5x/n3qvLdTpqCxDUle3lI3S4TrgdfyFWrWa3a3FzBoIaLeV3GQEAnB5yOBx1PHNV 59Qs7Vmjk0aNdwJVTJkZzgnI919u/rTAiujNZu01vqSTSn5NyMvKAcfjxVjz5Psccw1hCTGW MRC7gwUkD8+KrNrVm2pLcjS4hCIyhhyMHnOelTL4gsEg8pNHiXAwG3Anr7rzQBQutWvfNaMX jSRo3ynA/wAP84qqt/cq8jrKQ0nL4AGa159dsJZFkGjxpIo2grJgYzzxj0yM+9Vf7VtTqRu2 06Mr8m2LdgArj274/WhgUhfXAfzBJh8AFsckDGB+gp76ldSSCRpSZAAA+PmwDkc/XmpY761S YSGzDAoqPH2OCCWz2Jx6dzzUn9pWRt/L/suMSFNplDnOcH5sY9xx7UAVX1G8kQo1xIVPbNL/ AGheGRZDcy71zht5yM//AKzViLUbOGMRnTYpsDG9zhj157+o/KpP7YtPPLjR7XbtwEOcA5PP 6j8qAKUt/dzRmOW5ldD1VnJFIl9dxqFjuZlUY4VyBxwK0rbxCsFvBEdOtmMJBV+Rg+v1qE60 RqX2xbWFTsRSgHHylTn6nbj6E0AU2vLp1CvcSsBwAXJxxSi9vcYF1OB6CQ1pP4jPmyyx2FtF LKGDPGME5Bz+pz9QKb/wkk4EoFvCPOOXwPvdf8afzAyxPOhJWWRS3BwxGcU77RcjA86YY/2j x0/+tU99qj6girLEg2bthGcjJB5PfpjmrN14inu0dXtrVRImxykeCw3Buuc9R+tIDNLTONxZ 2GQMkk89qdm4bccynB+Y88H3qzbazNbae9ksMDRO5f5lJIJGODmrK+JrpTlbe1B+bpGeSc5J 596QGWEm8wRBZN+eEwc/lSFZQgcq4UnG4jjPpVv+17gal9vCx+eCT93g5GOmfSnXmsXN/EI5 li2g5G1cYPr/AD/OgCmYZ+B5cmSu8DB5Xrn6VHH0rRfXb5rfydyBBGYsBRypGKzo6TA6fQbf zbBmxn94R+gorR8KRhtJYn/nqf5CiueVSzsBwzrhFcdG96mshE17CJ5DHFvXe4GSozyagyCo AzgUsaF2CjqTgV0gdVDFYW5lSPxC6xFy21BjPB/A84qvPY6TNK2/WC/BKsR06kDpzz9OtaFn ouq2IurM6bbSxSFcGR8gc44PXir63GtWUXlDTbN8DKnfkv64+mec4pgcsLPRzdWy/bJRC5cS k9UwPlxxyDVxNL8PCPD6tIz7uqptBGfcGrVtZX2lTjNrZSJfuIgkjFlBxnnjpya2Ut9YEEob S9LjjUbWRicMAAOg6jAoWoHM22m+H3RTPqUqN8oZQvspJ6dMlh+FURaaY9/5X211t0TJl2Ft 7egGBjiupgttXuJyF0vTpCU8tmdflPPCn6BMgeg9az0sdT0DXAIrW0mmlt3coG3IU3EnrgDp 09KdgMZrGw+1LtvD9mZGJcr8yN82Bjqeg5Hr2q42kaH5YKa6zPhiVa1Zeik8E8HkAduTWxNq eqWN0tiNN01SwkVPLT5XCGTcOvqW4NTmy8SIyT/2JYdWCEFPlGG44b5RySKLAcv9h0yGzgeb UT9qZiJYFiJEY553Dhug6etD2mjtcweVqDrAzHzyyHMS9sDgsfoK2b/R9Y12O21CX7II55f+ WLZ2Ftqc4zx8o6Zxz71j33hy8sNRt7Od4gZ3CJIGyvJAzn05+tDQBFBokkY829licAE4jLZO xM9uPm8z8Mfipt9CEJ/06cyBc/LEfmbCfKMjsd/P0qxN4P1CEQNuieOUKQyNk8nGMde/0pW8 JzrGrC6hYuQoC8fMyoVBzgjO8Dpwc5oSAinTw75MDW88/m+ViRJFON+w88f7WOBxiobsaINQ i+zNM1p5beZwQd/zbcZ7fcqxqHhW50/TRdvPC7ZAMSMCRlNxPB7YP5GkPhllsLa9e9hEM0Rk wuC6naWA2556Yz68emTysIWceGxch7d7kx5GY5AQuNpzgjnk478Z74pRP4bV4v8ARpnXkSBm b+8MEEH+7njHWrdr4MS5cqdXgh+bH71Nvf6/5wfSqOveHBosULx38N5vDFvKx8mCo55PUt+l HyGN1SXQZLVV06GeKYNks5JyMdOp74/I0PPoQtoTFbz/AGgRBZA/KFsct1znPPpVm68KLbxy uuq2ku1AUVGG529MZ47c+9VLLQ47vTPtf9oW8TiXYYXYBtvqOefp+tIC7BfeGkcmXTpnXcSM HHGTx970xVLVrnR7hY/7OtZLcqDu3c7jx7/WtJvCunpYmc69bbxHv8sYznGcfe/zisuz0iK4 trp5b6CCaFsCN2Hz+uDmkBPPfaGbeXybCUStEUUsRhW7HrWGlbd9othbaXJcJqsUk69IBjLf OF7H0JNYi9BQwOy0C4+z6UgP8TFv1x/SiqFrOsOn2qkZJQn/AMeaiuOS1ZdznkKmzdcfMHBH 5VGtSRoDFPnquCPzpi9a60QdDpvlJJJHqb6hl4Q0ZjDBl98HqP0rSZNDiRo5Rq6uIwzFlYFB wN2M46j6Vc0q81S4soXk17TYFVAqq4UsFCk85xzwKsSzai7FD4k0xtu51wEAIwcZ7Zz25x1p gYSyeHZjGC2oFw4IRfmzgYA69/b8KSxtIH1e4Etpqc1n8wCRRvvjYn5Qeeu319al1qe9T7FG +rWt0I2DFodpETBsDofm9a6FbjUDPJ/xV+meV8uGxHkjHcH/ABpgZcVnooBjOna7LJtw2Yzu /j5wD9Pb5frVWb/hHbR9txY6ksuflWZT8ygtknDA5Jx7DFbCCaK8/deLNNUb96uoQYHzZyOm fmOBnv1GKoa7dzRR2+ox+I4bm8gVzGiRx5UsVDD5SQeCTn/ZqhGHrawyXxt9JtL2BDktDIWy wCg9Mnp8x/GsdRcISyiVSRjIz0PH65x+Naf/AAk2q/aobo3Aa4gLNDIyAmMt97HY5981Pc+N PEF5EUn1F3PGH2hWXBB4IAPVV/IUrgZraTqKFg1lcAoAxGw8AnA/WoI7S4lj3xwuyZIyFzyC oP6sv5iteTxfr0wAkvy+F2DdEhwOMj7vfAz64rPtNWvrDH2a4MeG3DAHBJVu49Y0P/AaQyJL G6k+7bSn/gB9QP5kD8abLaTwyRpLCyPIoZARywPQj61oTeJtZuVRZr+SRUbcoYLwcg+nqoP1 qrc6peXkkclxPveMKFYqMgL90dO1GgEbafeJndaTgAEk+WcYHU59KdPpd7bQPNNbOkaSeUzk cB8sMfX5G/KrjeJtZeF4m1KYxvGYmXIwUPUVDNrWpT25glu3eEuZNhAI3Hdk/X52/OgCCPTb 2WFJYrSeSNwCGSMsOSVHT1KkfhU0eianLIsaWU28nG0rgjkjkHp91uvoaW21rU7OBYba+nhj UYCo23jLHt7sx/Gn/wBvaubhp/t8/mvks+7k5zn/ANCb8zRoBBZaVfajFPJZ20k6wAGTYMkZ zjjqeh/KtC18Ia7eQiaCwZ4yoYMHXGCu4d/TJrPttUv7QyG1upYS4UP5bbc4GB09Kni17WEQ RxahcqoAUKshAxjAGPpx+NGgEdvo9/d3dxawW7ST24YyIpGRtOD9efSp08N6s9pJdC0byY1Z nbcPlCjJzzx0qrHf38VyZYrmdJ3G0sjEMR+FSfb9UlQx/abl15yu5iORg8fQ4/GkBCunXUun TXyJm3hYK7Z6EkDp+IqqvSp7ia7VHjlklCytvdWJAY+pHeoVHFJgb6siWtsrKSREOnuSf60V SvpZkkhROiwRjj/dFFYcl9SiiPkmuE7EH+dQr1qSUrLdEhuCM598VGvWt0SdhockV5YDy/DS Xr2i7XdJdrNuzztxyfz6VuTWc8kYkXwbCpUYws67ip68Bffr1GDXPaCumpZwtLc6nBNJLtcW qttlH93jvj05rYlm00W6P9s187Rkl2kCuMDOT2A68UwH39tdX+nmztfC1tbmRgVuUcHaFK55 2jg5xnv70aXqIv57o2XhK0kljUeYvmDJxn7oK+x6VQnurE2ErWdzrMjFQlvJufa0mF4POOxw BU9jJ4c8xnA1ppVgAnSJmwu3qSQc47c8CncDQW1v2tnvV8O2ZgZ42JMqfKGMe0cJ/nJ9K5fU vENteXFl5miWyC0JEiK+BNwB82AMcjtWxeTaNFIs0y6xFbcNEjGQCUHbgEseBgN064FZeqye EZEsV02G/iIkAu3bksncrkkA+1FwKsmt2E11b3EmjQZgIPl5+SUBVUK2McfKTx61NJr+lm8t bmDQYLYwTeaY43JWTAUBCT/DwxPX71Mlj8Mz3VsIZby2gEqLO0nzExYG5hgH587uOnSppofB /wDZ8zQXGq/ayMQrKECg4HLYB+UHPTn2oENg8T2sLRP/AGDYtLG8bBznogUbfodvPfnr1ytp 4qgsriZ4tB0/y5YTC0bKcEEAH+XT3pIH8KRxxCePUJJEAaQpjbI3y5HJBC8P2z8w9KgC+Gvt Yctfm18pAUG3zDJkbiOwXGQBnOcU7AR32vC7Niy6fbRtaPuBxkuAchW/2R0A9K1U8dSosONK sg8dv9m8wAh2TGMFuvvx3qAP4LB5g1o/KP44+ufp6U3T73wslwxvtMvHja3CYilHyycZYZ69 +c9+negC0fH96biOUWVrhVCshBxJg5G7155qlr3iuXxD5Zu7C0V4wQrxqVbGDgE+gJz/ADzU 11d+D5dMMVvp+oxXSK4jkLqQzc7S/PT7pwBxyOetJp1/4Wi0oRX+l3Ut4GDeZGwCnHY89Py6 +2aG2BTsvEQs7KK2bSdNuPLAAknh3NwzN1z6v+OB71MviyVJ5JU02wUMGCoIyFjDGU/KM8Y8 5sfRa0J9Z8I+W32fQ5DJvZlLjgAhsAgPzjI9OlJf6v4Rn0uSC10SeK5wSk5I+9g9QG6Z5wPX uABSAwLDVjp9w8kdlbSKxB8udC6jAI6E++fqBVx/E0rNGyafYRFDk+VCV3fMrDPPPKD9aNLv NAtre7h1DT57oyMPJkVgrIB68/mPetC61nwtNDcJHojo0mTERgeWecdG5HT9eelAzIfXpm1i LU1trdJ49uFVSEwqKgGM8ABf1rRi8b6jDdSXEdtZK7s7ECIgZYKDxn/ZH61PFr/hgBPP8Pb3 UMCysBu+b5cr0zgDPvmsrTb7RrZ7sX2nvcxyhRGAwUx8HOD25Ix9KQEGua9da9cLPdxwiQAK DGpXAGeMZ9/5Vmr0rU1m+0m6ggj03T2tmU/OzNuLDaoH6hj+NZi9RSYGpcxR+d95jgAZA9qK uwC2nj3srMwJB5orPmsM5yIYlizjBpMYY+1NAYsKeOtaCOv8O3F0NFeKHXLKzHm48qfarYOM kHrWxcF2tXhfxXpzxvlZE2pynTAweuAOOB71i+GIrifSb1ItJtL5VdS3mvtf8Pbj1rpJbXUj btjw9pYwxbaZBkHJ+bkY4z39OnSmBlx79L0+aC38TacIHV5TBGFcs+CQo44BwBnjr9MyaNFB bTRahF4psrOaeA+cBGhZWJ3EFTx1/HirElrfTQXFodG0yLzlLecXyW6neODzx3A68D0m0GLU 5NN02WDTNIkXy2VJ5m+ZR6MPf2z9RQBS1i3h1i4WK68WWssSFCXfywMAP02nkjOOf71YWpaD p1oqGDWra5Mk6oCjAhEJblhnORgHjjnrXf2setpqj+XY6C0o2HLscHl8Y4Hqc9uRXOeJINTl 0kNPo+nW6TTqWlgb595aQdSep5z2wF6U+gGBdaDYR+V9m1mCf51SUgfdBzlx/sgAe/NTJ4Y0 9ryOL/hJbAQGHe9wUfaj5/1eMZJxznpWvFot3p1veaUdK08XUi7vMupFmlTKOwVGUbRnyiOe 5HIzVq3fVLq5vIH0DRriWKSWNjJjAOHYgMTjA3HHIycc9aEBzlpoOk3cag67DbyntKnB5IA4 PB6HrgVPN4W0mKynuB4qsXMedsaxNuc4Jxjr2H510OqnUbWHTruDRNBhJnXBgjUu0hL8FTyA PpxgHPo/WNK8R6rav5unaHbrDMJ3lhlUEsu9eTuOc7efXA9KdkIwR4f8LLHBK3iJ33xAyRpF tZX6nqMY4Ix1yRzjNU9K0fQbm7vIr/WHtoo2cQSqhYPg/KSMcg8nt0966W3h1H+zLqd7bw7M 1tO+9JQJJDtdiec56ngdSMfjU1CW80+0us/2Ownc2ZSNSGhEhmO5Rn5QASM+4HY5dkBXj8Pe DzGVfxHIH8riXyzt8znjbtzjoevqKhstF8IzWyG61u6gmEhV8R7lK7WIYYXjkDue/wBa29N8 PXel5khuNElhuYzMqTL5hRsHCBSeuO578fWW8tJ7WcOtxohKQLIsMNswWTaGGGG7g4c5z16d eCrIDkrPSdCl8QXNrc6nLFpyo5hnVCzZDYG4AemT2/CtKLw54TFtul8Rys/l53JbOAD8/OCp 44TjPZvw0JUv/D0lx4jt7nSbm5uzLFNbKC4IZmd2ILcY24x+HPU68Nzrs+n20kF7oKx3Njyh YqYwwJCbd2P4sZxx9BS0A5CTRfC8fmq2rXeRHlG8kjcw354x0O1SBn159MPW7WwtL5o9Omlm hBcBpFwcCRgvGB1UKfqTXosy6tYXRuU1TRpm8ojeVLM7ASDaQW4+Vz83HZRnoeY8V6fcXAXU JNSsrkgKqxwfKwVvNkJ25PAwRz647ct2GccRSV1lp4L+1W1tOdZsIkmiEhDv8yEgEAjPvye2 DUsPgeOa58r+3bBFyoLMcdS46Z6DZz/vVIHGN1FSL1FaWu6K2i3iRG6t7lJFLI8Lg8BivI7H jpWdGBvXPTPNJgX4ba5ZNyMignoWwaKr+dBzlHP40VnqMb5eMERk47VBtIOCMGtPB7CqU6kT HNWmI1dFgjuLK+Q2dzPKFUrJDz5YzySMjNblhYxJYRNd6FqM00Zy7KTtcHBHGck4YdKx/DU0 cVxciW/urQGIkPbqW5B7gdutdJFd2jW5Y+IdWbCA70ifC8DnGOnB79qoCJrezeVYIvDd55p+ UsQcf+hEZ5HU/wCFPt7K0uLBfI8MXUru5RZfMGCVIyOvy9GFEN7p8bKkuv6sisg2QqjjjjH1 zyen59zSp7JLcK+pa3CPtjqscIfDjJwOP4u579aAMIeEPEMkxhGnSs4GSNy8dO+feoLzwzrd hZy3d3YywwxEB2cgEE47Zz1IH1z6V2cktml5FsufEHKnOTKHPzJ/s+mPxx7Vmao5utAuXNzr cxTad0xkaLdlQVbIwMHcfqBTsBzv/CM69/0CL7pn/UN09elQXGmanBEpuLeZUU7AGB+U7iNv scqePaul1LUg0RWLWtXW5ZFw0zMiupAOCB0AU5GOuacE0t3t5Bqutmz3u12ZYA53nJQoOQTk sSWx6ihAYK+HddglZTZXMEqoWKuCj7drt0PPSNvyp58LeIyNn9k35Bbp5THLfN+vyt+VbS3m nTTTPcahrvmgnbPvLOyjzgNxPTIZPplh3Na8cmnGK6uIde8UyLDmNSseMlmkAzx3yOTg5Y+v BYDj4PCGv3Fw8CaZOsiLuIcbeMkd/dT+VQXXh7U7OFZJ4QuXWMpvG5WbeACM5BzGw59K68DT oJ5YLp/Eq6mSxtnYne0YZjjAIO0jr3zkiq9xYSXmubWtdeutKjfDxSb2ZHwSAOeMAnHJPPvi i3YDHPgbxAqo7WWI3iMyyGRdpXGeueuOcUlx4K1q2z5sMI/d+YuJlO5fUYPPqfQc+tdiz6Xb SEtb+JhH5zBBLLICqqCGRcMOhwcnPoeorOvZrBNQjtpLfXYZpZP3KPPJ5ssbHAUZbg7hgcHO OenLsBzd14O1yz0z+0J7UJbnOGLjJwpfp/ugmufya77UbWG81i0t7C01s6ckqR3VrJvZnfcf MI+Y4OCBj1J/GePRPCrXLFNK16RWnISJkHADKCvBzgbsZ65K0rAec5NGTXbXFt4SsmR5dM1U QtIGBmO0lSUJXg9Au7Hc55Nc/q76K6qNKhuE6ZMx56c9/Xp6e9DAyMmjJoxSUgGt978KfGrO yqgJYngAUxvvfhWnoUe/WLdTyN2f0qZOwED2lxkAWsnAwTsPNFdnf6rBYXAhdCzbQeKKw9rL sXymL9kb0FZeoQmK4we4zXVtCS3SsLXI9txGfVauL1IDwxO9vqjFL6Gz3RspkmUMp745rrYL 6dYfn8S6ajbeAsSkZ+bj6dO3fpXF6LcPa6pHLGkTsFbiUZB+U111pcXnkt9mstGAUYIY7OMZ 4BPP3v0rVAKb2XBz4oskVctuEYLlhzkcZxkDHOcfgKbpWoNAl2kfiaC2X7c7fNCp8xc/6wem fyqpd6ve2CCYw6aoDcRwn03rjAPQZPH41m2/iy5t2uG+yWcnnT+efMjztb/Z54pgdZLqjCYv F4viLiMgM0KgE7l4PHtn6jqKpa3rdzeaBPHJ4oF758YaS3WBUywKcHjPd+n933rJk8c30xYy Wdi4ZdpVoiRjOemfp+VVj4uuxZTWkVrZwxTRNE4jixkMFBPXrhRz9aLgaun6xqd3Ml7qOuWt nLZoWtXkjV2yVwQqrxnAA+fj8at6fqAeU3L+LhbSSZeQtbhj5jpyRxwASR+YFYMXi2SG2SJd L0wsqhDI1vkkADHfg8Zz71UTxA0Wlyaatnb/AGeX75I/eH5g33vqPToSKaYHZXXiLU47S5W1 8VQXN5KUCpHAqAqSxYBmHGMg89uBUVtqVzLLexReNFBkViwa2ys3LkgA8KMYOO+49a5628a3 trHGqWOmsYxhXe2BbpjrnNKnjjUYr+K8htdPikizgJbKAc5/xPSmmBo3lzPc6vb30evGdIoZ gs6wKphz5hVdoA3bsckDjd2xWvdaq/2Sa6PjkXEykGP/AIl/BwsmAMjgknA6Yy3WuXPjfUvs c1osVokMysrKkZAwS5wADgDLnjGOBUdj4w1HT9K/s6OO1e3xj97CGI5J4Prk9fYUrgdXLPZe WLg+K7x5XjMsi/ZNjCbDc7tvyjlh3IznNUYrqHU9XuLrVNeuoWtJHNldG2BICNmJiAvT5mJH HT8stPHurKsSmO1cRMzLvjLZLAhs5PIOTx0qW5+I+t3dhPZSraGCZDG4EXO0jB5z6E/nRcDq Y9ctmiV5PGV8SxUM4t0IL5Tdx5fTAyOT0x9YBqNld2Ymm8WX8d7J5e1XtlcBgEOGwnzYIHQ/ 1zyGleMdQ0iz+y28Fm0IuPtIEsO/D8dOeOlWX+IGrtEsZhstqbQuIeRjaODnjhR09TT5hBB5 euXE6+IdcmjVYg0E5jL7nwAA2Bk4GOPepBoHhPyiD4o/eEABhbttBwmSRjJGS469hVM+NtVM Cw7bYKoRRiEZAQoygHsMxrwP8Mc0WNK4zqo9H8LOwEmuzRjeoz5ecL8mTgDry/HsK5u9jgin C20pkj2KSxH8RUFh+ByKgzSZpANP3q2fDQzrER7KrMfYYNY38Rq3Z3LWruy/xoUP0PWokrqw He2OmrfwNeT25czuXXK9F6D9BRWfH4/u4o1jjs7cIoAUfNwPzorl5KnQrmPRv+FdMeU1BD9Y iP61wXxD8PvoEtkskySmVXIKgjGMf419AzRCC4xj5G6V5T8Z7MtHpVwBlQZEJ/I/0rzMJiqr rqE3odFSEOTmieMtzTcn1NWWi7YphiPpXvXOUgJPvSVMY+KbsFAEVFSFabtp3AZkf5NKMf5N LtpCKLgGR6frSjBOAOaTFS2zrFcxyMMqrAkUNgaMeg3cts06LGSBny9/zH6Csw7QeV5rtILz TliM0l0AuM4BGfyrjrhlluZZFGFZywHoCaypzcm7jaGAp6frS7k/u03bS7K1EO3J/d/WjdH/ AHf1puylEdIB2Y/7n60Dy/7h/OrVjcLaCcNbxTebGUHmKDtz3Geh9xRp9xHZ3DSSW0c4KFQs igjkdeaVwKuI88KfzoxH/dP51ZsZltLxZ3gSZVz8jqGB+oPBqBsNMWCBVLZ2joB6UXAjKp24 /Gtvw5YC+nuIlgjmkEJKCToDkcj3pmr6t/aVvbQlBtgUKhKgFRjpx2rovhvZmbULuUg7UjC5 9yf/AK1ZVKnLTcmVGLbsjLXQ9Y1As0VsXSFjCMYXbjtj8aK9esLBNPt2iiJIZ2kJbrljk0Vw f2hHsbeymeh34Bt2JHI6VlXem2Wr6esGoW0dxEedsgzz60UV49RtTTRpD4TgPGHhXQ9PgtTa abDEZJ1RyM8gn68Vbbwd4eRBjS4eAOuT/Wiiu72kvZxdyEldnNeIdA0m0td0FhChLAZC9s0x NB0oRKfsEGcd1zRRW6nLlWorIQ6JpeR/oFv/AN8CopNH00YxY2//AHwKKKlTl3BobJpOnKpI sbccf88xXDa+qJNhI40AB+4gH8qKK6sNJuWpnLYwcn1oBPrRRXpMzNxLpwigJBjA6wIf6Vhu zbzz3oorKG42IGb1NdV4a2SIEkihdS38cSsfzIzRRU1/gHHc7ldI00qubC25H/PJf8Kf/Y2m Y/5B9t/36FFFeVzy7m9hraNpgP8Ax4W3/fsUsei6YXwbC3P/AGzFFFJzlbcLGjF4f0dkGdNt T/2yFS/8I5ovH/Ertf8Av2KKKwdSfdlWQDw7owP/ACC7T/v0K0rG0trNCltBHChOdsahR+lF FZSnJqzZpFI0ABgcUUUVkWf/2f/bAEMABQMEBAQDBQQEBAUFBQYHDAgHBwcHDwsLCQwRDxIS EQ8RERMWHBcTFBoVEREYIRgaHR0fHx8TFyIkIh4kHB4fHv/bAEMBBQUFBwYHDggIDh4UERQe Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHv/AABEI AeACgAMBIgACEQEDEQH/xAAdAAABBQEBAQEAAAAAAAAAAAAAAgMFBgcECAEJ/8QAVhAAAAQD BQQFCAYEDAUEAQUBAgMEBQABBgcREhMhFCIxQRUjMlFhFhckM0JScYEINENicpElU6GxNURU Y3OCkqLB0eHwJjZVk/EYJzdFsmSDo8LSRv/EABsBAQEBAQEBAQEAAAAAAAAAAAACAwQBBQYH /8QAJxEBAAEDAwUAAgIDAAAAAAAAAAMCEhMBFSIEERQyQgUGITNSYoL/2gAMAwEAAhEDEQA/ APK8EPuG4ojmgFQQmCAVBBCYAhUJhUAQQQQBBBBAELhEEAQuEQQC4IRC4AhUJggFQQmCAVC4 aggHYVDEKgHYIaggOiCGoIgPQ5HLCoDoj7jjmggOyFY448cGOA7scGOOPHC8cB3Y4XnRHY4M cBI50GdEdnQY4CRzoVnRGY4VnQEttMG0xE50GdATG0wvaYhM6DOgJvbIVnRC50G0xAmtph3b PCIDOgzoCw7ZBtkV7OgzoLT+2eEI2mIPOgzoITW0wbTELnQjaYLTe2QbTEJnQZ0BN7ZBtkQm dCc6LE1tnhCdsiHzoM6CErtnhCdpiJzoMcBLZ0GdETnQZ0BKbTBtMROdBnQEnnQnaYjscJxw EnnQjOiPzoM6AkM6G86OPHCMcB1Z0IxwzBAPR0J/WRxx1o/WBgOZ4+sRwxK1AAAFgsERUAQQ QqLBBghcTRbCvOR5wAeziw84CCwQrBC8cdyhGcS1lOX8XM3cz4wEdggwRO9Ar8wjqdxQHGEW LSON4RqWpRkqQdrs88UBHYIMETDW1KV6M1SDKyi90QjDLojDNwwYPdgGsEGCJRG1L1jeJYmJ xFB+9D6hhdSW/b8kGDtCwmahl8ICEwQYI6G8kaxQEkntiiQeGRe2p847KygiwCMLFfhH3TgI fBBgiRZ21S64tmwbvaELhHYXTbrmG48orD7Qhaa8ICCwR9iw+Sr31uMCcOHs4jO18ISXTDwM vH1QRi7JIhb4roCAgie8lXjZ/wCL5oQ4hE4tQy/0htRTy8ksoeNKIAhSAIQTPVinynAQsIix eSrxtBQAbKaUYGYs4szc04xHPjapalBQDsHWF4yxF6yFKAjoXCI7m9ApXp1xxODAhLxnQHDC 4a+zx+xCoBcIhMK34AhcI34N8fYgFwiJNOzqTqTPqEH1clTJOLvvnz+ERUA7BHc4NQ0bG2Oo x7jliywh47vfHBkndjJNxi7PVzgPsEIwHA7YBh/EG6FFplJ3qSTTfwhvgPsEKLTKR9hMo3f5 ufKEZJ2x7ZgHs4ftMOkB9ghWxrAJ9p2ZRs4uyZl6awKEaxGWE5SmNIAL2jA3QCYIlabYRuTo JGpGNGAtEJaIWHXLD7sud8OvjDsbWhdUG1KkqouY+sDqX+UBCwRP0fTCl1qQLapJVEFfaGBL 7Ol8paweTYzqP6VR5p6jpExOIr7kucBAQQ1Fh8nvQ6dxnDCofD+rw9gsm+7+1AQsJi7ulGE7 Gu6H201QjOkVhOF6zjfylylfFTRsjqpyMlAP0jEIP4A8RfDx4QHJBFrpelRrFDsjciRlKCUG 0JMJksAr++fdEOnpt4UmGg2bDkmSKEIQrpYhcJSgIyFRZqXpgZyN2UuqYZQCSDtm3rpiMBx0 7oddGRA202mHsC1YoOQBUCUhF2TBcsP/AJgKlConfJJyAYRt+UUVmFBPyxXmEyHdy79YtZlJ MhyxGDJGR6WIGHMn1hYQ8/8AcoDNYRFyqxqRpqbKXgQbGaJXMjL+5FPwQH2CLfSbOSdTe37A UsVCWyJ67sBDznBUlHj6c9AygpRdr+Zulrf3SgKbC4nPJJf0XtOcDHkzOCHXsRJ1Ywg6DTL0 eAjZ0QBnBCHtYucBUIItFSJkCZnps5MgB1hcxiD+s/FE6jQJlhaFScjS7RljH1ehfh+UBnUE aA8MO3ltQMAAmmCFmGEh0u8eUcbWSSzlubVnJOkhHBCWYYG+ApcEaUzto0zeHO2cCoxTPOMF 3cpS/wAoiS0xI3iqUwyQYCScfzgKRBBBAEJhUEAQQQQCYIVDUA+XD0Mlw9EBUdzX9cK/FHDH c1/XCvxSgJGvAemRVIuVeA9QP+blFNjOMEKLhMEbh+NPa8kbOzqcGbh3cwItAxl0dzWB7yxd G7bg9rIgtoLg1I8w07YCs3tCD73jD7ogJ6DTE5OFPnAF3SjMNpWe2pUYw7u8Kd8P43jo8XpK 3YuyLenlwQ1ZwJyVCPcyAF3gD8JwnYEakwOcT6sI8JPHhzujLf02NGVjG4GpxXZe9Ocr/CBw 6YJMKGv20I/sRGX/ALJwWuaj6wJGjZ8SVR9bJw3a85+GkSbHSTaSYuADAqSi3csV08u+UZ4j 6bXqM5GNUeoD7RYtYNmfgZ52BaH9eL/OCFoRj2azt9TbN9VW7vfEwYDOp8O/uCbJ+kf/ANYz xOS8KU5o021GlfaZfD5wwn6SGWaSm2jKL9YWG+78oB+ix5NQNwx7vWBjUjCQZbiTsYBYlO8E z2pfOMdiTUJn4lOE5SBwCnD2RC4QGgI0ZKZRgR+q2Qf/AO5dy8Y6P4mbuZo8ssez8w3f5Rlq fbDjAgTZoh+zh/wjq2N+6QwZK3a8P9f84DQHBGcNw6SADNAEiQSyQivmWZdHQ14/0UNSTmqC 7wHmcMud984zvYKkzBAAS5ZvaFvQlGgfjs3ZiVu6LCZhFdrAaooyRuB49wWYkF1+LTWU/lFI MQLPIM1GcDIHtJWXvS9Iv04xBFtVQjTiyUa3Z/aL5flDShte9nKOOTKtn0y8XDWAuvp6BnbP QwBW4hECRYrpGS74ibTPVsG5lDCmEERIuJevCcQaxqfgZA1KZb1m6SYIX+7o5XRA5IDA9JEm hNMDu53tRYs1n+xjb1XSWVsoTy8Jgu2E3lL4Th1nAPpSuUCnKKNMRG4Ql8PlFLjpa0C9fiAg AaaMO8LD/jEDQ2clMOm27cT9H9Di2nh6+XC/xgcNjWUe9DTZWUFEVk7upd3GMy/mR4/vF8r/ AIRLGVC6jb9gzgbPpiwh1FIPCU590WE0WcmBUiMazeK9qNKTkknKKdGPKNAIKrOF73u/7/bG fLHJ7AjSqTiUpCcwXUGFkylqHunHC6Oq91ytsO3Cb8ssvcAG/jwiBcLO/T6kWLHI4oK1LcUW HhIwN+v5RJsewJnSogY05RXTBQid6V2EXG6MrhcBfvrNN1cyI1gCP0pnlhxXSypazjPv99mD ciWLfnUlHsZKkAU+HDhy5cPjAWZvUoPJ+hRqRlYEq0zPLF7Mpz5yixKFiZMoI28ZSpUYrUjJ w3GzLKFLdn4Yf9zjIYfRnDRqNpRjylHsmB4xYuFpn8F0p9v6EPew9q4Xa74YoMYwFrE2MCXE YEWIR2SZ8pz5d8QvTzxtm3jch7R2AmCu3Zd0u6OVwWKXUzOXnbUP2cV0BptLqUCOm3tyOWfo 9K8esw35l4OEru+ccaNSw+btcSSpShNXEmCyTRdfnTnfoHkG74xVmNqfnKn/AENYUQ0CPyss wzAWcby+MQrgj2N0PQKQACqTiwGB+Eai6VQsAcsQOpLwV0bhTAEkCK8YsF1+53QWkOpKks3J GiNTqFOcWWE7Mn85eyHwijfaB98wUgh+9fEw+U2pZPrJyLNxYDiSxdYXP70oyFmR1gS5Vht6 kkpH+i9iLxaSxcr+6USyipGolGQBS5J1g05IsSQu6ZaiYhbkp3btwZd0ZWWDOMCSAGIZgpAC H3pzidLpVZ0g5o8acrosmQ1ZnIuc/s/EXhAXdnfmQDgqxvYPr+15xmkrsF2EMcdJvDI1M/pL qnxkuJ6rLD2xSEGcg3fGKRUjUNnUEEqco3OJCaQYX2BAnwuiOwfc7P3Y9vCO3/WFMX5xbOm0 ez0oMfrWc7CYWH2g334oq32ed7HvQGdSnzhgNyvew6RmNNMqdn9KxveLalOcHLv6sIfZ4c+E cqOp2fpDbDh4RqEBqcwsRfVF3z0lP4xVnxhOai24Azk4lq7LwkB9mQuzEmookZNSLGfpUr9H pJqF4glzvLw8pS5z7osSLfULV0o49JOXVCSBSEmFp5ykLW+eEPd8Y6jKzbVO1ddseFXnECEn x+zduy5TiJ8hh9H9Kjcv0eIuQgiyesvvu7P+sLWUHsGUcvdcKdQYApNkl4xixa3zlyldAdyO sGfyfNTLBqAm5JwMOXfMWZz7o5fK1q6P/jAlWwBRZGHTTnOfD98VSoEA2p4VNo94aczDijh7 eEHtiFIP5wF8dKzTHKCFKY5V64oZhGXdK4PeLiKc4c8s20lYRkgVHgzxKDBCLuw4pXXSjmcK JAmLcSUyxQqWt4esDl6CnppLnzio7MdujUgNSlZ2QIwwPZH3RAm6ke0a9vRs6bNEUFTnHHHa RGVANAN0F0UD0XQIfvXc47qoYeiqsFTyPGsGEsIu7jK+cP0/TwFKNzWOoFoQN4glZBAetEIU AU+/I0bH0UsAowZ0zupDfi8Jx3qKzJOxfo0eA6/PDi9Z7vylHKjpglfT7svbdoNVJVMiiyTN NJx1M9JJjmco5ZtG0GFjGYIN2BPg5TgOBwqclYzhR4FRQwlZGEIuru8e+FvFVJljP0amQGlZ hYSTDDBewHu8Yq0djGj6SfEaDHh2gzDigJN0eG1eW2E9GjykIcO8LtR1F1UAnKTJm3CiLCIO WIzf3vGJNwo8HR6obajNKNJOwBzBeslrrrFdTtoEeUc/AGEBwfRiA8Tp33cuUBMF1zk9SBt9 FD2SxGa3xGdPE9KHr1LaA00wUhh3rsucoTWiBG2ugUyP9TIRgeOXOfKIKAsxdYKf4ymAePMx h3rpRGGPCnLWdjNXCxKTPe8PhFupumEZzO0qRoM8awXXGe7L84gnSlV5KhcPqtlJDMeZi5cp fGArMEWFPTCnZ25epHhRKDJZgvCLJUjU2trX0l0ODAFXlEF/rJcr4DOoIvLw1AclCVqRo06F wLLmoXiCHQsHd8YTSbCg2hcPOTrtnJllmfZhvgKRBGmLEaAnagIyUQXIWWEsJ3td90o4dmwN exkgb+mBHGZ+Zxw90pQFBhqNbY2EH6MJyU/XXiUiFdeKfhGWrPrB/wDSi/fANFw9DJcPRAdi Qp/+FEv9JKI+JWl/4cS/0kByvDwNenCAfs7sQsKhMAQQQRYfjTaHyR0WaM440jLUy64vjGYR 3M725M+LYFOEBnaLMDjB+UFtIfKYal6zbMBuPL3vvS74Ujakaam1SZMA3AqDMXjFDMq1+O7a /wC9uhuh0urahAWaDbMRRnaxF38eN3dFoX4tAS20mlTJgbmIo+Ox4bUzwWajHvAzwiFi/wAI zPytfuj9g2zEn+8HX84QoqeoRllEjWDDhFLCIsOAYpy4axAu6gDPR6gRyMkfXBEQeWSKY8P3 v9I6KTbdgdBdcauRODdMWE7jd3TigKKqfjlBRxynrS+z1d35wvyzqTpDbwLAZuHB6uWC6fHS LFtToFLI6GpkYxlNRYdqw/D2b+cTFn40C9reBoDiilq4JojyDNDAyujPE9W1OAwQwLMWLeF1 d8vlKONPULqmeDXglThWnbphmHv8ICOR9SsIB7p0v3xt6glAcscQDzRZybrCeV3hGHGY94eD tbwt2JjyqftnCTt4927e9u6XLFEC8s9PIGd0SjQEjxmYt4Xshu7PxibLAAZf2uVsRof5zxjJ unnvf9PUYxGZu778OmVJUO2FKRrDSjS/V9Xgl+UWNFWbYcnZ9jONC35OM4XPcnw+cLTqSV7P 0kcBQRhdN0Jf5SnOU/8ACM+Lq2p8zGBf/Vy5XflCfKepNoPO6SNxi9ZiDp+XKA2R0AmBUjcM eMI9cvL7Hdr+cQ9aEjy3oH8YEixBF7FwZ8JSjLi6qqEnF+lTes3t7XWfd3QwZUL2Nv2AbkaJ P7WLiL4zgLg37eOzcWzAVBcC1pYTM/jfPnK/ldETaIcds7cz75oEYcZyvDoI4XKU+cQ5lSPw 8gA3U3Anuy/lw/KGnR+eHUsIHJeM8AeyXpdf3wExZ+1I3hQqRrCdzLxBP/V3Rc6bTI21wrJG SjNKwt0xFi13pS/z46RlCdSpJLNAScMoB26dh+0l3TjqLfngBgjgOSgJpheUIXPL934RAtdF tSB1pcOBAAS0WLEJTfvT5YRy/bfFF977osIo7Ebw6oEYkaBealKF7JcdCde2gR5I2Eo83D64 R05awFr2YlfR9EAU/V+k8oz5xNeTzCNRnL0CdLkuJ6UsPYkYAMty+/v/ANzjLtvWbPse0m7I EWIJPIM++UdnTzkNYQpWKRuOz+rJP1LixP2mNRLajp04CApGoVJhbSEv9ZKcNUGSmGx1EsOQ FLBt5MjycwN/xlHC4VPt5iXbGdKanRlzAQmxTu3p3znOfG+ONQ8Hb3RoOhyjA4TyUwp3Hfig L9Q6CnllFlOpyArEoUm5oAk5kw6aS8JeP7YYRtSNTSYiUDaURhJEPEeT2rvvxnydevRliJQL 1CUoW6IJIrpCg29fsewbeqClF2iMzc/KA02tG1hR0/gTI8XVpMgQSdAzndfiM5in3fshipDm dqtUIZ1jOiKai8IsWT2sQef9b4Rm23rxpwphr1Qk5e8WTmbgZ+EobUHHKTMaxSaqN/WHCxzg NipunmdqLEyPaZP0vlqF5Ig3GTy/Zul70u66IAw6mEFqDYsdUAykQUnXhMLu3+/BKendxlrG eZynaNp2xRtH67M3/wA4DBjOMxnDGeaLtGGCvmKA1mjxozqP9ATDNK8oDRlkiFO8svtBnO6X h8PGJWqEaNS4LFmzN/SRgVPRncYXdqaLxlPhO6MTLUqSfqyxQRi7WSZdihP9cf8AagNbWMKN BZm3DBgPNCcjOLU4pX347zcN3KXfOcctrCZANG8Oo0acpUJzLCgODxUEzlrPx1+HwjK/7eDs 4cWn5QvfH2xjFh7OIV+GAkaTWAQVY0rzvVJ1ZYzPhKNAZ8AKorwkZJSzbsJxBAhXyOlixcp8 ucZZBEDdXAbb6CN12LAWWmK2YIpYy1XGQRa7oA896OBrGBNT/YTrFpalSNaEkwJafevuxeHO V0YtCt2LyDV9jZybGzUxKlKaNUSE8OI68zOmLfwh92Uuet8Fqi9H5Pn9GgAanUCTBIEYokOW 7dfllcbuHH70ZNue5Cv6kBpdojkcdahTpwBohZZBAMQbsBc/bv7roky3VN52KrGM5EaBUkyE 29LLM4T1nwjIo+bnYwR7kG6GPCMdPhagL2rpUJIcwnEHKLxC/s3hly1uhTo9tq/KTI3JtNNR mBCeYcIMiw6XTmDFOMHwA90MGAHuhi7xdXQltqGqKte9vwt6feTi5HD4BlK/v14RUUY/SEox +yYEQvzhuCMBtLhU6DaFQ+nkpCddhASIgUpjJ1xTFPu096KfXDkgqHokCBYUlKJVzxEcABlf 66fiKKHue5C4DVOlaY85ji8KXJKIBiQIE5/bkTOWk/n3QoypGQ50eMDwAgCpSSoLO1lK4EuE vjGUwReQawz1PTYDFy8a8CPE47UWTh1EAMrtJS7/AJRwl1Uz9HhU52HCWaHYsOopjv48ozWC GQSqMltBSapSpH+kBHSAnJxcuc7oTS6wDbUCFed2CTMURkEQNP8AK1kBizlihZ12f1d8paS0 Dr/hpEd5QsKyoCntSNQFUEjCHq75Fj+EUGCAn/0IdVgTs401t7Z5h/Ewf+URLhkjWG5PqsXV /COaCAvbXVrama24B21Zrf2Qlh0F84S4Vg1KUZqDYFGy4cQcXHMvvnf4RRoIXi81JWaB1byk 2zKg4TAjF8uUo43CpEA0aFtRgVbOnU7QIR4tReEVKCAtaepyfKRzcjkw8pcXlCLD2whhxrqR qQbUSS2qAojrt3F1m74xUIIC1+U6A54NdVjUPNxS2fLF2cPC+EI6kTJlAl423NcBGTGEzFpr FXhUBci65yS8ewYlpZeEszFuBikY8cLhqAcLh6GS4eiAqJ+j/wDmBH/SRARY7P8A/mRH/SRA qEEEEbBELhELgHYah2PiceSoCP3RYoD7Gp0GSAdNlDziiB58gizPtPCM/qR46bUFKcnKyy8E dLHU6lqT7Nkp1SfFiwneyKAur5QaAbwa5EqRlJcWIwsPs/8AmJZ8Qfo9HsZxQkpZMjTkhhf2 cuIpfLlFHMtCezvYSh+770u6cJ8vHXY8nJRY8OAs7mEE+V3CLFurglAvodxWJhpzwJxFiIw8 SfCMm390eAQcUT6yqlJzGNq2NElAd68wkN2Z8uEcbo97ezo23BhAl9r3ogWmysGNO5j3CjSy +rNF7MWGpKMQP2wqQKfTcjrMvSR0r9RRmdPvaxkMNGmwCAYHCYWZwFKJoy0J7y8knZUpQbsv DxD/AOYCfptYBHt6PcEyocYTjhBumdpGa+uzTkwB5WLEH7sotvl4v63Oamo8BgsWEQZ3RDt9 Q7AW5gySsblfi5SDf3RYKPwDqRCA4GMGdLEGNcdGRA6t7sjXrMXpfViDxTd10YcjGNMYUcSP CMm4RYvGUWnzhPG8MAG8JpgsRwv1k/GUQLJTdMNrJXjKmUqTRGmBmLCLUH3dYh06nHbQaDGA 8oR80pnV6YL4ifLZ12xKsGNKaalFM0sQvH/fxjh6eOA+GvfVbUYKYxd184sNVQmAjqh2Rk+q JViCX8IjoUYdtJgjhnZozBYhC96cJiAQQmCAIVBBAEEJhUAQQQQBBBBALhELhEAQQQuARC4I IAggggCCH9gXjLzgIFQiv1gSZzB+cMQBBHX0U6gUEJhtS0Jqj1Ycme9HH/8AmHdEGA+wQ4nJ GcYEkkAxDF7IY7Gtke3LENtZ1qoBZkwCEWXoEcuX+MBHwQrB7Hth7QYPdB7Yt0IfenAJgiaM pKqgKCE3k84Zqi/LDh13eN/ddzvhh8YXhhyum0BqHOvETme1dx/bARkESDGyOr3m9FIxqsm7 MFpKQb+Gs470dH1OpLNGBqygFimEWccEvs8e1AQEETSOlahWNY3Ult9FCEQsWKV4gB4zkHjO UcCdtWHU+e/ATD6NJMkUYfyxC4B+MBwwQuO5jZ1724bA2k5qjDMfdIIA8RCnylKA4YIk3xkX smxjX5WUsDjIOJMxgMl8YRTbOvqF4C1M5O1KBBmL8Mpc5z5QEfBB2MQPdFMP5QQBBFrcKDe2 1GqOUjS40peM9MEV5hfxisIwbYoKJTbwzhYQ8pfnANwRK1YyKaefBMizAJUWWEYsvWW9D9N0 2c9p1izbE6FKhFIJxynSV4uEoCDgix+SSzyfcXsCkpUUjOkVhJvnMV8djPQa9yZynLbE5Q1B cxkkC43S75wFQggjrZ0Bzq6JW0n1qgWEOKA4YXFveKMGmZxr0akazJMyjA5N2vhEfS9NnPGe cdjRok5OaI7DfMUvuy5wEBBE/VjD0JsYwHZoFReMOLjEFAJgi7MdEkrEaE5SsNzXC8RZZN1w ZS75ziuLGdyTLFSbYzep+72pd8BEw1F3fKMGz0GQ/LzvTVBn1T9WGfC+fOKXAOFw9DUOxAVF rs3/AOaEsVSLlZX/AM0B/DGcgocJggjcIhcIggOiLRZugRr6sITKQYgC97hfFUiRY3hSyOhC 9NgEMkXZF7UQtq1YUGSvRm7MS3ty0szqzCOBgO66U4gKXoZSmfCNvUpTQYcRhIi+7jKcBlpa YebksIw5wsYsR1+/3w0ntIHtGcczgN/WdZdFoTTHR6PyseFIwJxNuLCEgQb+PdEi108yDaxE 9GpMGIwIsQes8MM4rZdpYAOB53QOJKdd1eZrfLnfDCe0jBn/AKE3MyZpPWdm/wB6LC09nSkn 0/bwYA9bkGF/ZS8YmHxMA5wSrGpAyrGUJgMzIDLGHvxS+EV9RaENY17Msbet16ws64GvfKOZ HWaZA17GgYQFGmYc8WdoZhiBaXyzfOrQKlAMro04yWJMHTL74nDKbZE1UejM6cr0Lq84vcvl PjOM/qy0I54RhJRoxt2EwI8zO1vDHYZaisGYjGNqALZ02ynYjPXSnzixCWoICUFWYEZICgGJ 5Giy+xi8IvVBtSM6k247Zm8WYZhPzy5TmL4XxmlWP3TzgUp2bZSk5OUSXx0iWputhtTP0acg 2ooJmMsQTMEw/HviBOvFnWS+HqSV5QWoJkxYf1d32UXBQwsilOQDYEuAOVl4S7jA/jihqLS1 gzBfopPlGBnnF4u0OfD8oR5y1+x4CW1OFXhCER2Kd10vCLF8fEbagb1yxSyN6zYz5BTBJuv1 4Yrobb0bUsWY9gRFO/R0xnBy5ZRc5/svlFM85YwZ4+gU+NUZIZ+Iy+Qpy7pcoY84WB0EvTU8 lKGcGYVPXTnM7FGnAaQop5qXtYiTkyUoaxJiEeQXLdHf2gXRnLXZi5Kelkw1mUoQ35IsO4ou lfx5Xx0I7UVKbCADCn2csnKLLEdO/vvnOEI7V3snav0aiN2gWIIRX9TpdDgJgz9PUu0pqe6K 2hOk9PTGE9aKcuM77v8Ae7HfXiBB5FrslGn9HTkjILCXcannzmKcUBnrPocs3Y2FEFaYEQNr 4TCEX74ddK/dV7GJtGjThNOLyjlIb96XwiOAgqXbSXh4IQKVmy7R2TuO/wApfOL9R9GJm20R iRuqwBozgiGYSIOgZy7Ovf4ftjPKfcuh3AheSSUfk9kszhFiLr916YbHg5GkPVNohCLMFf1m LlP4fnGYlvJ5HU9QVCpUrMjYVMyQktxd8zJe9IE/ziiuibY3RUj7WSZgxCDdEs11UNA+LHXo pKaNYZnZYr5ZYu8M5awGKWd+cFTxUjwoQqlAsWWmT5kosT7gmZ/MGQv63aguWHFzxd34bucc tWUe2s6dnAS6qj3V0JKPJIy9BSFyvlEOnqQ5AxrqbTASrmpQZjLEpDqG/wBqQeF/xhb5Vq91 UMqkZJSU1lLCUmMJ+7wvv/wgLW+WYktrxTabbzcp46gwIsONObdD5lmLUmdCMb8o2I4gwWHd kYIwM7rpSiAdLS6hdVjcpUpm0JredtCfLDP1nfP4+EMKK/eFihKcvQNSrZczCWIvc39RRpwE TVDaBqfDUBO1ZQd4O0huM+E7onWOm2Edm6qrXhetIyVeyZZAZT35yvDP4RHKHVBUjoJyq1Sr TdXgTlt5eKQZd29CVlQ4KXVUe1daxnKZKMxSXcoEZL9kei4ebRqBRaVyUvCgpQqbttLMEIMi +6QcPavF4XwhZZ0z5bcSgWOBozFJBBy0NwyN+6+6XGXhfFS8sHvoMtkGS3nlElbOSeaXeeWV 3S9n9kP+XlQ9HhRptlbsIixiOSF4DTMGocU4yF3cLMaeBUjS1EuSoOc5zRHFiOCMwWm6ZLul 333RAeStNr1FTJmpY5bU1oDcKcWszDwzu3e/5RE+X9Q9OJXsBLUUtSmTNDlk3YjZ/aC53xDp 3tyR1J5QpjspfnTOxexjFx07o04DVGeyth8l0LwsXqBDEQn2skxQEnZzTvEV0t384qjXR7Cv 8vM5+CEpnJEJv3vrHd8ZfCIcutqk2hcpOUlLBuBmaftJeMGPlMMuV0QCwY1ig1Sp3hnCxmcs U/hKI4D0hTYAbPSJO3jCV5MbyIsvqTLwCnMU+Up6c9YpSeiWdnUNL825pu1L0mwEnC9XIU9Z j8b+EUNHW1To0ZSMlYV1JeUScImQzQl+7fOEmVnVQzDx9Nm41RhRpwg3S1L7Epe6GXdKLvQ2 7H/xRTqlMM0QC6pNINEZ2wikDXB3B/KMrtgZ21tdELk2kjIA8Z6gRIvZwjw3/OIoyuatG4I1 /SuE1GIQ02EkMgFmD7RmHhMfjEW+PDq/LNseFm1G4cId26QZd0pSheLhYfg6UqZT/GyWA8SI XMJveD70XCy/Yx2f0HtKxUUMLqcIstPd1hgjZBvHvS/zjFm9YsbVgViBSMhQHsmB8Yk2uqqk ak+zNrwIgrFj7IZ4Rz4zDfLd+UZrajWlGMmW/wBVdGqNqFtAU6DXMUG5uHaJB5Eh+GscznSr dRlLsNSbH+lWp2TBOERfPOnMN8Zh5Q1CPfG9rRDETs4hCFfMRXHLn3yhRlT1OpTlJlL8tNTk ikIsvF2Zh4RpwQ1Ss1O30O2DbVbkhG7VZPMzA5RpebLeld3XwlwRo1leVM1OSbpFFRLYIprR Gfxgy+U9/wBoQhTjK3CoX5yMIOXvCo8SUWIjllj96Upc/GGk7w6pnATkmdVRS0z1h4Rb4vjC 9bWbOx/od6U9AjbCjF6T0AvTWcrr9eUPuGCoasNoN+alR7aS6HG9JlinIBY8OumkpSlddrOX jGQlvz8SoNUgfnAKg71xmZqLu/KGk7w8EpzUZLwtCnO9cXmaGX8b/jC9C+t/lCgo9YvxrVih UESBAH2EyMPaNFd4cJzix1gsYV/0dz/JtSPopCrTEEk7PgwmXXjmOfMQp3zv/ZGSdPP2x7B0 85bLhwZGduYfdu7o49pWbHsG2KNixYtmxdVf34YcFupQ1LCafRvZ26nWGTATva6eEXCw/J6U qTO3gGMpoMvmZfyl3/tilKF6xSnSozjsSdGHCQTyLv4/OGCzjiTMaY40g39YWK6cYD0I4NTO ppduQOSMCVoJTdYYYK+ZM824AQzFdOYx/CEWdr2pHaA7MOx9GOojxmmZAZZezgK3QiFyu4zl KUtYwAxYsHvnLFR4/wCcMnOE5xwOwpNCMXaEEyd4vnFoSrWzqXhY+5OAIW/NOMEZ3X/viPa/ 4QQj9jPK/wDylCC1iklOeSSpNKKUevCH7b8XfDEQt6aUHfpB/wBjTJQ7VlhIOPMuLUcO/lKU u6M3tETI1Pk6jpgCcSU5xGIwQdwYjJT3p3ciuN0Zfvj7ZxovxGTj7Fjd1iBMpt4c16k4HUpi tkLzJAzNJX3z5SDCS9j2yqUaPYso5zJFli1LypB3p/7u+EYT/XH/AGo+wG/0eNqTI3g5MpTl NQnTFhELQwoIbvDS/wDDHKndWoFP522J+j9iPzBYt/MFfhLlGFQQEqjasdHqn447DhMwEl+9 OfKOyztSSjrhsWKR4SizJ7wvhFdxj7GPc93lH2IG9dNtpLfgUuTeR18zzCy7t4v4S53xwFvz aNQsyViUIFCIISCcXZ1v3uU5/nGIwuA0WsNjqesGdABYDKTkT2k4u7AGKCswbYeBMPEUEUwl i96UMQQGv0/UjamZ2z0xOUBOX1gRdu/uujjfKqauizyUyzNN3R5nNTdO/L/DKMsggNHryqkb 3ZujTdV0qJTjOIL+zByjM4VDUB0Q7DUOxAVF5sj/AOYP6sUaNAsf/hg/7pcYT+gzOCCCOoIg hcEAqEwqCAXFos7akbw8bMsJzQZeLL966OYvoHyTNAMH6VxdWLn/AJQ1R7x0C8BWDAM0HZEE PHXugLrVFnuNvCsYUGwm4uuTCMnw96V8R1PsjOmUdG1C1DVLzLsOEW4EE+d8uESvnIZ0xeAl M5H70xhEdphnHMnramOkDV6xqcilRxeERhN09fCAjmum2dY+P7IT/F8Qkx+Ls3S4TihxcGd+ ZGR4WLG1MtwGFzATncdfeiqff97egGoIIIAggggCCCFwCIIXCIAggggCCCCAIIIIAggggCCC CAIIIIAggggCCFwQCIIIIAgghcAiCFwQBCIXBAIghcEAQiCFwCIIIXAIghWCDBjgEwQosAxl 4wEmiB7wS53R9gEQQr+/90MOqCTkxgSVKZQQaZ2SzC5ymL4QDEEdhaBeNYajJQLTVBfrCwkz vD8YdTs7wpxDTM7kaAsWEWFPPdnAR0EdmwL+jxL+jVuyh+0yZ3QoxtciW8pec2rQpTrsszJn cLFwu+MBwwRJuDI9oC85ezrUZXvHF3SiPgEQR3NbU5OuLo1Aaqy/WZfsw24I1KBRsy8nIUB+ zFAcsLiaR0lUixv6STM5pqUQZiCZpwlxn3w0ZTdQgZ+leijdl7WL53QEPC4nFlJVImyMbOb6 QKQAh46z7+6HTKMqQDgQg6KGI07F7XZw9q+fK6ArcLix+RNSfyDEDDjzsyWXd8YPImpN70AA Si7uuMMuBvcJSnAVyCOt0QKWpYJGsBlKC+0GOaATBFmMol7TJzTlICg5ZeMwnMvMDKIdnbVL w6FNraDPUHCwhD/rARhkEWSoKVXs7WFeccnNKEZlYife7orcA7DsNQ7EBUaHY/8AWFw/5uUZ 5GkWV/we5ne6GOfq/RbNMAIaMhJfrN+JZ8QJicI0w9wXzjoQhIXCIXFgh8sGOGIfgNZT2YtR zeh/hIShUTjzgi6sufjFHUUZU5Kw0no3Fli7WLl3xoNN2lsPk+jTLF7ghNSl4BEZc5yM/KGl lpFPKS8n9IZXbxZevwgICoKAOTI2caMk0SpUZIJxeZfh/LhE35t2fpggkY1ogbNM0ReZrjl4 x2OFoVMD2VSSNaI0JkhmF5PZhCy0KlekCDiRrRdWIIhZPZxRYqj5Z65AeNmYQYisnHhUmSlM v7t8dnkSjJpfbDmdascAiwnElHer8fl8IshdpdPAxI/SsrL+s7PIevwiCR1VT3lIa8KV7vm4 u1lywGS7rpcIDhcKGJHSaF+ZEygf8rIMO1DLwhRlN0qvpfb2pG5I1QhBAXnGX5k5+EWJPaRT AGc8GBaFQYIYyy8nTe8YpjxVQDqbZEyDNSrW07NxYdPD5xA7LTKMR0wxtKkk401Uo3VIRcAz 8IYs3ptBUO3bYmNVbKTMQSSxXYp/KO+uK8BVVDo0CzN6XCfI84WTKQPzl/lEXZvUiam3BVtm 0ZSovBmEdsvxuixKVhZuvTFo1jCjHs6gvrCDjN9OLunziaY7NGo5r/SSY0S3FhOMLM+r6Xx0 +dRnTFlbGByWGkl5WYYG7Mv79eXfHMntFpsGLcdSgFnZpfV48yfdOPcY6vNcybOUm2NQbiIm PbQmT3Zyv0u4RUagpJtTU3Tq9q2gRq5XJOdmCi1p7VGfqlJxLklNJCIOQWHGWZfwvnyitvFT 08sodGzg6SC4J1O0erlg15X/AOkeCdUUHTaOvGmnliNR6UmEIRmZz7+PfDTHZoBM+OaN7TbY AN40ASztDi79N7w5xwrK5ZDrRGepAActnQppEHBEHf093XWJpwtXYVKzZgNrl0aIsQBHYet3 u4N90AkyzFnUp39A2gyHJPgEkzjNN6XZnP8AxiHpNkpg5rcU1Q02MpQ1liCtX7RPdNlLSUpc L5xNNdqNMErFxyxA64DCwAIEEuU57vvS5RUnSuUyxjqlBsAw9PK5KC/5u73o1FMTg2lQEkG7 nGYS8zx4XxbvN1UKZQHbNlCDayk4uu96fGUU9PgzA494GmIPhGi1JaQje28pB0aqKAlMKEk3 uyWHjIXjHOOivLPf+PCqbptGBLlpsZh5xl8jLud3GUUOoGcbI4bGNSlVbuIJyYV4BSi2vFct q+1DywJTORCcSbIEEIsBunOXH8o5qoWI68qTbEGyspSdPgEY4iyxqNb79NIscdBsPTad9Hkg NGhRCUYRCwcJX3w+12bvy+n0rkSpb81YkmrISCvzDCg9oV3hDtJvaag3B4JU4HjbkAkuYgMx gDi8YlaftLRtTGhTDZFBrk3ohIEwgmdVlC44vGICVliFeJqb6eH0aJPkBPyyzrz7hfc74jHC zR7RuDEmGclwPV+QZrLCOUr5ynzi0I7cnJM4Z3Q+ai2SRAUghfaS+0nOOjzqNVT1hSw1jaNn Sta3ajlJx1/4v9IsZzXFJL6SMR7YcUeBYGYiTCb/AGdJw7T9Evb9TZrwzgz8laFKIkN+PXjP 4SidtIfgV5XBpIF7W0sTbmhbTBXyLMDOd+Z34hR3Wf2ijsoLWNraS1VTthkj84JgpAJ5Tl8b oDjeLJV7OjPUuVSNRAE5mQLuzcOLD84hZM//ALHn1J6PuuwU5hn2ob/8NP2xNWiWo+WdNr2o 6nthGscQrczOxyLwhw4ZSiul1OAmy9ZQfRuLbF4Vu15nZw8sMBdbSKGQDWWctVMDK2p6bg5h mHcOnOfrpz8YrNolBqaMLSqRr9sTqDhJ8WTMqeIM5yndKeswzu0nHT5zlIE9Lf8ADyQThToQ gIWiM+zD7MpS4X98MVhVSavHRKBT+gE5YhmmK1aoSmd8+UpezLulKXGA4bO6SOrB86NJGMrd xCMCXfh+PCLNZfTZJNaV0yPaZOsNZ2VZl4tZBNB9pLxjhpOsCbOlB/QilPVJS7CM/dEnkEYJ 7mvGffOUcbXaEsQVo/1V0OnNNfExqc9Nmbgcy6+d8Aqg0aM6wevHhSmCavSqEYU54uJeIV07 omFFkSkDfgTPwDXcklKaeQIMpFF5+ges5z/bFPp+pzmei32lQIyj074IoRpghXZOXrK7viyK LWns5vyQNSIhaYEgClbmTvOAT2A4eUoDmqCiUCOqCqVan5Q4u4V+yLSdluw3dswPeGXjdFrp ugG2m7d6ZanhZtyJcm2ogIgyuFPXQd2kuE533xVjLS1PlAGoUFNtTc5Z0z1J+ozFApywzli9 gN3IPOEvlpz25VYy1P0aiRqmUvKTBJEK7D3T585xpwEtSdm5NWvFTLEyxUBtQukkpRZJYc0Q xi1ndO6UgB1nxhlvsrUrHSskfTaUPk+WZl70rzhBlfr7oe+ccie05yJNc/8Ah5n6PdBAGegD iLLxB1vFMO8LFPta3TinrHVepWOazaRI+lBT2stN1ZYpT1y7vc8I9Ho+h2FtAz0amGNtCnUM ExnJA3ZisyYRiGb2dfxYoySu7N0dK0WfU/Tw1SJUIkLOHDqrxajMnL2Spcp36xzNdpz22t6M kltaxKkKTYky8y+ZxZXDh2b5Svu0jjqCv6hqFOuRuuzmp1hhIhF8i5FdkJfuhjzghZrWF/Qi izx1QJm9CaZThZuIKeVxYhTneZh5zlyvi4KKYR1C4U3ULqsxJ21qCq2lMXcY4mTOkGU7p+xG WulorqvWMqk5kYv0OTs6YOWKchF8LhX/AOF0dnnXqoDgBSBM1BThI2ctuy57Pl4sffinvd84 vgtzW4f/ADJVPs+ky3Qhu9mUdVHpiCbE6+qEH8JFnpERQvdKH2/zirVQ/L6kqBU/OWzhVKvW ZAbgQhre3JqRuKNGMGzuBeA8swN8vjLxjD7HpNjakwPJYG2ZTf5KfwYWXeWcYIExCNFyvndz 1jO/NEyehjJcloU70rTBQcJzJTi7Zk9efLWKajtIqpGiKRk7AKZJEkoVZhOM/Jl9nfPS6EmW kVmcoPOG69aoUgVCEEN2EYOxIHuhl3BujUSeSgQWgAZ6DalXTRak1CExWZMQAjlO7NkLS66W saHQ69ne7dKZQbSJcOn248ktxy9F6oAd82+euGUuzOet8oynzhVP04U9g6PIVFhEEIS09xe/ 2hTlzFPvhXnIq3ygIqEClKQ4JyBJSMlPKQCyxdq4Pf4wGkUGMDrRdSL+klqVU5VaQlJWkXSP 10BK/S4OvD/8oj2gT9SpVcvxzwaqT0wfNvTJgboDFBumaKV3s/nGc0/WdSU9n9DrAFAUHTPE ERch4TJ6Yg38JxwdNuvRaxq2weyuB+0KyxfbGS5znxjy8bxR7k2v1Lm4MYTUdNTJMQGEzyxG TFK86V98ha/inE/udMLiftU7i3AUiM9V2ZTuK13fGV8vhHnfyzqcbH0D0qILfhkDCWGUhiCH gEQuM5eEKWVnVS8tKSpeDcCUzNJywyBve9O7jOPRrNrGx+a+rhkjNNGF4IB1neLe0/y0+EYm 8NS9qMIAvJyDTiZHBD9ycdNQVO91DlAeF+eUTvBLCGRYL++d0cz48LHtw29fvG4cO7pIMvCU ZEbSLJwJvNW/7Tm+kOhJXU9vh4+MaDVlH0291Jt7kgxGowy3cWq8YSvVd+nhHntjqF7ZMXRS 81LmbwsPf3wrykfhmFHdMLcZOIRIsXq5i7U5eM++AuresXslk7nVWcb0g6LeiiyTBaJCud0v e7u6JGmwLybJ6n2klaU5ejhzjxX529uyB8Iy3b1g0YUY1JokpZmMJOLcCOfEV3fHUoqF7Ulk EqXhaICf1IczswGxU2pUslFs53Rq3aguIswgWphk5h7Ur+EvyizJ9gBT6EHpBQDESs8RB3r9 4Wukv8px55UPz2pUFHKXhaaMn1PWer+EJ6beOkNv6VW7X2c7M1ugPRrhsZNmezbMMIBF4gpg +sFvce/9kO1ZsZzG0oBk5oyRA6kItSZ4fb4x5s6eeNoGp6YW7QLtGZ2sJLeHUnNyXVUHM7WE yIFurxtOfrSKiGjGVlIS5ZgvhLhKKY177gl/pg/vhJa9SSnPTEqRhAq9f/OfGGID0kYMkbg5 5KMHWFhDiOFcA7ldr8IjmslnQPiEbblbP1+cdzMMu4SlyDL4Rgu3rB4ca9ULD2esnCc479ca H+tAapbQpJJoNnQYMg0S8Q8jFrly5xkMKUDGcZjOOGaP3jBXw3AOw7DUKiA7Gi2d7lLuw4zq NDpPcs/cx+9GE/o0jZaX6yJZ4UgU4Rg92UcGCPsbszUIhcIiwuFQmFQBHUnBjMCD3hYY7qTT NqxwyXI7IKw9rFdrHKoySXQ3Zh5qcs7qxe9KUBofm0RjT4Ealw6Qys0OZdMsXhFNLYV4FAel UahCnzpFGHYb8N8aoz2isOzpdpezSssjAJNlzx3xAVhVtPPbfsYFJpWWYAWLL9dd3wDRdnqD ygEjGvWmpQpNo6sMpD/xiTLsrZ+jwuu0vAk5n2O7Iwv46Q75Z08meEa8l1xYUWziMCXPd8Yl vOcw9HgQdNj2jtbaFPPB8O+LESoslZ02VnKXU3aLssQburv97SMuqRt6HfFjbjzdnMw4veja VFqLCcWUmA8GpTU92I/JngO77ozx0Opt+qB4eDh4cXqcQsExad3PWArdLtoHV4IQDHhzhYYv lQWYk9HrB02ByEqRmYBFqRS66XeGKDTa/o14RrxgxAJMkIXfGxedGm+tGN1cDcwUhlhCTqTE RjPKboZ+XvCMlY1GhSmbwhZkuHOJ9vs0zq8cWf0ropP/ABjFKUw/5xOp7TqY6UCsO6QIxFzK EEJd8i5d8Pp7SKPA8LvSVuyqMIgn7PzDLuixGM9lzOsbxYznIRuYMITA9gvD72kU9voCoR5S k5AATaIzDmBOlIeD3sPGL432kUwTn9ctD14hl+j6KJThh0tRZ19P5JI1aFVkzIEXs8pzFIXL F7MaWCv2iUSmangLVTzC6712WtOMvKMvgpOzpZ5UBZ6qJyClBIssxMqkPeu04RLU/aFT1Nse zJjnVxNMOLNEWcX9Xu43Tjhb6noltrzyhTLHc3OMGeeHJ0LxfvjMQRlm9YdOKm0CArq/VmGK JSAIPLe4RVnRApbVhqBeDCoL7QcV/wC2NgeLTqVctqZxgdeilBEyhKcnf1+7GeMfkl5UD2w5 QayhJ6sSvQwwcpeEJBXU/rCge8ZIP5xuJlkTUpLPQIEC0pUWgkeS4mHdUcbP2buH7fe0jETM G2CGmB1WdiJCL3L9L42dPa6w5eNZ01jEk2USIsPV92LFfCMUBPZ1WY1AQdGlBHtOQLEd+fy8 eEXCoLLifOQzs7OmzUAkUj1+cdppO4Vwo6DLYGobgjU9FOHoIpgTf0Ew4Z4vvR0qLXaY8pCl hKN12LYNkOxE3D7WK+Ur9Y9xhbXZjSvTFRE7AaqAncwkFk52DJJEG/Mv53RTFll1QjWOY2TZ Rt6c8YEmeZcacWHmEPOXjFkLtUpjpR29DdwolSklUWLLlmYwSuumG/8AxhZlsyY5Gq6lybFG caNNsgQj7crpSFOfZ8btY0Q4K8o9Mgp9s8m6SAu2hMUI5z2q8ZJwuMsEVtwsxqckxKgzmg9a cYEoxMFReYnnP9ZK7d79Y76TrOnqVZ1nRra5GvS4uRR4Thej8b78XH85Th9RX9N+WBFYIGdy 6azpGqc8VxQZSDh3ec53fCC1wMsxpgFcM7bsAFX/AA4cqyAnTyFCoAru3yD8IrzpR9MILZ2C nNgwp3hEDOTlmaJzh+6K/W74x0rLWmHphKpRs7lsvRh7epzLpDwHTvnMMr9YgnC0JGprxiqQ DUo2Wn0kk7cSIVxhgwdiZndK/jdBClVIg6HqR2Z8ebsKsxPme9hnEfHS6LVLq6LHVZ9aXHiU G4eGIXdHNHOsiCFwiAIIIIAhcEIgCCFwQBCIIXAIggg3IAggg/HAEEEIxg9+AXBCM4n3wR9x k++CAVBCc4n34+Ywe/ALggxghcAiCCF/2/7M4BEEK/33wYB+2AYfxBu/fAJghcOFplJ3qUag 0Ae0Isuc5QDcEEKweo3B+keq3Z9Z8IBMEdxjU6gUFEjaluad6sOTO8UHQ7rtmwdFLdow4svL 1ugOGCH1CZSjMyVJIyDQ/Zi4wxAEESBbC9jR7eBqV7LhxZ2Xpd3xwwCYIkOh3XbCEHRqjalQ cZJOHUUu+BwZ3VtUEErEBpRqgWEkPvTgIoyCOl4QKW1YJGsJGQoL7RYuIY5oB+CCCAdjRWf/ AOMzfvGCjOI0xv3LP0v84ZOOWdbK86DHHLEonQDObxLPdjqQ44IIIAh2GodgLlQdDE1IjVLF jqNGnT/qS8c/2xy1ZRjkyKCNjJVOKVQXIZJwSf3yiz2L1g1MO3I168CESgPVnGBnMF/yi7uF f0kAv/mEC4eHD1Zc7r585aSgtmFN0MscmtcsUgVIRpQzEEJhPrLtYcZ6AOX0v0wcpUId4PVm E9qU+cpxpCOtqPGjVEjqcoPHtFi6zTlpHN5Z0eOlwpungYyy8OTli5fKCFIqyzropv2lqWKH E0JkgCJEXKWs/dnKGqXoBSvUHk1CByZ8kuY8IS5XiujQfOFSQCyhjddqBiDhJyRTyfjEPVlW s7k4EAR1aBGVix5iROP+9fFjNzGQ5YsETTaB1WFF9raC5AGG79kWEug0YKb6Ve1LkjNzpFYS yccgz+9FzcKzpJSn6K6ewjyMAnEKedxk456frOm0bOa1HVOaLLOx5hhIrlEpcpf6xAgPNij6 D2wl7VCUCIEeHdlliw/uvilUu29NvBCDHlZ3tBjXvL+jzms/08aUGEYdiyRdZi/ZGSUuvA1V Ajch48os7Fu8Qyj2v0F1qizECZvVKabG6rjUZmAwk8Mt7xDdHLQ9no3gsRz90ghBhxFhJuxi /ONBMtRpXrRjqRQqzjJDLLLTzvLu5T0jgT2kUeNwzhrFSPEXPD6PO4n8tYrQRXmoZ0ZZpy9y dzyswIC9mw4w4ve05REulm6NG11EcB4VGqmvfCTly3pcv9yi5l2nUrvIyXhUjw5fpeziuOw8 fGIlRW1GL/KTOdTSOkCcgPo8+sulx/PvjUVFZRiNBZujqRYpWhWrBBCWXl9XfP3ucr4Yp+jF nlAzo6kRqEaJ0uyTyRSn2uESzhU7OOztiZOklCxQhUFDMJy57xYeXdFwqS0Wg3UtiAmOcCOj 1ZR4i9n9XIPGUZCCa7JR+Vjsge9tC2pwiNSGECljUBlw747EdjKNe+N2SvcEbQqIzTNpuzC5 38OUpxYllsFH9KYEalyNTmYsSsKe7JnPhpPj3xx+exGjdGVAmXmrGhP/AAmecj9ZdP2JT14c I0sGIPiPYHxxbQDxASniKCYL2pS5xJ+RlVZYRgZx4BETUBFil6uXOG68XoHuuHp4bfqS5TM0 vEXg4+EXwuv6e835VJHdK5WxYDjsN8872Q+IYz+xwVpZ6Sz03TuwAcj3x2CEWH7AN/EM+6Kj VlKv1KmFAeyU5WZ2clQE3Xunh4RcaorlqXl0LsC93CoYScCkzDdMM/eBPhOcoLQHVkrwxuba VJxOucI1QrVhClAKU+U58L758Y9FTs/ZPKGqCGoYBizA4urFdP8AbOUv2x0NdDVO9luKltQA CnSqREYT1EgD05Sv7XyiVo8Hm3tAbHipxp9nCGYv0cokpH/dn/jKJ+l7SKVQFngWEuuAl4G6 oMKeQ8QxchcLvjxi7BW2+yK0tez9ME0wPZcIhYhHSloDtaRFKKJqcljbHjYytlcDy0pYs7sm i4SF3RrKP6QgCVDYDopUFtLLHt5fEYhCneHBrdd3/vjlrS1qmKwY0dPIG1ybjTnRMq6+6RBO EXx0l3wsQzWqKAq2mzEYHJAULajwpS8g7M60Xsz7ottH2YjJWVSTVrIoVKmVMWaQiJM0OmLv EH3ed18/CJT6RlfkHVWWyUlNPsTerC5dIJlGZnKZXXXT4SulEFS9q53TD6srPaj+miQFCE3B 1Iwe6G+Wnhwj1butIscdUbo2DpVtykrgEoIkhyi8ac0XG+fuy96d0NUHSVKvZbwwrGQ81a3k nBUvAVWgTw9kJQOF3d8JxOqbdWcBhXRTI67pZSIxQpuxmIQdqV1/bF8Yq1H1tQFKycXVtpt8 6VUFnlEFiOkJPljvw4p8sP4Z/GCExaBZ0gZKfRtrDSpqpUYSn/TG0famXXhEXfO6KHXFDOVH 7jkvaj1GZlGkJFGMxOZ3DDyi/qLbE2xhUoGRV00YnSpVebonyiJ37gpTxTv7p6RSLTakpapn M93ZGVemclx2etUqxS3e8JYZcuGsFueyemCawtIZ6bUnZCdQZMZ4v5sEsU5fOL/QdGML2z1T UiCkgOaguoS29IgVqBZSdNxEIUwzvxXcdbvCMwouoVlJVYhqFB61GKe790Wgvndwi6U3aWzt qOomo5kcOiHZx6QLCRhmYGeG7CLFK66MhI2gWOORNcLCab2ILR1g94z6tIIMQsXdLuvirOln qlkZ251fqha0u2JyluwEivU7MLmH2Zz+E4ubpbqBYoVYKSyErhmdJl7VOY1e7gJDMV2gA3Sn OUpcYqlYVsw1O3s+30qPpVtSEoMzO9H2cF89JcZi7r5wE06MNMOtn7PsbInYnJ0eiErUZ6sx Wj7I1A8c53Sx8+EXwyzqjPPg7UqmptFstN0+YoKLOUTuVnSuw54uUtdYzCvK5pKpNlOR0etS rU5hGE5QuxyJTFfYlgulLXT+9Hcotax2qP8AWwKeGFO/IBIFKTaOswilKV8hXXcAy5RvkHex tv8A7jlMh1l9O7QuIAtF1kzExKMOphoLvCU+M7oiW6gzbRXGsHujchC1N4p7IXs8wFCwhv3e Qb5BmK770L87qkFZm1CmYQBT9ATp9EiEonPJTcpjH7U/lCLN7WlNE0X5MeTxTnvGiJPEdgyc 2WEc8N07xd0+6IvQsS2jAE2X030JTbQ5qHZh29eadquvx3CML+6GU/GLfWlAU8jpurkxLC1J UrS0yUNxhYQ7WLCAHWDFixajnO/T5RmCe11YmpshtTMJQXBO29FFqxKMZYU053i6u7UXiK+H agtjXurG8JgMWQ5PSSSVarMWTGDL0kLLLu3b5Bl4R685srL9WAf3Y1f6PbCmePLJYNAiWLW9 ESFFtuHKJxi3hb27fdwnO+KZVD8gX0/TbI2oNlKZ00wnHCDKU1CgU7xi05eM9Y6rO62U0Z0m ACDpFI6BLCpKzsqe5qG4Uo52jWLRLHzqkqBpHTZzaQoUIk4lpaQuUibp9tQH2ZAlLxiIs/eG pkouplhzCyuNNsIjERa/ZcZ69WZfIueOfAHtaa9mIlRbrUOYDY2FqQEhyQiCEQpmHpyZXATm mdqYdZznddrFPUVmvU0g8UtsiUhE8OvSp+X7Jn6sMvdjoQvlHrEDrY/Uw1NNsGBrRFCITJi+ uLmEepho5708XHnpFko/yefqLYH6rEDAJIS7BCZshOWWm3ZzCSbwvFP4y0jLfOEMmlxMiClW VDtBZZS1SXferAHXelHUstOUnNZDUjpVlQtRamStQiDfMCk2QcO93Su93nAbqjphAsLYng5G ymu4mt0PLUlhDNOHellz03N0M/dnd3w68U81E2b+U6MDaJ3MIwFumWGYMMx3bm7d4S3Yw7zw PwFCXZmRqRtCVIYkLZycUiMA53jnPneKfGOgy2moRo+ijmRlNZQkllFte9lBkGd98xdoUxT7 V8484DfKgp5tQFsqlqJbUZrgpAJxU5csakGDQMr79MU+EsMeX7WEAE1rFXIECbCUlWi6ssOg Zc4sxlt9YKTMbqjanHCdmpgmYgATXcJAkG6Wl0VkitnIlHVecACpwqi7a1IuAQX3ilIPjyv0 jBaJotGSvrRgQKQZqdQ4kAMDyEGYuEel60YW14Z6pQPC/wBY6FFEZBf1SQhzkAIN2Ur53SDd HlprUnNrgjXox4VCMyRpIvEMX7zx1gDFsBLQ3DMMmaYYQTqIyd/Wb1+us56c4sX6g7PU1GOj sScsz30LCabn9uSIYhSkHDP35S46CuipfSATdZQoAelKlCAYRGBDqdPHdLxiuo7S6qTZQMaV UUWmmlEWeGc84E53zzJ8RznP3oaLr94HWiGql5Kc9Q2lzAkTF9WUX/jAVJYAabPAPdNLvCIP MM5R6js7bUxLXRAM7KK6FEISQJeigYsQpzFP5c748vLDhrFB6lTvGqjBGmfEXGLc12kVUgby kaY5L1JOQWeYTeaEvuviBP2gWesjDRbjVQBqhAXYOjiPEU94wXKQO6L+z+n2gWSKVICsfQah VuhuDiunrL4fOMVdK2qR4LXEuS/ainARQlJYg9rL7AZe6GXdKOxZaRVqlQhU7SlKGhDgIyyb tJ8b4sehGMCPyPXLNpzcnOwrxB37+8N984aUEpvNulHtIw7QWTmKfbM377r5ctNN6MC85dYD MD6eVlBDMGzBJuI3uO5znDXnIrDbBKekihDMu3REymWHDwwh5QFitwbVK+1zopqTDPN6MKHh L8A3znOMwM9z72H9sWFHWD2mdHN12nNcHAnKMPO+zl92XCV3KK9ED1GoAj6QVEjzTctnCARI eF0gh5e9r3RlNplKtVJM4VLamN29QrL8dil3T7xziseXlW5YSemBgw3bxYbhiu758Y4fKF43 fTxiyzs8IRcMc+M4DdVAP/dg9SpxlZdMFdZ4/d8Ynab8ngGUepOOAU6mCF0cE8N5l4hXCnx/ bHnYys6nOcNvG6j2jDh8Lu66Obyke+nCnvpI3pAn1B36nuw910BJ21//ACxUX9PFNh9wUnLF hqlSdmqDN4wwXtQxAPwQmFRAXGjuA8mg2wHvXxnEaLUn/L7SD+bjCdbMDAAiyU3jG1qgA92K xFio87Bmk/rAxvIhCKPWChuH1n1gUMRYIdhqHYBEOwFgxqAg+9FhqxnQNWw7Gs2oZxeIzhu/ l/jAS1L0MB7Z+klLrsoMzAEJafN/xiJqikntkeBIBoFCr9WcWTO4UXqyeqkDaxnoDnhO2KMz EHP4Cl8bpxcHC0Kj+x08UaPshOLLn1fjKAysug146HVVD6QUaT/FhJ9TPhHcjsxUnN7cpOch pdsFLMLMT6l3xonlnRh1J5PlOnxll4csQRXin8LoHStqJORo1IKkKEMJhXU5YsZd3y5QGZVh Z0vZ8jocah6AcLDup8A/yhTPQGNjWOT2c5Nmx+sILS4x/lONP84VEkuBWN7KWDMv67LFgLl3 d8V5ZWDapqQOCtim4okOH0Yk2RArp+M53zn4xYplF0H5VbcMBy0hInLmIs8xP2tOEV5Owup3 XbAaFLnYM/lG8I7RaDHthPTexgxfqRXHacZRGN9Z2dJqLPbQOWUaLF1eyz6y/nwiBSqws0JY afG6png08ZIZCOLOLlKWvuz5xnUbTWlbUq5UGegJddsNMICUSmyxXlz4X690ZvUDayIKfbBo FmetODLODmY/j8OUWJiz+iU1To1SxYvVEFJf5MGUx6/GGqwoB4ZFBHRqZa5olBchBMy9Q3+z O6JixusG2ntuRuS8SHaPVnZcxy+GkX5ZavR4C8HSqpYboDdTzwX8zQ3xAzdjs0Xr6XdXVeBa 3GoQiEWTp1l37fyjqZ7LhrKHRvaxSqQqlCkkGSK67ALnfF+T2l0B5LnoDn5WEZYRgLzEorzs XOGHC0uhlNJowdJKBKicj0bZxX7v7IsU2vLKxs6cI6eG4Ljc/Z8k8MpYvvB8IKPsuGcW5nVa S5IxoS8ZZCQQZjO+HHXw4xfPPBRiNwKO29a4jOOzRC2f6oCcrrtf8IrdSVzTDxVCUfla5I0S cvdOQIcosueKQuHtTn3xpYhAWb2deWFSLCdjd25oTlz65TcA0sfIM5TjppOz2knss1tA/OvS /WiFhD1BOH3pzDGgt9s1AbQqJUqXBKlDhy1OyzntEwy44eOsU9vqSy4mm3hH5QvSMbkrmoOy 0OMZwf1V/uz7pwjoD6ixlqA1qsCx32pO3TV7XilkGTDK/DKXjyjPKspUlvoenqnRnGmonYOA ws3thN/yjWTLY6V8n9xY65vRgkQWwRM+M5SDKYp34dOcZXVlTplln9N0YgAPKa+uPPMDd1s+ UvDxj0UrAAHYhcEEc6xBBBAI7HYhcEEAQQQQBBBBAEEEEAQQQQBBBBAEEEEAQQQQBBBBAEIh cEAiFwiFwBBBBAEEEEAQQQQBBBBAEEEEAqCD7PHv4PwzhWD7gw/iDdANwQqFYBj7BJpv4Qzn AJhMOYIT9nj9jFhxeMAmCHzExxJeccmUFFe8IucpQYB7o8G4ZvB+9ANQmFQ+jQL1n1NGoVYe 1llznAcMEKUAGAwQB7ow9oMJgH4IIIgOxplSABs6EHukS/dGap/WBjSKsO2ZYlB/MA/dHJ1C 2TGR2M+4ojmMh9vAMajADtx3IKcPrEc0PrNwzfhiAIdhqHYCVptkOe3QpASPKGZ7UW6pLMTm dOqObXIbtsosKgsKW78tZ3xW6LdSWepEa9SPCAsyWIUehlFotNjMNOOqpoyjPVhJ4/PSC3nu m6Ycnt0KQbAtKzPtBJZzwxYm+zReprRZT2cMIEv8b2fc+Hd+2NRR1/R/SgR+UicgrCIAQ4Z3 a8+EOo6zowDosB5Tpeuu6zW7SCGbl2SnDRiOG9+lYhBLLCl03e8V+kVZro9+UrAAOalqNKIz BtYk88HyjbG+vKSJLPJ8p04U4VAhiLwi66Xhpzhh4tFps6n/ANDvbehHl4PVmzPL8Qy7MBkN YUqmYXTodApcHZw/V7HcD5TlEZ5MVPtAUfk25Zot4JeTGytdc0wgZwgdat6YUZkssWWKYyfj DDHWFNs9SHqVNYdLJ1QTMsIgjy09/wC2LGQ+TFTjUCR+Tblml9oOT2Y4TCTgKNmUgGUaEWEQ RcQzjcXSvKeck6pq8p0qEYi8JKtMSbIAfhfrGMPGDpk3A5CdQYpelmBumddEDQE9koDk5GB4 VdIKE20BLCnll/DFxis0vQb26vmwLEChsAEWE48Rca7TdqNNks7cBTU+x7ORgNTZIsd/hdKG 1FqNGHZXp6gOWIIsWz+un4wFd8yZO0f8wrdlCEQjMSeWbu90ucJ80tPEp0axTVq0opYHqCNn ln38Pyl3xcjLV6MJWBwPYzxmXi2kJIrk/dLXXjrCTK/s6X5G31ViWpy5hCp2McytflHQhnae y4naKkJHUmI1lCIYSwky3rpX3X3wwx2dJlNnZFVOrqqRmqjiyiCwp75b3Oc+UTtFv1GM7pUm 2VhtRS4gRW0iRiBNQIUtRXa8++ccZlZsgLJyKb6bNVKiVZIsvLF1hILtNeXOMlppRYUj3QJn 5wCMJhYThGFhwGYv1c+cRiey6m1lceTZK+oiN00OJSSEGKYOcu8PjFzMtjo8BZB22LVRuIGF Nki9Eu4+H5QKLV6GHUDcd02tPAWZM8w8SUXUyuukV3zj1DAqoZHWm3g1teEwyDQ35fPEDv00 h9vpWp3JOUsbWc1UnOFhLMDdFmt0q1nq2oG4bDtBqVvIEVnHF4MyYp36S7om7K7SGGj6TEzq RuG1KD8Rgiw3yTlYbp4PHwh9rcBlmOwWTm1g99LlOAleypkhBchyv4b3O6+/8oqlQUHVtPMZ Dw9tQEqU67+MBGMN/eGWsoudQWhM6yyPyYRuTl0h0tJaSHLullX8J8pd8P2gVzTdW0eUyE7Q 51IoEThPPT5OTd7w+E7r48QqljdKttZ1x0C5HKCACTGmhMJ43hl4w75pbRx1AsZ0FKqFg0+/ iLFK7L5a8L/CJqzMk6zGtEtVVgNOU3hJGV6EqAoNvFd7IZ3xoJn0jWdtMVDphG4GjyAJ0xh4 cvM1vFOd092Uvn8I0sGNea6v9oc0w2HKUNZOepJEoljwc7pc7vCGE9nVZnUn5VAaihNWRtGI KiWPLlxnh46Rvpn0j6KPTrBnNTuUtOT5ZhhRH1oV12uugJRWjK2QUf8ARzYkDVsq51XEqUgi do30ic2faGAPP4y+cLBmtB2bvT26UoN1RqEbHUCnAFSHt4ZaznKXjwlOd0vGL1WFif8Awesd aVZFqFajczU+QtUX7QmDf1sr5S7uXynFWpe1qoW3yUQL8B7VTog4Qh9acEPZlP8ADyu18Y0N RbxSQC9xNUTwPaxLyc4OUAs7DcAvjOeC+PRQ6ToNqTKEKOvCVond2yRNjYkF9kOd2aaKXZw8 4HSxx7OeH8dMDb+gEKsxOmOXqpFDOwylikHvu4XxZ261mhzKxWVk6pn9LUqxvCjMXkEhGFOO ehhicAp7s8OgL5z+EQTpXlnrrRhtJL22ogtSVzMcG4JYQZpwxSulnT0DK++8WGV8ZDIzNzF/ N34vlF1tEphHStB0ad611qJNt5h2Lqyy77pBuim9vFuYACv6sPsy7otdaVUmqqh6bZFKM0Lk wl7KWf8AZbN//q+IWstUWWuR1dsdLU2jKKOXMRbl6Wo9ZfxnfrEJUFl1YMLG4vawlF0ehKKN EeWdoZmCwhw+9r3RcFlsjP5y6ZrBAzuAiWFi6KyTtBmDwzDKfGem9Dplt6NS7pukqYGupsLS FAtbjhaqDATmIJnPdvnwnOLQrpdi1cnGLAfo/NRpC1RhOZOc7hBxcZSu0lxiMY6ebVP0f6pr MeLpVC7J0hHuBLFx+caVT/0kNma3ED8wqlipUYdkCIMlIsksYcEgzlpfhlpKMuaqrRoLJKko HYFAumHEtWSfi0JkDhIUBIrLP16qh6COZEZInKp1Myc2Z3aFfzl7AZSuviT+kBQzZQyOi0yD IErVIjukFJIpzAoNAK68N/K+Gmy09M10xQLWjZ1AlVJLDFgjTBXANx9qUpS/0jltnr9qtC8n iUbOqbCmnFmGHivmLMHiHpKNVs6i92P0wCpPK4YySjxtLKarLCYZd2ZX3/e7ohbQHhqe6k2l hR7G2lkBIJDl5eK72sMSdldbE0N5TY2obiN8azG0PWYJFyFxmLv1ujISNP2OVO90OjqdG5Nv pxBhxCTXOFIvtz+AecJ80VSeUFQsgFKUShhQFKj8IRTxTH9mCUr5zn8JX+ESdJ2zKaeoNDSR LCAWxtyxEFTndqagV8zLuG7+cCO2x+Rp2TYGpOQ4IRE9Jr8zrXUBU9woXPDL48YIRNollz3Q DxSyZ7OKNTvR5Yd0OCeggyMlMM9ZcYtNQUYz/wDq/FQ6NAV0QE4AS0ghTweokPWf4teMQtrF q/l+sp47ye6KAwqZnkl7RmZmIchiv4ainKGj7Uc63uVrnQXW4sewbRzyssO/Ba7/AEdLLkr3 XDu91OBAeykuCxsTIsufWqAhxXylLsBCHvnGAdsw3+kF++Ngs3t1OozpH/hUpdtTie4EekYN nMODhnfpr+yKHS9Qo2RrqYnYM1a9ByiRYZTAnLnixX368+XdGgqxnqxxsVSWdbe6WV02gUok PlA1zN2kkPa54h38ZzjHcHV5P3cMaeZa0p6coh4R08nKHRqKaVIWYonPaNLpY5yu4eERGJGq LDV7IjXLwVIBcnTthyorCnumoGXOcpylLuvlpPWJGj/o9vD90TjeMopcylOGYWTKZYTDewTM U7pX3a84gjLaakG8MrkNAiEBrJNIEg1yFcjJ4p5kvj8/GJGm/pA1mzrHFYNG3uahYp2gjPvw INzLwlBlwlIOko8QjLM2FH5D2uqXIko9ayoglJjP1Y8YgzmH8o52+ldp+jWQ9ptn21dUoG/F 9pvSlhDMXCUufDnEQx10sZ2ur20lAnNBVlwVYhfY6zFu/OfOFN9eLEFm6Wg0yBPsqV0C67WI U8wRweGnLTSNVtGt4olpoOxhjZ0xwFq9O+iJWr8nAMweXiFLnPDL5X3RheAe6PAPAZ2d3tfC NBtUtXeLQqbIYXJnQICiVM1WcTfMYjJ8Z935RW6wqHp7owAEw0qVtTbOSWIV8/Gf7IyGh2Bs iZTZ/Xz36IU5JRJU6RSpLxyTyHPfwynfLFOWkp3Ti62kWPttSVYlXoHjY9nTJxPGWT1ZZeC/ FKXtDF3XxidD1sspVvc20CBK4t7oIA1KZTfdeHhwif8APTWY1BB3oXUnTNw4fWbuAIRfdCHh dGofp8DUP6NlphiVIVjJdkQCFpmp4ihHS0v+HdG90/RjCOqD2E4Dee0EtKfC14b9bpYhC+N+ u9P4R5lb6/XoKLdqVJamrZ3hTtSs8Qd/M8A9m6XKV0TfnprDeGj6PSrTsAT1ZeLOOkDhK/uj IejaXpVncnioulQInESVXiTEBDcWklrg5S5S1jFrfCSfNWyrNpKWKjn40rOCXdO6V+nLTu0l Fb881Wk/UEzahAI6Z6kJIZ+kjn78+PPldrEA6VsvdXBqGsTJ+j2k+aohsT3gKzJzvEL4inxi ChWliY5Go2ZSSMo0PaLFxje7F21N5u6RHtIEpq50OEf3qJSndIM/D8owyoHVS9vip1WetOu8 cMpaSl8pROU3aE/MLWlQINi9BxCSGHF4xp5ivvmHlzixptoFmLD+nazzlYUQQnCCmDpnH33X S90AfhrHMxo0zrZvZISpTFYFD8Zmh+4HTXXnGfLLRaqWFnkqVgMChNspgcOmHv8AxT75wecK oei2xtJ2UhO1ixpssOoRd9/jEDfXCnmR+R1EB7cgGohOgcWYHLkSEM9Cg8O67S6UZp9KwkBN aMQCSSggMbA5JZIfy4flFGqStn6oW8ptXjThRBOz8kkOCRhnOYvjCHStnh4qhDUjxlKlTfcE gPAFweEBCuCBY2rBI15IyFBfaLFxDHoKx8lACzujQDHlbY4mjEEP2m9LjO/h+yPP745KXh0P clg8ShQLEL/CUvCUTDPXlSMiMpG2qQBAT6oQi7xk38wz5QDVqmDzmVJgwhBtoghCHhpFZgMG MZghjHiGYLEIQuIpzggFw7CIXEDpa/4QI/pJRea4BjdDQfzYcP5RTaf/AIYR/wBNKLhaYsJB UGD3Qyjnk91s1UesjsY/4QKjnWesgbvrAY6EJSpAemRDxOVJ6yIWPIwmHYRC40Co7C2pf/0p bve6nnDCfcMDv5X3o25rramwNaNMN+AE0Jcs47DPlygKK+WdL21GznYzTxuBkgCJ2OeMv5cY sHmcGBwCmWP2QVkZu6jvHf8Ahvi/Olf0TtCFYCp0puE6QsIQi3fHhA4V5RPTgTgVUnFiJEHO wj3e7lAYw+UM/IHjY0DaqdisvHnkp53XePdEm6UAgZ6XSvbq9uAVCq4IUxLffhn3TnfGsl2l 0T16Yl4S5uGWI88s3Add+GK6x1yydKKljrW2el1xJNnFcZ+EPdFig+b1YCz82rR7UHCLq0wk 92dKfdOOOl6GdXV0So3IlQylKN7MMJ5eEbA8V/Z68Unsw3sAd3DsQiRd/Cel0KeLSLPRp2nZ nj6uIIsOyi6mIGRWkUYCktlyV41idV2c4vLHp4RT41S1R+puqlDYmJeNs6/Gcp7GWD3d6KLV iZnRvGzMinPThDvCxY9fj8IsXem7K0Dkzo1il7cAqFnqSyE4Zlh+M56xUnCj6nRvB6DoRwPy RT6wsvtSlzjUbP7S2RtpNG2qX7o4aftE5Ip4peF2kSbha1RikvJ29wwC3hHbPrpPQMR8DP3y y5e20+yryekDVrgeEBqTLleTfx8dPGLJ5kEYHhKjWPbgAAkG0HFllhzMcvZl3xa3S1qgP0cs JdVRpoTgjEXsouru+MIcLV6D6cIUkvCoXUDAYfsot3FF6DK6ksuqRG+CQU8gVOycJOaIwVwJ k+AuV8SjhZu2s9BkPzkTU57go3clIXIZacX3tL8OnGNDT2zUT16Mk40rCEIdtOQzMzhS54f3 XzisUvaRTyN8XPzxVT6qzBDwoNn6s7F92Wko1Qg2uyvOs3HVTwsWtPXgy8QZXCKnz74n2+xm lXtOQpaqkddlzso8RwQ3mXccGkStSWqUBUNDjbVil3SqDsIMkKW/Lliv48IY85dnra4M6ltd Xc8DaHAQmChwSL01MmLjMU7/AAgKzVlmNNtRjOpAsfUqVctkky1OEZl4uE9Jf774zyvGEdK1 g408cPHsot0XhPhGrWgWl0rUPQ6bb3VcBG4hXnHmJ7suQPswyFOd85/L4xltpFQ+WFcOdSbN kAVC6kvmEuXDF4x5WK9BBBGCzWAEOwmFQBCNzt+3C4IAggggCCCFwCIIIIAggggCEwqCAIII IBMKgggCCCFwCIIMYPeDBue+D+1AJghUJgCCCFQCYIVBAJhUEEAmCFQmAIIIVAJhUEEAQQuP mCAbhULhEAQQrAPLzsk3B+sy53fnH2ARBDuAe0ZOAYje1lhDO+FbMp2jJ2NVm4cWHJnAMQmO ktMsOxAJRqhDL9YHJnuwxAcsOlwmHC4BcLggiBL0fv1Q3f00dlpA/wDihV8gwWd/82If6TFD VaE51QLDvvRz/a1edPWQ0n9YCO589ZEZHQhYqg+rlfhiCiacN9rKiFjyMELhELjQOYMcaGx2 Y7e1lHDfsKhQHEWQFLfL+1fGflxtlD1+yJqfRplNSJ27J9cWYTOY/ldKAygynntMsNTdCLcR YsOIKee94xaags0XtqNnGAag81wMkEwnY9Se/TjpGlLLUaMO6kD2MPtZmzzjvcLS6AGoRqfK QBuEyQvq4939kBSPMn+kAplNSDIK2bN3Uspjv7rr4qNQWevyB8EgbUC11TlhxZ4Sez8Y2VRa RQHTgDian7RIgCOyR3Bv4coC7V6DBnpgOoA7svSTko550/hL9l84DMHiz1tZ6XSvDk5PRqpV 2SCEMpyLH3T53eMPs9lClfSZT2cvVIRnHFhyzE8uxPnFmp+vKbJcFjq8VstWZgp+gbKLAK/u lwlE6stRoNTT4f0waFRphTbKK8Ov5QFbb7CkC/PyaqXlARiwqRGJQ734Jc4odplGE0YoRgTL FCpOqDPDnlyAZp4RtjfbNR6As3aX5Us2jslhSzuT/OMptoqphqTYAM6k1cMm8RikwvB/VlG4 coezdtfqf6YcnJyDiOkUWSiLlPjznfEe+Wb1IgqzodMgUHpRC6tXh9jvnFmsntCZKepsTUve FDSPOkMIiSZjxSl8ItbhbNQx2IkA3cQDN0w7J1DLwiPgQ/mNbRt5WTULkFR1YjzDCw5evIEC yxmkkydUpOqF9Qp0IsJgjCwz2j8EpS+UTfnjolMnKGSNyPNCGQAptn0L8Zz/AMoFFqlm68s9 M8OTusTqjAjy9j0T3cuOsI0KYZZXTw6wZ21NU7gUkdE0zyQmFhmdx+UvzjspeyJkUluI3Jyd RGluM0SYJN3yEK8P+kNeVtAAtQKqoD8+KgdoWchukXwwlAlLXDHZTdpFJM9ULnXp6oiijj5n 5JKXQ6/Wcpyv7+E740WgPNi2+S9RLOnlRq1pXyS5YS5Xazl/vnF1MsBp44solG8O+0F5O0ni EGZYsXHBpFbR15Rnk3VoF43UpVUC/asgtPjwy0w3i7+/jFip+2mm6epcKAlTUjwqMMAIRasu WWmlLjgFGSGc2wUqyUq6BRsiaoisIsIjHO7LO+8AUv8AekVljph+fk56lnQbUUnuCZvSlrPh Lx+UaHbZaXT1W02UzsJLkIYlu2nnrS8GXd9mDWd8RNi9fttAGOK9SmVLFqgMiiCy/VhlzFPx j2taYoOx/Gz1W61sS4EDYyJ4UiIwM5inhvvn+HnKWsUjze1b5NhqQaBOlQGF55ecqlIwRXfI HGcaD50aV8n66RgA+/8AEQcJAcPtT4iHO/8AffHOz2l0qTZf5MOSB1eHXZNkILPLDs4b75Sn mdqQZX6y8I8QydnbVj26JW1qTDVLVQpBIJD7V8XV4sWtOZ1CADpTxSPblMkpGJUGeIc/hw+c SFm7Ops9qBprl4fqbPTt9xuzJnCRirwlly5xprf9KVGpzfKGm1QhiUiNTCIuvSEz4XX8RwWx tHZLX6yoHNkJaku1tYpbQExVIHH4xUXxtWMjgual4MpahFgOL8Y9L0XapSS+pK8rxSApCAxs LKTNzmowDVnF6hDprO/SXHnwjFuh3K0VY7VgvqSlWVQ5KJiEmWrMofDkG7hLhBCx2gWV4LK6 brakgbhzWJW5lnnXmaT7Upd0o46gs3zqfstJpJMapeqsSHKD8wzc3Zy/shDKf92LK82v08gs qlQbO2rVzqW2CaBOJm6kEAXbMBz+ERbPa6gbS7OcDIqEqo0k0kwzFodIyVwsP+5fGC0V5kK8 G4EEk9CiSmJhKNv2r0fAGd096790TlB2S9N0vW7bgSuNVN5iQDYemVej9ZPXulw7/wAolvPv T2weTRNMOQaYE3KUR2IXpnXixCul2dOGt98Q9mdsFPWddPgp6lVuU7CIAWEwy+ZaYuU5TmKd +por/CUoIVkuyKrei1i9SsZSAJTjSi8w6d6vL0EYXp2b9L53QxSdmlQurHTlTrEw0bA8PRDb mfa5YxXCNDLulrrOLsz20021M7mjBR7gLaBH7MiEolNKEJnCQ9PzulGfs9oVVIEbE1DX57Uz uIHAtJ7xgZ33X90BudeWDs51Jvo6bp5KwLW1xyUSgxYMc1JQdJ48zhi8OcZWx0T5K1QxIK5p tO+uD4TjTNgl2zlp7xYcRw5cO/ui9GfSKZPTBk0MtVKFynbT9pVSLlnBnOZctyV8wynP8opj 5adTdTviF4rOjDXNUSi2c88lRcMwy++Uwy4SCHhKU8UQJa0Cxb/iyoljIvaqbpVGpKSkCcTL sR4ipCwh+em9OMVUAyTDQdrLFMOIPAV3OUbVVFuSCrW9zbaqonbEChaFWiIKVTlhGAvLLzBf vw3RjCgecYaPAUVmCmLJL0AXf7MvCUWtrbfZ6yGMdkqNYDGqrVxmerUh4lkgFIOUHW7W/ujR awsTZ3Wk6h6EZGimXBteJkIDAnTHnJgy0kK++eMXy1jG2u09YjY6SQDbilKilFslLepEK7q7 75l6d/fF3/8AUOAlQec20YP0hSNeZtKy/wBLn2BB3dAhvvujVDqszslTM/SJNZtrU/1Psic1 MxmKNE2MW/mXXSxyBrxndKcT5lH2XM9sFRUeCkilmy+lOKtT6huS7PIzq5SnqK+d2t0ZsotX bXWoEb3VVDFOyhOmCAwwtZMsZxwZ3yNv/wANdIlvPqgWdPnVDZ6BxNflJapWItwEVmSLDIJJ I5ylfMAcMp3SugLdT9ndnp1m+2IGFPgWU8vdU5ynVeIYJ7t0uQA+Etb+MRKajbOqYouyfykQ Np/lEYBa5qz1GuDQV18uAJSmAM9ZSit+e9T5Jiak1NlEOXRw2wtaFR1ZaUztykVzF7s533RW anrxM/NdENo6YK2SkiNnyzjsW2y0xYrrrsV0WNsR0A21PaptI6TpDyOCStUNImm65XMEpZWc L+9PDpFk829DgpNnfh0xTZtWLiiyiE27JILrgyNMkDFdoDneK6McT29jbdhTMNEomxlSlnhE 3BUesz7sd07sIZfKGFFtiZSYhJU0AlPaG0nKQIhOA7y96Q5iGPiKYhS3ohCbtbsdaUFcVG7H PySkqa6RLRNheTmYjpp5GDld9nK++6+MHwekGgB1uEU94PAUpe1GsLLcl7wjXpqwo9qqTaF+ 3EZ5k5FpjbsMt2XG6X7Ip9N1b0JSdVtuxgNcKkuAYdlyyySdZzu+c9JcJRk2U9RuJxRuNUWU dJWiUHRjapRIelqcCtCaQXp2ZznOeKes54ZzjDsHV5Mauotpex1xTdYJmRvSqqdbJtiInMnP EXhmCUxT8JTnCMdlX2FL2Gm3N+BUYF6cltJVJCwJesUTMHg+EpSuv9qJ1n+jY6uToemA/bhL YUoz8mUi9pHLFk3+EvGfjhisee+qvKxufhoG0XR7d0aFALFs5xfGUxy4znfrHfTf0hK5Zy1W cmb3Y1QeNQWeffLZpjlcLBIOktNPhBCHoNtQHfRotRezkxQ16daiJIP5lhmbK+Uvzjp8iRut iFm8moaUC2oH8aTMw3D44ZYhX8A/CUVRnrNe00JUlGEpkokVRKJHqThdsuYfclwiRT2nPaOl 6Wp5AjREJ6XW7akO1zDDed/dxnwgtefpQUq1UZZ/ZqyNuAY04lydSrycqakwAgyEKcuPanO6 +MPMJGDDjAMOYHGXiDdil3yi+WsWnOtpaNqRurU2tyVrOEaEKK+8Ux9ue93/AL4h7TKtOraq OmzkYEYC0xaRMQHXCUDhfPnOIFh+jmzkvFYPWPBjR0+qUE4g34Zyl2g+Mo77K7HCats/Rvw3 5QQoWbWElOEMruplOc5znr+6KZZ/Wa+iVjisakyU1Q4IhIDBKL+rKF2rpS/xiTpe06p6bptL TzVsoUqUs8BIhBvGHP8AWT7ufdFiz+ZkHlAag6YVGpU9MdIbSEuUs5VOeGRIePO7viKtssoH Z7RdLLzl4jVroLJVkCuvJMDdOctL++6I0u1GsyabbqeA64UredI4Jgb886cp3yCYLmGUFoFp dQ1y3oW17A3hSt52eQWmLu3+fHv5xAvFrDIg/wDVRS1PAJKIS5DeUIvlrxv1/wAYsVl9Bt6m 3uqateFIxpWOoejUyYJcutOFeGV990gBDLhGQuFor85WiIa/WARGu6EIQlBwzkXudm/nEnTd sFYU88Obwj6PNUOSkSszOL3AmildOYZS4aRYrNSJjnK0ipkyBMI0XSSsWWSX2QBF4S4SlEEn BtKhKT7Bx5QPzFKLIz1gvallROQAAE5PgZhMP4SJxTvFcH90VtP1OUMHbJFIYReMogeyakZG Q5RVzIpOym8luJAWSSn1Jvulu+8Kc/jGD1pZ6gs9dKZJxiXOCx03k5mpZBN8pBLGL2hz8OEc PnjrYBm0pjkSZRpnGFl6nYezi8JcYhPLyoRqGw444pUNrOEoTZgftRainOA3lwJR+eS15fuI 9hTICUxgS/U4ghvwy7/l8os1QIEaal245Mp2MawSfPVlk3mqAXTn8f2x5vMtRqo50XOR2xGm uF20l5PViu8Id87tc7YJYNenPNzMZeYXoTOUrpYA8A3eEB6cqhtQI6oYEBOBGUcZMQiQ/beM 5x4/qRGpWPlTL0yYWxI3E2RhgQ7hes7omvOjWwP/ALIraNfSRF9aXi44e6IDyhWApMVNk7qc 46Z55n2h058vhpAQEOw1DsA7BBBECw0P/DGP3S5xwLPWC3/aiRoMnOcDf6GBY2jzBb8Z/Yiq gB2YhIsVQA9HDFdi4xNm/wAFhiJh3aR5eD2Iaj0ELhELiwqFFwmAuA1ZjsrJXtaU7pVaJUqD iLLJTyyw/GcVIyj6qJdDUHQK0WWLDmBL/bGqUPacwo6bRo1lSDQ7P2k4U85zF+USay12jFPU 7Y4FFdvFk6inLvgKHUFlDkg6CATtRqhyMlnk5cvR+/8ALxid8yCYDxsyl+W4ApseEkkMx3xa 1lrVAbQhUkvCs0eKQjPRRdX3w0otXoPpzGS8LcrJmAR+yi+OkBlb5ZjU6Z8PRtSA1clT3Yjx CCDDfyn4/CJGoLPUbJTaVeMmolzgcHskFyyyTO4Wl8aH55qMyz0xKk1Luyy1JjfmmGC96QeH w14xXabtFphAsVPC9+elygWLCiETua/lAVd0s3UttnZVQj2gLgcYWEtMZddcL9sIpOzFeveC kdQ5rcUYTnhyRBHMX75Rfny1egHJjKAp6QNNxBFkbPpfKcd75bTQyx0QnE9KhAT2vRfV8rg6 wGQ2oUkmpJwRkpjjRAVFzHlndsN3fdFSLjSK8qSlatqBpB6R0UjDPMPUhy5iv+F+kUqqBtXl Aq6BB+j8Usnjvd/HWNKxrLHYy2r29u33c1asTZ2filIgufdw/wAYoCygKnbVBvTaPY0Sc4JR ynFKeG+d2neLwjTaTtjptAzoQORz7moyMGyJi+rM7tb5fujhry1SmKqZws+wO6VOWZIRfOfj OceALscp7y0Rtu3u6xEJpEt6u7MOHLhwl/rEqj+j2jXvDcdtLgztBhEzTwnCxmhnfpLW6+G/ O7R5L42L03TvoqCaAwzZ5boe+W9rP8o7C/pDgQPDSS2nOvQSXeWmKEoZqFE7/ZlfpKUvG+Az 6m6AanuoKwYSTlQVTSI0SQRgtMAJX6+M4zCNYT2ltSCtKwrBAgcDVT5mBSEnXAkXIXvXd0ZP gH7e+P2ogEJhUJgCCCCARgB7gP7MLgggPm57cJMwD7YAChcEAQQQQBBBCoBMEEEAQQQQBCIX BAIhcEEAQR87Hbg7fYgPsEEKgEwQQQBBDWcT78PwCYIRnE+/BnE/7DOAXBHzdhOMH393+bn/ AJQBC4RjB9//ALc/8oV2/f3vuzgEwQuCARC4+fgJNNw9rLLnP90fYAghX8XCdkm5QuyLLndA YAZJhQDiVARmerCIkV4v2QDULhwwkYDMAwDKH7pgboUnTKVP1ZGqPw9rJJmOQfygGYRD5ZKk 4sQwI1eAvdMFkzuD8Ya/i+0gxiKxSBiwzuvFwgPsEPKEC9MXjUoFRAPeMLnKUMwBBDyNGsWb iNGoVYe1kl3w2YSMkwQDgDKGHtBFpMMA1CDI6tjUjTmqckezk+sMw6Bv8YSYmO2MKzJHs4t0 JnIUBxw7DUPwC4VCYIgW+zdSSjULlIyc3Cm7MRig44Zghw/S31Nd/Ry/fC3Abbs+SmxiUe9H P9rRzh1zXjiuxP5xPQeDHvxARvGg6WDHBEiz4Ms0H3Y4DI0CYXCIXAOxcbP6MTVDnnLDluAv 7FJ2/wBsU6L3ZnWCOm88ClSoS532xIb5hgHass0fm1QV0O2qliU4P2l2MufdEsz2Vrx0m4ur wStRqiQzyCMQesnLw48YtfnmpslPkpul1Q+yI8wv/WFJ7YKJ6HNRjA9Zu9lhyb+PfOArzXY/ jpNGseFi1CqUCKxF7s90X+MKryx85BkApJM4KjTDsrJVmS3vvX6XSlE6otgpIbOQTszqJUXh +xldu+N8P+e+m0xnUoHA/OFiPMOJl1el27K/X9kBWafsl/Q65ZUiNwNVE+pIRHSwCu8Y56Ds x6eMcVjq2uTO3k4skJh2vDS/nOOp8tCph7qQpe6qanEnT7xYSywA1vv0AG6V3KLIXbfTB22b e1O4QdknLLlPF8dZQFRp+z2nnum1Q0HTQVScM8SlQLq8Wt0gh5/thuuLNE1H2bpXs5eoVOpg iswv7MuQocp+v6Yp4tYpakDuJyOx5ITsOSHFfdf33fCCqLVzqhsv8mHXalLkI4I87JCWWG7l pCMRVkdGNtYOB4HLbTQJyxCyU2kzJylE/XljjkjLQqaYZxhCoD1yY9ReMv8AxirWV1gTR7ga cpJUCAcXgxEduNG8/DUjLCSgZHU0YeyepFLHr8IBVP2JsnReB42gTli9JMCo6tP+GUuM4k09 iFGZeBSS5bOFNM0xxzp36cgh7MQae2lhJ/8A+bcMYTpmkl5ksAhXe1P/AEhwu3JqHlKV7I6n qgl4MksUpEb3HxgI+rKDs9JZ25ej6XbClC8pOX1mYeoLnxFdw0/fEJWFm4/OoGj6P7IkG1ek inP46yh+uK/oyoTEYyWF6IGlywl4jpZZJcp4hYQc5zndxiyI7dWFtrjykR0q4fUtl6w6WZdf fLW7hANsdlbajpNz6Vp5O+1OnU5GQY4TKAWH3pXTl+UWaj7CqbXtbOBZTY9ocLxL1IlQpbJP XQsPCfzjPvOjSo64VVgspJwEqEZmkFhVdkUpXS1ifT/SEJ2xK6r6YUHuCMwRpBZarAReL3tP 3QDf0gLK2ehmvJYaSNyiQ4ulhLswYviDu+XIUZNRdKuVWugkDUNPmhJmb1wrtJcpd85xpFoF uXlVS7mgBT2yuTwXIC1WYdeDBffOQAfuvnFAsvqcmiakKfuiukzU5MwEFiMukEU5aCn8Isaf ZBYUcorvo2vAEDAW2jWmIi1WGeOWgSxz/bO6cVBvsrcqhTuNSIzm1iaNrMKQJjBTMmLD3Xcu V89L4sKO3LBVHlIspjPWibjkpnpF2YYZK7F4Sl3SiHsvtUJoZjVIAU2auzjBDCWJZgI3uQpc 5XwjQzAsGNRkg9ozKCLlffdGlVhYbVtNt6VYNe3rM44koQSAinl5nD5+EQCNkptT+mHWv0SN Ucp2g5EShFPDPFfdfwjY7SPpAgBUDACjMpc0N5JY1pmXljUHBldKWIUr7pcdLohajuFgNZo6 0HTw17eEotsm4GLRX3YZTuulLjMV/CUSKP6NlYHLDwHPzaUUXlBCYEsRmcIcr5SlKXD5ziYT 23pqkrQK97JKptvCgEkEHVTtAJivwj01v5+Md9UfSNTEvB6ZkalTm1BLJwn7QJFM40qUtdN6 RXhfK+UdCHn2oG1Sw1A4siz603qZpTMPvS0i+VJY+5U9T6V1cn4oJosoZ6YlPOciSxfzmusu crogk6ClXjbHuoa26HcFh5igxAQ3zOw3/e75xZKgtdOX2d+RKNkAQVlhKMVnqJmzEEN2sgT0 lMV2vGAmrZ7MWcm2enqJoY7cXNYDTAkkzMy7pT6yfG+YsM58vZiYs4scbWq3R2o+tV6dYEll NVpicntX/ad27K/2r4gC7eHImpGl+BSrbtrei2Q48QutVl3XYb/ZBLulHGstveFNqhVoXQiU hUFum37MWZplT+PCMgxZZYg8VzTZ9QkveU37eNIiFsuOajBKYswXCQAXS4znGamJjgOgmrcN UBV7Ju8BGYsPHujVmO29e1U+uZAUq27AoUzVEpiThElEjnynhumLx74p7WjonZwvDlWbgF6z tqEiIb7y82++7FGotz/YbsFWIaMQVyiX1IYpASrRbPdJPKYccxX63ykHvu4x2eYQampGpA21 mA1K6FrBEqTEeXiml0M3eOHunziOdLbHJZUhFTpqYakb0E6Rylf2z1GEOXKV/sSw+5DpluT9 5QNzkgZG1AU2kKCEyQsU7gzP9abOfMU4BNeWFPFMU2ueAvxS8BY0QEwQk6mZ4pS5X3ftn4Rb 3D6Kjw2o1Rymrc0YSxCLyUspFbocU8Yr54ZfKKeXb3WBNYeUmxtovQJIC0gr8oMg9kzvmKOb z01P5HiptejROeIJ2FaffeXnX5k8HZmLWd0xSnAc1UWYs9N0GxvzrXeUqeEwFSdOFPKeIuc9 66cp63eEWP6SFHsKO0OiKbokGUa4NKcGWZcWVcMVwThD7xa4r+6M+tArBTWbPTbUsQJ0qenU myJBFinMZgNNRX/COyvLRXis29nTOqNvKNawhCFaSH0g7D2JCF7ob53BlGS2y0JY4TTFSV8j UqG12cG1sT9GqlJfUpxm+tnMM75SnLlOf5RJ2qWCJqqqxsWMLqiQj2JON2yCbiMvWYzwB4a3 aBvlGGUXadUlNuDssHge+mAgCv28yfWYOxrLXTuizGfSBrnaCjgI2ggATgmiJLCK46QJXFki nfflB7g3Rqw5rvSFkzO2/Rwq+rdHpwcGw5SiUiunJMnBfhl+IUsQp6Qu2eyhNUNB0lU9PejO RbO1EHIk5MpAO2gUt7xFfOfykGMfY7Tn5na6rbSSURoKsv28RgfVyFffIsMt2XanFncPpCVy pb2lAjTNTUU25AcSYM8agJPqwjFPW6XHdu1g0RdvllfmuUU8DbzVnSxBkxZmG8swvDilu/G6 E/RrYW2obUDSXUnak7azqXAJHIw0GgZT/O+I61S06obSNh6eTN5AG/EIgKQN3a48YgKLqR1p KoAvbOMAVAQzAIIuwYCfsi5xl9rekPo0MKZfZ5TlR/o1KteKlPG7GGkyxqQb0pFAlh0lfOWg cN3G+IK0yw2nkzxU1a9MKiKYTnm5hBZf8amfhyQyw34Jd8pTjPKXtmq2m2/Y0aZoNAFSarTC OJ+rGjvxTBKV0pcYHS2auXItUmUnN+zqEU0QidnvLCWKeIYrp33jFO++Yr4Ibnah5JebRxfk DIy1EiSuyEppRJNMJkwSlhngvFqIUhYZ8ZQ+xktSmq0qOo0aDyxYaaXr3RSnTyGW2HGXTCEI Q3hmMAJy0CEUYf58qz/R2SjYkpSE+SrJLT6HGhlhCIXOV0p+zdCDLbKw6U2zY2IooRZwDkhK eYClGdPEbMzW8UxT1nfEDekjDTH/AKgBVIp2I3o2gi3AjEnv2ic5ivWYeErpbt185xRLL3sm uLPENGUlU4GWt1ShatWhKa5SCqlPEK7EIOEG5z49mMy87tZgqR6qHORGuD0i6PPEInQlN+rL DwlHHR9pdT0fT/QjD0elw48lXs96gnHfiwz4X3Tu4RY9X0nStPIEdMs6wCXoMNJgNPbMnGBQ ZcIRxop4Z33/AIp390RNYUkw2r0VsbU5Igt65/TFEGpywz6OJCTjmEN3Ccw9+msed/PNXPRe x5yLHs0km2iJxqNnD9niFfprOFKLaa8H0dkqUSMDaZnElkE4JCMuuxC533d0QIC0xNQyBwIJ ok51NAEwwhWFeH1Yw9m6d0r7/CK66IFLa4CQL0w0qou7MJM0mG+J+oK2dahqRpe3hMgF0Wbm kIkxOSRfixzvu1vELjPjEVVD2sqSpFj85fWlgpYvuylK6UvlKLW9J2CIECOzCzX0/YDXp3PG rDIvFNbcPDKQp+yGUvhEPaRY1SpKx2rYkaw1EoUiCnbdC9pVCUYZzluywJwfCeKMjpu06sKe Z0rU1KU4SkOISI4wnGakmK++Zd+kuMOqLUa5U5+c8euIKTi3fsy53glfPx11gPSVvClG2s7q sRoCnhQlqNClJSHE3AT9TLDIrBvceW7HG1nbTWGwPGzqnqn2Ncc6PBZYcaRWK4UwlFy0vAAV 0tJxgSi2CvFKxCsGvS428UzSA7PLBmTlhzBd87oSotdrk5QUMa9LgLLEVswU8pFXDniHMQfa nOffAbBaxQ1KqdqtCqTazWVpZW0oshJoeoGeKfWD/PXeivWPvy+m6frSoW04ZVLUbvJGkwu4 1WcfugzRXYrgznffLWM+T2u1+S6LnXpvPVLrhGZxMpgDhlcHAHgGUpcLorvlO99BuzJt49ie lIVTiX/KDA6hv8JT5QHqZvQEqbK0rb6OQ4HUaoWhTBL9EJmcLU+/jMU+PtXXQryPphNZ/Zyz smxLGhPUqfPP/lIskYzL/CYuU5yjzQstFrBZS4qYOdf0aIsJBgQh6wwoPZLEPjh8Iab68qpA xtzCgcshtazs9MWEP2k+M7/nAbPbps3mLqJftO2KBVOArEZxL55YdNJSDd3RgDw1L2dYBG6p hpVAi5G5YvdFziWqCtn6odh6bUgPTt52eSkCHLKxz1nOcg85xE1A6qXt4Ncl/rTPd4Bl3SiB vFh6NB5j0IxrNjNcKlkEwRfbUSD2S5z7r/GWsSNqFmNNrHh4rDJVYy84IUwdJrTA7mkrt0IO dwdYwmn65qenm/YGdeAgoIpiCERePDOfOV/CF+XlVf8AWDd4nK+X+fjOA3V8oNnbbHwUS24g 7Y5owLV/HFMe+LD3Slw4xVvpKIEDJZvSjOzoxkIiXE8BeLWe7pff4xm6i0WsFLeQgG8D2dOL GWEOm933xH1ZWFQ1OWQB+ctqAl9SXhukGArsOw1DsAQuEQuIFhY/4PVfeifRs5Oz44rLePA3 iifZ1+NPgjkkWzwuEQ6j9ZAZ6yO5B9vhsz1kPM/r4Ss9eKIDEEELiw7FtszphtqSoNmcjlGV hmLLTdsV3+EVKLRZ3VRNMPm2HJjTQYcIsnt/4RAuFUWSuXShSalSdzLmM7a1EpSL/rc47vNc mbaTEvXsK14d/wBXtmWWHxl4S7okU9t7Um6lMzuRSXCLrN0Z+Ofx00itp6/YfKA9+OQPp6r7 DMUY/wA4taRa7LmryL6YeyXIpUccEAS8y7LlOd3++PCHawsuRplCNqZGFyCMzDiXnKL9Oen+ nKIxwtLRrGM9B0UqzTle1YszcDEg6WzY2vAzoFSZyMCEJiswyU8Mpe7L/OCEPbRRLVRPRJLa NQeMwMwqTjPe8IzuNCryv01YN7Igckyr9HmSGeeZd12uu7KKtWC9nXuhXQKPZURJODs3Zk++ 6A1Sz+y5kdabRrBs6hzNVesOMUTBIn8MpTl+2KtVFkr2zui4YxpwsqcXrszUIOUvxR1Ufaij ZGdKgXsipdsosReWowA+cdlSWzdPIxIDqYykot7LCd7ffAQFplNsLJS9NuTIA0O3BnnCOMvn 4RRIu1YVm1P1NtLD0CaQBvEHrjDr9JcdJRE1g8M7l0cmZEGylJScJgsNwzJ/KA0iyOzphfqT 6VUs4HZUYoCV16jLLLBPjzlBUlhTr5aGgbViIpi7ZnWepl3fGK3QdpZNMM/RS9kG5p8zHhCo ytfHSLIs+kCpU7nkwiCn9ovaPWd2KcBbKksoo9HTaw5NTaUoCVFM0J+1XqDhSlfrvaflGR2m U82ttJ0pULUTsoHZN1hOs8M/nrfFgdLbNvZzUZNPAKVHEbOYeJZfLLnxwg4cOEUetKqU1IjZ 0GzARt7ORlJiCxX/ANafjFoVqCCCIWRBBue/BAEEEEAQQQQBBBBAEELggEQQuCARBC4IBEEL j5/vvgEwQrAP3DSv6QuYP3wosBw/UplBuHtZZIh4fylANwmHslSMvO2BblfrNnFg/O6G4Agh 3AdjKK2Y8RpheaWEskU8QO/hHzJGDcOJNKH7phcwT/KcA3BDuScMsQwI1RpRfrDCyRCkH5yl CpkqdjCv2Bbspl2Wds4sAr+F07oBiCOlQjWJsO2I1SPF2c8mZeL4XwJ0a9YZgQIFqwfupk4j P3QHNBHcW1PAzFIAMjpjRiuUh2MfUz472mkcf8XNU74iibswQQznIN/CATBHYY1OpKMK85nc CEQrsKkxOKRevDWffHNAIgjsb21ycjMDa2rVww9oKYmY8P5Q0oTHJlBqZSSaQoJFhOJMDcMu fdOUAxBHZsCzos912NR0enMkUapy55ZYxcJTFwvhXRq8BbcPo1Xgcr9iwkz9Iu03e/WA4YTE g4NTk1KApnVtVNxog4glqS8ExS75Q+z09UL2WepZGFwcU6cWE44gmcwFznrdMXDhAREESCdn dVJbiNM1LTQNt+2iLLnORN3HF+38oUYyPZNPlPylkXkNR1wi1ZhM8sV/C6fjARsEdZiBYSjQ rBplGU4fVBZc+uu03e/WEuCNSgWHo1hIyFCcWEwkwN0wz8ZQHNBBBAIggggCCCCAIIIIAhoy HYaMgCFwiHYBcEEEQO7/AOviQptSADgHHEV7EKTjwKAxmIxH6yBR6yFI/Xhh1431ghxuFsYM ayHHQGBRHM3jwKI6XQeMyIHDC4RC4sOxYaDZEz3UiVAszcoXsl6TFFbiYpt4GyOhC8BObkix RC2y1RZEAbWb0I2pWxQWZLL9Ix5gPHWesRNF2PrOnA+Umy7OWHGYWEyd4fy/zg896YH1Ckut ELEIw9Vj/dCm+2waZQI5TTGbmX5mFRdMU5+N3CLQlqXsrahuj+seCSujwnCAiLxTv4d0dnm0 pgdLgA2tWUtERMRZghTmYIff8Jc4gEdt+TtX/CQBbQLEEO2XSD8dL5xyp7b1KZP6NTyfbeyE 8SjQN/uh/wA4CRp+xzocwhyrNSiWIMMswOKZRWIXCWKd18KLs36brQI+imJHTYRYgiSCnPOL 5fGYvjFeqC1HpvI6SpjPyRYhZy6c/wApdkP5RIo7bziTCAIKVRFNqfspC1E/2i/ygOx8sfWO tUOw2Q5OhbScOSSEuYxiv8P9Yn6bsZQNVHvSx+TDc3oJZgSMIurJkEN+Kcu+KootvWZh+Om0 oU532AVggA+c5b0/HWISm7VHtn6RwE7Z0gGYcsw4WUTi90MosQVm7UmeKsQtrqDPKEZLOJ4Y teE/CN0rSyhqXta5M2ksrSrCdLZjE1w5hl7oud84890+5HM7oUvJ3hlixRpBdvDqDF0VTbUl GYLEYZiEZMU++IjFwoOytnYc8moQInZ3ycRhhwcZSaXd+KcW0uzSj0ebszC1FAOPlnKVIb5i l3AlPh4Rjpdtj2T9ZZG1SD3RCFLM/FznAXbk97QIa9kbXE3FjJLMxyLJ+AZflFi+Vo1UGgpt /wD+D29uRJRTIIw+vUnz7Os/z3b4qNY0SgcqXs6TUq1AQmuWhwiusGKXeKf+d0R1QW2L6hb9 gX0qxGjDeEJxgRTGTi4zBLhIV2l90N+eZyRt7OmRsLOlKZ8ISBb05/7nzuiENFouyVtpKrFR LwBO8D6MGeWcpLlMtPOU7p7uu9+ccLxYn5W145nNo+iWolEEQTgl4CzjRcOPC+Kost+qpS4B cljU1C6vK2fLGAsQJ8p87ofa/pA1+gMVDAS29d2QiJnKSb8EdAmqT8mEdm7+c8Uq2pWdnLGk MViDiVLV090Guk7vhfGI0e29KvDc2rFOx7QZIAjsOPDf4c5xofnmfvJvofyYp0QAiGIJ4k8x zJNM4mB5SHrPe4xn1PuRzI8JXVMAo1QlMzS87WWLvjnW3Gm7EGpktIplNU7xthS5bMeyCL6v LD2AmTlzFOXDT4ww6Wettf2uVqd0kBuRNK3YiEjcSEEzLuIrp6YQxTPPNWY3hK6rOj1itKp2 osRhf2ny4Xcro46ftRqFkqR2qElG1HuDsdM8/PLndin3XRaFUqRt6HqRczgzfRT8oIjtJi8Z xsDX9H7pWsG5qBUJoURlPycDleXubTMV2Vzl+2/wih7fR72scX6uen1z+uOxmCRYSyOGkvl3 d0o6U9qFZI6c6CQLBEMKVWE4IOIxYdQFmmc5acIha+22fR1Js0s7VVUCqVbuanMKAIkScJYL hTunwvnFMsXsrWWnNdQjbVOUtbywhTk8jBi5iFylL5zhKi0WoXstcgrZe4KmV8PkrW7OXcYd h7AQX6SBK7gGOlotHJoFQaOyYha1bUGW1idcJ0xXd3LhpFi61hYDStDU2e91PVTuLYSyQqcg uV2aZpuyu4X+N8UZE1IzvoqVS6gH6moE4BCy5YzC75XSnP8ArX6Rz1Pa7XNTsbizvS9OeS5C lNWLL1Fh4SlylKXhEAjqp4R0GqoZNlBZVh2ceHDvmD+MENqtHoBlrCo7HqbZCzWkDkzYzVAS +BMt4V90tTBd84Qo+j9SXnIbKbA/OANqSLDTiCzgHGk5OC6+ctL7p8LvnGZp7V68TNbS2pnj KStIgiTYS5Y93symLjdKLRRFtFSJ7QyqndW7pxUSkPJQIEBMigBEbO8Zs5BlrPvnAW5g+jSj WV45to3JaBnJTFZRghdYWcMN+XOXO74yiOs8+j2zuVJpV786upq1UnXGh2a6RZeRPCCQtL97 j8uMUhstUtUpBwc8DktRqHQyZ5oXEmYx692P8oslH2zOVMUGqH5NqlS1UYcV0mJQICTNO47n Zxd39aNQ7abYaw0lZh0kS/G9NFpE5uIwyU88wcw5lxUtQBDKctdYttmdmNN0lag0jRvZTqqM o9QrzhXTAWfPTaCpcpSlprrGI1JaXWdQ035NvDqA1v6sJgQkyxnSBqCQx9qcpT1uviMpt7qG klhFQtQ1BBqoOUWccXMclAPd14y0jIeo68siZLQqfpRMc8KOlSUgx9KiDdiLkMOPH+4N98RF OdCLWw2xSjFlSU2oROKvCpmjlgPkGXAw2cufG+7kHWMcqS1e044w1teHgZG8ARyYKeRPZ1AG cpSlO6/2eENF2zWlklrgAqf+EhYlJ2zgx4rrtzTc07oIapWA/OFZWajYXh9bCqVp6QlaI5HI tIvydRilPjPFOX7JR50pNMS5VJTyNSD0VY4pgHh/mxClfKLC4WhVmspPyVOex9EYZAEWEMpD MBLgEY+0KXxnFbMTKUydGsOJNKTqN5MZhuzMM/Z+cFvWVNk/+/dr5x2NNsbckTtxxZfqCJhl 6qXC7TlElaTZBSto6hidDljkmmlaUQj1uHqzk88c5B++cOfcLSWGPNJdc2is9SFKdvUBd1CY KcJZycI84r2Q4OesdVQWkWogfDSX6oXApyQq80RJgZA2dRddfIN27cHhdGg9JUeSgQWXtzb0 JsYPJx3PJazrjCw4TftffFPS+eGd3fEPTb28DLo9qqdtKcVtRL0S0xMWTMCVjSguwyvlfvCn Ls33XR52MtLrk6nzWEdSKOjThYji8MrzOeouN0+ffEm6Wo2rrKfIOX1IqC1bSHJMLLAVIRoe zK8Mr58OHDSPR6atUoZnrwxs6b2s9vbROjgYTwMViBhwBDOXAEu6Ur4xqxA4HnUyaQTPVKUx 0TOoFqRR61bIielwp72XMd3AWt0UFRa7aQpeErwdVSgSpKGYSMIQyLDKd1+5KWG+ffdESsrm rVj4uflNQqBOroTkKz+EzCf1fdIOnCUZD1vYHUI6kounnhYAYVT04uSgJIRXlbt8pTNnd7N1 0v3xX6fpKikH0bHNkYXJvdsxe2CeleKU5nKtsJmIoQZaBlKV0gyvn2o86UfU9fo6fcWGlXVa Q1EpxHKySAy6sr2p38ZS77o4WN6qpqoRYUzrFSOmTlYNpyw3AMU8QXi4z4cILeoLfjkPmrtj K2lQaaSpRbhl+WTMUypBCXy4cZSu+EeSXhkXs5bd0kTkbcmkqJD9yff3RZ6wqG0WoaPbFNVL 16qm1BvomZcEpQYD4ceF3yiv1Q/L6kcAr3LKxll5RZZIcACweEo0rsG7fRrAgJsPcViw5alz qwThzEXrTLsGAuf3b9fHhF5tssjpN1qR+rYbYo28khRcikZq7GBJLDIy6+cwllc8Ab5x50sv U2qATrgWddIbOEyW15OHLCYLhqLTFpyjhdKtrltcDUDxULqlWowiSHEHGal39sM+++fOCHpB 8s0Z22whHZug2ghOuf2oDi48c4w6YM0QZT0lh0ldfFrVsKRntEspRtrVNG2siZ/JThFeKYZA kWAAt66d4pSxR5heHK2kFDoVK8b/AOTuYTsX9afVTulv6z4X8YkXQ76QJ1SMoF/T6p16zowO IM8u6V4+GktJcZ90ZrbhUFAUxWHQ7w/Jv0e10sHZEiswY+tMMFdMY5XiFOd33ogmsDJ0gusW YW2pEbQW+SNMeEl5ICTZkXzLFPjKXxuvujG9ptmR2kBTY30NXvBOPdFKczCg8Jyn2ZBDdPwl dCqXR207O8AZOlUqfazQOIhKgl4jZdud4v3xpQLgeWgYvoeOaBnmqxLKw2BWrD/G8I+1PTsT AGXHnGkW+UwwvBj6c8PzgysTSe1FLd6U055el5YAzu1lK7hPjyjy9nVUdZ2LfcPJBrUyDh/i 5Zwp33/eFOfxjoeFNeVJS7Yc5Dd3hlEvkiQZmpQlIpcu+d0py+Ue9hsX0xBkjY7J19GDwpwi OC0hTBn2bysqYfkGUUH6WGx+fRUBAMAtnbExJ+HXrZB1v8Y4KkQWtIDGBY8dJeinyRM5gVAZ 7IZykG7sT00+EUh4RrEDosRuQDSnAs6e0hO9Zmc77++OccMJhUJgCEQuCARBBBAEEEEAmEGQ 7DRkAQ7DUOwBC4RC4gdUfC0ZxxnUgxDh9GTjifa16YlYBMTug+0OjnFGgMHjhEEdYXHSYPHH HD+CA+wQQQDsSVPo0yx4RplPqjDpBFEVHSjUjTKAnA7ZYsUQPTVQWaMhzeagTJmhuAFP6Nl+ v+d0UpjscGmeEYHV4TmgELGIjL+zl/nEKXbY9/xZqbdo7IjxYjJ/5Qgu12pwKNpGS3njxYhY r97wv7vhFjREdnTIdaAsdTgJwtRJEslJk378+fdHc30lTexrCQM6IrOPF9neYKfKV/KUZqXb ZUgHDb+imjrC8OThFg/znHKXbBU+YfgRtu1GXizMmc8u/wB2XCAuCexxtYcp+fngBqcIsZxB 4ZSIDroX3iv+EOvlEnV+8BOZ3VtRsGKQcKRvyxl/LS+cUBwtLfliMJKxG3m4ftjgzGZ+3QMd Rdq9YbOQBGjSo0RfskJxBkZd7w/8oDTafsuaqb2r0lEeqwzwmL8M5k/KV90R1rlnVKoG8irX V+GjKMJlhLRJ9DhTnx8PyjPPOjUIFGcNM1ZWvo2TcXvTvnfdqK+cOrLWq2cjBJlhLesHh6sn Y5zkn/ACXCAqzGmRnVIlJH1qUR8g732kr+cemXyj2F4b1zbtKIjqerISJ9U/+seXNsU9ICXj +tZmMWIPP4Rek9q9oWx40BJRQMMgiVloxTmKUu8c4DT6Ds0Z6PdPSR9IrREmDEeYXIckQOV3 eOLgYwshLeavJAibNoyRGLzE8pnmS7paT4x52LtXrYBn1lOqxfZ5N+ZOfw4x2ecu0jpgQBpt qWnBmIJBjfPq5fdLlK6V0BqVYMjONjrxtRtSIgeSWIKkIesFil73/n4RNNdntKoLJ2dMgRtS 4GcjPWniwzGcZPlP/KMK84tf5jmgGD0pcGe3iEjnmYLrvhKUpRHMdf1U1U2JqZDv0aEyR5mW nxzEPleKA9gMbIznJ3hYcNKuVJVE8KkxLeBAC77KXMXdGYPllaOvK4blh2aU0Ftc8xSEUgGH DnPjOWt+vdGXqLTrXQN5Sk7NRtXaD+j8og6/mL3r/GOFHa7aQB42xG9+lKNwIS0oefIALrpf KLGwUfZ01Pdm77Qzlm/o1+EQScWG6e7K+U5/P/zHmFYDJcFib+TnmFf2Z3RoHnRtOZNuZ+ku jDTDpiU+iykfmT0nO/jKcZ0Xg9vH97viB9jU7A7KwWnI6iBtIylqMvCmDiuBfPmKf/n4RWzH iz3LCAFnpoeGIQnKd4o7kdfqWRQEFmLaKlDTtDso6Zxii/lrygNUrixCgKApM91e+ml3R5JW eIsV2YaLS+QdNL/GKCjbUyn6J9Ur020YCXwjq9N4OK/Wd3j4xDulZ2nVIW8U85OTg4g7bmXl 67nvTu0CHuiup6qeCaPFSSZyymJQZmmJiwy6wXfOfGLHoK0SjGSvKosmbUaA1uajmeQj1IeJ ZfHLnpdfpPWd0I8ydm6m0xCwptqEAxEqNMJIUTHIOC7L6yfEU5cbtIwzy5q0CNCjA9qNnb/q xOlwbuHxizUXbNU7JWAqqcsD+4bIJImzxZZabFdeKQQ/CA2Gm/o5UqprSoiTv4NJJKKILzpj GQeIGIV8gz9nvEL5RGWb2A0Y5UGmOWAWrF+xKzTz866QTgznIoN0uV29w+cYcx15WbCWsAz1 OtR7cZM08QRaimL709YvLHaXWFN2X7Yjp4BSdYYYkLfjDJ9oztYQ8MU9bp/ijVCdtosloakr LwnNRwwu5ZaTr8QjJiGOfWY5dkEsPDnFws3pKg6YtIF5MPxqk3yJPEpUldZMkycw9aCfI277 OPOLxWdTvbOQzutQqFzeTvFkCuuvlzn3/OOGn3typtw6SZF40Kv9cGMh64qSzGja/o+kBuUl pGyoS7nQ8WoS8yW5Pe3zTOEp70NUHQbJVVkjnR7kyGoWxLVSoJJZ3rEEiy90U56Svlwnfu73 GPMSi0Ks1hmNTVrgIeZI31nMPZu8Jd0fPOLW3RZ7P5WrQt6q8SkkIpSzpz44u+/nG94qRm+n F+LB8r7v3RuP0iCSUdqFmSZATiYgtaICQJOoMzNuF89JXxiGMn3wxLeULkPo79Kmi6LFiQb1 +zT7w+N8YrekDLOqYqH6S9pqaoWgbmUjbE69EEwwUtZFAv7M756/+IafLB6JG+BaqeTAGNtq Ug98xKLshvysY5cbpXX+E4xOm1lotYVAuGyOTk5u5hMtvP2jB1QeEjBd3dKOOqB1nTbwuaqh WOCFycCQ7eHaL9rK5SFMOgg+EaIbjaZYzRTbYJU1Ts6Yo1VmdINygjWWyDNuAHFoGfV6zwxR rYwf+wdhZ2ViAEJ+L5jL/fd3RTtsrw6zc9eNe7io5GIKfDmej73KQeesNvLfWyWhGWpnjbQ0 xnYWXNM3Qz5TAXxlfdxu5QHpSdDMi36U7m9OTaar6HY0KtsIGZO45RK6QZ38Z4cPD9kYxbRT rrUn0p6pYWpNmrVhwTS8QpAlhCSG+eKekvnFefHK0Wnnhufnh4ekLu6IgqEykwzrxJvZ+Epc oaotfXLrXgllNrFCqp1CY3MWmXTMCVKW+KYx7odOc4Combhgge2EUw/OUbUY1IF9hFi20IMZ SqpdlPLEKeAUjDMP97DfFDpOy6v6npsh+aqeBsCoJoiMxUEIzpA7cwhnvTiHRvb8vMaWRM6u B4058gNaIIp+jncJZcvZnfzjJb1bVllFliN3IkBhRIVSjb0LeSG/AYfIMsuY/nzjlsjsToM7 o5A9tresd2NsklfkXrB7UdvaikLDuA7r+1xjEXCgLZk1QMrapRqxLTBGCQGBcpTkmMD25zHw BPxnOH2uz23FM9uKNAUtQHZJRq1b0pllKJDFudbwHOYuUaoWKy9qA1N/0hmpMDCBGiOTkBFx ywzOkGX9mUR1LsiZ6+ihTKVUXkAVV+QnOPxdkocsIjJX6RU2ekrSFiisEaBMqB0T/wAw+lZY DJy1kAfv8J6R0VBRNp1PWfo3J+OToWDLCrTN3Skr9+66YSZe1PSA1j6Y7agZbJKOQM7QFvaG 96OTpCgTnPq964Wuu9O+cYLWFMOVKqGxM65QFDggCvCWWLHlgFyF96O+0BNXKBGweXilyPKc ic9tTKVGdpK6XY1unwice7PbXairwSZ7QZr4JpA5KTFqoJciU1+AMp3bobrrsMoyGvfRTA1D sQIAsTGqheVwhlkld+XKUpmaTwhlrrO7WXGLRapQ1GL3R/q1ZTCQ9/CnWiSIjBSxrwl4QiVT lroDlux5ceE1eWaOgmRS5KmVQoIko9AWdWcULgZKYdJxXjHJf1oznJaLMLkQZ1wpzML5Fz75 X8ogeyXxfUTlZxUzxTaNey1Y+HtKVEFSIEigikIF0yp3zuuDmX385cIRTQHllqNBT56JQram dscxCcldxR7wvHdmzLLvxABfOYQzw698efqkoa2NnZwPb8sUYGUuR+R0tmKEEhylrg9md3dr FI8p35e6IzvKR1VLRGBITGCVCmMMxaSu7oD16gVISbf0w+jhyXttnuPJzPqE5GXiJnx39fen GY2Dg84VDtNGVJR4/JjbVisx226fUm3DHvS0n92+c/ejNFFK1+jtXPs+2xR5TrMIVOWs9cGc pDljM7sOusdtOWY2rPDO5pmyezNpas9IJJ0hlyVjK9ZcXzlpHRoJ5jRqVn0SHoB0j+jRVYWM sXuog9ocpeFw43hGppJyp+y5ZSuAim079Po4OTMvCWBOcCcxY9b8ePenhjxYne169OlZCXJa anOMkSSizBZWMU5SlK7hxi015StYUNsZL2/JdoJPkSkbkThM01OZPuBLs/4wW2O1sks6gKPY WhEc2OS6uxqCU54rjhBDmSGfrKV0r56z+esZN9Jh1QPdvdUr2oeaixEJwmB4YiyQhH/ejsMs xtUU1oU1KR/pfo7ajTlDlfNEVwnKYuXHlFYb6AqdfaH5AoUYFzvhx9QZKZWC7Fjx8Jad/OMh UoIcMBgUHk/qTJlC+IdIWnJGpUEJiQZqhQZIoksPEQhaSlEBiCLpWFmNT0kzrHV46PykJ4E6 0KY7MGmNHK+QRXac4jKHo97rYxV0CArKRk5qk88WWWXLlx4zn4QFcgi+l2S1ntjiScBvRlIT iiBHnnXFmGGdgIfGfdHC4WdVU2tdSOq9GApLT5wSFZmZ7YtOzPWAqEEWZHQ1Tr6PIqpM2/o9 YtAiSCMFdNQYLTdlFm8yFoRxmS2pm9xNCdlHhJO+rzuv3xcA3S74DM45zItNaUk5UkoQkuQy jekCc1MYRfMBgYrCiA+wqEwqAIXBCogd3qU/4oYLJOHue9E0syd0H3ZQ0WcAEc61ZxwYIdwQ +oB1cdCHKnBjMh1QPrIW1kjOMjn9uLH2FQmFQC4eTgAMwOPsYpQzCscB6vRs7UOm2lBtKVGn OSfUiU98xTnznFA8z7UmWFDG8KuuOlhJy5boL9b4pbHXloXR+SzgzSk4cGcWjxzD4Yo5fOFW eZjG69b7WIvu5TgNscKPZ19oDYsHjKStqQwJZAQy64cp6XxJlkpiVjsMCYBG0CBiyy98yXKV /G6MM851eKXAo7bwGq+ySWWllz+7KHVleWloHARy9SajVHfrkspT/q910BpThZXSqMxZULws GUaI/OyxCllhl3ABxFO+FvDIO07KyX5wQt6XCExNs4QgFLjp4/5RlbfVVoSxGq2A5UqT/wAZ OCnx6/jhXlDaWNjD/CRTUX2cKXAAXx96Au7xSVPUZUjccw9eo2uRGWf6RMMhd+l0hXeEXpny U1QVMdgytoMLxCLD1pnwn3RhLxUNopOwvDxtRWX9SEcjukGYtL5Au4+MSJbxa6NwxgA67UcX i+qy4fPswEdagmAC1RcDADKEcEWX4eMekEaZqck6NApUqBYmyYdmJL6sMv8AOPLhjVUix8VA OQLVTkXeap+0mHDxxT8Ik2urbQlLeaSzr3ASVKHrNmJ7P9aL+xt9J2esNGPgVLUSMS0V+YYf vyRBu7P4xfsi7+jdD7TnDbAHEz6/DerFcKPMudaumbwuX6XAn7e9ri8cPGccayqrQm142xe9 uRTgIvdMOunPB93lK6IHolZvuD0gRk5CdVTgxbxcsy/W7FPjf8/lHLZmz02CwfopnOS5pZYR unV3jEeGd90/ly1jzoXXNYAMPGCpFuao9cd9oL+txjhb6he0CM1GgdVCVKdvHFk6Z0/vd8B7 J8m6eq1HUiB1OcFSXCAR/wBmVwvkEE56f74Rm9mdE0kO0Dpgmm+iQN5cxIicwXWDCLdvmLjw v0jBzK5rM4sgk6p3ARSf1JOLcD/V4QeW1YdKdK+U7l0hhw5+ZqGXdLui8g9HJ7Im2qrUK8fq kTAEBQYEKYOLUPVSxGXaSlIN3OceXtm/4gE2j3QBX7P44MV0SPlnVvX/APE7r6V68W0anfGc QWd1mP2+1i8e+IHsAz6OVAIEaqoVibbClASQJEmZOUiZTulf3jHOf/iMrWI6YavpQMtNsNN9 GFNK8JQhFin1053b1/K6Mr8raqzAj8p3XGX6v0ifV3cLu66OHphyA6dMAXqOksWLa8XW39+K A9M2ZgTNtpFtlNks5Sg0wlSJPnazPlh9TPwnz1vhii7JaDbbF0Zz8z5r+YmPNW7uYcScGU5y 1lulgBKWs5/nHm8t7eCVhq8l1WlLTvXKQnTzDPiKDpt76PE29MOHR5nrk2dPAZ+LvgJGyNA2 1JaAwM7wd6EqUy2neu3fGcbqjs6Z6ktoSoDqGQU8wN5yjCLFP9JklzlKVwOO9/ucY35frwMY WpGyMSHLLwBUkp+v+OLviC8oX4awKwb85CVFhwlniUTxhlLlKcWPS9QWXUlTb5XLq1UYnf1p YkvRzWd6vLFKWfdKXu/7lFisvptnqGxw+mKkYUpCcT4pFsh13omEmc5Clpy1l/a1jyMXUL8S YI4l7cgmmBwmGBUTxil8Ya6VcsvJ6SW5X6vOndrx08ecMiHpO1yg7N6esLPObWdOFWlbEwyl ZfESgQrr5m3zvnx3ZflGOfRvQM9Q2wMrI8ICnNKqLMzCzA6aBvvin9MLzsgCxYoWJ04sZaY8 ycyvyi7o7ZqwQLCl6BMwI1BN+WYS3hlxlOX7pziB6EY7JbOlltCoZKZoNKbWkCde1khlPCqM HO+eu7LCXdfrOcc1lFl1mhzg5s/QLauy6jW5+0CxDCSCU8ksE7pT0vlO6X5x5QMeHIbguctv UFKnA4R6kwkzBmDFO+fDxizUnajWdJM5rVTy8pKAy8WeImRh4Zi0nMIp8J3c4vIPQlWUBZcz 2ThAOnk5pRaROIw4kIQDzxmXetv43+zvaRT/AKRFJUqgY6UU7A3tLf0wQQcSQTIKkRF2/Pjv SlO++c48+mL1mWAA16o0oIsQQiOnOV/f8YSoWKTvrKlQfh7OcZjwwyD1RRZ1m690tNBQzVtj UobUYNmCZOUlswYr8EpyxYfelrf7sXusaYoWoVjac+sjYNUhAQUlK2iWaM8BIp5Bo5XzASDj PXjHhpOpOTfVlJpH9CLB+6DaTv5So/7k+fGGQbYjQPyz6JFc7YmDm+U4TyyyxbmWEQMWX92+ Q7otNszxSSV9sZMq9qmCmUjKFYcmCLMFiwAkWUIHOQRfnvSjzZtinLwbYoyv1OZPB+UJMOGP fOGM3+kFfDItvn04DiV9UUQ8AOxbUyixYg3aYsUtNbuM4rP0b8kaO0pnxlAcHqmjUqLMFdin hFfryl3xkxhwx9sYzf6QV8JxxA9zWACaZ2dWdKD0RKg9ubDixK8yXoE+fzHwituiCm6YT+UN Ks7AKr07mg6WJzpYEkxcCgC96emK4UeQdpO7G0m5X6vMnd+UJx/fHu/enBD2jWjIvqQulKVJ WeSxTge4rn5MSoDMzZsV4pXS7WMfhdfErSah8UuNTFPbQlINz2rYmXagGbEkJF9oZIcpTnKW +KV87u4UeHM47t7Soxiu3syd+nDWDGP9co/FmTvi8g9PVS9px2P24L21OlUAV1Llln5mqkAs mU/jIMsWG6OC0AsFT2DudT1zTzGlWt7OlT084plE5nmb1wQz8deGvaFHm3H2e3gD2Q4tPygx j3d8YsPZxC7PwhkW9M1apQUYssSqSvEhylO0seA0AetMksuBhvlffpPX4yjV6kUoB1xUOAAF ytVTiAOyCOuGYMB5opynhu7MpynO4U/hHg/OH28YxfiFOcGP74w/exTvgPQVuDIC0j6Q6Nkb XBKl6LpYPSRnbkkmDGMQfleDnpijAG/fcG4fsbaT+WOUCdScmLPAmONIAqDgPyxXZwb78Iu+ V8NxA/Qd4XtpyypFKNA1GgcNkAWerUSkUt0BinPe0CAMtdL9Io9PttAHVwxKaeAwGtvRjie0 nmYZHGuAjwymdlzlKWGUpXAFhjxZ/a/tThf++1Ae7aSJagfSDtAegdGmuRytvAE8zDMRKYCI EjsM79NdJxBUG8I22nEakZyLZG897PWr8Us5BmmCmVlS0vEK/wB35x4v/t/2pwf/AI+7y/KL Hr2pPJSmbIWsylkLbMIEaGSbrgFlbVmcb+2MwUxa6i4RAVomTdKUK91O1MHl4uq4gYgojL5H IAajNFfrdKffdHl7/wDr2d6D7+/j97Fr+cB60a3slytztiJwoFE1SNO3pCBCDlqC5y375z48 ZznE3ZBUlndPWyPtJMBIEqpR6UvXlCDs4sor1cxinO7eFi3btY8Xx8+zwdkMQLOxsIHsutXv bNgbWcw00sRgb8wQpimWVfymK6HLG1JKa1ij16weQnJcyjTBC9m7WKznD2fZsY9nxYsnFuX9 90NY4D20ocqeJ6YJWDaGpO4PA1fXBxzEmlKczDgglfrOc7vZ1nwivM5zIj6YQUkBoCiUNyIp pa8yV12bjMmeZfvCn2piEKceRP734oXF5B7NUPbC9lmgbVid2y6gkfmHClcnAEIQCFK+crpS lfLlGf1YpTP1ldqy8leVsT1UBI0AsXrCCRy3gS0007pR5x+5B/vw/KIHr5PWFKv1ndEL0f6J SpX4jISCMleEskM5TM485/C+LCzvbCgY3ZGpG3pVDgpOGkRBMlIa2V3EV2uGYp+EeIY+ff3/ AMWKd8B7Rp8FHutqhDk9uraJU1tJCcSbOllFmTvmO/W6U5Sn33x5Qtg2PzsVJ0blbFtotnye xgitxzmQC4ITCogLhRcJhRcApwH6RDEdKgGMyBQgOJLxj9qAdwQQ0YMcdBeCAGs4CYzfjgUe sEOHVABwxggCCCCLBHRDUKgPTlB7H5u2kGNR/QJg9rxH4d8YnUjI5HVJUiklN6KlUiEIzFKE UmOv1jeaCmznALeXumGEikXL4Y44Vi94QJzWFSdlAxYji+Zk/EXOEYtdhYweVAvZ6mfWeEbA 4Uew1PT5AF6ZaEosyY9pU8btez3z7o86J0z2gZ/KFMA1KnCZIATw98+F0ondgtLdVCPrndYN UHEXiUexLnPlKUBs9NjRozOgUbOoStpO8Xh1zPEfxhX/ABODNUjAasNOPEBMH7BMX727Ld0l drGBPCmqmEzYF7wtIzg9kKi/MD8ecoli0dop1L9JDdVSNiFuh2hdlyM/q84DcagydnKWLAGm gCpI6zmcLhKXwl4RGVJUK8FpC5qRtShVtROEXpF2HFxnLuuu748+mPbqdhGN4Wm5PqRCMn1f 4e6O6m/Kp7dMlhUuBrgZ2js66d0u8cBtlDs/QlaOzO2jHsRjYYI7evwmilznxv8AjOJux8FP ebNdTDUMaVQjxdIhy+0PxnPTlGBPiCraYL9MclBRSz7QhV6z4zjspuj62eGPpJAPZW0wzCHN VZe0D/DxnAbxUg03ke8Kck0IzEGHaxGbhk+AQgl8Yx+3DJAz0Ug/+ySoPSw8w/i8YpqjyhG+ dAjUuSpanMwFkYhTkEfh/nFmUWRV5tmzbGUqVYpBP9Ix5N+u+Phw8YsZ7BF781FYHLEZKMlK sKVX4Tyzri9PGcRlJ0NUlVOjwgakGb0Lm7afwKDg5SnznPuiBV4bi/o7KKtOZ0y87YiDVCQS stJmXmZQeM/CIR0o9+baPYKkUpgZT8cEpIXzFigK3BGl+ZaswPgUB2ykA2CS048y+4N87pF+ I590opVWMKymKgPZHL60Tdiw+MBEQQ9knDLxgTKDQfrCyZzl+cGzKdnKO2BVlHerFkzuFfAM wR17Av2gpH0at2gwOIsvZxXilLnwgLQORxhpIGpwEMkWE4IU4urnx1gOWPkTnk6p836ysx7q VOtCiycPWCELn4SlEcobXIlGUsUtq0hOd6s44mYAC/OA5YIdLJGPNwEjNyS5mmYQ34Qy4zjq Rs72sLCcmYXU0owOMJgUorhA774DggiwSppZOzRzra+QCka8tCEiYZ4zDBcZ+EpRJ2kUA90M XTfSRIxGviIKgJZYb5liFPQr8UBTIIljKeqQl0C2nU26lLRFzNCRs88eCV187vCEp2R7OWLk YGRfmt/1svJneTz1gIuCJFGzvaxv6SRsjkelyxG5xacU5YA9qfwlAYyPxLehcjmFyClXCLCm MyfWTF2bvjygI6CJR0YXtndEra8M61CtVCwkEHEzxmcv36RdLP7KF9SM6x1cl5rEBK9BY8nZ cw4SqcpCFilphkGU4vGM3gi3VZZ7VTDXCqkuh1S5QWI3JOCXPAoKL7R3DQMucWuoLFgIKfNe E1eN6wCNanSuIsIZFFiMlfPAK+eKctNOOsQMmgi+WqWek0Y3028IH7pptqAJokxxiWacfV3S vwz1unffK+I+zejzqwdHMG07C2s7cc6OavLzMkkuV+6DTEKfdfAVOHI1+zuwdTU9L0yvU1Ia lX1ISoPSJiUeIAQFfrB8sUUim6Dq17qgNPAZFBA9rKTnqTPVJ8c9Jznw4a3QFXgjZKksKAyb CvOrbIYsSoCtSelkWZeQLB1Rc94zFPh4axMF/RsU9KLMdZj6PLCjyMtHKagRiid0gilwDh48 flF4xgcEagjscUdHWhuTk/bK30irGhLMAlzNrPDd+Xs9/bhq1yy5HZ1T6MZ1Quq51UJE52Ho /AkDMzjLN1lpdOIGYQRpFaWVurVU9H0ywndPuNTNgFoMvcL3uf4ZS3r58os6iwKSOo6oRrKs Okjp1IgGYcmRXjOOU8JSlfwlAYhHyNfcLEDk1eVXR5NT5q1nZZOqQJye6agN14gzu7Pdf96M fLHjLCP3oD7BBBAEIgggCCCCAIIIIAhMEKgEwQQQBBBBAEEEEARzmesjojn+0gFwqEwqAXBB CogKL3zIkXwfZB7oZQwnBk9cP+rHKZvwEpBDsEQPhfuQkwnq4XDJkBEQQoyExsCHC4bhUB6B sTGjOoc9GcjGuN2mQgpgmZctOc4sVQMlKqVm0qUDea4C3Sy8zs6azFGBUXSr9UmfsCnY0qcP XHmHTAD4acb4YqRhWMKgJKwefmBxFnBxXChGPQzo1M51DtyM5Ml6ILMKHk4rgHCCL9t8TD5g 6UQ4xlBBliCSSWKUtJ8NJco82t9KvC+m3GocZoUrf+sEK++6+6USLXZ1VTkztzqSMAekhBw5 xwpYQT5zF3QG8bNTZzh6eBEsdQk4DAl4Z7PLwnPdBd4xXy9mqfaiXVA0JabSmbuYovmHTTXh fGO1ZRjlTZhBOMa7asWHICLew8fG6OpvoBYpptTUL25AZUSXdyzgiEMU/wAP7IsbI+IKJ8l0 aNGmRFNog4MzdBLjxkGe8YMXwuibcPJJqcG4DaNEHqcOSEy8y6fIV3+keXE7UsXmCGgRqlRW Zgz8M7v9Itayy5+JfG5tTYDwLiZG7bqAsv5xAs30gFiMbOzoAbIUtLOmIxMmMzMuXj4xerG3 VB5DtxOBvEanMkMwxadIBaeXhf7UY1WFADphn6VAv2wrPyDOry97w74douzc6p2c17UuWwog nSTkhw5hhxk/u8pQrG8OjrRgFio5G5NAXAwWIS0N3Ugv9UHvGL4RK+UNNpsIFjkl9I+qIiTp Zl05aiH3f1o8wvFDPaCqPJtM2mrDcWEkQQ3SF3znPldzi9GWCOuWHY3tOaq6vaRYcBBeLlIX Gc4aDTOkkY6kYEe2NSYaMwahTkqpZBMp6S3r7sc+ctPjHNZXWFMNrpVdMDGlISmHnLTHHOkA swQuEr/anP4xnnmNTdHnuQ6t2NlSn5Rx56XBM4zuKB7WKeko4y7GVI6oPZxvBRSdOimqLzA3 m6Sv7PD9sdA3Oj6to9GnRnL1LQU0J0k055hgrz1HulgD2phn+2Hakq2kjnymV6l4alQy1Oam TYpT2aUw4ZTwy0Bh+V3fGBU5Ysc5UmjeFbxhdFiY1WSkAG+RYAe8Px+EVt4s9UttD0y8EqSl y2oFckuQWHcDi4b2s5/lHOPTjhU9PeWgwE1U2nqujsrPzpTLJHIV+op6cP8AxHmi3R1an61B 2cmc7PSiCWDP/XDDK6c5eEXRRYOjTWiJaGHUgxLeixK1OWluBmcpB/1jJ3hqcmRZsDwj2NUH 7Pjp8YsetrM1lPHWXkDUkgIZUrLMB5ZhcsoU7+ffMU5cLtYjq4rykljwwDJWNQShLU6ozexn BLBK7h2SQhDdpzjzeW1Vs5NaMklM6qm04s1QnJ1yssvtGYe6XfOJ2qLMR03ZfTdQqRmmvVSC ls7YUTuBALhKYuN92sQPSRdpFnRz4ecmcm89aYkOBmC6sG8O8MhGaXSu+MUGqLRWsFCV4pYX 5vSuixeSFt2YPrAlhlIcwSnrdPlOf5RgtUUq903lAfm3Y87eLDikPh8I4y2dyOY1T8mbRmok p5SUw4P6wydwQ/H4RY1Gi3hhB9HhYzvy9OBaqqFOr2QWszCwCCId8vGOz6RDl5Tumcz1UB4T uRxI0FPkB+r4Q3TmKfLhfFI81Fpe8PyJcOrvxC03bpXzv7rordNpnJY+JUbCA3pJQZgJydwd /PXldAbh9HQDXQZ9SAtZRgaW14TAICFZrnXT1LnIN87pz5Rd7W7WqTOs+qEFDvxSNbhTkNeW G4YpFzvFgDxkG7dlf+UefkdB2nVPnndDuC4CNSJLmKTvaDxuv8Ocd9D2aL19aO1PVCmGjNbW s1X6MKQ8QpS0li4Xd8aDsZ3tB/6XKkp5Y6gC+OD0UqTJvbFhmCcxfsjTS6/oVTU9l1WutQ5q pgbtiUIBl35Zky8Ij5znwnfdGPp7PTv/AE6CtTGcDa+kwklpxaS2fs398xTHwlLlHOssrtCR t6NedT24uMJKCHOljDM3sY/d+cZj05SlVMNR2z4Gd1SjbWunlgjzUl+AjGMF2+PtDwyxRw2f 2x2WdKVXUi87olUuNCSAJ4ZzMUJiypAB+3WPOKyze0VnqRppg5q2Va8YskslVoLBdikKctOf OBnsxr94eHZqR08AahpUlpVOcokXLNH2QymLjOcB6as0cmFBYuA5f1TKhp5SixbuzmYh+5O+ eYZ3XC4RD1va7Rix0ZF7I8Iis5eQoPDkzmMkoJWGeK/dld7OG6MHMsrtU6HWLDmE0KVGYf1A lGpmRoYIBXGcpfCIyqLPazpWmyn5+ak6VOdlBywqJDNDMzsymGXONENbtNtLpVutTo+pqYOD UQ2ck+andnl9Z7uP7ScolrL7XWE5nehvbqlYF6yoxu+EwvHLKFKUsMp3drlfFBs4sXcl9ZrG itUC9vAnp4TyBImn1qiekgl4tZS14y4w9apYU9sihiOpJnVHpXAhPnlKzN9MpNndhxcNOcZj TawtgoB7YH1lA/qyjXpKfmLglzvTYpyyk4dOcu1pOKDaB5sVlB0tSrPaEApE1mADsiZDOecO frlZuK6WLujgY7MaPHTb6S6r3AVSMqBQqcTE/wBUTHAnhLIlP7QQp8pRS6psxrakqcLe6nQI kZIsoIigqJCPLmPUMhAlwgtbfpGVVTz8x0QwslQ+UyhhLP2pzycvFId2AN10uEpRD2F1OyU2 oqtBUJw0rfUTKa2iPLDimTilOWku/WKzZ3TY6wtAYqSJOyOkj8Jh36ssO8Ofxu4Rqlm9kVK1 OorJy2Z4WJUNR9Dt6Yk7XCDtGjnIPdr3RA0Gxi2OjKZs3plqX1IBMJlSmkKEwk4pmKJznuYc N90RdWWwUe8U+U1NtTuSBahXohluxafrXHBfmGClyAG/dxCv8Izq0Sw2sGe0BYz08gz2jrjk Ss87UJJcgzFjw3zldfdKc5axcqrsIoZnpNcsWu7u39CjQ7a8esLVyNw5mUX85Blzv5RaE1UF c2U1DUFGkv1W9MJ6d2paadscyk6pSbOWUEd0vjOeEM/GFUfabQbU61IestFOWKHBakWnvAm8 wsKnJnfkllhneEF24HX44oiG+w6zp+UMDq1KXcLasa1zh0YYZcqUllCCEkWuspCv5B+cNI7A mUdsa5qNk5FU2108W5qyZGSmMlUO+5PMznpKYr5e7Gi0DUlorQ5WO2hNqZ3MTONTVIJyQN+X fPZxGFzninddK/DfOF1BWzD5hHimPL9wql9fApQFolJOjdgFKY7hXaBu/wAISnsupjzMIa2Q Uq+v61dth/167Yiy5ikHFKWorrsWkvYFFSUUGgHYfRtVU8cqXP8AUD5JsEWZoDGLFuyl+IMt YC81faWw09VNDP1BuSWpFrPTxbArCeSIsrAG68y+d075yxd8aD576AHXFVqW2pykYHQhCUnc djHd1GLFfK6Qp3yHdLu7oqx/0cmFtqii2dzcV67Ma3FW8bOLDtBpGTcEqV192I27hwDGf/SI s9Z7PTKU6KJUI+mkx4lCQ8zMyzC5y1lOcr9ZCjO8WiobWqV86doFfoDDVg3BlkyMqbLmHacQ Q5h85+wEMw89Zx57LJyU4Qe6GHVA8lOIfux6ca/o5MKln2bJcD3XycKculhHYSNrHiuKkC66 7Tx0iB5egjQS7HLShqErb0On21U4ibyeuuzMsOMw3WXYlLnP5RozrYQQbb21UtT146bTtqRW 8KxHab45h3Bd4sIbroWDzxHyPTFB2BUq9uFRbT0kqCXVy1nThCdgkkTEynPMn7wuHdGXN9jl cOTWF4RJk/RqgQjSOsuVCSBHgEdli7uMXYM5j5G6252Po2F8R09Q9HuoNqcEyIp8PXZhQhjl Kc75cu7eu7AonlFhdEztbd6YB0wNPTtO7eeXnXbecLs3C9mXf4wHmyCN5s4sQJq+1tzQbE4M tJtIC84tSLrRHjBikXKfPXx4S+9FGoCjGqpKWtHO2lQQ4U2WYtTfq8kv2Z85zFddEWDPIIO2 WEfvBxQQCYIIIAggggCCCCAI5/tI6I5/tIBcKhMKiA7ErTZIDnQrH2Iios1n4P04VHmovXQ6 A77EEK6Bbf5MCJgsEOmerj4+sjoYxC4cwQrBH1XO5oI6cELwQWrqj1kJjpWesjmjRAhcEEBr Vg782tpbiSs2fGdulhPFLL/rXxoLhWdH5YdpcmpUqLDgLCSHqi5+9GD0HR46teNj2kCNOWXM ZhmHHp3SlE1VlnqlqRkKWclUuTmdrETdP9kXYNZ8p6SHSZqM57RZQcQcOG7aL9exzv8AhDrp WdMHI27G9pRDxFejB9mUvhpKMmpOzdY5Fual1ANCBCTP2dRCuvu1h2m7MVjlQ/Taw7o41QcH LCIv7OfPvgNbLr+j0zh/CqdYqwz6zFuEy4SLxz4fKIAus21ZUh41NTtqNiJ+xLL0Ow91+9O+ KjWFlY21OlBT21Oyg46QAl4ZSzPeMu5Bl3zgpuysY29YvqraCNn9WmSXTGK7xgNGWWi0f5P5 LbsSXrBBILMD2cXaFIuWl/jOOrzl0Sga24npgC5VkhAIssOgfjPSUowsujH5yLVLG1hUEN5I sGJXpPwl4z+EJ8hqtA3hWDZ8jOFhCWYZKRgv6vGAvVslYM7xSfQ6NeUuVGKZH+jhuLTglynP nOO6xeuWqnqTNbVLknbDRHyNzzC8eGUvdl3xVrULOvIOl2c45ZnuSozCrCENwCZ90JsroNHV qdxXuQ1BoEu6SkTds4Xff3ShWNbdLXaGOzwAcjfSvXqcnfCGUtCwfGDztUYBOl9Mzx7oSUgQ 7ieUuYp98ZrWlj9SI6kIQU825pSouQg5xnq/enPuCHnOcWtPYhTx1Ppf0qqzTCwiOcfYEO/W RYO7uvgJhRaFQC/CS8P22DJP2ogvDORBYpdkI+/xuisUvVtKoLTHap3KrTVxRyIRIjxJcvOM FyLBLWRQeAb5w/VFjlNpm804npBsSp1pKfPP6w1RKc96cg+PKOFPY+B4tsdqeRjNS0w0hAae eLfM3tZFy5TFOLHfR9pbJTFNriRvA1wzCxEJkQSdd4N0p4uUpX66xBeUlPE2d0eyI34fSrSv LWiEEu+RN09d6enzi00/YmyDWKs4laszHQwgO9dJMSHhfwvF+yK2ZYJVQKkyVOBG1CV9rieF Lf2ru+7vgLCXadSp30gDa8UvCgLV0XsQRCJ1FP7ofd/KM3twqpqrOuAuTIA3o9KikkJMUBuG ddrfdylG4o/o/UYvUOPoDgjRNp+FMXnYz1t3vX8JfCMYt4pJto+oGlG2gygLEE1BxeZjkWPF ddi5+MBa6btOp5tsvDR6k5UaoUJDClp4Q8xdgkP3AwxVFpDUsT2apkbqqNNpcrAtOEXuaylL d75ylpKGrE7LgVDRdRVm/A9CJSH9Fl4rhqDQBvmKQe6/SKyssoq1tovykcjkW6iCtOTBF1hZ QuF/K/wiBYbVHhqtOdGltowHWpcZqhWr6kFwvZ1jqoOp0Fm6cVK1sSndm/Ok4FkoDMz0kPYC Kcrru+cZzQdKuVbPHRTV2wphKjMV/ZD8OcXBosErw5nIXrtgasRE1BhagW8WCXfFjWW/6VZI OjgL0Az+rMm4iLD9oLsFlyl3f7nGV2fs51B1ojtFeF7UFvTqBKhJi1EhqLh+zhl7XhEZS9Gb TQdoy87KXK2MuWzHlmdWGXMyXffyiVquzJGnsvssWU2cFTUVTnZZgf10x3fIIQcJ6c4DYHD6 S1nqnKyW1yTJwhNHh2ftGClcH563zjD7D6zQUfWj0/VCctVFKm45IQH1hgsfC+fhKJpw+j3W yOoGxn29AaNcYcDMwzBK8uV8+Ot3jddHK32D1gsrTybApTi/Rm3lqwh6syU5zlLw1nLvgGKH rOkkFi6qg6kQOCzLdukkBZAu0ZwDjndoGXGcabUFt7VWzpSzUjGoRjMfEJ63EGRSdOSUK8V5 nEX7A6RmlH2IVa/N+2DWIm7rFOSSdfjOCR2xS+ekPK/o/V8TS6NfNSg21Rs+YkGKReTI4WGV 5k92+XGcpXxA1ipLe6PR2yYzmvaGdnKUFJHFN1oxHHzCIw0AeHK6Oqzu1GmKkqd9eFJydrbR OxDgHpE7LHeWVIM5y+GGXznGGVZZE/MNUU9TaBYndlT0eJOXhLmVIvD2p6+zLjf3Rotn9iyZ N5WgqFqQP7q1uydCmCoOuThJFhmMzjLjKfPXwjTGhJ1Z9IphWMbs2tXSARiEsAmySw3KJHCn MJghTluylffpKcUi1C1phqSg0bCgJVHupZyc3aTw3bNMn2gz4iEKffExan9H9WjrR6WMLkkQ 0mlLGpU8PQJAKCPBLjMQha3aRIsdGWS1VTdN4KYGygdHJKnbDjPrbmAN01BopX3yB7OLv5R4 tAUnb86+WC54qrGEChnm1kiQB1TXzvzbp8Rznva6Rbf/AFLMKNYjG2tTkfkkkIjFKnjswNRi CCU9TRz01nyjP/pMUqjph0QjbaVb2JvErVJSTkh2PaMsV0scvZndEJYPTza/PFTL3hNtiWm6 fUOYUWKYJKjQy3QiFLWQfhAWlHaFZW20Osp5A1PhQVR5ysxELCOSo0U55MjTBSnPAXfylxlE BbRW1JVysNqFGgcgVIuyQqc4XoyYBcrurlzEK6XhGs2B2RUe62eUQrX02gcOm0ixQ5q1AuuD O+4uRcr+XhLxiit9hQ2d8QuVVPyQdJidEqckzQG3yM9m+/QOl198aIZlZ3UnkfXjTVRIAGjb zJiw+ApYZ/snGn0Pa7TDIXUiM4l1Ronh+6aLEmuGYG+68vlppF1tIoazRhdKUWAoZOpcHYS5 OgayPVKDAiDIrNFylKU+MpRMU/ZXZisrCpBpqebRCSr0LednXySBmL1uR3iFPduv0nBan1J9 IlqeEDw2+Taspvdk520hMUYzBHDkEJevAIABlqGUrpxGeeWjPI9LSalteHZtUKUxzoSpM6sI CJhFcXK++eIQQXyvlLSFeb6j2GzC0yoFLalUmk1KoaUBZx100RQRBCCUtJ3may5T4Q39ISla YR0Oe60Az0wOmG0SIClekOxrwzFOWk+Mu7jP2uERYhIGW00T5YOL2man83pZAegXqT7swsod 2AJQL8OEEpaSu96Ik22tknUlTPA21eUnXUzKnGsjFiGEvXrThd+sS1UWTMj9bVS9P0um6Dpz yTIenAIbzTMvNFKcpcZiHOWAMWsyyOkk1cV8pR08zjyXJrToiHGfUEljIKEbxFxEKc/h3RVH +C2QWR1/StAU3tJLO5LKs2Y5OWZnTklFmSulfrdLDK7gG+ETr9narHKZo+mALyqiYV/SQV5p cpFZ08V93wxafhiJt4ZEFPW4VXTzImyESMRIyySw6FyGQAYuHK+cRllbOmqS1SlmFfvIly8I Tw+8GWsw/OIGyl/SQTHGU6NeS4LFaFuUJF60IZAmIw/LvMACWm7g0viqVRaFR9W2gUWN7QLQ 0nS5JoRCUanqxC3uwD70gSuv1jVLTLE2R4pNx8m0rExvCd8MJSbMHtFSBukC49YKd3dxirWQ WDyBaR/xg6oFKRnJTdJN3/6w8F4Sb5bumk9J8wwsQ89vmB1cHNSSTsadYpGaUR+pLEK8IflK PQyf6RTBsYMba6jUGNZbYaSHDkhJl2xB1vmIUtI46EsmbfIi0qsnoCU0KpueegkIpakgImIG bKX3ZyBLhFsqyx+mx2LlNtK081BqLYmgCZTiwHbQeaAIzDBT4XynPTX4QWrRn0jECx4aXVyp hQV0eYoAVlGeoSHBkDK++LSXdHQ1/SKo9NXDi8Apt16LVJESfDilM30WYhB5/e5infDVN2Ms lE1gjWV29pHNsyVJOUrS5JOeHdCLWessXDSCkLNSHq3cIKtaqbStqenulUiBtFcmVl33ANnP uv3pxoI5nt6YW3bFnQK3aAvyx7QEYgXCOPkINxguV2PiGV8NVhb309ZuOm9gcCFpyQtIcIm6 RWEM75ixTvFOc+F18T1ndIUy8WYBqNloNgc3KoXJfkplRkw9UXIWGRW793uD2ogXSxomkvoq v9QvBAFlUnFplYRB1kgKEcEOEIpTwinhx4uPGMxBulpFJAptlpWm2p6RtRL4Q7uZh5mZMWXx LLlOftfKUdJdsbOdaRXVSL2pwC31ciLRCLDhMOTlgBIHZnu8uekQFojIzk2KWb1k2o9hUOme jPLD9plinLMn43yjNoDfmP6SDkmtQVVCsTKiqYycBDOThMMFcHAGYhz18f2RmTPW3QlL1qjQ Jh9JVgYICkwz1aZJOc53S7xzxTl4RSoIgJ7H9WEwuCARBC4IBqFQQQCYIVBAEcsdUcsAuHYR C4gKi22bg/Tn/wC3FVi6WXg/SB/9HGcg0ouIKuF+wMZ/vmbgYsEZ3aQdtLwQ2g/rR8mjnW6E VggjpyYMEfSZOaEx04IMEBW3D1kcsSjwDrIi46EPkEfY+QF2snqpHTFQbYs3QCLwYvd/LWNP MtgpgHqRuC5QX2ThF3Av96Uoxug2EmoakSoFJwyihdrL7YvCUaZVllwOixDYUAEJpZ+HeOx5 gOXPjOLHY32o0qBGeSdtvWCx4cu+YhT4wvzqUr0GUmGBaaoD6svL3Aylwvn/AKRBUPZcd0wb 5T5WzpS+uLLM1CZPlP8A8x1UvZimGzvCx7xhzDBhRBxdkMv9+MBNeeOm0yjGSSqNGdcI84wN wC7uQZS1n+yIV0tFp51qApS5L33o9OHdLLDdmTvv0BLly1nyiTqiy5q8myCabbcLkLKCTmHb +vaEPlIMc7HZcjp4w9ZWA07jxCmJELKLEL9k/nAd/nvahpz/AENWR+pLJDjM4XSxTnuh+UVm pLSG1eWQsAStNek4cJIeBBd3MQuM5390ILsuqF7WKlgCW9nRB+rFk7+d4/6xNs9lGwUm9HPY Cj3UwswKDCK+Rc5cJzu8fjAV20S0vywodpYVOae4JTJGnq8OAAp88MNWX1ygpJGsTL9qylXa MI9Z8osVoFmjbR9h6FeTmqXoRhIla0XDe4lhl3SiEsHphqqF4XDckYHHZSJiIIOFgKxcpinA WxZbq2nJxJiWFVlCDIBxgjOsMLl9nf3d8I8+TamLK2ZnN23DIkOIXVJyZf8A5Th+tLHOkljT 5NnN6UZybEfl6F6dozwDKUTDHZvRnkulRgTbVnBHiVmB9IWjl7Qb9AADy01ixV3y2Nkck+x7 GtFtCkpQtPM+5O/CWGOfz05NpHlOgJVIW/TaSOJimcuHwldFzqigKVJp9cm6ESkJUZAREZf1 gV3MU9Z6z+MJZ6Go/wA4CpT0IlEBPTUjSCBeqCZ70++fz+UQIRPbwg2wTkpYVpvpe1kJiTrp Y/Zxi7offPpFKXXCMbUbtWIPZFgTlglO+ektRzv74gKgsxO/SNVVCsKZW/dCkISF45nX87uU Wal7H0fmPeHIAAO1ROhPoxwhaIi77g/1py1npO6LDRf0jSU22bMyKM1yFiXqzDN/uwly5XX6 RllqlZ+XLwjUkoOjkTem2VITmZg7p6zmMXOc4021mz2nqJsspRBkAcFRLwnAvP7O04pay/DF K+kg2oGe1DY2pMBKlE2EDCWXwvnxnATVn9tJNK0H5NnMI3EYSzCiBZlwA4tJ3wmoLYxvFFm0 kjZAJVDgQBAevMM6skiXHDL/ADjH46WtNt7ojQA/jR4CP7U7ogalQb3Tdj7x5TslQ+VLhs+z hRZOUDXnMXdFhqz6SCmpGtzTLKVAEa5BNB6zqwyH2hd8dX/pjdSXBzGseNlb88ohuFhljOvu vnPulf3/AJRVqLpKmyfpCNNKo3I1zASI0CvPLukE4Pw/z+cWKlZ/WYKSoOqaYA27YOoCQpxH iFdIkuUu7nOd8WFjta6KpOmWTyeTrFFNnSGgWnC9TKU754Q+8Lviao+m6f8ANJbOpUgEqd0r hMorLL3g9Z1eH4i4y10h3zGks9mbZVrq8em7InXiTi9WLFOXU3drXhpKPbBMMFura62qMtQ1 GjE0trWWoNOMzJnGnnmAwyCEPAIfhHGx/STfmqpH11Gzp3EDgZLZg9jJKB6uX7Z6RZ7dLEPK evELxTGMjpBxTpFKYsMsssvIzBGS924Mud0Vh4sNZ2GoKpUvFQq/J1nRJ1BeQXeYdM+c5S5X Tu8NfCLsQmKAtxZGSmz1jrm7biUiIbCybwYzvv8ALWd4ucVKqLdV781tyNSwgxpTihmGBUTu FIE77pB/Zx4Ra6Ls9p6p/o/uqMCk5K3tNRmKjFpie9WYQWRIWWGV0sQpzFwjzyxpumHhuQY9 l25SEnEL7OQp84zW0i0i2N1q1QxHIG0DF0KdNUSIJmMwR0+d/KUvCCi7XXJkTvCZ+QDqbpZa FarzjsvEaG67s+zpwiTtMsrZKMqSitjGvWIlz4QkU54pTl2paTu97u+7E4Oy5nrG3u1FO4r1 SYlpNTmlhT3faSlu90ro1QjHT6Q9QupZ6ZYwpBIlhZwVZGZ9YmbLDryuCHSWl8cyi2wGzsuw UA2pVTHklIlYjJjmnKK4BD3Xxa2j6ODPJ0Egcn5yPGcrW5Iibrk5RMtMzTWYp/CUU2m6YJqT 6N9AoAdQqdq7klPV8RhCLHK/5aRktBWyWnLLRejCTmcpsSt4jDQllmY5nGj7QhTiEs3rBfRj wsWIExSwC5IJIpTGdg4oXKfhF3+kPZWw2cJms9ncjj9qWnJjCTDMye57U58p+F0cf0V21G62 yBRqf+krJkiw35Y8F2LXTSU4Dvoe29ypWm2pnTU8nPGzlnFNx+0TBkSN7W7z8L9YaqC297qF H0a6sjea3hPTmpk2KdyeRPKU+M5i9rW7wjqsTsWaqzsjIqQ5yWlOSgxUQWEPYCMsIhyFfdPu iyf+nZhUoOiiX1yAvRnNpS9Xu4DNow48BfhK67WAgi7eFIHxpcgUM2p07SmPKbSAnTls8z59 acGffO6Gmu3VS2mG7NQzRsucUqSIs4WBOcX2DMXaFPnONPtDslpupKwommCZqEjQz08vN3RY DD8kwosN85+M75zuiho7E6YOtsVUr5VZTQWxdJdqV+IUvfnpMIe1Od8EM6eLRVjrQbxR6xqK PG7Pgn1avDi3VI5ynPCGW6GV0dlQWkdJUP5HpqYRNLeqMIG5mEC31+TdMMp/OV8elvo+MLKT ZvZ+g29OICgtwEYAskNznvDliFfLFdKU79Pu6xm/mXouiZtNfOqxe5sxzkiEiS5PZkKc5izA 63y03d7WC2bVxbAvqSrGJ+Az9AKGsoBIS0gh3qSACkIJU53S3f8A/UWEy35yXujwscqPb1RT ocQaYiEoHKRYyQhCHx4S15TjRbY3UCCdn9QM+A9WsPdMLkW35pqdLmSvmWVhl2QTuDiD84y7 6XACQW0FDJAEIFTGmO3ftL79Z+MaCC85y/Mr54ckYFL7WCaScxR9mkTSDhGG7npgu7sEVKj3 s6mKkaX5tBiUNpkhkZhc8AtLuMX6nyQIPoqVW/JiZbe5VCQ2qzsN8y0gcM7u+Upij0y/0/TC 2VYUesXYGVO2pkpbckQ3zSSuDdhnK8QzJzFwu92Mxgaz6RtT7OaBtptqbBnHDUZ4bzjwqTJY BHAvvlKcgXhlpzgY/pM1I2uipT5Nt6w0RJQBFix33lSnKRo53YpinfO+Lcx2cUxY/V+ByWK1 j0uZ1+wHiJzS0W+EJQ5Tu1HIPa3Z3RdnRaZT9pyhUQlby2hK0t6uoahEnvmolrIBJYZSvmI2 d0pSlPnGiGHtf0hHsmj3GmPJ5vVJV20FCM1lImSicxGhwylh1mKfGAz6Q9Q9HpdgbW9KoCYm 2leXfjV5OpRc/CN1YwNCmzcKklkA09NJn5aJrMLDgMFmCw5opBlhwy7pfOM5McKZo2zCw1NO Wc2qFAnNYEKO8xQIFwhcJXzuEZdLvlhgtRKotpOqF8QL3uiW00pPnCEkPxmbSI2UpCnPFK6X ylzhrz5OQ60XVIOm0QlBzH0EkQBzMtIhvvnLheK+fOcb0xtvlDWYLRTngaptManU5jTLUISZ tgpDDLFh4zmGWl8wz0izlrKPTdAE7Sk6aeiU4C3bZQ5igvPukG+72uzK+CHleh7XXij6PQsL azojzW3O6LcVHrEUz78wQZcL96cRXnIfvNO7WenYlxTwfI9SvUqBDNLwzDPCGXC7djTrW7NK MYXN1fn7pXaqgdnETYU2E9WkkQK7eDdrfPXhKUYGnRrzqfPe9mH0enOCnPPw7gTBdmXzjNaY rCrVj8jZ0AySkLQwp9nbkBOoC7+0bPnMYp8Yrka19E9AjX2yY1hJRuwtKlQTnBvAEy67F8o2 e0SyhntIY6WAme8DqSmONCvyZA2gGdK/Hw0DwDO6cQPHuCEGbhYh+wGPWVmlmNPUkjrR+xnu KhQkcEreScG+RJZAPWT53inzwyujgaLMWWmPo6Go8EnFY+GM6hUI4F3rVAOqDO+XLx/tRdg8 uduCPa1qFANtpZaOm0A06MomqREnqS0sg7MWSnEKZIJS79ON0ooLWyUNZQ8OZO2KukHZAECQ wQZKtmFMWk93T9+sMY8zw2WMA+xHpum2Emm3S1uoanXp3Z/Y0BIilIktxZeYG8OEEtL56Sl3 RIqKbG5WLsrJTHRSBasp4bmtCYjl1khi1Fi175+9dDGPK0EeirdKJpuifoxtSantlccLoTnu el6qcw3zu4zkHw8Io30hECZMXRC/JKIcHJnkarw/s0/8xAyuCCCAIYh+OcuAXDsNQuIDsX6y v1iz8MooMaJZX6tV8o5+o/rF6MHkpxHD9mM8osnpurDV/sB3v8on7RF+zMYiQds7cjqs3QbM x53tnb3yjhj9L3QgsEGCO4yOeOtzueFYIdwQ7ggKjVMQMWirARWI3DUEOw1GgmKXe+gXgheA GLLjRvPB2ujWHfFvmHHnY9+fMPdGb02jTLHxCSpBiKEeHEH3vCN9qSj2dyTrkfopGHCEslMT qT3S8ZzgKU12u7Hix09m5gezndqfeKcKLtgOJRnpugShDOv+03C5c/GJSk7MW1BUhXSTltmz k4xEhDfv8pd2kuMTlL0Y2gqCpH5TgN2g8QCCMP1cAgcfjFill2zLwJygI2ooI9M5SIV8xeAZ cJRwPFpfSTwFycmEBoA/ZiUTHMzwnyu8JSjTy6VbVNHlMiNAnINMQTCWEIdA/wA6IXG+IxHQ dJWbuBDksU9IqAl4CwndZiHOW8LBLs3d8BUjLZnX7ZkK2fQJCYsyZYNOEpz7U5d904aLtje+ h1TaBqTjNMvDn63E38cIZf4xeaTp5H5xCKhqFZtwFCI81ESYnuyZ9+CXC6XCIOz9y2/ppSNA UU0EnzCcZ2TVakWgCvhrwlAUNRXjqss/8khgGelzs0xWdfOd/KUuUpRy0XVp1KqDTgJtqAoD gOL4Zku6NsqRGj8256YDaUjN6LEPZiw3Fpvxz5mzjNfo5kplNoBQzgFCGWiMESI7gWO7tfGA 7FlsdTjL2PodKhS6dRrKZgA8C5i44e+PhdsdVbObszUnEq9pTlznkynxkAMtJfONGqSz1krB rbP0kbuhMGJxw4erlPWd37tIlqXZGRAxhZ0CDKS55mST9oo09aYL3YDGllqL8vb99k9HMw7W p3sxWEPAuYuGGH1Fsb8N4IX9AousIkUWSHF1xcuV/GYfCUbG4I2cCNUTgAbs7KaItEWXLZQ3 X8e8Qp/+I4GdMSdWlHvClMVjDSRuEWXoSbP3Zd90Bkyy1eqvSgPDUlPNO9WQpLnIpP8AhB4c ojKbtIqdhRuaZMMBo3YzEpOO1090IeF0aW+UA1ATn1bU+1OxuQHIQcw4p/d7U446fsfbVlnd TPzqSahUYThpCMW+nkGWmLugKfVlqlSVOxtyZ1aijWptVlD3Qi9IOl2ZCn/lEJaZUNSVU6EO VQtWwjLLyiernLTuvnG3tfRSag7FWpGT6Kcdmn4g4ACH7Qh6a73PT4xy/SUA2jsvXKUwzTR+ UYcRx2mZPX1cvc7roIYdTfkSBOaOqgOB6jF1IU2kgh/xnEwjX2YoMKxMzvB7gSZmpgiM0COX Zv8AhFisHo+m6kb3ZY9ptuWliwEk65ZMu/TtCnFwR2P0xujyR/o9AuEvDmX+k8Sg/wBWUu75 wWqJn0h7TjsjOWIhFEmZoQ5ftS7N8+N0oozPWDw1VwbXJOzmvphgjcwQdzMFxnG9F2J0Gvpd iO2YKPMLRnKzszXe1FLWektO+MatkRtqB4K6NpjoBKEw0gv/APVyDO7Munrd4wDFN2kVVTyh 7WNSkopU9CENWZh9oXGYZfuiTdLSK5OpNuQOX8EHYcs44M71ICp6F4vcvidsDo+lakpdzWOq ADi4Z+AITL8tOXdfK7vmLn3RpHkwzvH0Z0oHtMDAxpHA9Idi0JGCc5F4e++7u5cYsZM6W8Wk OTojclK9P6D6okIbixTn70pQpwtjtFJqA9Y8DSCWqCQhOIOJlIGDlfKMpb1IBqG7HvYlBOIP 9aUeq3yiabfvpQVcS/NQFxRNMFL0xZgp4MwEgh5eP/iIGNN9sFfoEZqZA6pys48as4WSHeOH pi4aXS0ldCW9TRhNLmvaOjFqpwb8Oa6iOnlBUi4Tny/8RuvmZoNA8LCQNSJdtjplHZnBATs2 Oc5XT03vewyh1ws9phB9HNdSVPD9Ccj249WvCKUxnTGqBi+7ugD3iix54qC0uqn5waV7wpTm 9DnSUJCQhwF50p35k5d98LLtOrOT45vpbkDb3YRc14sO6Zg7MtOXhG/1hZdZKjqSnUHk3ubf gLCnvkAwsJU9DRa4t7enOUw90U99omz5nt/YyamLSN7CYziViKK6sBp0hTlv63gDp3xqjIas ztarPybdlKOm3Cono448XSIRZZQTTJe7Ld3Za3S7oyJrrOpGen0LCjX5CVpW7eWHDvhVS9q+ PS9h4Ke8i6N6K201vJqFaaRk6YZTnO4w3uCGUp693OK3b/QFGI6Equs2ttRdOKiyxBJCo3CS hKPrH3zRd184LZq4P1VVhVlOprQaecHpOYmMUNzWSn2fOkPtH6Sv4yvmL7l0dKDyqZa0Ur7L 7PVVPKkqLKUiM63dM47wt3hp/VjbEQFfnXoZ7ciZ/wDxvlG8h5/OQfvcYkakdThvhdEpqVVr Eq5la+kTClkizWzCMXVjF2jBB7U97hGQ8vNdc1tSqcTCgcujtlMOxE5cp5Zo/W+GLlfEwotR tUWU+hwOSsaBK4kJyTSU++Yp4lF5nGc/C+KpaQ2pmS0SpmRAcM1KhcTSCBGCvHdLvnznKNpp eRPkv9Ho5MMGxNzwcF0Di3S1JgpCBMcu/QesBWawtFtvbXBM91VmoMu9ITmJwyL1uxBEGWl8 5y5xQ1CmqrRawNOHtT0+rg4jMgP2QJdwdAgDL5R7FeKepV+pt6YXVGPZ11Qr1RxiviXIIB41 Rcph7IeAf3xRaIbWKibRK58m2SWzoaECe3rQHaKCwhvnMXPEMUu/TBBDIqPq22lnos0mm0a0 pobc0OZschzTXesw4vC/hHK4VVbMBrDUK/pXYnw9MPPEX9YHL6vKXOUuN0g3SnGh2MSrGVjp 9QKRnqtqSHpWVFd1JZIt5WrM01HeEQZTHfFut/QHL2dxfqWOVI3BOc1ga1AVkpFKxD3Z4ZT3 QYJSv+IeEe8BjVWV5bKz1Q1LKtzUbgIsRLeQajDIu4U+s3JaXzFpO+K68MlpdW1o+jcmR1c3 pGIsC8WXdk3hvLL7g6cJR6gQUw3PCOgB1G2yA5MLW6KiGdeozDDFQTipSmMeohayxXyCKJxv BgtMrUexmqtoqdqF1J2CYSwJSutFPF2AzDO+X3eEZreQabR2keS7sSyM7r0QqxAXl5frMvWe k+N118WnzhW6pqXSvGNUhbQklem7OHGIrWReMXanK++PUFJ9FHPlMrADmsyVTv6SRupw4zDB TEIMpSlvS4Tn+cU23M1tIYrVnGQ9xcypwlqBDxFKJzlIIAlz4cZT0DzjT/QoebW+06uUZiMY HvN2POyAnFyHLrp4jZz96Yp85xZKHtFtvUrHZZSozXNQcYWJefsoRyLndcUHe3Q3S4BDGfVB TDlTbXTpzllfphukrJCWK+YZcN6N6+imBH5pHYBxJpojKnLxFk6YpSBLDj0ncGXHlwjNDK3C 0u0tM3udHr3gaPMMNA4kCTyAbeL1ofC/nHGsqetjqbYH4479B02okkZzgk9WmMulcG+Ws53S 5+7HpK1eg6Pcl7/Uh7IUOpRJ12yJhHSzFoA4QzUXa3BK/DfHVaBQFJAoSiaMTIyCqTDVyQW6 Z68rZTJimMV8+2ZfKc54YtbB1FeW3r6kZTvTT1CpAM5uTEpZZBiac+sMwS0nfd2hRzKLVLV6 eqRZti8Dc8CLwGFmIwSyQ/dlyj0o8dTXAfQNgCXQC5OUgLM10PBgLDdfO+4PIIo4XChqJfq4 enWoW1OuNTp25AFId12wFSKxGF7or5i+8LhAedmeobYx0Gb0Vtp9OqM0QloiQz43zNmEQvnf OUVnpKp/M+jYUbOoDSpjpIe0llznNSpFoEu/hy5cZxuBaVtrCgFVMjph6Z6Wp9O6dGuIXDQU pDmK4YOfZ5ynwFEi3OSNGk+jw1IU40KIyYlQ+u3NJSneL8Qt6NBgBY6zsxeCl40CplWqA4A5 5Prpcw3fGLE6WhWwL3g9hUqVAVWWFQciIS5c8srelKeGWLDKes5RstSI6MQV5TdW1y5KgGnL 1+xNh+I0vac7CWZdoKUuHs3d04jqgAcD6fmPacCXYCzV4uAAlBTa4p92KUozGPp7bLSyW9cm JqErKdLxKRCSh9rjhlwD8oaMtgtFHT5TD096AThEHq+s3ezv8dIpDocSc+OylN9XOXnjIw8M uYtIZiBfVFsFoqlYhUjewB6Pv2YksnAC8XamK7jOcJT2u1yS+Gv22N4lpxeV9Vll4ZfdigR8 gLf5xawGjf0w3Ik3yiu6WMMJlebdoEMuQQh5SlDplp1ZjpMVK9JAC1GFyKOwl9aYWHgHF3RS 4ICwqatezqPQ0Yfs/QDednlJsP2l856i48ZxwVI9utSOgnV7U7UtMuDiw4JXS4SkGWkojYIB EEEEAmGS4ehkuAXC4IIgOxqtkaBSczqjiScXWRlUajSbr0DZuep9sRgsv4xhP6CLqDaahrgp qJJxZO5h8eca4jp5eBOEAEBu6GKPYm1dYe8Kd4YuzGwF44+ZPw4LYzHPHdghvBHWhywuH4Is VurAejxTIv8AVAPQ4ocdEYRHyPsfI0DidSNGYE4nth3ovPl5WZLWBSAkKNOLsqcnUzxxTihx o1ohykbXTKnfyk5PZ9i/lp/pAcqOtqzTKEuAGaMwMxEBET2u8XjfD5loteNShUA4ZRC0z1mY TqG/ulEtaANf0pSKwnHjEXIJmX8eEXXyVoxyqBc8VhvDLIKKCHMukHw8Z/7uixk3nFq3Y9jA vAUVixCEWHrBXcsXd8IaUV5UKnIzlKf0X1Icv9s+c5xsrpZ7QyMzJbWoAgHEzOPOEZfl6aSl yldFPeKepVN5LM/Q5WBwDIZ5+ZrdKfOcBSvLyrTngS/b8S0wuZQRZcurBPjhDCWuvKnZ0+xt qwogGKYvUynPGLiLX2vGNDrhqbW2qGdNSSAoCpQdPs6AyJcZ3z5d4tIzC0AbUOrFnQn1f7QX IRvtTl4QCnCs6nWM42c5yHsRnrgh4nfiFxuiMZ3VY1KNpQbpsR0EQLW4V/WC/wCsvZouHVhD cDThK7u8IPLyrcs8AHtQHaN04Xtil3X8peEVSCLFkMrOpDmvoobkPYvaJ/WeAp8Zy8IfMryr TlBRw3gfU+pDhlIAflFUggLP5eVgBYav6eUbad9uK6cw/h93wujnLrCpwIxIAParZzvXBxes /FPnEBHyAmVFTvanZc5yNEBH9UL9gn4SgqCpH5+yAPDqoWFJ/UEi9WX4yD3+MQ0EBMs9SPzI WLoR1NbsztCJ46xYmO1GoWGlzWFqAUHOLEAxWZvmb/bnL7wu+cUSCAmfKeod39NqhYeziF3c I6k9WuXTHTb3+n1QS8onbdQFh8JRXIIC0OFc1CcYLYDuhSjA4BEINyV3O+OBRU9QqWvodS9r RNWnomZuClLlPviGhuAtzpWylY1lICWdtQ5eEQTiS9/diHMfnsag1Yc8KhKDgyAcdmaiBLgH 8PhETBATflJUIE56YD2tCUq3Tw5nrJd04PKSoejwtXTa3o8veCmCZuXxCQQE6ZU9QnGEHHPa 0Q0v1brPU/hjhdF6x1UCWOqxQ4qDO0ceLHPThL4RwQQEsjfnhAnEjQOqpKnM9YWUZdIUJMdX I7FnL1RuZdmYjL8Ug9mXwlylEfBATJlT1IcYQpOfnARqf1AhHer+EJLqSoSVB6wl+cgqlHrj 9onjF84iIID7D5axSAsJIFJoQBFjCHFoEff8Y54ICUWPz2vLwL3twVAw4MsxRO7B3XQnph16 39KreuDIB3XT6wsPAuf3Zd0RsEBKdPPYG/o0D24BbxbokwTpyLFLunKEmPDqdsuc6uBoEe8m CI6dxM+8MRsEBKdPPfSHSXTbh0gG4IVO0TzLpcJXwdPPwM0YH5yCNQHCeZtE7zJeM4i4ICQ6 VdQNZrUB1cAt53rEwTp5ZnxlA4OrkvRlI17ktWJSfVkHHTmAPyiPggO10cl7qoCpclI1RoS5 FF4vZLlwDLwhbe8PDV/BTqtbsXa2YzBiiPggOvbFm96eq6wOAzrp7we6fhD5j29nZQDntyNA T6kIlE7i/wAMRsEBL+UlQ7YFf5Quu1B9WoEqnjD8Jw0neHhNm7M9uRA1HrxFqJymZ8YjYIDt 6Vdei+iulXDo8XaSZ08oXPWUBjq5HGFDUuq00af1GI71PLc7ojoICRUOrqpdAuqx1WqnAu7L UnGXmF4eGGfK6GlDk5HZ4znJaaNUHApEI6d5wZeyKfOXhHHBAEfIIIAhEEEAQQQQBBBBAEEE EAgyGi4dMhMAuFQmFRAXEvtIxt4SR+qDvBDERDmcOAvlP2ivbUnCmJTJRFF9ndh3zl1UB0Cv OHiK/UB7EUDOHC84Y458Y12E4In+gXX/AKUq/wC3HKYgWA7aNR/25xwZdGnbVGQuO7ZvfAP+ zBgjS7RHbVW6kJ/R4ozcyNZfAfos38MZWZHXFr3eGIRC4RHQGjI7OmF/VAGpNEAvsh5B+Ucc fICS6ecswJw16gRofVixer7roa6VUj3xrFAva3hc++OKCA7emFmXk7eqyvaDmaC+PfCTHVSM zOGpNEP2RCF2fhHJBAdJjkpHiGNSoEIQcIhCMnfd3fCOfOhuCLCs6DOhMEQDOgzoIIAzoM6E wqLBnQjOhcEAjOhedBBAIzoM6FwQCM6DOhcEAjHBjhcLgGccGOHoIBnHBjh6CAZxjgxw/BAM YxwuHNyF7sAxBD+AEKwAgGYRvw/uwrcgObfg346dyDACAYxjgxjh/ACF4AQHNHzejqwAhWAE QOPeg3o6sAIN2A5d6DejswAgwA9+A496Dejs3IVgBAcO9Ct+OzACPuAHvwHBvQb0SOAHvwnA D34Dg3oN6O7AT78LwE/rICM34N+JPJJ/XQjJB78BHwb8SeSD34MkHvwETvQuJDZge/Bkg9+A jYIkMkHvwrZge/ARsESWzA9+DJB78BFQRJ5IPfhJiYEBwwqFYIVggCJQunn47fJZ1Qge9hjj LjbjKnRk0+UjAp9IyZYfyjnkkxjK2+lXIawIF6YaMr2hGRNVwz0wgayAMh2eoMFvCzMfjEU4 OSwBnp+blYt0yI7HnOAMmDofoUXH3AD3Af2Ya3yTMEdEfy7vq+//AAb2ZMPtpiv+3KGzGpq/ kCX/ALco7IMEZ5dUdtGd2uNrUjoNxOJQJwjy572GUeI/Yj3Rbh/8duf9HHhv2I/c/r2veB8b q/dzw3DsfI/SOQ3HyHYbgPkEfY+QCIIXBAIghcEAiCCCATCoIIBMEKhMAQQQRYRC4IIAhEEE AQQQQC4IRBALhEEEAuCEQQC4VDUEA7Em1tpy8zc/tco428naVASfejQ0abZiwgBGEkgSz0G1 KcO3vYyPvFhjsqSyjZi86nn4p29rLFuThwscSidSMEcOSsY0oJGmUCJOBhGHdEEUMRodpCPb E/SWDrS/WfelGeR3RgghMEbhULhqCAcxwY4bggHMcfYaggHMcfYaggHYIRBEBWODHDcEWHsc ENwRAcggLxj7AMQ/dDHQ4IF6AzA5IFSMfs55eCA54IbhcB9xw5H0sk4ZYxgTGm4e0IJc5w1A EEfI+wDkEfFADicOcmNKxdnMLnKG4D7DkNR9gHII06h7Datq1nE6plje3FfZ5/Eyf+EU2tKP fqPUZLwSDCLsnFi3IzyUCDghqPsaDoLjdS6bQPDGjzgZRuTLrg8eEYUXHpelyf0Oj/oQ/ujj 6v0GWvjU5U9uLE21IhfaYdwUVum6bWVI4CA1ZRQ9cIRRuNoB2zUms/o59qIn6PbIT0WavGAH awhjljn4XrerXhN7YI4Sx44sygGMuKs4E7Moxx+FkjfTgkdhYI+x8Tjxw9HzXeplrBOdQbiD +bjwpgj9BawTbTTa4n+ZnHgp0JyVion3TRBj9n+uycHyerREIjqhqP1bgMQiOiCPRzwQ7BFh mCHIIBuCHIIDngh2CAaj5D0fIBqCHYbgG4IXBAIghcIgEwQqCATBCoIBMIh2EwCIIXBAIhcK ggEwQqCAmqP/AIYK/DONB7cZa3nbMoCcD2Y01rUkqU4RgjgnWDEx3biRRtrkNPjyR73Zh0uJ otYpy8GPcjhyNVUqxGNNTazaf5POMkjRbUH4A0/Q5I8Qxev+7LujPY+l0jI1BDsEdaDUEOwQ CIIXH2AbhMPQQDcEOQQDcEOQQDcEdEEA1CI6IIC0WbnDQOnSRODaE4sQY0O1ysx1bT+S5Jk4 csOIOEMpYZ/KMYTjOTGYyd2H1i9Ys9cdue7HJXQI+PpfrAQ5BHUN5szqpTTDGe2pkBRpSjtC EG+MktEyfKQ04kGVnbxgfGOVO9ryU+SA6I4wYzjMY+3HLj53hiLPZ/uOgVmDNGT2QxXIeRqT kZmMkeGNxtlpFZnVhT5qZ7bUocPqTCi7phjCYlHB1WL+2OI+MIKLA1ErTZOc4f3oj4eRnbMo zgezG42dve3JMzhBtgwgM7WGICrHs54Z1RK/ewh3YrflJ1e//ZiHdHIazc9iPnUQfytEw5BH 2PqIPpwdZg96PVbOjH0ej/oS/wB0eY6fJ2l4Rk+8dKPXKcnAWEHuhlHwvy3UY3X08amWiMLq 8U+JAgwYxRN2bs42GnwoFPrcUT+CH4/P+fXZY6vHbbEQ6ExMQ2ZGEjlU8sezKMHsRLRzuibt Rxt6n7EcfNkfSjSKgGcnNB7wY8N2mMhzVWC4kYNwRkxBj3WXFPrSz1hqovA5A3/1kdf4nr/E c/UR5HhbBDGCPVBn0cqe9h1VBjjM+je1ew9qo/X6fmulcOCt5hwQYI3CrLMaGpvFtlVGiUfq A8Yq9P2dOtTmfoFAbsX8pO0B+fOOry40Y2b4IMEehk9gjaAsO2PZppv83pKDzDsmX/CSr+1G G7QrwVvO2CE4I9F+ZBhB/HFH9qOUyxangfxlUL+tDdoTBW8+QiN4UWRU8D7ZQL+tFWqSlaVQ bhOaeo93Mjo8+gxsuhEaez2egWb6zGUD3YsHm0Yf53+1Dz6DAxCPkbl5t6e9w3+1B5vab/Um /wBqPNzoMDDYI3Lze03+pH/ahHkBT38mH/aiNzoMDDIMEbt5AU9/Jv70HkHT38g/vQ3OgwMJ gjcfIangfxP+9DXkYw/yONNzoMbEoI3fyJp7+QQnyMp7+QQ3OgxsKgjcvI+nsv6gCOFYz0eT 64CUP9aHn0GNjEEaU6eQYE5uTlZuGeXh74orfsxKwW0gxAyd34x1RyM0fCY54THWh1QqOOCA 6oVHHCoDqjuRrzkfqRxDxcKLX08mTm9MINqHi3fhHPIH09YHA7YAChpwrB1OLwEjAR+GJvpu if8AohsHTdDf9EHHF/w6FAj5E9Wi9hUlldCI8jjnYoqmOO6Nzu2CODHBjjQd8EcGOFY4Dugj hxwuA74I0xvXWaZYSRkldmWIQr+MTSfzbqexsW9HDr1fZpjYzH2N7Lpij1PqUaU38Iof8jKb 7Y2oEc+5ULwPPsEegvIylf8Ao4IT5E0x/wBKKhudBgef4XG/+Q1K736KBHzyGpX/AKUD+1Dc 6DAwGCN88hqVH/8AW/3oT5B0r/03+9Dc6DAweCN28hqY/wCm/wB6DyGpj/pv96G50GBhOCE4 I3XyDpv+Qf8A8kHkNTH8g/vQ3OgwMMgwRvfkBSv8g/vR0+bqkv8Apv8A/JGe7UGB57wQYI9H F2aUl/03/wDkhXmuoz+QD/7kN2gX49bzbBgj0l5q6P8A5AP/ALkK81FH/wAgF/3Ib1AjA814 II9Jeauj/wCQD/7kHmoo/L+oD/7kN6gMFbzbBHpLzUUT/wBNN/7kK81dH/8ATR/9yI3qBpgr eaIXHpkuzGj/APpX96Owug6VJ/8Apyob1CeJWx2xem1LlVCVfk+ioxYxC/wj0jHIjRkpvqxI CgfdiRj8/wBf1md3QR4y4VBDuCPmN3//2Q== --------------090008060702010503060703 Content-Type: image/jpeg; name="stacktrace-02.jpg" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="stacktrace-02.jpg" /9j/4AAQSkZJRgABAQEASABIAAD/4SJXRXhpZgAATU0AKgAAAAgABQEaAAUAAAABAAAASgEb AAUAAAABAAAAUgEoAAMAAAABAAIAAAITAAMAAAABAAEAAIdpAAQAAAABAAAAWgAAAKgAAABI AAAAAQAAAEgAAAABAAaQAAAHAAAABDAyMTCRAQAHAAAABAECAwCgAAAHAAAABAAAAACgAQAD AAAAAQABAACgAgAEAAAAAQAAAoCgAwAEAAAAAQAAAeAAAAAAAAYBAwADAAAAAQAGAAABGgAF AAAAAQAAAPYBGwAFAAAAAQAAAP4BKAADAAAAAQACAAACAQAEAAAAAQAAAQYCAgAEAAAAAQAA IUkAAAAAAAAASAAAAAEAAABIAAAAAf/Y/+AAEEpGSUYAAQEAAAEAAQAA/9sAQwAIBgYHBgUI BwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04Mjwu MzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAkwDEAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAA AAAAAAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQci cRQygZGhCCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldY WVpjZGVmZ2hpanN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrC w8TFxsfIycrS09TV1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEA AAAAAAABAgMEBQYHCAkKC//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXET IjKBCBRCkaGxwQkjM1LwFWJy0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZX WFlaY2RlZmdoaWpzdHV2d3h5eoKDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5 usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A8amn M77yAPpTBk1bv7aO38oxZ2uueTVaKNpnSNASzMAAO+aFqAmD6Uu0+lakFtItvJA1g7urkq54 xxn8ehq1I+yJozpJByVzxn/PB596tQAwcGlGa04LV4WNtJYmRpiTHlgDx1/lVnyWeEt/ZWFY 4+Z8EHPHv3oUGBh5NG41rLA8xcDTixYAk7uM4znp/tDj6VFb28treSWr2PmuwQFGPQnHf6mh wYGeHpRKRWktwCwiXTlJKg7d33h8oHb2/WpNtzCRK+lsCFzlh2/LsBRyAZX2jFOF2RVy40y7 nnjJgWPzM7ee5JbB98fyqmbCYXPkFQJMFsH0AJ/kKTg0A77caUagw9afLpNzDIFkVVBGQ+eD xmnPo9yuAAjMSQApzkgkEenYmjkl2AZ/aT+9KNUkHQmkvNLnsVVpdpBz93nGDjP61JJo88Lg Oy4YZBHOeQP6ijkkFxh1SU+tN/tKX1NW4dBlmXIniXjo3H+f/wBVQXWmNa3cdu0iNv2jeOgy SP6UckkBEdSlPc0n2+X1NT3GlPbxM5mjYg8Kp5I/z/Kmrpwa3jmFxH84JK55FHKwIPtsh9aQ 3kh9av3GkwwwM6XsUjjGEBGTk/WoILGKW3jla6jRmfDISMgZxn+tHKwKpuXPWnoxJyTUl5aQ QW8bx3KSO2NyD+Hiooz0qXoB6ZDxa24/6ZL/ACoqCWXykgXIH7pe+KK89q7NkzidZRPsljKj ZLR/MM9DgVlRu0bB0YqykEEdjTSSRyaWNirAjGRzzXelYxNm1uXmjmE+qPFIpAXupHf+tWpP srI2dacvjAJGRjJ4q8i380pnbSrSNnwSWPoVwePqPyqKSLUJw+dNty5ADoOpOQFz788V0paA UsWkksUzatJ8pbAOSyg44Bx7nP0qvaTeaZFutRljwAyMCWGf84qaQXEerWaC1topCVK7RhTu HQ+9bMSaurSILKziXe2SCQPcjBoSuxGUn2NUCDV5xwBlQ2BwuePrn8hUaGwEiyNqE+84DY3B gBjvjn1rShi1a3kciG3ygYuCS3GFweOednH41R1MXVhdLeSxWbHYsYCAkc5IPPf5f5U2tLgZ d3Ksc5FrNIyLwGPUAE459MY/Goftl0yshnlZWGCpYnNWYtXeK4M/2eFpChjIZcqwznkdz7+1 SSa7LIVZbW0jkUg7o4QP73b/AIEfyHpWencCkZblVwZJQq/LjJwPamM8rfO7Of8AaJPv/wDX q/PrlzcB98MA3qFYqpGeCPXrz1qC31Oe2VAixsE4G9M/3/8A4tv09KWncCESXDZIeQ+vJpp8 3eFO/d1A5zzVuTWLmUrlYRtGPljAz16/nUUuoTTXYunCebu3ZC9eAP6UnbuBCvmSMEXczMcA DnNDJIqq7KwU8AnoeAf5EfmKvNrt+2cyJyVP+rXjaQR29QKrzX9xPbxQSMrRxLtQbR8owo6/ RRQ7dwIfLkyBtbJwRx6jNOFvOVJEbY27unbGc/lVmHWb+BVWK42hcY+UcYAUdvQAVH/aV3sk XzflkUqw2jkH/wDUKPd7jIktp3gM6RMYlbaWA4Bq2uiakylhaPgZycjt/kfmKgj1C6ihkhSY rHISXUAYORg1L/bWolWX7XIA2cgcZz/+ofkPShcvUCCGzuLiKSSGJnSPG4rzjPSpJNMvIrY3 DwkRAZL5GOuP5mo4r25h8zypnTzPvbTjNON9duoUzyFR2zx1B/mBS0AjktZltUuWXETttBz1 P+RSx9RUTyyGNYi7bFOQpPAqSLllHvUsDuNWEguIggfAiHQe5oqh4mlmXUo1j3YEK52nvk0V yKLaNLnHUq9al8kNbGYEY3Yxnn/PNRDrXWZnTK+kMkcwfUViIVWAyV35BOD64FOZNNDRkR6i FchOjYzn+H1JxjH+FS6db3Npp8YtdYsVikQzFJCNyvtzjB+gFXLmS8BdBrtkykMvAUHOT+Q9 66Y6oDKuxpbi2+zWl7vSQSTbtxzEMgkc+1SxyaEY5ZRa37xbuHOSFJ7cMP155qW+u7mO3kX+ 17eT5/JKrGmShLDdkdsH9ams7KO1+1W6eIbSKCY8hQhDAjkYJ4prfQTKMkVnFGWfTbwYZvmI cDpJgdfZfyNZ97PpE16GghuUt/LIKkgnfzg8k8VtzST3KmKXXoPI3MSpKD5jvGRgnj1P+1WR qGj2NvewQ22rW80ciMzSlhhCOcHHr0pSvbQCIyaK98ZDFcrandmJGAfknbgnIwBjOf8A69DP oq3KvElwYNkgdHxvydwXHbj5Sf605tGga8EcOoQtB+8LSnogXOM4/vY4+tLdaHDb2nnRapa3 EhbCRRnluetZpPsAoutE3bjZ3GSXyNwwAQwXHPYlT+H5kV7oqLco+nzMr48tvM5XBJ/DtS/2 VpwJzq8RCrzhfvMc4xz0+7k+5qNdKsvtUkb6rEsKsFSYJkOMEk4zkYIA/Gn7y6AQ3FzYtcQy RWpChMSg8BmxjcB0HritB9X0fzZHj0hUDgdcNtII6A8DjIPrmoG0vS1ikYa2jMoBCi3bLcZP U/hUltYaFL9pE2qSREbfJbyiQQQCc46+mOPxo95dgHDWtNEpP9jw7M52kDrgDrjp14qlql9Z X0vmW9gtodvKxt8pPHOOwxmrF7ZaMlj51pqbNOI1PkPEcsx2556DGX9fu981Nb2vhxreB59Q nSXK+bH5ZOcgbsHHGPx6fjTbk9HYCrBqOnII/O0hJiu3JMxXdhVB6epBP1Pty0albCKRPsCZ aPYrbvu8KM9Ovyn/AL6q68PhtETZczO+BuB3YzlP9n03/l9KbfQeHfsQ+xXUxuQB99WCk557 ccf19qGpeQXM60vYLcSB7KOcMSVEh+76fWpjqkHmAx6dCiYwUySGOHGT/wB9/wDjoqXT00M2 Y+3SzrcrcZ/dg7WiwOPbnPvU0/8AwjxgbyfOEofKfewy+hz/AE9OopK9t0Mpxat5GqvfJbRk uzMUblfmJP8A9arVt4kktS3lWduARjbjgck8fnUjS+GTE5FvcCQou0bjgN82e/8Au/5zVOzO kLBcJeCdpN37qSIY4+hNGq2aAq6lfnULozvEiOx52dOgAH6frTbcbp4x6sB+tT6s+mPJF/Zs cqqN2/zevXjv6VFZDdewD1kUfrWUtwOr1lg2pyAnG0KOfpRWbrZJ1m5/3gP0FFYw+FA3qc6G zGQoO3P4U1etX7BUls7yJuGADqfcZ/xqiOtaAdfaWskul2TL4eWUyRlRcK4wwBIJIxwfc88V Jf6dcz2206AkG87vNjcZXDEheBwSDjHU4H0qtpE1kLC0E+o6nbsJCpSHfsbnouOh+lX3fTSs BW/1l2bAAbzMSHavT6dcCumNrCKUlrPZaQou9BUG1X57kuBuDEDpjk/MB7VZ0zQr+0+128ui xXCOEIaWYDbjqQcc1U1EWE+lO9rdapczpwzzBthXjIPUDB28f/WzqW/9ktNjGuyP5St5Q8z5 eeDwc4P5elNJXEZupaNqOr6htt9Oggwx3GNwVXheCccdvxJrGk0DUYp7e3aAi4nJCQk4bgA8 59iK663OjoZXurfXXVCSxzINvyIeeeOeTnsR7Vz+sGy22iWdzfiTqz3eQApVSCAM+/Ttipml uCZQl0HUIp4IfJDvPnytjA7iFDED3AI/pU3/AAi2si4uYDZESWqLJOPMXEasMgk5xjirttFp 62EbzPqc86yr53lD9yI965wTht2GUY45I55qW2bQJ4o/O/tgABQyQ4ILZQNtz/wLr3IpcqC5 nweFdVuY0kt4UkDbekgGNwBHUjswpZfCesw2/nzWqxx5UFnmQY3EAZ54+8K0mXRbDULZVttW lymJAzbcsVX7owCRyeOOo6ior3+zppLP7Bp+qG3jlLSRzDcCh2kAYPXn24K9etHLEdxj+CdS jfa7wYIBRlfIbJxx+JA59R2yRV0vwzeavZyXFtJBlG2+W77STx68d60rXT9Nlt7KWbSNVcSN HGXiZQsjFVGBnpk7iD3498Qm0tUskhn0q6S5uhFHBLgYztgLkDPU/Mfbfz7Dir6AEngq9SKV xc27NHgbQW+bgHjjnr/nNFv4Pe6hjlj1K0CvH5mGOG/g4x3Pz/p71Np3h91gaK/0K7klzkSL KsYAYqF5JwTkNx6mrselwW2oRO/hyc2omQeTJOhZi3kYUnPIzu/7+Y45p8q7COf0/wAOy6hd Xdut1bxPAu5TK4VX9ME9AfX3FaA8FS7cHVLFZCoKqZOCSEOCe338fh7021tI9CiM2s6LJcW1 zEoj8xwjBiuSR1K9evt9a3o7ZkkiQ+D1YnynyUXYRujXhvc8HJP3jnvS5Yhqc4nhiJwM6tap k/xcDH7vJPPT5z9dprFvbVbSfy1mWXjOV/lXZ29pNDJD53hmORm2gZ2hWZvKAxxjqDkdt56c 1z+v6ddRyLfPp62lvMdsaoQRnaGOMezD/OaJwVroaMOit6HwfrNw0QjteJYhKjFgAQff156U +HwZrU8kiJBHmMlWJkGMjt+orPkl2C6OcP3hV/S13anaj/psn8xUV9p9zp135F1GUfGRnuMk ZHtwataKu7WbMf8ATZf51EtExmpqlwU1S5CrkeYe3vRUGqXsY1S5Xk7ZWGfxNFZxTsga1M3T U3SXIHDBCVql3q3BJ9mvZ+R91hVTua0A6bTNUvtP0RZLW6tzsnz5DoCy4Gd2T2ro1urya2iL +IdNWOSFX2Kih1bA+UjIxwMZzWD4egebSpyNCj1FUlBLeZtYcD0HT/GuintLpYSR4Usk2uSG 88fIdzfMfl+6PfjpxXTDZMTKN6TJHJC3iGycTx7WCRIvHygj72BwOPp2qS41O9sdJjmh8TWc siRhBCkSFgACcevUY/HNPGm3Rgu3i8M2kO6NlMr3BOAQeQCO+Pbp2q1pFtqEtpYyw+H9Mk3W oCzySfeGBwRjgnr/AFquojko/GeuwlzHebfMJLfulwcgA9u4AqCbxRq889pLJdKZLRw8J8pP lIULzxzwoHPpXdKL60mug+jaM/7syOHZumHOPujPCnj296ztcW+eCwEmjacIRqCqY4G5Z+fk bIHDc/lzioafcDlf+Ep1r7W12Lw+ezly/lr1Oznpj/lmn5e5plv4h1K0jMdtMsSMMMojVt3z BjncCeSAcdK6q+kls5Vz4W0VVnnSJFwG8tzghCc46Dr05NV49E1ZtTtLKXQ7KW6ghW72eagE kY2p+8wemV5UEHntRZ9wMH/hJ9WaS1kkuPNa0Obcsg/dEY5GPoOtSN4v15oljN++FIOdq5OA oGeOwUfr610VnDqd3L59npekPHcMD9mChUAzAQMehIX1z81XobLVFTzh4a0DagRVZihBZliw Tg89M4GPvHr3ai+jDQ4aLxBrEVusEd9P5SFWCk5A2kFevYEDA6DAqB9Qv38jfPKfJbdFz91s KOPwVfyFd3pceqeUbq3t9B2SssEkAiVgAyqucA/MemV7ZJwOazP+JjqWuRWUstnBJZsk6MS5 Vj+7UD5jzxg9s8896Ti+4GCNc1tyo+2XLFRhQecAkHp7kD68U3+0tZaQSi4ui4KkNzkH5SP5 J+lei2/9rNPHFJe6NG6nyi8cbEEB0ILMGGev4ZI7nGetxqN3eWm7UtOwzRSMXRljjfdBj+Lk jI59mHGeHyvuJM4S4vtTntVS4nuXgVAqhySoUbcAe33f0pw8QawoAGqXgCgAATtwAQR39QDX VajPqGoXVpoVzqFl9lljEX2pIwANqo2Dz/spjpnP5U08DJn9/r2mIu5hmOUPwCgB6jruPHbb 78Q0+hVznG1nU2xnULo7en75uOnv/sj8hUMl9dSpskuZXXGMM5IxwMfoPyroU8I23mJHNrti jFSSUIZQcrgAkjPDdfUY96yNU0yHTvLEV9DdFsZ8o5A/dxv6+rsv1Q/QS+bqMgGq6gqqq31y AoAAErcAdB1pBqV6GLC8uAxGCRKcn9aq0UuZ9wHSzyzyhpZHkYDGXYk4rU8Pjdr1mP8ApoDW P/FW34a2/wBv2pbO0Ficf7pqJbMCrd7JbyaQ4y7luM9zRVm9W3F3J5ETeSWJTefm254zjvRS T0HYy/knvSedrc1GylJGU9jipbbC3UJY8EU2U5mY+9UI39B+x/2dem6GpDaUIktCdq/73bn3 rflTSTbO/wBm8QEBv9YS3Uk4HJxzkds81h+F7treG9RdaGnFlUgMgYSHnrwent610TakPJYH xjiQjgiBcdBnoM92reGwmZ7w6e80gjtdclZQ4kjJ+VGIYDpzgH1PY571PpFvpcllp5l0bWLi Vonz5THy5cdSPmBGPw696fHq1ux8qXxNdJCBxtCjA7DAX65/rUei6laRaVYxzeKbqz2B/Mt0 jzs5ONp2n68568Yqrq4mXHh0e3ldrvw7rBj+UYDncP8AWZwNx6jHPbb270dfh0i1023QaDqV o6XSiaad/mdPnBUcn5iUfnHY+lWb7UtOkiuVg8WXfzABfMjJDjnIOFHcjH/6qoaze6bd6ZKk niG7v7pWTZvjIRsSPzgjPCNnk9WNKVughkH9iXGoXF7Bp2sHTfLcPFbn5lbdnluQEC4BBPer Vpp0H2b7Pe6BqZjiJeQwE4B3YJ68kKDx179BUVw+m2+k3NtbeKm8qYbxaRWpjSUjIG/HAPA6 9j2qJtVe30qM23iW7OoeZuliEhVFB3F8N0Jzjoed3tSuMt/ZNDtYIppPD2srNLcLFEplIO7C nA6HJzxxz+FOsoLQ6ets/hW+kIuvMWYMSEG1QQ2Rj3IPA4zS/bdClkL3HinUJBuZ1V7ctsfB CsCc8gY54PbimWWraPBc3UM3iPVmtpbdsOqH/WHvjPX/ADmqUhFTET+IS6+HWEbW8TLaFMZy 6AMo7hunvuraSKGLEq+BZRE8pKxum9uWj4+YZxlgB0xnHrWRPqWijTJXj1G9k1McRTMWyFUJ tGcA/eU8ZwOvJAzLBrGi3OmRLqOraw03mRmWPzWZXXCeYDk8DIJBHPA/A0Cxoppkqz20kvhO ARhImUMyqsg3wjk9zlWB/wCunOQec+ysn1bVYtT0/wAOrLb2xKS2aspEm1R0GOTkk9OcCprb WvD/APoQudR1UKkarMY55SQQUOFyeBw38x2FMfUfCVvpMkem3Gq2164UBxK4UEgbiQG56A/n 7Um0NGxFYwwZlj8H2gAfcQ96rgB2jI6g8YH5E46nMI06WC1F7D4WsntYkI2m5DFlJX5gWHYg nd6HrjGcPTdX0STS7VNVvtY+1JJmVYpiUdN33eTxwB05/SrT6x4WEMGy61tnjADZnIEnCjJ+ bgjBIAxk47U+ZAZLWN34nSV9M0qKEWoRnSI4J3RooAzyR+6ZuT/Eevdv/CC6+1u0otAcAHYH G45Cnp7bufofSrP9qeG4rZDDHqSXG1FkKzHDhXX/AGv+eYYDoAT06Y5s6lekAG8uD/20P+NZ vl6lGxF4J1ed9kIgc+YiDbJkHdjB/wB3nr7fTODcW720gjkxuKJJwezKGH6EU83lyTk3Ep6d XPbpUDEsckkn3qHy9AGfx1seHzt1Pf8A3IpW/wDHDWOPvVraKCZ7naMkW0uP++cf1rOWzBGn ZTRy24JSIEEg56mis2G0Qpl7vyzn7u3NFQ4lGQqkMOcd807JPJq35TYJVATgjBqu0bIcMMGt SS3p2pSafIWjRG3FT82f4WDDp7itNPE0q2ogOm6c+AoEskG6TgAD5s56AUzwvAJ7+aM6Yt/m Bv3bPt28jkH17fjXVW+nA25C+EEIMfIe4+YjngcZzwffkVrBNrRgziL/AFGS/KboYIlTosMe 0dAP6fzqnzXoUOmSTPs/4RqzI2EFTNg/wDggfw4wevU980mhabOlp5f/AAjtleNBfNG0skwB Vhxzxyo/yOlPkbYrnn2DSc16jd6dcM4gk8NaYvmcDy5gNuWjUdFzwWHHI/Ac52t2d5N4Ve7j 0rTrSzVFJaJ8uVxFgY2g5zjrzy3XuvZ+YXPPuaXBr0e40XUBfN5PhextoHiaNQswZXPluSwL c5IPGeAQOlSXWnag6SRf8Idp0UkEfmblnUtGhMhGATg9T2J+Ue2BQC55pzSc16I2kajba+1u 3h6xmudQ3Xf2SSVWjjUGRcA5wB82epPAqWWC61S0Mdt4c0MMsbINpAMY3yrkEkD7yseD6fgc gXPNqK9WivdYsrixhk0fQobhkS0R2wMJkYyc+oPHXg8VBHp2reHrbV7+aHRp0LzvJC53h1Yp nA/u8cA8jn1p8gXPMcGkwa9Os9Y1G5tlFto+gtGYhmJ12hl2W5AwTgnlBj13VJZXWurqUdoY tGErSxud+GQbfs5DZBx0den9046CjkA8sORSZNXtULm7TzGQt9ngxs6AeUmAfcDAPvmqOKyY xM0UUUAFFGKWkA0ferU0lxGL5ycYtXH5kD+tZgHzGtTSreS4jvY4l3O0IAH/AANaUtgKTwyK EPmZDru4PTn/AOtRWhLo9+CqmIDC4GXH+NFK6ANjelVLpcSDPpXQGzAP3qzNVt/Kkj5zkU0A /wAOeV/a6rMl26sjDbasQ/T2IrqLVNPkt+IPEE3yH5tx4+/z94D+nyn3rjtLuWsr9JknaBgr YdeudpwOh6nArq7bXIjGfN8R3ULBsgBc5GD3C8HJ61tTdkJj1trR548afrZXg4DfMwwxAPzc ZC5PTpxjulha2h+0iXSNVfbqBC+S/wB1TghG+brg8n9ax9S1+4hvGNhrFxMpLEuRtJyT7dcH /PQZ8XiDVIDIYtQmTzX3vtfG5vU/kPypuaTA7S6tbCK5iJ8O6kgC5CGbJOGUnA35JwCMD19u M+/toE8Pzb9CninEQ23JmAUEeVkkbjknJGO24d845xvEerM25tSuC2MZL5OKgm1i+nthbS3s zwD/AJZlzt7dv+Aj8qHUQWOyn0+1js4zbeHtQfaQ0ssj7iynyzkAHp+H8fWmXdnavbXLr4b1 dpdyN5lxKdw7Yz1OQw49vauS/t3UhG0Y1G52Mu0r5rYIwBj6YAH4Ckm13U7iJoptSupIz1R5 mIP4Zpc6sFjv9RsrWF76KPwvNZsFEjpNcJ5e0RvkgE47g5GcEVwttomqXsaSWtpJOHAZRGNx IJcZx16xP+VQz63qdwrLNqN3IrDBDzMQRjGOvoSKhi1G7gTZFdTxrjGEkIGOeP8Ax5v++j60 nJMEi+PDmrl0jNjMskgUojjaWBDEYB652N+VUr6yuNPm8m4UK/PQg9GKnp7qR+FK2r6g8gka /ui46MZmyOvfPufzPrVaaeSeQyTSPI56s5JJ/E0m10GNzSZozRU3ADTaWjn0pAJRS4PpRj60 AJS0Y+tFADR1NdT4OTNzdHH/ACzA/WuXA5NdL4auFs7bUJ2ZQyooUMfvHngVM9gNC8sJtUvJ ZYpCscbeUMHrjr+pNFb+nixtLKOF9Rs94GXPmjljyf50VlzNaWGTN4M1xTn+z5D9CD/WuS8X aXe6XNbJd27ws6sVDDr0r6XaLypzE3/AT615V8Z9OkkXTLxI2ZEDxswHAJwRn9axp4iTqckk aSguW6PFjnvTSParhgbP3T+VMMDf3T+VdlzIqYox7VZMDf3D+VJ5Lk4EbZ+lFwK/4Un4VZ+z Tf8APF/++TSfZZ/+eEn/AHyaLoCvn2o3e1WPsdyf+XeX/vg1HJDJFxJGynGfmGKLoCPd7VJC rTSrGgyzHAqPj1FS20vkXMci8lWyB60wOgTw/C9o2LhhcgZAKjafb1rnWZkYqRgg4NdguorH AXGnXDTEcAxHGfrXHyHMjF/vEnP1qINvcBPNPoKXzT6D8qb8vqKsw2FzcJvhtpZFzjciEiru BB5p9B+VKJT6D8qt/wBk33/Plcf9+m/wpf7Jvv8AnyuP+/Tf4UuZBYihhuriKaWGB5I4V3Ss qZCDOMn0FFvFc3XmeRA8vloXfYmdqjqTjtVuKz1OCOSOO2uFWQYYeUeR+VLbWeq22/yLW5Xe u1sRHkflS5kFipbw3N5L5VtA80mC22NNxwOScCog7MwUAZPGMVo2+n6tauXhsrpWIxnyW/wp i6TqayBxYXW4HOfJb/CjmXcLDdS0u90tolvYVTzFDoVdWBH1Unn2qbS7C81K2nhtFXIZWbLA DHzetSXVnrN8ymXT7o46AQN/hXXeDfDFy1jefbY5rYTFVUEbWIGe341nKooxvJjUWzjr3TDZ zLEblJX2AvswQp9M5or0FPhvbHcXvpsk5G1QAB+OaKj6zT7l+yZ7lqYAhD4+YHg1EUWWECRQ wPUEZFFFceI+Iqmct4wI0/RZZ7WOKKUMBuEan+YrNtNPtI7KKcQIZpUDPI3zMT9TRRUXfKaW 1MnWQIbWV41VWCkg4rJsIkFosu0eY4yzHqTRRTi3yhbUsFRnpUcgGRxRRTQ2hG71xPjD/j4Y 9/s3/tQUUV0UPiMp7HGGlU4II9aKK7jE9TW4l+yK2/nYDnHtXlbklySckmiiuehuy59BBXqH gv8A5F6EerMf/HjRRTxPwBDc6QdDTsCiivPNxjVJb/eoooA1I+VqYAY6UUVhIoAAT0qWIcUU Uug0TDpRRRQM/9n/2wBDAAUDBAQEAwUEBAQFBQUGBwwIBwcHBw8LCwkMEQ8SEhEPERETFhwX ExQaFRERGCEYGh0dHx8fExciJCIeJBweHx7/2wBDAQUFBQcGBw4ICA4eFBEUHh4eHh4eHh4e Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh7/wAARCAHgAoADASIA AhEBAxEB/8QAHQAAAAcBAQEAAAAAAAAAAAAAAAIDBAUGBwEICf/EAFIQAAAFAwIDBQQGBgcF BgYCAwECAwQFAAYREiEHEzEUIkFRYRUjMnEWQlKBkaEIFzNisfAkJUNywdHhNDVTgvEmNlVj c5IYREVUk6InZHRlsv/EABoBAQEBAQEBAQAAAAAAAAAAAAACAwEEBQb/xAA0EQEAAQMCBQMC BAUEAwAAAAAAAgEDEhETBBQhIjEyQUJh8BUjM1EFcYGRsTRSYqFDRMH/2gAMAwEAAhEDEQA/ AMGdI6u/VYdftBpw4kFlfr7fZ8KYmHVUxA1V2iUaqHaFEo1B2hRKNQdoUKFAKFChQChQoUBq FFoUBq7RKFArQolCgPQolCgPmjaqSrtApXc0jqruaBbVXc0jqruaBXNHzSOqhqoF9VdzTfVX c0DrNd1U11UNdA81UYp6Zcyu82gf82ja6judRyq0Enzq7zqjOdXefQSvOovOqM59Dn0Et2iu 9pqH59H59BMc+j9pqD7T+9Q7TQT3aaP2zyqvdp/eo3av3qCe7V7yjdpqv9r/AHqHa6Cx9s/f pT2l+9VY7X+9Q7V60Us3baL2396q32z96i9solZjPf3qT7dVe7Z+9RO10Fj7bQ7bVc7XQ7XQ WLt1c7fVd7XQ7XQWDt9cM9/eqv8Aa6L2mgsBn1J9uNUH2mi9poJ7t3rXDPKgu00O0UE12qi9 rNUP2muc+gmu10Qzmofn0Xn0Ex2ui9pqJ541znjQS/aaKZzUVzh86HOHzoH5ljUmZY1M+Yaj UC2ulNdNy0sWgvPCXa4h/wDT/wA60x5/u91/6Y1mfCH/ALxKf+lWkvs+z3H92vl8Z6m9t5oo 9Eo9fUYBRqLQoDUbTQL3qBjaKA2gaGiicynsaiq8cclIuR6j8qBroruipOajnEemiscAFFXY pyDkM+VEhWDmTWVRbAAqJJioJRNjaqxkI/RXdFTEXEuHrNNbul5uyYGHGofKnX0bkP2OgoO9 An5JhwOAptyFc0UNFTT6Edt2Kzn3Yi3xziAbcoefrUFrNTEH0UNFP4dgo/KspkCppBk5h8KJ MMXMc8K3U31kBVM5NwOUfEKYhnooaKfxcau/avnCf/yaQqnAdsgHkPjQZx67iD9qp/s+0pt9 Jth7+MD+dMZBjihipSch3DBHmayqgVbs59HUp8dKLBxSz9w6RMbki3QMuOsOoF8vWm3IRmmh SyiImU/oxueX7RAHFOPZ6xrZPMp5MCbkG6qekcl2zn5UxDHTQrnKW5PO0G5X28Diku9UhTFG p5bseeVkDNCnxoROsb+6UN8etLTUUqyasnyJhWauyjpNpwJDAOMGD/GqxEXQqXteEXlpgzA2 pHCZx1mDYDFLnSNIwsUtJQ8o/wB0QZt+cmIhspv0/nPypiGFFqwSFv8AZoXtRHArLEIkYxdO w68fD5/ztSFuwKz2cbMHYKtyrlOOvT9kucfPam3IQ1CnzhoVw+7PGkdKYIIn5hMCG/X5etPb Vt9xK3InFrEWST1CRY+P2Y4267fdTEQveouqrPA20k+jUhUdqguuLjQJShoLyvteWf5GoZrH 9ptF1MEP71i5Im5TEPqn+ExfP5Ve1IMM0M0TTXMVkFM0M0TTQ00B81zVRdNDTQG1V3NE00NN AbXQ1VzFDRQd1UNVc0UNFAM13VXNFd00A1UNdDTQ00A10NdDTXdFAXNd1V3RXdNATNDNH0UN NATNDNH013FAnroZo2K7poCZrmqlNNdoE80M0euYoC5oZNSlCgS1V3JqPprtAlQ3pWhQJb13 vUpQoE+9XKVopqAuaXT+Gm1OU/hoFaVLRKVrgvXCEP68X/8AR/zrSHX+xrj6ZrOuDZdUw68u R/jWgyRtMW4Oc2CgQc183jPW9NtjzGEjjopqaNWSgIgI+NQdwNiNnWkhcBVtgTkVjUTE66d/ nVfvAnvgNXut+phJXaFChWqR06C1BOjqFzQLpxxzxar8ohhIwAYvj86fWWqRG4m5jqcsByXU OwZEPyoIxE37PHkoiKChdZiAbcQDqOPGoiqU1PDc8asis2S0gr30ziHQM98P8qiIlEifEJko 15XZVWI8o5dgOXPUfX09KqTxu/bItFnIq8p1js5xNkBp2nAzPbk2hURBTlcwg68Bp9B8PlXp zStcHhGB7KchVFGckJTlzuTfr/P41PvHLf6RNH5DIqpJlOQyxRAOXv41kz4jyPfKouuYi4L8 e+4h5+tPE4eSGNCRKYpWqveAebgT/d41rC7j0PqvUwq3O3l1MpGSXYGFFcDfF3enz2/0rOFm Atodi71Z55A2+z/OKSLrNpb794wFKTwz8qlXULMByG5ygYurQUhVM8sR8MeFebXIPrBWTAsm 1OYNSyACQhvr4HpVmeLMFEWRnnJBIqSRQDIakltQ4+7f/SqFLRD+JUT7SQABTOg5DZAflQi4 x1Jc06WnSTGsxx2++tI1wpgL3G8r2bJo85rz+U6ScaDAGTadsB5b/wDWmigtT2CjylkgKRFq c6RevMKbvff/ADiqTKNHMY+MzdF5SwAA7eIedSCNvyaseDlEgCUUxWKTO4k8TAHjV5+wuTx3 G8zmruEVG55BJQmB2MXA7j/nUVMOXBJZuRgsgisYiqXMEwDzExEO6aoJxb0ikzM4wkblJAqd MDd4hR8cf4flSMhEvGTqORch35BIFW+N8lEcfdXMxaluwFRdto1ZBrJqt0TiIGwBTgPfx5fL 8qNZq3Z4mTTXcNeZ7UKooUTBhQmjf5h/Oap0xGOYqQFo4083qOjf8fWg3jVHEG8lUtJk2RwK qT6wZ8QrkZYyFgmFSPIdmeMeoJIJNFEnKIjgTjqHGw9Rx41Xuwk+jftLVhTtIJcv0x1p9F22 7kGbRYh0S9sARbEOOBPpD8vnTf2PI/RtaZUS5bdu6Buchh72ofEA8Q9a5Lv+IXsN03ZXICjk 4FTUarIajdAExds1b/ajBKLbpvFkDclFQV2xBASqAJgwUA+7pWaaNX1c07iWCshKNY9Eoc1w Pc8vnWcbuNBotuyrBKSeZk0cmeg5IcwhjkiljSUfHGwY2GouJeMPoerHdsTKqkwctTkzp5hj GyQfXYKp8lHnbPlmfdccofjS7xRpnp/d6ela7uidF8WmI32KVXmgZMGzRMjf6xVkzBqyH3Dv 09Aol2S6LhYewv00E15PtSaiQ99MNIhn90PTaql2P+qRktX9uCOnG458fWkDNzpadSZi6zYL 3R3Gu73arFevakWlymqrwou1YhwzVeFLsJjHyTUYP56UnZ8ozjVFmbmX5iibtFwDk/Q4EKOS gPXFUnkH5gI8hQDHHYnLEBGulbLHUMiVBQTJmApi6ByUfIfKp3Urxb8zEM25UlnmCNXDoVCa REHBVQ7pi+fyqsRrxJnZMtGl/bybhLu+BEyDnPz9KjOWPvfdiIoFExygG5QD+FWiPtLtSccX teHUlHnfNiaO5gue6YfAe6NVrKYqdCnKLRQ2ecmogmkoVNwYwY5Yj5+v8aszWziP3DM7B8oo 0WI4McTJ4PhIuoRKHUch/wBawjblJSoUKkVGBXMh2eH57svLBQROTSYnoNMlkjoqCmoQSqEH SYo9QHyqcQjRqlUov/sa/uJQ+EkXRGSRQ6mVMGfwwA1Y1LMS5jxigssZ82jSPM93lqGECiJQ /wDd/pVRtSkKRQp8jDzC2xY1bmdoFuJfEpwDIgPljzp03iytXiqU2UUsJAZEiZgEyhhHAY8/ lU7Yh6FXRjabRW6JxEVl1Y2KZA4MJNIn1YL3fUdx/CmyMC1+hbGYM3eujyPaBKZL+wKQcAIh 4/hjrvV7EhVKFWEraEUtNxJEbuCmTAiJFjmHCio/ZDx8PzpWBtZ04uK32b8ATaSxzYUKbPwh kQ8MVO1IVmhV0ibfZvJh0mrFOGvIjV3KaBhyVYxDYDBvH1xmoy9IpOK9jCRAyAvWZlVEjZ7p iqCXbO/hVbEk5K9Qrpu7mtIibVaKFhyGjuYg9hzunDvfURXBhDHh9Xp86mFmUyUsWbUaplxC PIdFSSkSILNW6iQBg2SudYZ7vmHn5VJT3sxn7JSNAtUZERFdZv0ICZwDlgcf8MBiqjZUqlCr hNNmsdPRnJjo7nP2BVDczZuU2sQ1F9NqsrW3oklxOmbNiiqqMsikdFUodxAShqEN9vnt8qrl 05MrrlahG24wR9mt0myAorruQV5/xmAFBIGnONgAP9aeI2xHjLKRPZmvYgZgIJhjmgYN9Q9f Prvmq5SSvjkyTH51ytFuyObEtu5FOSgAslUiogTGtLvYwO3XH/Ss8MUdjaeu4Vlct4Jtyy6i 0NNXGxWgK2/NLa00ViqIpEVPtoznp+FSVyWm1eTRnKLgW6aRCGekITYC6PiJ1yPpXY2JY6qZ 5oP8WkcUWtWgY5sX2CkU6fJOyUMdExf22de4/h51l/KOZMy2geUBxLq8M5HauStYpjLIlp1d 0uR+W9HURUT+Mhi/3iiFWHhukRW8GusudKapt/MCdasryFaTFusWXOUUccxUqbjGAKIAGdWe gda5C1kpnCaJ1DaUyGMPXBQzSjVq4cl1N0VFCgOnJS7Zq6Wq3RjuJgsGmrlkaqAoJy/EbR1D 09acWakj9FYDWoKSij5US6PrDrDrWkOGyFGKwfHRFYjZUUwzuBaP7NeFb9oM2UBLGdeNsVra zdH6UNEt/wBkoPKAA5ed9x/nwCo24Em5C3KfWbmFYABiDjR0LjHrvXeWTCWTK6WZtXDxTlNk hUMBRMOPAPMaBmbhOPaO1SYTcE1EHzq0cOSFMnO83oZqUuAxkQEwVjG3qpWXjNwxUAjknLEQ 1B6h5hQbsXLlFdZFEyibcmpYwfUD1rTJCKYSHZSuyAmmmkmUi5xAN9Q90fUar0Kkp2e9CJNl ESdmFMqXkOQ2+e1XtEVdawr9yzScpI9xUmone3MHmAeNNexLjE+1eWPZNfLBQegm8q02FK21 QqpyDlON/a/VKGk2fv8A4VH3gvGueGZVow5gag+TIkTGAAd858/n402k6s0pwWm9OC/DWCi9 K0hRy1waLwb/AN4Pjf8A9cP41eZj/c7jP2B/kao3B3/apA3/AJIB+dXW4iHPb7gC4+Adxr5n F/qt7fpZbCpciNSeE/ZDkFS+nmFMryAnuzkNrKYoCAhUzZrYVoMPej8Yhp8Kh70ZKMNJNfMR NuHoPlXrj60SVOhQoV6WYydLUgWljUGtw5kD2/bjwoe8Klp5hOhR8jVGyUDHBzFiNEwOY+VE 9vtfGH+VZ2xkHjRM6bd2smmYciQpu7nzrvanhjft1TDp0bm6l8h8wr0xnHQahNRzQ3s1oq3K DRJ2CaPluA/z/jTxwkb6TNwWIUuYRZMUR+sAG+H+fwGsydJXASNL2ntYsi4EBE+QL5D6U1NI v1lkNb1cyhB9yYT7kH0HwreN6Mev35GqdgjneXTgEzLEap+7OGsQJncgj/PyqETSRfmVgVme qJTcmFJYMgKJtIDv5+O/4jVPUJMoziaKh3SciqUNHe7xijS7VjcZ3D0iBHYKpHEjkNWBE2A/ HrUZ0FhmGIMWMZ2Jmk4aAjqVV2yU5T9c+G3h6VNzTZi5ljyeQQNzmpk3GoMLFNgP86y/nOUC qM+cqmTXpOlq21eWPOpCSjZltGh2zmAz0goUhlPDzxU5Cy8Uil9ml7nKFOUULo/4mc+8x4fz vTLh6qn7NnGhu8oKZVSp5xqwIf5evyquPk5AI9q8dmVM0W7qBzmyA+gUIdm/fOtEfnnF32HG A+fhSd3Keo1GSRinnYlnyaBQTTSTTMcQESqb4SN6etN4s39BRSWKXJGzpJwb/gn+z8uvzrM5 JJ+0dKIv+aC2wnA5s58hpHnLd4Ocpg/xhq2N6j51rvxS1VwsgpHrnwmJXEAcpHAG21cvAF/E P9Krk7zkUeHTwxCiCTQiB9XQvf2z5f4YqDLAzRo/uJCKApCvyde+gOpgJ41EdpOKf7YwpbYD IiAfKubv5en37DRuS0dcZpw63KS5WpRDfZX+f5CnsGgi2uK70WZUQaqKoKJkyGkxNtWPMOv+ VZzIMHjBSOF0Jg7eQFWygmzqKI9c0++jk2Egsw/ZKI6dQ87Ad7oGf8K7W5qNDauGBVGRWRUF G7GTWIIgO6BdWch0wHXf86jpySipuwbmQa+6FounpSLjCpgPnmF88+NZs8ItHOnDRbUgqgbQ sXcMD5etSTi33jaLav1VEU0XKPPQLzMCoTzAPGq3+vhOJC1TiW5I45TpF98H7XZPHkYfD5+F Xpu5jWd/Wq7iToezk1VUz6xwdM2rcTdPuN4h41RUYd+tDt5VFLUg4eFZdcCBzB0H/OpA1oTR XSTcpEjaym75DbE0/EA/515oNEtbqxfpJcaJuUUTvxNkpgIfTq6l8w9Kq9wI/wDaCS5WVU+0 GEDkLsYPTFOlLdkE30a2yiPtFMTNVQP3VBDwz500ayMjD81miYWopnEFCY+EwdaqSUsxOl+q uUSV5fPJMt1SJm+MSY3x6b1cnTyH7Yos5cNVGS8yycMigICCZCl7+PsF286yhQ+tYyxviMIi I0T/AJQ8qbsTRs7qftm4Gpk3R27RdlID2f6gHU07H8cFEcb03b9gf8QLoctHCZWxoAFjqIdA US0aseY90f8AKsg7v2Q8vup0zdrs9XY1jN+YXSpy9tZfIfMK35yMvMRZk7qZtriuV62ZFWaT CApJ9zSORL1H93PhVjtWeYIxturKOW6aTCNO3dlMAc0pveYAu2rfUFZdRdvIM1nHiu5EoZL5 dEpFP7bUjU3uV0jtO0uMZM8KAdA8wJt65qSh5mPhPY7NzLIvFidsTK5S3KmmqnoJny3xtgPn WY9KG32a5HiMeq8WkLS8VyXEJ7STI6Vhkmp3wdDKpq6sCcOuS/P5VRJbT7QXKV2LzBsdoN/a bdfUKZbdMBjyo1Zzv5UNE41foH4fyltre7UUfJv2x/ATFKJRKP41dPplGq85ytJL9ndRSTLs hM60lMEKJ8CONtHX1DasvoVUOJrFTRy3lD+2GL3KoFYOV0iJkJsqkomJAXHzNvv09Bqvw/sG MnkVjTCrsrdsblrqEyUqwj1L/Pj1qsUKS4nJEYLjBzEbEvrn/rJysnJRxm6K2gfeLGEB1Gx/ H1pe1bqjmVvxDV5z+bFIu0+SBMkXFYNhH0LmqPQpzVXa9yYcySKtmW/CFIIrRrpVdcDBhM+o xR+8dsVcZK/Yo8hCvGCD3+rX6jvQoAhp5gAAlJjAABcB0wNZtmhUx4mUVL6jeUc15DFEjhVk Vm6bqORLhXUufVkC/COP86i303ESVwW72kioxUUQSKiqTvKhrE4hpDHnjr99VahXeZTiUdCR RwuYgYSOcwkL9koj0q4x96NW7OO5rVwL5gwFiTRjlGDcNWeofH+VUqhURvyjXUlHJY7kuROY hTxJWfJbJnSFgURERRAod7V5mN50nOTjWauz2y/YiZqZuRA7fPewQgFAfyCoChTfkpYpCbin 7pv2uKUUj2rYrZunr94UpTagz9407Tu1H6SLXAvFZedoKu2MRUSimJSgAAbzDYOnrVSoU35J xW5jeqyKbc67MFHbUypkDkHQUBUNqHPn3hpX6dPNXa+ylCSMkCR19YiTG3QB8cAG9UyhVcxM xWKcuVSSj3jQGaTQX6pVXZyDnWJR8PIPSo+afpPlG/JIJSoNypd7qOPGo2hWcrspEY4paFml otFwgVFJdByJTHIfIbl6YqQUvOYOskrpQ90oJwzkdeQxpN6AHSqzQpG/KKlgRuqQTbpkBNDm JEMRNf8AtCFHOwfiO9R3bv6hTiSl92RUVRPncw0woU3ZGJ1GvnMc8K8aiAKkzpz0++pFxc8q s3Vba00m6pBKZJMuC7jmoShXNyURNN7klUZBSRKsUXSiYJHOcue6AYx+FJtbgkmifKRWAC6x UKGkPdmHxL9momhXd2Ql/pHMdn5HbBEMCGowAJ8Z86TdTcm6Z9kcPFDJ7AbzOHkYfGoyhXN2 QdPnyzxNFNX9mgTSQA8v864xeOWKnNbKGTEQwOnxD1ptQqcg9WlH6xsneLCOQEO90+VdTlH5 CqEI7VKCg5PpH4/nTGhXdyod9td8nkdpV5X2NW2KbqOFuz8jnKcnqCee7nzx50SiGrmQLThP 4abU4L8NSFaWLSNKFqRpXB3/AOpD+4UPzqz3gfRa6/vBKAl8KrXB/wD2eTP6FCpziIbRa6mn qIgGPTNfMv8A6zePpVPhmfMKsT7Kv+FF4jJf1bn94P4hUPY8wlDt10XHvOYbUGB6U6uqeZv4 /lJFMA+terCW6lRaLRjUWvWyClTUlStApGsV363Z2walOuMgG1FT1JONJthIcAMA+A5p7A+1 knHPjGiqyhQH4SZDHrTN1zTOlu0EMCwnHmFOAgOr1qviptDMjNV9uQywuYoQMQ37M5cdPT+d qhW9pwhXDQgNtSKq4Dvj3W37M3n86ojd/Nki/duXXZEu7qDoQPL0rhnE2dEHOt6KLlUogcoj gx/Aa9mccMUtTkI9s8vaLWcNu8jEHMmn13IpsAfz91dxiSuA65DYGQbOMBsJB0l3CsylH1yN 3SB5RZ8i5TD3BlNhAPHFdYublkXSrxms8XW0aVjlN8QeRvlWlbsfH340GjPIOEOaUcv0ETc5 +cpzgXJgMJcgIf5fnUCVFG6mbcsi1UauI9mBUHOoeWsmUfhx4fLw8qpvb5disukdyuiqcffl 1dTeY+tN+3vwZ9j7Ut2f/h6u7U1vR1Gp3pEIrW7GR7cqaCCUwgVLwKIGKO/l/PWlnEMzir2R M1bcsryFdFcN9gA5iiGweWf5CspUlJE7MrM71wo3LjSQx8gAh0GlUV5iReJFSdu13BTZS7+5 B9PKkL0Kff1SnuIDQzy4IEjfYV4whClN/Z97GBH/AB2qqvm52bxdqrgTJGEg6ByAj6D4hT6S CZjpJJzKAsm66pHUHPQfAaDeLlplRd43bKOlDDrUOGO8P+dYz0qpqtvrMxTtV3p94MQZIF/A vxZKbyqKdQsOVuifsbcFVnjYXSeQwgAm3EB8NXlVJj4q5zMVexpOgRAR1pAfA+uA8abuoueb RftJ23dA3UACnOJsjjwA3jitqz1onFqdxMGy12QSLlujyEWrxNuUcAQpgEBT+W4DSUocTzUm ZZFNZ04imyxmvgppMGfuL5enw1l8knMtuwkkTPA7QXW05gjnHmXy6U9NCXOaWTbqkd9q5XNI odTfT8/Dx2rSvERlUaZ2eF50y6W0vFzSSYL90pxFIyPwj6B57dKrEagjNs1GExGo+yWLdwDB 2Bvep6RyUo/zv61WGtvXOLx0QiK6DpMdKwmV0CYcdBN40zeRsuxh+3OSqoszuBbHAD7c37Ih 9w7/AJ1O7/xTi0m8EeZw3bt47s6aASTBVsomcA+IogJhHz1D1pWHKMLcUe0cYCN5a7ddwoYP fOzpjuP+e2ayDWtp0cxXR/w9Xd/Cja1ljJkVWVUHUBSazCPe/wA6mnERporRotwGBVjY6HJI 0cNX5lToCb4SlMURH06D/nVOvx2g/vqffNN2zh+oombwEB/wpK4IuVhXyKUrqBdRPUQRPqHT 5enyqLrK5P2HKFSK0K8Ja6VyaQ9nHc9l153KpjoIdQ6daje5515sVO12uf5Z+6uloBQqbt23 HU0zcPUlUUGrZcrdRRbIAChugfkNMp6Ldws06h3xP6U2HvgTIgIYzkPSq25eQwoVY1LQflgT S4OGpgI2K7M31YV5Qm06gz1EPIKr2k+2UlC6gyGsghtTbkC12nMWzWkZJvHtg1LOTgmQPX/A KkI+CO/uZaERWLqSKoIq/U7hREf4UjblIQ1CuolOsjzk0VjF0ibIJiOwdaUKgsfAFRWETIc8 ABMf2f2vlU41CNdozoijZumssiqmCpAOnrKIaw8w86nZq3DxV1R8GKvOF4k3V1kwOkFQAfDO RDPz9KrEQFCrNb9rKzHEb6Ko87lFembKOSJ5AgF+sOcAH3iFV14lyHzpp17OsZLV56R612Vu VAnQoVMvoVRKPt1ZEiqi0yRQxCCGA7psd0fGoxENQqRNBTRFNB4x2H9GUd/BkOUT4zfIvj5U ZjAzD/sfZmCo9sbGdN9W3MTKbSIl8+9t9w1WFRGUKsNmwScy3uY6yp0TQ0Wo7IXAd85TAGkc 9OtNW7DmWG6uISK+6epNu6GSBqLnA+Q7Dj5DXdqQiKFXC4LSPDcNWU6/TUQlVZTsqrcTAIFT MTUA7dDeg1T65K3KIFCpzh/FEnb0jIdQmpNycwGLnAjgo9On8aFv2tMTxVnEckjyU3YtcqKa cH3EpR8hEAHHniqjalIQdCpxjas08kIZgk3Lz5ZFVVAomx+zE2oB/wDaakX1vyjO0WtzqJF7 EupydRBEdB98AbyzgfnU7chE0Ksl6RbeNZ2gdrkDSkUR04E3TmCsYuQ8gwAf51NSFnq/rUk4 ghGrRjE8lZzzVMk5ZgJtnxE2oKvYkKDQqf4hMm8bxAn41ilymrV8ZNIniUPy/nwquqailHzq KxxkR7h6FbP9EYorNox7G17KeEF0otpDmgtytYGzvtn+HUKzi4LYdW9F9veuW65RcETbaB2d EwA8wv7v4dQrWdiUE5fFX6G3mFa2aBhx4naUGCCaCdsldpk6l5ukO8PXPX/pUo6gmBbP9spo x6UisiVMHOwJB7zTnp19d605OWuia3O/Bh/d867W/wAtBR7Ase6ZtWLdV4qn2nIAAHHSHdLu ONzdNqxu9GhG16TrNslpQbPDFKUA2KFZ3+Gla8tPfRCUbSbyH8KfW2iRzckY2UDUkq6IU5R6 CGrxrXpSHZSrOYZvHBcduKkiZMoam45Nt0DHQNqmNrJMpYsRxRypKGNoImYwh1ApREQq6M4c tu35bDBQ/OeKK5cgfcgAY2A+/wC/arAxQTBS81iGBoITAJcwhNylDOwbbBt6U2ismV6DmUFP QbmAGRJpHIB6hRelb0nDsCXBLPG/ZDPF2Y608h7oCpdcevXNYQ3RWWbrLFIYyaH7U/gX50nY wV8ieKcvI563R5i7RZEo+JyiFSNkkIreEORXcoui5Dw++rzxC5P0LnlgWMr/AFkmUmrPu9zb F8unTapjayjqmUmT05LSBqWLWSitKlpKj1I07hL/ALtk/wDlqa4hG0waQFL1UL1qK4S/7lff 3yh/Gp6+GaTuDATrilyzgb0H0r5d+X5zePpYDkaNRKFfWYC0KFCgFOC03pWg1HhDyRtuZ1jo FNQDaybGL06VJ3JbERNvGr5TmmcdmKbmF2BUuR/AdqyaFlZGIdGcMHJkTKEEhw6lOXyMHjUj 9ILhee67WqOBA5Sph8Il6Yr12pwjDSpJocXDsGlnySLVFUpXzZcTa+pdIdB/n8aUUjUIuw41 szJ7sjlm4ET9DCJgAf8Arj8Kz5rcNzFTeFbu1zJqau0kAMhkQ73yzSXti5PYJWhlnnszBQLr IOn03rWk4f5S1iWh2M8stHu88hKV1Dr33wPT09PzquKGjYB0q2jWbrkySBknZG2RFIQN1Dx+ 70qke2rgfKIJFfOlVkzgdPR8eoOg+o+tLPpC5UpJJy6M4Rd/ATJcZz/HpVzvRlXUWl9a0bFQ 72QO3UmvepaObnmFKcPMN9sUtG2xbR7bReO2xig4MoGRAeYhgNvn94ffVHUmJ1tJLKKPHCbo 2AUA23y2pRm6ubsbgzMz1RucRUW0BkuR6j6VnrDJSbvKLjYuJjWzOJFUXEeVz7QJnIG1CGDe HQApnwlOQl/MtfQxThv06VB+2JL2X7O7csZp9gR2x5fKmrXndoJ2Tmc4DAJNHxAPpWM5RG1K Q0bJ2yWLcoLKpkenHUcQ1oGwIib5UlFx7aKbu2zdHDdJy2OXQPxG/wCL/p0+VZpML3Y20nlT v0SnAU8qdD56gP502jXk2Z0mkweOxX0AiQpTb6AHYvyD8q9M70UdzZ1uSEgyOrzNTeXV76OM AIiHx+XXr6fFVXvD2yyi50xyLPFHYqIkzuVNrqHcMdMeQ5qjRprhF48ZslnvaialHSZR72QD cR9aUL9LTwfaCKSRo3Rgw5yXT459K1lxGVaurDcRjmt3hq8comVK3wmcDeAawwA+XT8qs7xQ D8YrmbaB0BFKnIgccgr3AEQL5B6flWUN3MnIlbxSTtZdPIdnba+6A+lOZppcMdJJKzB3Cb8T gmRY6oCoA9MZ8OmKwhe06/yTi1t4Vs8t9du598isRicG4HNrSDcBLkN8h/1AKRtmHYeyZ+Cf EB3HBcIlyvjJC8rIG8sh5/nWZIxd3e2lUiEehIimAnOKmDCXyEfu6VyPiLtW7Y3bEfJCmryn SYqaNSnrnqNb04in3/VzFAJ5SdEAhv2bgAKJuhu9tn0rT7yjoiNZoPWDBpzfbLVR+iGP6Kp1 5XoBg/hWcKMHiTVZdZsZMrdz2VUB/s1fsj/nTcyyw6tayhteNeoc6xDoI+YhivHlj5W1i8Fk f1+TIHZ85MW4iQNj7iUvfKHTu+XoNUbiM3I2uru8oOc3KqblF0hq6Dkv1R26VAdocioCxnKx lw6Kifv/AI08jZp4wUVVLy3SivxGc98a7O7GQ1PhCk0ecL3bR6RFZoaZNziLY06RRHffp86m oNKwT23E26vHR4vnsCZQHW+rTg24juAmASh1rDHz9y8cKLCfk8z40kR0p/hTb+Q9OmwelbWu KhDTtRKLZLpiYtpH2T2UrZwq0mkGYOk8Dz2xsYEQDw6hnH31G8VDwMVfkK35KaikQ/cldcnc QSBX3QGHxEoeHXwzWZNXCrR4i7ROPNQOB0/ECiAgIfgIUpKP3cnKOpR+fmvHZ+aufpqN51nK /HR3FqsLNw8h9M/Y6COHc23etW2nRqR7+oxQ2wG+ceHlVjnH0E8nnDhwrG9uydKKOoqGAV7M AGKsGR0hqDun2rz9q8sh8tq53armvo5g0JrGvI3h+UUnBFVXZCLSCh3Jd0CmAeSHXUGQHu+Y DQ4xLOncg7Xbu2SttqPSmik0jAJiF09Sl+qTr19Kz3Af41zuh9X0qN+OOjuKesGXRt+/IKcc 6uQxeFVU0ZE2PTcP4h86s/CXs0ZxrU7c5alZim91rHOHLEFEjaAE3TORDx286zyi4DTo0hp8 vCs4XcWjWuDMvEMLNRjJl03TEs8rzU1egtzthKPX6usA323xvTNnc0OaAZXE4HS9j4UbdPGF DIqFNqwsURzgAKbxzvjFZjpJ9gPLp4Ub97xxjNa80ywaZxlc2+5sOIi4F81dlYOxFqmnkyhG piFAusc7myQchgOoVH3dKs3nE605Vs7KZq3ax5VldWxBS0gcB3Hpp/6VQdIF+EAD5BXdvIN+ tJ8Rk1bRA3PBNOIl2K+10WiTi5kZNu7IOAVbEOcxilHbYQMG2Qz41nke0jJS7rkO9d8pkQrt 03UIIBzD/wBmAZ6gPl1qs6SfDoDAeGKN93TpU8z7M8XCiOkom2EQDIVe1p2OLbfC9MrzU4gX Kh3yYAOUyncAcP8A9S/nVGoVjG5iprVxcQoY7xuRiddZmq5lUn2gohhq7MXSJenzxp++lLTv 21YaYTQ5zjscJyE4Z7yRyomQ4nUAQDBgE4m2HPhWQ0K9fO11RgusFcMUymL+UVWPybgZOEWJ ykHAmOcDl1eXTHjUXEybJHhLLW2qooEk6k27pEmjJNKZcDkfD4h/Cq9QrGXE5LaPxQvWBue1 VW0ad2D1eWJImRWSEOWUEgTEudwEch4Y61Tp72WEfDEYH1OuyiZ8YOnMEdg9B9Kia5Uzu5Cw cN5ttbN/Q9xPeaKEeoZQ4JFETjttgMh/GpmwbzYWx2jLdwrqnUZNMxM55aWruj0HI6g+sHSq NXa7a4isFLszvhJsxWEseX2w3OqEQ+x+wRVMIqAbzP3hwPhkaXvq/Gty2WMCVi4QXOuiuc5v 2epMolwHpgaoVCu8xVGCcuqYQnGttI8lRE8OxKzXz0U0qCfUX8fyqySHEJm8vSenRi1vZ84i kmugJsKkFPRpEPAfgDrWfV2pjxMo9XcVnWno19xKeXUugZNk4Oot2c5AMYDCXABjpVXU7+ry MYRx5b0KFTK7kqPbTRei8Qj6UVjxuXpGAR5z68pmT6Zx54/Coy5LsNPMewumReUV0Vdtk4jy iBgOX6fdVYoVUuJlJOK6vL8OtcRZhKMTS/oHYFkzKCPMSwAB9+A/yrv0/c9h9mezkfZgEIBU NY6wEptQDq6iIj1zVJrtVzczCi8rcSpVz/tbRFZNI5Ttiic3usYwHy2D8Kgk7hVBOeMskCjq aEOaf6pN8jt/CoOuVnK/KRiVYrqM3CLlubSqicDEP4gIDVp+n0wHMOg3ZNzKnFRTQT4jj4+n UaqNdqI3JRMU4nc8kEhHyJ+Uu6YEEqJz5zuPUw9RH1pX6WyfaHq2hqPbT81ZIS9zV5hVdrtd 3ZKTTe55dCUeyZVgM6ep8pbWGQ04xgPLb8KaNZEWkS4jkSBhyIaz+OPSmFCubkgq1WUbLJrN zimomOohy9Sj6U8nJ6TlG/JeLAKWvXpKUCgJvMfOo6k1K5uSiOU4LTanJagKUctEo5aDV+Ev /d90Pm4xS3FxQxLZACGENZwCi8Kf+7hv/wDJGm/GY+Ilp5c7/CvmXf8AUN4+ljtGotGr6bAW hQoUApQtJ0oWgsVhxcfMTXs+RK4AqiZtCqX1T42Aav1s2jHQ84Vx/SDLM0g1b5AxtQbl9Ky6 DkpKKfdqiziVfQJdgzko+FSre7bnYOETFeLJqIJikQFk+qYj0HPWvRbx06jS7Th2ra5Lmk9J uYs/Vb48NKhc/wA/xrkCgRe24+OP/bxa6WjbSOA/161nTW87qTeOnjZ2PNdG1rlAmS6vMA8K Qb3JcIM1W6LgeUImE2km6efiAPKvbG9a11TiuRrbh7WRZyjXmi+akSVApd+ZuGQx4fOnTeAR uecLcHbHyjVRyY5mzkuBSU+IAL6bf61QVp+4lIlBu4WcdlIUoJKGTEBwA90NXiFHNctyvnDf Q9W5qBgMnyAwOrwH51jnBS/zFspXDxGbrO2/9E9kgKpN9RRA+A+/0p1a7L2EjJxfNU5bWcTS ROXrpEvQ3pv/AK1nri5rw9rIvHDh0i/KkKBMJiURT8seNERmbu7Y65Kz1VwfHaQ5QiIiHiPr Wu7DX7/ZPcZSUO8XuCf7MnrK0eLCpp2AAAeof5UWyzlC6IzyM4J/Gjs3M62LIqpM3CguMldK HRMOBMG4/OodEv7Pl5yGBIIdc+YV4bnWqm/S0dFSTO5Y54RddH20UxwHqibONRPT0qHt+0Yq NuZucjQVlWLXnpnLuVcwH+Iv8+e1Z68mrzbt01HTmRQSyGhUS6dQ42ER86bRMlcZlkCxbx8o qgAlSKmOdICO9e+9ehOev35To2W04xqjf1zT3JOo9GVFvt9QiiWc/wA7UxtlA3sOPZn1AoLF 2iA9CY32N/n/ABrM2cjfPthwu0cS3tI/+0nDYw/OkkVbzIzekRCWK31iZ2QC7AYQ7wiHr41p vwz1TjVepS34O34eMkGbVM0igm2dtjlIOFB1Bkph+7rThrb0bdM19I3qDhoo5eK9oYORE4Cf GoDBnG233+dZiZ5PHt9Eh3D8YkTlSTAc6NWdgCnEwrdhexLSZ5PBTlK1Oc3wm8BD1rDOKmkX Qzk5HiEx5ZlmyJoRNV0KfQAIYfdgPn6bVJt3/tSFfPH7J0RQtwInKiJe+mHK7oiAgOB26/gN ZYV3fC04CPaZf2mVH6w4NyhHcPl6VxulfK0s7OkeXCRKXS5OJ8GEAANhH0rTep9/yNF0f8ol w8VxcGL2NZIxSajbCtjJQ9R/H5Vj6P7Ev90Ovyp64Vee/buVVcmUy4If6ygeJvMab15L88yI tCpGShpKOYt3rxqoi3dfsTm6G/nA/hTCvMoWhRqLtQChQp9AxjqamG8QwKUXbkcJFObSAj8+ lAzoU9jYt2/uBKBRJ/T1HHZwTEQD3nlnp99N3iJ2jxwzW2WbKGSVL9kxRwIVWMglQopjkKnr +qHiG9S9zQby3lI4j/l/1iwTftjENqA6Rx2H57dK4IijUPyz0ztUvb8C6miySqKqCCMYmVR0 q4NpKXUIAUA8zCI7AFdxERQqVuSCfQEsWNflKKiiZFUTojrTVIYuQEoh8+nhT6NtF9IQK8q2 ex48hmd8drzMLckg4MbH+FXsz10FcotG0n5ZVuSsCZvhOZMQAfkPjSrNso8eN2bcgnXcqlRS IH1jGHABWWgSrtWtOxngvrlIq9RTaW6KZHbgpdXvDjjSUOphzkPuqLuy339tzXsx2QVxMQii KqAayKFOUDBjHjgenhV7MhD0KuzfhxJPLdB+i+S7YeFGaI10CIA2A4lyJvtbCOkM+FKrcOVT ppezZ5o6WLJNI90XAFImouAiGk3QwB/ltVbUk5KLQq5SFhuiTFvR8Y/I+9uPTs0jnJy9JimA md/q94BzT0vD9jqvBytcK/YrbWbIG5DPKih1REuAL5AJR3zvtVctNSgUKvFt2G2lGLJ+tKu0 kJGVGOaaEiifIaO8co4Eu5gp/IcKXEa1fNncuY0wzh1pgyZCByDIpK8vTq27477Bmq5Sacmb 0KfvIWYZRqEi9jV27dfToObGMmDIAPl/oNMK82ihaNU1YsL9IbsZw3vcLlUEeUGT4KUR2CiQ tsz02zUfRkaZw1KodITkMGxi74EOucb/AI1eEhEUKl2NtTzx1GtkY1bnSTE75sXH7REurJg8 w7h9/DSNISkJKxtvs51y2DsT3ZFUpwOGrHwjjoOP4DXMRH0Ktt8W23hpm1GDM/M9sxDR4fWI ABVFjYEM+VSUbYjh1xaeW92QUIuMfpIPjOFAIJCnMAAUR+0I7YrXYkKBQqWvBgnFXlPRKGrk MJJdqlr66SGEAz61FVgOUKsTiE02DbkqRJMqsnJKthXE4eAlDSYPDGQ3wFSa3DK5EZRqxV7H lVVZuoOsQ5SqRNeg/iURDoAhWuxM9KkUarPbtlTE2zgHSfKKlMnWKkbqBeUO+ry69af2HbIG 4jS1tzzfvRrF6ZYgZ/aJJiPl5h/qFTsyK9qlUKsFqxfb+Ht2TJipKKRybfGr4icw+Ml86szy 0iQXB+WeSPJUlssl0hKGRQTVz3RHzGtNiQzihR6ufB+KaSc1KGdppqdjjTro6wASgfIBkfxr KMchSqGK1u6LC9sMYlzFGboyZm2tVukAACxeZp1B6FDr1qGtGLjSF4hMj8h97PizmbOeoagx uX/p+Fa8tJMZZM9ru1bTZ8IwNE2szOi1FJ3GGcOEjAAnUyBtw23Dp41ONbYjFbkkI5ZFkpHk bJaGv9ombu7jvnfPnvtVx4SUlQ7nnmk1q1/iEzQTsWadm5BzNn6ZENABlIBMbu9Nhxj/AFrJ nyKqOOYQS5DIagxtXnlbxTGWRvTktN6cVmoalS0lShaDX+Fv/dUvq5P/AIUz4uF7T2NmQcaR 5gj91PuGP/dNv5isp/GmXEAoGli+YJhXzf8A2GvwY/QoUK+kycNXKBqFAKUTpKlC0F04Sgip fTJNwQDJn8B+Yb1pN1W9Gzca7bP3iiwt5ICorkIICQe93em4bdd6whq6dsXiDxmuZFdAwHTO XwGrUpf91OeZhRIBUETqclLdQ3mPrXr4ecYeol4XW1bSjIS4O063RlGiZQOAiAgY4mDp5h0q StOAZs5a6HoBkzl+5Qx4AUweFZi1vG6WCyJu2KFVQS5Recl8RM/Wz13pVje91oOHa7Z1kzw4 qOA5WoNQhgRDyre1O1BNWjw7JF5abGNU7vOiFS8nAaPHvehv5xUT9HYO0exyrTnHdtAR2KbP M1Y3x4eH+lUdvdVyez1GzdyPJABARKnkUwHqUPT0pN5c1yLRrVN24X5BNHJWMjpMOnGkM43r mVvDQaAxtttPTje4TP3zpmdRRYjZyXSZI4d4Ch6bVPPuQMpOOzc1qCpGiuoM6yhqABDqGenT 8qyf6WXY8fIrIv1+0JDlMG5PHzx40o4ua8PbHaVlFknpk+SKfJwCiec4EvjvV78FN2fJokRj 3XQHHL98T+1yA/GH84rzemTst1CifAcqSEhgDp8fh6VKfS+7G7hbVJLFUMODpnL+zEPsh9Wo czN+qmo9M0dKpibUovyhEMj4iPnUcRdjOGEUxeg3zSOeGnWDgqy6aiBTqttxDAFLuTcenl+V QVu2wwtucBNikYQXaORMp1MBQJsAfvVlf0uuXsqbb2wvyyAUCmAe/pL0ATeIURrN3Iq4AGz9 4osZYVwITqKg9TB5Z8a0petOdzcNDdW3+cvzClUbN9ByAHNKUD9BHbV/pTWcVk2EopMF7UrG osCmRIQv7ZQxMAAh4jt57eVZA6mbvjpbtL50/ZvDpaNJy6QFPPwgHQQz4eFLMbkvY/POxk5J UN1VNGTAXbqH2armI6pxT8eo7/UvLHOgOptPNlSk0CAfEO3TpvU/xAfoy/DGclG6L1u6NJM1 QauU8GRN8Pc8/urO2J71Wg1+wFkFYtxlVzpIAkUEQ3MP+dNHEjcLuBQO5cvlYlI5Spip8BTB 8O9ZZxW1W4pNRhxDYuXLJ27CRtTs7ns5MrJ6s6jF65Ev2fyqzzTeOVt0zb3yiSjRgAHTESr4 Awh887bh+IBWDykxdCbxoeSkZArpBPU1OccGTL+6PgG1NPpBOhIGkCzL0HihdJ1gU3MXyH0r XmoolEtfDD2RekzFlXMuDZwIAuf4jAIAPe8xq/vLZiFeHZJwsUl7WND6ztDGDvlA3eck8c7b l6elZUoodVQyyxxVVObJzm3Ew+Y+tKdve7f0xfupCgXvf2Q9U/7vpXk3YZ1qtrt/Lxzia4ZJ rMFlGC8ImPI1fvGwXHiJfu8aqvGKLRjZCMcotWrVF0kf9iTliIlNjByeAh51TVnz5YqBV3i6 oNQ0ttRs8gPInkG1Om86/CSB+/H2uoUgkAj8dZcUzjjoNI4GsLJWtOal7yZoOk28ki3RMpn3 eoo46eYgG1W+S4fWqnG3tyWqC6CzVw6ZkTMT+hqkSKYpNjZyI+HjgdqwaYlTyZtXY2rJPAAZ FtkE1MdBMHiIU17Y/wD/ABJ7vgR98O4h0zSk4x0GszsLBN+CMZJrtmSRnsKkoiptzheEV090 NhwJQ9aonCNb/wDk61TgPeK/SMI+QZ6j0x+VR8xPv5iNhY19yuzwaYpMdAYECibVg330rJXN IP2vZjNI9p3gMVVony1CiHkPgG41yuNRqt2IMY7jXYMkdJsykV5E4yWjBQ1Fc4KYemNvH86X t1m2GYuYCNm6rwl+lK9FQAEfZ5jG5uRH6vjnPrWGmVWVU5yy6yyv/EObJ/xoc1YDCqRwsVQw aTnKcQE4evn0re5xEZ1qnFsF2MUW1mg2sZtGuIzEiWUOJgMJcKDygzjOdG4bD0+Ial7uSh/1 TWg4xGPZhCGiu0oOzgXS25490pvEdQBqJ4BvisFLqKXQQ6hEx6kKYQKb5h40PiyJt8+dZ1vR rXVzBrnGhJomWGlVyJH0S5zDHKaAOKOQNguj+yDcvw/fUrD3DbM9dF/mt+MQBCTZNRbtF/dE dctUgnwTUXAFDOwD4ZwFYb+IiAaQEwiI48q6bfHp0pLiY69KKjF6blJK2+0Risw7jA7IZg3Z IEXKJmb0qI7HHI6Uy93fV4eFZtw3bLRUPdjyYcQwMpGNeJnXK5AFu0/VSDbOk4+GB1edZZoS D6gdMUNBPsBW/PRlp2uYtR4yKrOU+1xz5iNqnQZAwbJqgY6ZipEAdJd9IagN/kFUWz5QkJeU DMrauTHySDlTRuOkpwEcVD8sgGyBQAa7Xlu3c2kW1w0lGozPFGNSexbs828Qex4qLF5K6fNM oO+epQOG3XPhVkWvG3lnyBXswzU77ZmzA5yD7MWTa8tRcMibBRNgAERANvDpXm/QTTp0FwHh iu6E/wDhk8unhW1rjcK64uY9NGyWXcxmNhynt2Uhlint5zEMzgP9PKdQw6UzB4kyIjnAjuFE /qG1fobybginENESLR0+I2V5irtbWAnX0BjBSFDAbgO+9Y9gnM16C6vPG9ApSE+EhQ+QBXOb j/tcxbopdsczvewlnU4ycuY2YdPXr5vuiRqocogXOQDUJSm22xkMmGqjHzDpTiBczpneKcOm tJ84DnMAJPESnHSGR8i9PnWc6CadJSBjyxtQ0l+yG3Tauz42sxvMbfsCd8YI2XbxLNrdK8io mcnLIu0OBBwmHQRHl9MF6hTf9Y0b7NuuScTCTtCaZLtmcaDYAdNhUW1AUw+JAABEfi6hWHYD xANum1d/e8fOq59OGTQOL0xFT0g9uGInjrBInQFKKxjsxSpgUdXlgS+GOtVu5m0O2j4D2avz nazDmyfe1AmsJxwX90dOO7v5+lQlFryznuGK5cFbgjrT4qQtyS6yiLJjzhUOQomN3kxKAAAY 33qf4RXxBWdHpoyRnAmb3MSSAyKWRMiVE5O703EThtqL61mFCu2r20qscmjxt/sGltpLCisN 2RiR46LX05J2NUxhOJh+0AKGAPLNO+LV927ddhlg4QjtAwP0npEFiCAJYS5Zkw6hgNh265rL a7V80YrffVwxVwzVnv0jOCoxUWzZPgFPvgKJt9Pn6VbmvEy3icRLvmF0ZH2ZcD1s7S0JjrJy TgbSYoCHXwGshoVnv92qluTkrfecTJyff7xb07l0gksTIidTcpRDz3qoJ50hnrXaLU1nkLS6 uFktw5t21yor9riJJR6dQc8o4HxkA9e6XwDxqzT3FVZ46K5j43kqFmlJICr7lEihNBk/TYMd 0C1mVCtOYmNQY8V0GMssDWA7PbfZwTaxiSgkFEQPr1CIdRMb4vMNqhWt7JI8Spm8DR5hTl0F 0jobZIKpNOfLAf8ATFUmu05qqdE/bM8jD2XcduGaCsM2CQc4BwCYJG1Bnz3xU3cF/km7LWgn MTy3qybcijkp+4PJ6CHiFUSu1MeJlpopLPpFA9qxMMil7xmodRRTGMiYR2Dz/wBKWs24Vrbf OliI89F2gKC5M4ES+nrUFQrPc9xfFOJUkRuCDBsVuBNBSH1d/SU2rAiG45yNMo+8gZLT5wiU D+3QEq4asAUo74AA261UaFaczLynFcWN8vWrFoRJm37Wzbi3buTbiUg/xEMjgacfrJni6lmx G6DxYCgsuQTZMBf+gVRqFOZmpZbiux5Mx5o87Zu3bquAcLAl1UOA+PkFR96TilwywPzpAjpR IgRMBz3SgAbj4jt/kFRVJKVlKcjEC04puWl6zB6UTpOjloNo4a7Wmy+Zx/OoW+sfSIcGEe4U MVYOHpf+y8f6kMP5jVUuQ6pLycKn6ZKH5V823/qKtPgy+hTnkh5UOzhX0mZuauUdQuKJQco5 aJRy0HDVcOE+gbyakUxpEPHzyFVE1OmLh5GuEXzfnoKkMApqcscZrtFUbhcVvRdwwPJePlFV UH+lJwQglEBwbuDtuG3X86ZWXaMbCzyzrLgVWZCEOU+4GMYd8enqFUD6c3MfJSLIp6zCJwTS ANZh+sPrXI29LsZukuS+HmkS5Wk6WRMUBzvX0ZXbVUtOs+3WEaW5VwKooq8Xdo4EMkKGn5dP 53ozNmnJWSwij/28J3kNPcLgfjAftemPurMmN73g2WkDtlFf6SoY7kvZxEoHEA1CG23WmZbr uH2eWOI/HkAXSTBQ1lKP1Q9PStd61p/f/KcWiGgbcsV83lGvNUcNjpImIRTWJwMAd708K7E2 wzlLgaXCMk+etNKjlsi4Lg6Ri94C/Las+kJ67VG7ft/agTS0CkudvgR0/Dkcb0da57zPJNnP aHhHAAIpAkiIAbI7jjxrHKCmhOrOYXLxIuN8/REGR00hIcmdaZzEDw8fGpWzWZY6LTilM5QW cNQD+yXKAY74f4/nWUfS6805pVx254hJKk0KF5QlEwAIeGPD8qbluq5mZnCRZFVMVjidUpg3 A4huIeQ1tvQjLNPtoh0Y152N255A8hoqKahw6FHNWvguJP1gNCnwICmbrUMz+kCVvuGzaMdm j1jAoqsCIjjAdQH8c1HRpnJHSKjAVSuCCBkTJfGA+GK+d75Kb66gIS4bTbsHhnDkE3JgIsf4 0j6M79ch6/nUBYcclC8VJOCZIKpsxhlQPqyIHPyx7wD5b+dUN1JX8o8Kzce1irrJmLyOVpBQ o/FkMYH50GY3+1lA7MjMlkUm/KL7vJwRD6vqFfRleh0Q1XhmLUlm2adydZFRMqhcJ/CI6gDv 7h+P50jxObRC3A+cZwDhIzZjIpisUCiU/aBU7wCHQR6d7x86yaPl7wQTeFZLSaJEzmM6AqeA TNjcendHeo1m/kuyrRbV4t2d8cBXQKYMODeAm8xqKXYwpo5itfEDQrwzshyt/vECKJHE37Tl bYAQ8tvL76odT0pAXaXsgSUU87oAg3KfAimHgUPINqIaz7qI+SZnt94CyoCJNgwOB33ryT7m iCotPJJk8jXijF+2UaukhwdM/UBprWALQqTNCSZYH292NX2aBwTFx4ZH+PzqOoC0KNQ+8P5/ 60BaFd7n2w/GhqA3wmAaDtCh8PxVJWzDPbieOmcUTnLtmirw5f8AykwyYa6I2hXCnSMXXq2/ n/OpRxCPkbVaXOcgezXbkzZI+dxOUAH4eoBuG/jXcRGUKGSj8Nd/H7gzUjlCgXvG0hqEQ6gB ByHzoag6l1CHXOga6DUK59bTvnSBsaR6edH0n1FJyXGVAyQOSbvB6bb13EFoVYLBtWRvG7kr bYAKLpRuq41LEMUpSppicc+XTGfUN6gkSHW5mhFXUmUxjk0jqIBeuQ8MUxBKFaFa/CqSno2H cklkWrqaaLO2DY6BhIYqevYynQom5ZvyqglScGRUV7E792JCHLyTZKY3wh9/50xTkToVpTXh FMfSizYOSeJMXFzM3DkCGLu25erunzjvd38+tUAsXKnlFYr2U97ckBhO35QifSXqPy9arbUa UK7U19Hlf1erXWq45KZ5AsewIAAYVlQwKmr7AAU3XG/SuRjkIShWp3Nwi9lNbkSYSbySl7eF EHLcUSkTVFTRkE/rGEBOG1Vjh7Zrm53y3bu0RsahGO5E7jTkyhW3xlIH1jZEArStiUT21VOh WmOOHNvR88ijK3O+BnINGDiMQSQKLtTtX2g+HuZHOB8ql7f4MMXCjts/m5AyxZJ8ySUbFLy0 wbFAcqag1ajeWA2zV8ndTnRjtCrYjZ5C8H215yLt8kvJyItGJU0S8nuGLkTmzkudR8DjHcx4 1bprhhBE4qMbAYmuBuZSTBspJOMcg6YFybl9Mm28cY3zURsSr0UyWuVskPwlt+ZgVrlZrS6D OPF4VwycKF5q4pEKcgkEOgCBgz3fDrUDdXDGSJPJktdEy8UrGM33MerFTFAXBMlSOfOnVsP4 VUuGmV7a6VZvQpd0iq2cKtliaVUTiQ5fIweFEKUwmTIGwnOUmfLJgD/GvMC12txubg5Hk+k0 XCNDNJGIM3I0cuXGhN0YxwIfVzMAAeu/qAVTrB4fOXUsj9JWH9HWjHzts01iQy6jfoB9tRSZ +tjfFb8vI9tWf0K1yStCzYq+vZBIpZ69kGLJZqw1m0JicuVdRgHAAUPHUPjtUla/D2zXayx0 UFJGPWmXbQqx1P2SaSYCXT01D64DpWkeDnJOrEaFWV1ZUm1tdGccyTFHtCHa2zQ/7ZVDUIai /aDYd6ujGIs+Wj7fI4ttOLPPPUSsNGrmqIgbSdTrjTqDGf41MeGlJTJqFbFeXD2LerQLeNaB GGWdvAcqIAJ/cIiHh9Y1Ss1Ydvs7uvIzCIRxGx0aLIjk2SFFYA1mHI4Eevj+FXyMxg9dq6cZ ohlDXwi0jm5UUnEW3dmITGkDmLvp64CqSt3U9Qen8a8s7eMsVVDUXpnfyo1egJCzIYE5SIBm yRaIwqKhDlABXTVEpO9nIjjJh+fpWe/qxkgeMY5zIFRXeLqlJ3B7yKZNQqF8cfPGK3nwsoJl 2qDSa1bZcVmMJLiEy5Ioso2Lhmrt1oAPeiJ9O2+4jt4jVE44JNEOLk82YJppNE1C8pMgYKAa Q9A/gHyqbliUBTC04pH61LV5h2lSmpKlKKbnYe1tx/8A6X+I1nFyPXA3Y9J/ZgfH31pVnl0w LIPJAo1lEstzbgd6f+MP8a+fb/WkuXoVXmDVrjYWNWt/2qs9NsAiJQ8/L51T6sjNYi0eyQJ+ 1Ip3/IQr3VQjZJsLfGdtQZDPXFMafSy3PeLHHbBtJQ9ApjVJco5aJRy0DtnjtSOr/iF/jXpZ 5GsXTdmwWP8A0JaFMBmoEzvg3eDyHbpt8q8x/V8qtrfiBeDaPaoFWDS2T5CDkzbvkJ9kDeVb 8NXSZLwtTPhnDouGX9Mem5zhIyBtQbE26+Q1Z5C3o6Q4iREh75MrWJMYoeJjJKDjO3y/yrKv prdRzH0PzajKFVDQnkSmL0x/lTp5ft8DKN5FwqZB4gQUk/6LoASmHcBDG9emNYff8xqyehGW uJxu3BSRbqdwoZEDEDujUFJcPbbB5ISTkVEF1H6qhNCmAIPUAAvj4VQ/preq0ou4yqo4VABW IDQRDbx6bCH5U1RvG6uW6Q7aqqChxVVIdLJiGxuIbbDj/Ctc7Xv9+UL4+Q+nrNLs7+QalYtk 012JyYTVKH1gH5eHpSnFYDQ0TAEh+1JBGOTNtZQET4wAgIdazj6X3H7LLGe01AblwBdAABtI D0EfEKdOr1u6TTbtlpNd12Y4GQAEwEwGDoPqNZbsdOrrV48kK5uK2Zh47KDj2eoVuLrZRU+o BDV6hnrWVcYGxmvFS4yGx3nAKd3puUKZXBK3K6kmryc7Uk7b95vrREgFHIDkNuuaZyTyWuGS UkXnOevDF76gEyOADxxUzn26DebL5PsO1ffKF1tDgLcNk1O8Hxb+vXG1QH0Jh4VwlNR7NXmH dJlTSUz7vv8Ae1eQbDvWWxd1XHFsexMJZdFAOhNh0D+75Vz6QXCooP8AXD0xlCAkPeyJi5+E fPeqpdhhpUej24AvIOD+9EqT5wQwnLk5BFPqT0qHfe1XETA+ynjsqBSGM7VD9oUpdJgDqPr8 9t6xiYlL8J2R9LuJhAqIh2dZQMABvDfz260pH3Ff8i8/qqVk119GBTb4xp2zkOleu7xNqTLB frLlX8xcHEQws12yD+NXORuchgHIJaS5z9Ycbh+VM4OwWBOC6FyLM8yyRCP2yhPrFKb9mb12 HwzVK9pX+2lna3aZlvJmTE7o+geZoAA2H0wHSohO4ZsjEWaUw8BmpkxkAP7sREOuKw3Ya97R uMDi45xK9nbeQi3qDxsko2cqjylAEALqJq3Dp9wgI7VcbbRafRm6GyaLtb+luTiRYe+YRTNk SDjpsG/iPiNeW3E/Nrs0GK8w9Vat8clIyuxNPTHyozi5LhcrIOHE/JKKtx1Im525B8w9dq7a 4qMU4pjipEFiZ6MAHbpwDyLTcFB0bWqhuIcoR8cYq48M7WgJmzU5CSiEVJBDnFRIY2Af9zJQ HyAMdQ9d6yd8+eP3hnki8WeOD9VVjajfLPlXU379HlFbvXSIIGEyIEUEATN9ovkPrXlpOO7r VbUZ5VP/AOHuxy9kUSSNLii4TKppKYuQyBgHrqEvUS+A7jSfGiCj2Vst5aOhGkYkR2RDuoik sUolHJT7iB9wHcPCsyUfPlGYMFHjhRmU2srY58plN9oA8B9adJzcp2hqs8erySbX9k2eHFRL 5Yqt/pinFc/0d4yPuO+nsQ+bNXifspdwkVX4SqphkBz5VpNi2PZ8ld1xKFbMFY84ptV2pNIk bnMgJjGKP1QA2fEM+lZIz4lzcfJe0oyHgY90LdRscyDcQ1pKBgxR/H+FU5uY7UokaOF0ANsf lnEusM9B865CUYEm7cN7ctxzZqDNSLjV3KMJJhIgsUOcm6TAdA+mC48B69aZ8Vou22PCnVGx rfSDKPVYvU0i4AxtOv3gfEYe/kPToGKzaLve44yFNEMVUASOUxeedPK5AOGDgU37wDUAissk VBPtKxkW5wOkic4imU3nitKX4UMVo4O9lV4gNSKtCvimbq4TMAd0dOxi6thEPKtVt9dG2+N6 pDqxyYyNruS9xHRhwZMwAUQDOBz9X1DpWN3Bd8xOtSoPCMW4EOCpDM0ASOAhnx8tx2+VQhjn FTmHUVMrnVzDGET5881G5ClNHW9cEbSjkbTupG4vZizpVR00eJqrJkI3U5OUxL+8Y4gGOm3W q80cuJ79FqPjQcsdMFPCo9SUMVM/JEA0h17wiIj4ZEA8cVkWn5+u/UfMfMaN3Tf4+Q/Ou70H W8fpIexSW24JEJNTMTSrc8SqloH3HK35envad8bgHSqZwBMiF1TxTpJhIK265JEHckwBHeSa TBq2zjO9Z+xWVYvEHrY2ldsbUgbroHzAKk7mumfuVNJKcf8Aayon1pgCZSaTee1N2Go2Kw1J LVMpPnEKhdZZ6LXkTpqpl1sSlHnhqHu7ZATFKP3VL2nJWkdGfalfxYR7i6ZtIiY6dKjI7XKO 2PgFTobAb/W2rzXykvsV0xCD9QOgB93lSF+FPZOLdLdn7UbRMbfsg7YO+bCI2wtEimBliKgc uVTkHomBC7DvnYKs89KxJuJ1tpHeRho0bmO7brC7TEpGWgQwXGOUngQDBtPSvMvd1a8BnGM+ lF5SPw8ou/XakeIU2ThneyjH9Ikj+blSpsSg9i+efAEFExDAiUw/Z1CTA58A3qt2hPNLAvS6 U5IiNyg6ZuWAuiFyRZVQogA/+nkciPXbbFULAGLowGny8KHw90vSplxHfqPRfC+74Nra9kuX MhFooQkW5QkedpB2koIrCUqYY1jq5hdg6+dQ17XjAp2qPsaRbvJuMeRbp+58Zw6YbAQd8Jpb AJc5z1CsM0JategufPG9dLp2wQAx02pG/HTwjB6NZ3tbby9uEtxLPmMf2RtJKypAcauyHVE4 lKcdh1Dq9OvWnNv3jw/acQmkhJXEkMrDQzJp7VHUok45SwncAGk2o6hiYKUdQ+oV5o0Jb9wu /XbrQ0E6aC4D0quYdxTt+rM3N/XG8jTpqMXMq4XbHTDBBSObJcemB6VJpzTJfgqNqqqcp9Gz 3tJsTA/0gihClNjwyXTVQ/drtYZ9zR6XluKltvH08/C9HEc0nDszMewpj2qP0qFOqJtygA9z xEeobVULmv8AgbhmIN5ETClpgRm+bOGZW4HatjHUyUw7bmWD4u71xvWK7avhCjVvzSMG8uL2 suTv1efUuBNk+j4VpEMJA7IxiCcpcLuESb6RDcCZHbOcUjYt+2ZbzFFqeZd4iH8goQpkTm9o lXTAqaoD0E2w/EXxrDKFaR45OC6SdxM1uCFu2ojJKmkWEss7cs9I6OUpp079BxozgA+tVxtz iFatreyDtpaauLkziMlrdo+9aJFTMQU8juI5Nq7okAcb1jVCs6cbWi6xybTKcQLbcxbKDNdU 0qmm9WemkyIHEU9SZEyJ9/UI/D0AADek5/iNadyoz0PMryjVk+SjU0X7ZsBjHBmUQHJR3DUJ tt/uCsc1UWq52umKcU/Anh/aU45kBy37Kp2Ei+5zKCHdEemTbfiNQKJhTMgfqZI5D7+OkQH/ AArlCvNO7k0bg84wWw5fS7xwxlniE44RVeNjk08kqZgPgmBDUImANtgxUIbihHvZZOSmI1cX TmJeRMoqgUN0ljZTFIOnd8QEKyqhW9eMqnRqpuIltu7idyT6Pkw/qtvFMVUt1iopl0mEwiPx G239KTtniREwbdoilFPFPZL9y6iQFQcCC5NGlXyxgNygA+tZdXNVOempd7ouyEuK2mKD+Hc+ 3mEcEeiuU+UQIBjDq37wj3vHNF+napJOyJBsyDm2q0K3wc44XED6shjAgGBx1ql0Ky5iSdF7 uy/zyKMY0t9FeIasV1nGs58qnMsYBMHkAbff41LTnFVGYmpp05hVQZTLVsgqiRTvkFv8AgP8 fPyrLq5Vc5NS8qXqhI3wtcspHZAkcLJm3+PTgmggnE2d/HP4YqjadZcH8d9vnQrtZTuZDSTc VHB+c4PCN1njlBNu65qhhRVTKBdtPrpCmn6zpgXjd4o2brrNl1TkOfqZNQukUh9Ch0xiqDQq +bmNG/Ws++kBpP2O25KrIjJZsZQ3eImOSjn7v8qpl7TitzXU9nlm6bZR2YBFMnQu1RlIqVM7 8pjtL0gWl6wB6N9UflSdKUG/W2XTBt/RsTP/ALQrG3hNEsub/wA0w/8A7DWyx+0GHo2D5fCF Y+VqdzzVs/WER/Gvn2v1ZLn6Va5RaUb+6NqAceVIc+jdo9K+ggZakKOZTVRKAUYtFoxaBxXo 62WaLmxYVkqmn/Smi5eziUNCgiTqYfqj+FebKtkHeN5sIP2XHLOFGRPhMDcTijtjumxttW/C 10uanxXz6CwNoRrGbK5W7YggRfl6gOKneDIAHhQfIt5S4Gl3KyD1wycyZSFZrI4FIxx2wG+w Y6/nWfrXxc7mLRjln+pJEoFIYUgA+AHOBpWSu+7HZWhnbsQTbqlOiPIAA5hRDSPqNb5Qx0S2 RMUnV7Xuh2hZNRsJiN3JCgU6IYAcF88eHoHSicN4BizuCU5km0eSzkgG9/ghxTOTcf4betY+ W5rz+lCku3O79qPye9ErXPNL0HIY6U0+k1yM7kNPdrWQmADQdQ6eDFDAbb9ArXdhp/URjeJf KGkCtmxlU2CigLHLjAAUc5qZ4XmJ9NI7XgUxOHX50WNc3MRjJLto1VVF+Jhcr8gcZEByYv51 DN0HzdEsgik4TTROXS4ABACm8N/urxz89FPRU9Aw09FzEdIdoXTTli9766R98Y9MY2qoWfEp 2lxejoxgRcG6scIKnMOSqjq+Io+AemQ6DWfqXzeC+CjcDr/kAAE44xkfMaRLP3VGOma/b3jd dFEStjKF3KmPXGa+hc4iF2uv35ZRjiapwj9/cUrHsGxlVm7hUwk+HugI70lb4gE4xz07SUBz 86mIN3eDiQdy0U1cv3SxRI5WBIB6h/Gq4ZJVJwLdQhk1yG0nIbYwG/zrwXe7WrV6jkmEa/8A pGyfNnbxBbTrRH4cABNyd78vSoe27VhrWkHbFk2V5a0W5MdcmRMO3wl9cB8/nWPLSHElGPa8 5aeBnkgNzBkPHu70OxcSWzhD+jzyanM1JiUdgObqb0EfGvbS5FljJp6xEkuIlhnR53ZBh1UV uePe5RT9FB2/Hbp1rCJoqZJ6WI209nK9VBHT8OnVtj0qwOiX6tcBm7lKaVluzmDpkwJeIB4Y /hVXxoMKWxRIOkxfsj5VlxM4y8OxErlTilq3IlD+2Tw64R2kTc/b4fPHXGw/hUbGs3Ei6SaM ExXXV+AhfH19A9a8bQ1oVK3Fb03bjpNpPRyjJZUomTAwgYDgA4HAh61FfD8RsUxxAoVNQtsT czFvpWNYGXZMC6nS2QACBjPj1HACOA8qgyqpH+A+aYg1Cu0TWl9sPOpBqFAu/eDegYxSGAo9 R3D8aAUK5rS9d8eA+Yf51aI+yZ1/fDSzmiKSsm6R5pAKqAlxp1Bkfq7faxjxqsZCsV2u/WUI UFBFMwgbBBHGKBRKYuouoQ89A4pjIcoV36qZh1ACuNAiQQ1dOnn1rve1aOWvqEcaeSbOfwpi C0KU0DzuRylAV37hiCBvw++rfZ/D6QuWJjZMkkzj0JSSGMYFX+NZbAeXwlyIF1G2yNVG3KQp lCpCSipGPnl4N0yXTet1hSULyxwGDadX931q8uuE50uJTfh6jdzJxOnciguQrcwETACCcR1d B2Dpt1Cm3JOTNqFStwMI2OeAhGTYTBe9zFiICmUggOMBnrnrmntj20tdMk9RI4TatY5grIvn B9+WimHgH1jDnYK5hLLQV2hWlWTwlfXDB24/Vm+zOrjK4Owb9myTCQiHfU+pqEo7jt03qlQ8 LJyc02iiMFkVVXqDM51SiVNIyx9BBMboBR867t+4jKLWo3FwkJEuks3UJmKL12ykVjNNB0jN wKJhTIPxlEByA7Z8KXNwe5KakytcLtSA9ksJFFRux1uD9rV5ZC8vxwOc4yOMVpys06xZPRtN XK5uHN0Rl1XHBxsU6mUoBwKK7xsTJNia9/IdOREPDA7VJW/YdrTlhyU+jdztu7j40HLoDttL VJyY+kjXXjJjm3xpA1RGzKTuWLOaGK1PiFwjPa8G7UYSL6RkWMizjlCHbARJyounqyj4jgch gd/GphbgYdreTKAfy6htFoHuGQ7NgR1EPoMin11Dq2/yqpWsfLmTFKFW/iRaSNr/AEfWaOHS recjhelI5xzERA4kEpsf3aqKncTE/wBkM1nO3jXRTlCtxjeCbB5FoJorS6kotbBZoq/d7MKo k5nIAA3zpx5+uKzRGw73cGUQRttftRJL2WZM3d0OeXzBKbPTBcjkfAK02KmSt0NNa1eHCVdt f1qW7bxTOiyNvtZeSE6xdKJTqCRTB+mAx575qyRPBi3nN8XZH8qTeNY+520OgQi4AKCSpBEy x+mrTt4h0Go2x5/o2mr0/wCF90HLJvIgjZ1GpOHoR6oq+9eINj4UVITqYADA5qT4qWTH23ar V/DwLhyi4YM1hmiudRCKqgGoukBEA3yHzAelacrPTUyZlpoaa3j9T0CjxAsGyZAH3bJGOWfS ix1MAIlb80UwKHTA5LkBDpVXY8O05u/mLM8a5tKHKzB7IiupzgFLmafciGdZjZAuA8c05euu hky2hWtw9hwj79Jqb4ZnK4IxOs6asFdWFEDJpichx6APT8+lZEnkxe91KIlH5hWOKna7QrlZ gUKFCgFChQoBQoUKAUkb4qVpI3xUHS0rSRaVoFaOXp+FJU4bftC/3g/jSo3zpbqvh/Rv8Kyt rqYtVieJ8/xrU5Du2u68B7P/AIVj7pbveeK+Zw3qkqfpU6pKJi1pErgyP9gmKgh50zMQvnVp 4dmOD5wBNwFLvB5hmvoyklWkya09dJ1PXAxIxkFeT3U1cm0+tQNUBSlJ0agXLXoThj2P9U7c /aDMze0EgMZMmoVNh2H8Oteeqsdpz14RzdZpb/aFkDG1qJlb8woCHj02GtLPr1PbRrd0cL7d dzEpM6HgZUUKsgmIB3zFAdRfSnFwWrFjw/hoEqS4Iov2SgqeJsgID4fz44rIlr2vMzoTuZt4 DgmopgOGBKI9QxS61332pboIrSTs0WgcuFOVsBg+HvfdXspOOVf6pby+Yt0Lmh0EETJItGjt oU2O/guMDULLWXbc+4QmJYnNInF8tPWcSCPfHc2Oo/xrJXl2cR33YVFnUmsYg6WZioZER/D8 6RfXPfkVMc5+9kI96KfL0Kpafd+QAIdM/hW2dv7/AKJxaT2SNkEfoMyXmmTFu51NnzbocdJd jfu7+O4461JuLQjovhO7t5Jur/SdKrlxn4zFVAOnyAPCsoh5LiQs3du4U8oqgqOXKqZQ0Zx1 AfDYB/Co4t2Xa2YqwXt16DcTaVGpjAO/iA+Y1O7B1q1yWTw6hHTFVZUrIyDhvlQgGPzMjvqA cgGf8qiv0pCEPPWu/RVQUQXjlCpCiAgXQU/d+W3hVGmvp45gUhmkpRWJIUBIdUAEADwz+H5V CyEvJSTdqg9fqukWhNDYhxAQTL5B5VjKsRsHBvso8OX3aTOi6JJuOWoBrzkcZ9Ks10WTbcjc j2fWjwPIEDUJM7LG5YYHrtjHSsLtEl4GUV+inbs4yqDc4FDHrmiS0ldLOSFGXkpNCQSMIiRR UdRTD1EPX5VVqdKQpq78no1no9ltSrFMCpmDcxznH3Y4U+APDO3T8qNJIvztbgb252tJ8aVT MoJ8FAQMI6hKOOmM+fSsCUjeIy1tpqGSmFofUBiBzQEM5646+dOZBrxTYs2r9yaaBEgl5JiO gEyYm2DYNyj1rbdjKiJUaRHuJZLjtb7Ird8mgxZqM011CCUXKRTFEynXpqAd8h8OaNwz4dRk ua9VJ1kiv/WjhJPUXCiHd1Affw29QHzrJHi9+NrmatXryZCc5QC2yqIqFIYfAfDI1IM7b4lu 5KWRTCUK6bqlSfiq9BMTHEMgBhHqPpU59fv9jFs8Cz5vDeJYLIlKupbCzQ7zI6SBuGjT08Nv L7I1CX1w8bxFl2o5tVIrefB03ZHeoaCc1I5MnOPh1xvgMYGsw+hnEoId8B2cgmyROYztsLvG rSGTG5f1vu61W4t5KyDpmxZyzwyqhipNSC4EAARHYA8qz1xgYr5x8SkGnsGKWbOPZsYQ6Sb1 zgDvFzDk5gDrp67+IgNPOBsLb0xb8oa6WzQGjeQb8l4fTr5o/CjgcZKYfH51nl3EuBjcDuEu R48WkI8/LUTcripyxx4fMBConmqFLpBVQpeolA2AEfP51lOXctu8moRlwI4mMjQDZmsldKRT JIHxyxMAZ046gAAIeOd80lfkVGL8DUn7KKYxwNmLUxdaRQUUMJviIqHxGHvAJfTptWIdoc8v ldqXFM25yaxwoPmbzGudsVJyUzu1uUmYFCICYRIA5DcArSN7rVGC1cF5CBbX8gW4CJqsXjZV oHOSExCKqBggj5Dv1ztW62XH8NLIgfZl3soGVk7fYD7ROBAVA3NWDSABkAOcCfVDJg8QrztN XfJ3C3LGv+xco6pRKCDYEx1Z26eG/T5U+jbGnn98fQxqimvJmQFcSgtkpgAue8bp08+lTGKk 3+ks2gEOIvabUQbIxkjFouipMyhyyqGDcAABHSP7vh5VtVm29YTzh/b14GeQpJhtah2/Y1Fi AdQ2g+o4pCXJlNYlwPrXmy27vmoJus3h3IJJnOJldbfWOr7+nWoZwsR84VfuPeLLHFU5+WIB kfLyD0q9aa6p09mp/pEyiqTiGgGrWPI3Uj2ciB0EgA5HIlwfpnqbOQ9OgYq6PJZjbH6VFoSY OUG7RxENk3ahThp1CngQEc7DrAPEuB8q876ykKmPvfebkExTd/Pl50NtXJ5awnPnu8o4iP5U 3TF6T4UdkhzXk2lXLNW5huJF2sdqqkAqtTgIiUTG2KQom1GKA5L91LW2/gWXBy4LgfqMG8Yr OS8amjy9faUlksolLgO8AHN8Qem+1eaCogdbk8o3OABExBKIH9ch1rSbTsu57nseAa/SVowh ZV+qELGOc4XWTzrUD7Pe7mocBkQDNdhX+5i0ec+iTTg5YTftMfIpxs3FPdOsqjlVDGlwUEw3 ENQgGNhH7quT+WiCyUc/m3zRJEtyzCTMXCYIigKiH9H6l7ogOnSYQDGA721eRDM1Wcx2dw1U Zu0HBSnPyx90bWAas+IAPiFW3jRG3bCXw6tW8ZZ3MKRuAbqq5FE5TlKbUT8QDz2q6SjCXdR1 oE1fkLbfHa2bkkotKQJGQRGrkUFiulklcn0qag7plwKIbZ8etSHCK6IRa1YoOTDtlGF1KyTh B6sCfZEDiQQMkImDJgAg/wCdYjZdvPLkuRnARCQc9zqMPkQhQyc4+gFAacxNsozMhcibdygu 3gmizkroC5I5KmOA0Z+14fwrtm5Ss+io9rbr6u22pWJnyNrgi/pA6jVlmkqUC6ex9r1gwPt3 1RDA9DCH3VGT1xvPozFLP76gFrxPPIrMZpkCYnSamTEDmNgAAveEPi0+AeFYZ2B4EanJHhnp WZtJyr9lNy8m2AQNjA/6UUzBZFR2Q0asU7bQVwXs4gJBP8ICHgI1Fy9mjBonHB+yetLORM+i 5K5GrN0E4+jwDlKiZYRRDUUAKJgJ4Y2zTHgvNxsPJXTHSrkjRG4bdcxhHJ/gTVNgS6vIBxjI 1W4u3nxrwiLVds1Yt1JPkWoFXSEgkFUwFAwh5b1MN7KOtxOuCyRW/wBy9u1rFIJwP2Uph2Dw zp/zrH5La9wl4iwUVw9sNF1Ksmv0bM69qoqCAODd9Q6fKD4jZ1B0Eu+NxpGT4iWWtbLeMVmF 3Thg9h3Ui+OkB1JxNJXUdA2B/ZogIYDUJhEtZPw3sVxelt3RPnIsybwUUd8mqZDKbg5MDygM OMDsPTPyqnp6RTTV0AGS5+WQprpDROL0PfN02Tc9yQ8XcVxtZOPJcb6YKsTPJRZmAOQ2OOA3 MJdwwGAHAjSDW8YhnOXYT6fNPalwNGaraVbJGTasjIL6zNQ8g0FAC4yHnWAIolFRJAiJR5yp EwLgNxEwBVsuSxJZpfk/asJGKyIQzgqSh9k/ixgRA2MVvHidPDmDULrva0rpjbjbR91Htn/t S4mEjFRUAXiR25SdzHUxzFHOQD4gzWYqTsb+o9vaiJVAlfpKaRdF8DocsClyPiOQHwqHcWzc KBikcwLtJT2oERoOTAldf8P0Gl31pXSwh3kw/g3TViydCzdKn/sVs40nDqXfIVGdcdFtl4hc Y43lu5i2pQZORezbSWj2DhMwJxoIpcsxR6CBjZ+qIU9bcYbQLckFKAZFioeyXEJInbt1NDN0 ooVQMdREusDfjWOXhbScHwpsW8U1uYtcwveakYuAR5CoJhgfHVmn81w+lf1jR1nQzB28XWjm z1zkpQFMpylFU2wiGkuR39PupXvTglrnuC27qvayGL9wDuHgWRkH702UyOh1mVMIbgJQHVjr nrWYSBCKqOyt/wBgZQ/I19eXnu5q3cbLWZWXxWn7RYHUXZR50eSdbAmEDpEUwPhtqqnLH0Jm PjOAzWVy5mqPSmj0Ix4xWx9HY4jx9JZJbQQa8akkbuHFMiQrAJsk2KUR+ERHIYpQnHS2/pJb cqrHyQFteQXRjyIHMbmx6zYEucqJt1F9W4/DttTGJ4Iw8jEqINiywzP0USmiPzm/o53Bia+Q BQ9BDffpviqlwv4TT1w3syh7larRcd7SWjnxw+MqySHOEoBtjIB8XTfbNemVZeKssO5bJzij ZTy5moEWk1YU1oI266cg1HmAdJYFNQENnID+9mlEeLtqlvC4JL+tm7R5c7W4mKqTfKiopJ6T N1A8CiI7CA1Wp6z7HhVrallmE1yZyKMs3hOaPOO45wplADgGcbFHGN/Cr1G8D7P+mFwsE0X8 w3bXM0iEidpAvY0VG4KHUMID3jEMIFxkPhHbNZ1x6UUhP11Rri0RYdkfMZFH2iKSSKBBTOZ2 Yxijrx7sCa9wKXIiHWqL9JreYcK5i14RKSF/cCbMr8HWeSiKCgKCZPrnI+fnkKmy8PIeP4SX pdsqm9flazhoqJUTW5eEgMIAvjHeybSGBDoA0ONFkxVtW2otA2rzGRG7MT3CR4KheYcoCcpi ZNjIgJc+g1prXSskxjQs54px6fGO3b6Ytn6jOLhixiqaoe+/YnSEwZHf485zv6UykOJx2txW 4tbSr5nDxDYGrnWAcx0Tm8w2C9ADfuhnwzSl5cPWzu6LBhrM5yKdwW6lKLqORAeWAmOJzj8i E6VcJDhZaSN4XgeMixlo+Kgo9xHtjLjhYy+PeashsAZHG/3VNMpzrJrjkoRuI6CPGu4OKLFo 77Y9KqaKIfAC3UOTRlQfIpchtWaFJoL+Y/OtzU4b2qtx1+hyLMWrWYtntzbQp/sa/JFXbcQE O4O2R6+FYS3OZVuUR6+P415rvb0UNXK7QrzDlCu1ygFChXaDlCu0KDlJG+KlaR+tQGS+Kl6R T+KlqA9O4/vPEA81C/xppT+F/wB6NP8A1i/xrlfA265NRLRcY68kC1kbpHrWwXR3LdVD90AJ nzx0Gswcf7KJzdc4NtXy+Fl1XKPaoRqsNhr9nmil/wCKAkqvH+Iadw/dfJH8SmyFfTkiK+Xg z7TG80PiSHUFZ4atGmHgHj9KXfUVTz6FrPFC4MIeVRY8KkTo1FoVqkuWtd4Mnb/R2SIdwq19 8n30Q7/UPUNqyGpe13NzIvBC3O2CuYvfKgTVkvrWlv1DeLqsG2Z2STmXTdcFOzp6hzjn7eXm OK79F41DhC6hmjFdMr1PnuDZERAxVfh/APKsVkJ+9G7rkyspJt3ACBwIpsIY6Y+VOGc9fjmJ dps5KUXjgAVHIEwJADxEf58K92cMkt/dR7SLj4FiwbaWjJ+30HHIiYDE+IB3x8wx8wprOWrA XM8ZHmWxnSbEjrSmvnUoOw5yG+Ax1/jWFGlr/eW+3W7ZNuYxNVMqBgHIAYfgxRrgdcQYp83e XA6mmLrGEVVVMD8vnV70cfv9xqRUodoxdWlHMJNKLfGSUOu2MchkjgI7ht8Owbm69MU8T4b2 dDIm7Yh2xVN0YnaxATrFEC5Dpt59ayGDWv8Al3C76CcybpTGldYrgChjyER/hUctK3FFKO41 aXet1DGHtKPPyAm8c+Y1lnHyPS8SxiX75s1XK8UB1CCmOo2UTFwO3iADt0z57BWFcWopnGSD lmwtAsM2ZuQQTfEEcOS48c+I4HcPIag9d5/RsFiOJn2QChEijzB5eTDsAfhSt0RV8NItqvcq Uj2HugiLhfmAUR6bfVHar3s4aJxXzgH2Za27kbuQWUASZ0IGwfYQH7+nTfPlWjXNaFszijGR ko0vNQbI8s7ge+YMmwkb12+6vOdoxtzyUhy7WB12sCiJxRW5eCh1yNcuRG54SQKhcbl8g6V9 +TW5E+vfGoBDxrnD3cYKq9NRpOVEs0ztSoKlYLpmPkcIhqH3eOn4/gNML2OiMPcajdJZBRVo goVfX3FDd3SBfMe6O3exjpWFR9q3/KW2o/ZIyDiLUyYxe1/tcBkR0dTdPvo61mcRht1F+do7 VY6AVI3B9qMUNv7PqHyrTPVli12YfxEJxstyXugjsBVt9NBNYCczluNQgGfIQ33yGPKrXNNW qNwXek4b+2DKP2jrR0ERBMAEds5xj7vSvMtxRF1MHkS1mySBnL9MFmSaioqGxnG32Rz4VMJ8 P+I/t5dkJFWb9BEqq6jmQ5eCiOxRN0z+7+IVlWu6YvUN2KpO5ZIdaKwA1cInfEUATR+UQ/e6 jjoPlWX3JYsDG8E7bdxyTN3KNXTBVN4XQBzlMr3w2648/KsIuKOlralF4WYMu1cCAGWIRYTk VAfHIbGzTuPtyae2bIXaz95DxhypuB54hoE2OhfHqXp51yde5WLY/wBLpjG9jSlTt2icyaSS SIoQQ5yjbljq1bjkAN4j06V55U2/HGwCNKGVFbQodZVbu9wVDCI4+/5VKW7ccpbiirmKWRSO cglPzEgUDT99YTrlJcUEZQvLNo5gj6EN6f517AtO2uHTqz4C8+1QRZVO2TI9kUVIAnNpMJjC ljIn1CGPn0rzm34o3kkoqsjJIgK/eOJWBfy22DvVDLRbmUt2YvZU6KpUHZSONQ6DnUOP1S/Z zitIxpHqmTRP0iZIyNyREA0YxpW/KaPiKt0ygYiuAA4ZLnxEc/wDFXv21GWx+lvDyAOWbZg9 iEk3ChDBo1mT+1nbvgHiX7qwm6LYkrYi7ffyJPcz7UXbMQ1COnOMGDHXcPxqBxoyTQoXO4gc ogI/jXZTcxek+FZG0ND3a0kHkavcprjK4cmbrJACrY6e5RE3dKQBNqEoDkPOnMK8tZlwGkZe S7E3j3jmUjkE+SJzLczPJ0iAbgUw9cD8xxXmQqHM7hGyqvXOhMxxx64qSWmpdzbiUSo7eHgW CuSNBSHkoq/a6fFvVRnQxejroJZbPhvw7RaO2Mv7Jn4tcNByqOFGenCvuwHfvY22EceFWuRf wqDmFfzCzdFZRecSZrqockU1VADkmKBgDSONinENumoa8gRbFc8hHLN2rlr2l0kRu+FAxSJn MYNJwNjzxVn4xM7vYcQHVr3hIyU88jT8lqodMxynKIFNqTDHqFdhKPuL7JX3AW9xzZ3DJxKM ikhAdiX5ShXCiS4gOk+oO6ZQAEAH5j0qycIrogPoDZXN9jND29KuXLlF0qAHaEMrzPc5MURH Tnfxz1rzgogo09ydoq1MH1FExIP4D/GlEY12876MU6dgACInTbGUAADrnAeFRn3aKegeJ1xW 7OWPJMG05FrT7lm2WO+5hMrIdq1A0zj4il0CJcmHbcKV/S5uq2puBFnGzTSXeOLhSfNxQOCn KbFakTMGQMOgNYdMBnrXnfsivskst7NX9nnUwVx2YeWJx26469fwpZSHlGZSqDb8iiVRYjcp uyGKBlDblLnzHy61V+5u9Ra+BtyMLR4pxs3KFHsfJXaKCX6nOIJAMPoGcjUrwKXi7XluJMc/ m2RWjm1n8YyXMbQR4sbAJiTzzgfxqjmt64/axYcbble3HSFUrcWxtYkAdzY8vWm5Yl+d86jP ZLsXsekZdw25AioiUgZMIh4aQ8fCsqU0dbnw8v8AtVlwZjoKVkidsTtWYaKtVC5Azk6pDNSi GcCbBR05IOM9aVPxGsBT+vpA5nzy+F44LlYGTEqcYi005AMaTG1CQBxkAEKp9n8HC3Cxt86s 8q3lrhjXEkwbEaa0QKlnAKK/VE2kfQNgrOHEXMN2r9y6hnTcGKySD06hB0pHU+ADD5jvgPHF d8UQ2HjRd9tyvGbhxcsZMtpNvCi0Tk3LdEyZQFJzrEwFHfTpHbfwpha9zQLP9Jy8rnPMIkg5 EJQUHQ5Ai3PKPLL57mEPw3xUXOcJV2XFO1bCipZOTC4GDZ525FDBSJqAOTAHiAAURAR8w6Ut bHCUt1cY3tlwkoc8FHLAR1KOW5U+Sb/hgURADm1bFAByIAI0lDWq1v4Z8QLSacBfoq/nRjpF rb8vGGaHIfS6WcqAokcukdI4ANOTF2zsIBWNxrCIDhW7kXbnE+WTQbtG2oN2+geYYS+Wcd7+ NRcgh2aUes/i7I5UQ1iHXSbrVtb2JzrLtGbVd8l9d04DCLJtp7OU4JqKGHw94IBj+NPTLEU5 H/am/f5QA4TMZT7AAcO991bbJcRrWDjdxIuRF8s4irlhRZMFCJDgy2EQDUAgOA92bcS+PSmt 38FCM4eccWee4JV7CSnYXCDpEpQVIBRE6pMB8IaDfhmq/wAOuHPtaEfXJdpJSPimrRm5aotS hzngOV+SQxBNtoKbOfPwCqhalGaM6VaBJcX7FkrynnUi2kV49vNo3LbSqImICz1JuUgJrAO5 CCcoDkuPHNJXLxetK4+Bkzbbnntbnnm5FHqLdgUjYHhXArnUE3URUz+9jAUza8HLFacRJiyZ a65X2kjIGSaERFP3LbkFVBZUeniAb6OnrUcz4Pwv6pfb6j+VGX+jak4DspinZCJVRIVuHiJz YDzx412Maa00cU29rhi5zgrw9tFpzvattme9tKcmCYXW1lEo+OwVfi8TLPJxKVlTO3q8LIWS W23Djs48xNQNACbQYB1B3PHOc701ZcI4EDcMo2bfyjWTughXb4w4KkmkICOgBxsfBQ2HzqDk rLgCcV7Wtj2XcdtR0lIA0WO/wc64iroKKfhj6oj4DvWsP015ZdCt9XJaF6fpIuLxcc5S1Hhk VHJXJBIcxUkCE04AQHcSdNQZ9KzKSIRZR2VAulE5z8kDY2LnugP5VsVhcIUrl45XDbijkzW0 oGWWYqOljhrObUYqCQDtqOYxc7eADT/hjwgtyWtmy3swxlnql0PXqJ10FRISOIkcxCAYMd4T HAB307AIdcVhjSXh2MTuN41W37BTRkTzwmUtosCvHoo5STHSQhli6h0iOgg74HOaibs4twd0 Gghftp6P9gSanYF49UQWIwMmUpRMJh94uBw3Hu7beNY2sQyLp221auzODo6vPSYQzVy4I2uw vbilF23K8zsKqThdcpBwJwSSMcC58MiFXzFaIwaAjxbtIbmjZB99IXB4aAUi4yVUQKd0Vc58 i40jsQSlNpKI6umcUwtPiZZluqO2bOOuD2YhcaNwxRj4OuoqmjyzEXHyMbfUA775ocSuEDhC yYa5LPghZLq9pLIxR3JlVO4qUhBTA2FDjgwagAu3yp5wh4JyTziU+ZXg2ZqQscoswc8pyIj2 rs3OACiXxKBgyAiGNwrmdPIpU1e7aT4UTVpGQcFkpS6T3Bq04bpFMXAp/wARxiiurqthpwyn rQtmKkWytxCwF+dyf3SPZjavd9RMJhHx+6pCzeH/ADuAV23hcJUTu1WKLmCAqg80EwccpY4k D6ucBnfxq6cQOE0C1tZy0tqKTRmSP4dhGuwciYXarsgCpzgHIJl32Nneu6dmS1Dvq/0H7i1H 1me0od3AQ5YYVHAFHWiUwiGOudjCFWG4uMkVPy0+dSFfoRk7EtWCwJiXnJmbmyUweGOnxZz6 Ue1eEpYG72/05Wi5CIcsZArUoqikkZ4hgpSn1YMACYdh8aJZfDr2/wAZyRU3azKCYowCkqmx Ree6cABfdnA/kJ9OrywNXHWKIzQTrimp9O393sY7kPvZJYmKE5hMLVIE+WJzCPU4lHr4ZGsz KnykwSJ0AK3Lh7Z9tyvD5S5WFntZNzLzbtu2bLriB2yBEgMUCY+M33B6UhD8LWcb+jNc15yp F3c+oyavmPdNy2aB19GQN8KhzAB8hvpAC9BqeIhXXua/JidD50b4igf0CtG/R5txhcl8SaUg zSeljoJ0+RbL7JKrFAAKB/3d68UYjN+6Pw7/ACoG0l+I1bpenCta44u2nVrJRrSaXjCrOo5t ggOA54pmWLnYClAMm3Ed6muFdjWoSHYtHiMbKKvZSRarOjIic7siCPdMjnoXr4FzXqpwldao pPKmtHm7WQfrhR8dK9OQdjW6lB25CezI1Ro/tZeQWOcgC5MryznAxRDV3QwHibqO9UCVtJjO 8PODDKJat4t7O9uI8XAfjBJUAAw59Mj8xrLY+LsZZV0ZCYwE+M2KLrT+2FeppCxLaZX3BpMI Ns3asrPcuiEXwYDrkU0cw476g8c7/wDLTpS27eTtlncZI6N7a5SRKL/lAZrgVhDAF2yYSl2H O29acqnd7sXlCkPrVtb7hcM9cl6PGxvZrVkuuZkntpOCQAJgAMbdB8PurFC9/vV5rlqUWmRR P4qWpJOlazBqlLbLmcYh/wD2C1G1LWj3rmjg/wDOCuV8DaLqJm2VldW6WDZrJ3Tn9ql9qtO4 mH5NkvNJsZwH51hplj/aGvn8HHJrIzcfthpSNIY7wpA+IRwFEeftxpaHHEkgfyOFfRZLbCj7 lyzU/bkznPXHlVRdbLG+dXS4mQmN21rssT4g8wqlODZUEazthKjUWjVoFC1p/A06QSEgC3N/ 2ZT9l8fw+H4f6VmBafQPtr2on7EM6B70J2c2DY/yrS3LGVKj0PMWfb1yx8WtJNlP6O2EEl1T d/AG+E3TOfOpG1bXjY23bgbsIYzftguUF++IikTlbANefZ5a82RkyTzyTRFXcgHXyBgD5U3b 3JciJViI3DJpAv8AtAIuPf8An517N2OetU4vQzeBTieEsczjGYoonKzXUN11Kgpvn1wH/Spq 5oCMuF0o0mEAM1CUItpWERBQ2kenkHyH7689N4riW5t/WkeXGIEBUKmLoAAQDqIE642H51Ct X9wzLxq0byko9dEEAbk54iJB9Ps/OuRnpSlfv76uNxfNmkE+UgbfttdRvIoHSekSyjjBwyYA 8gwPzAKcNeHlkxUfJAow9pGBVLUJyc1VEDFyJevp4j86yc1rcUCzyZDlk+3HAS9o7eHQOoCf OA+VEb2hxH7Y85ZHyKmnUuoL3QCoD6/WrXXq6u1usXn6t7kj26S/ZUZdIzMhxyIJEP09cAHX ep3jcXncNZc/7PPY1Odrz2kdtsb4/wBKyCJt6/HiMo0ZpyCaDBQSPEzOtBNePIfiEd/nXbgt C8IqLZnmzp8lYhVWzY78DnwIhgQJ4VNK9UyW79HNRH25KNli8znMVgBLONeS9P5/CtSuCBti SiYck9FtGyTZtpJrEBUTNzA0lwOM5+X3V5ylrbuGBeRbd2zXbvJEgqNCpKZPgBx9XpvUwtw7 v08wZi/R5LgqBXChnrvAAXOAAR88+FYW/wBlPQ0GmVuVMDERQ7M5cF5qZwArEophsG+PCm7x ZqeHF0RIBKpbqqZH/NDAm0iAJh56h8PT4a86LWVdrdw8ZiTJkmwuFSpOhMCiYdR/e+VVjmHM iBOarydh0ax0/hXslexqjF6ClF2tsPOE8/c7JV00bw4tjikIHOmsJw0jp28c+XQav9wDHOLk dhpLIjIxCC4oqLFAVNKmcDgeoeWdsfDXj0yqh/jWVUDwA5xEA+Vc1G1Z1qZ89Q5rywu4O4vX XFAiT+DbntRtbzuZSIilJJOFk/co6DZTMoPQC5D+NRzxpEOf0dVYyKXiUWTlgl2rsyhcncAs AiOPrd3xwOcdK8pYDfr3vi3Hf5+dDBPs/d4Ve/HKlXMHoL9JaEttnwxtxaEWjnC7VwkkVw3V KKqjcS9TFAdu96VAfovtrVkp6fhrrdMmzd3HmBNR0YpQDpnAjtnrt+VY3oAptQF9PurptJ9j BkPWsblzuot684jObUgbDnD2Q/txdSIjGybIUzpnEfeDkM+JuWP3eQVilombSX6NvEUjxRgk +XkmrpqkYSkOIgYBU0BsIhjw3/Ksr5aO3ugDA5++jG0mMBjFyJenpWkrsZaIjHR6LdT0PP2z wdm5meYrtoJVJvKsVRAD6zHDvaPIpShvsG4b1CfpTPEJiUiG0Ui1kHBV3ChDMFAcKiiJ8hkC B3QwIbDnp1rD9tWvAZ86dQr99CPAew7lSPdgGkq6GxwD+QqITjF3FrfBtR2w4d3RDtH6Fr3c 6kWrlk4k/wCjCLYg9/Bzh8Pp+VXawXljM+Et7MntzwzuUlk5EjnX3QcPDF9ydINsE2+z1EBz XnGclZWecFcz0ivKLJl0kO5HUJQ8g9NqY6Etvdl22DYK7nGnShi3XiBI+0rLtM8ZeMQnCJMI tqtC6i80ztM4cwwhjuJlxnV0HbuVq0pxGsBxfQybyejnaiVwrgzUUEB5aJ2JUyGKO+gvND4u 7868bdzVr0F1D1HG9DST/hJ9NPQOnlU5mLVeNhXN1XtGIW63LOqx0OVu4NFnM6AmkxsAZT6x tIAIj61oP6P8kTh9wZuSVvBF7GBH3EQ5W/Iyqcx0NPLEOoAYfH0rzrFyUhFGMeHfuowygaTn aKcsTh5DjqFKvJmbepmRfzck8ROIGOm4cGOQ4+Zg8R2pnlXV3Hpo3Zaf4bl/RhC24yXZlk1U mSwsXICCoO01wUX232MUMB8Wc1p9yXXE261Z3NcQPEGqt7IPARflIJ0iizFLJAyYBKQwdS6M Y8K8WdzVnQXPyClnDx475ZHz928TRDSkRwsKhUw/dz0qs44pwehVL6t5K+kG30ghhalg3DcX IHWOiYxlSiVIyw94BMUoiPXcd6p48S2NqcVb2lLeQGcipmPNHJquBwbPKKQDgIhkUwHO31gA OlZF3dONBceWNqFaXeL3Daek+FPFK2Ia07RK+m27T2HFuGb5iqgIrLKm16NAgURx3w6CHrVX 4q35bF0cLXdqsJVc8i1XjwI+OmIGmSkKIHFTOcESyGnI5HbasT2+LSGa7WG500Nvu1b9KX5a DHjRw1uOMuvnxkHCIxsq5TbnAMIAO2nqOsf8KheGHFRK1+K8q5klm7i2pCcNIOHiiRjnAE9X KMmUN8jnAB4ZrG6Fab9GiVup22fXhPSDMQM0eSa66BihgDEMbICAeHyq4R97Rf6vbCi3hVQl LJn+1N0yEESuWp1SqqDnpqAxQDFZ1QrHc7snHplTjLYvtZ86GYlHyb6XCXSKkkdHs3LKbltz 7ZMBjnwPQBLnNVWS4oRFwXk3uJzck1bDh5DtkpPsLfnIg5SPuiRM+cJacCXcQA29Ylqoaq9F OKqy2G7POI3Dyenb4m5WRl4Ve5nJUjdkZCoodgREhCJgYfhE4l74CHlgaaR/FK2G3DP2T/Wv tUtpLWySOKiHZRMdXUDsVPAQDqGB9KxTVXc1G9T9mrRryvC354vDZIzmWUb25Epx8oUpBAQE ohk6W/e6+mcBUrJ39aKtwcMG7dxOLwVkuFHR3bhPLpycyxFsafmQA67hWR0XNRufROLbbV4x srY43y1yx7iSUsqWlFZV00UaJi5OscpgDSH1dJjj0NuAb1JW7xugI+Oh01G8yk4gJB67Zot0 S8h6C6hlCgoIY0YE3QofPNYBmhmuwvUh4VosSb+J+gcyisij7fkpgrpMwE7ySO4mwbwDIjt4 59Kd8I7vTsTiNH3Qu1UdIIJLIKkT+PSqQSZL5iGelVKhUSnkpuxuOrCNiWja2Id57Tik3BYq UfgGpIzlUDOBMmX3YDoDSU2B8c9Rp1avHq2YaUmF/og+Rau5paZZFQOBjkVWbchUFNX/AL8l xnevP2qhqqs/ozxawx4mW+ThGrZLyAfKyPsoIpN0VUvJBMq4rlMbbrrEPPGNutSMpxzIqsSW jbfWTmHEjGv5MyywggoLIukpUw+LBtvHwrFtVczXeYrjopqt+cS7du6ajFZK2JBzEtReKLIL u9SgquRKICmGNJCk0F2xvvmjl4tM/p8NyGt8/YEbbNbrFlzcnKhoEhTKGH4h3/w2rJ81yu1v 6pxabww4qfQmAjo5aB9pOYhy4cRqoODEIBlyaDgoHiGwDtjxqPhuJEu04Z3RZMgdxJFnuQBF 1Fhw0KkbVpKH7w426YDpVDrmTVHMTaJ91LsP1cxFsNmxgdtnh3btwIbCI7ABPEdsZ8NqdcNb vVsm4HUoRmD1F4wUYuERNpyQ+OnrtVWoVzdllkS7mrfrolWjcqEPGpsk0AQSbH5o8wqCR+YK Zjh3jCcxh31eghXI/jI/Y8wzaCaJrJOnTqNUIbQDQzgPeZKHdH8KyqhWvOT11TttLNxdmDwr VuaPRGTbxoxZJAVBN7kwYEdI9TYEcGHIhkahbovY81Z9vW0hGpRiVulMDNwgceZ3xycRHzEd 8+o1TtVCo35GLSzcYJw7qNWPHNzFZxIxJyHUMbnojj4h8R8c/hR/1xzvJTZjERpo1AqZWzQc +7FPIgYTfEYRERzkd/Ksvo1OambbRWPGK7Gke9aaGKwPDrGOYSYxzv2gAHQOu3lWZ/3aVpD6 1ZTuyn5UWTpakU6WrMCp6xy5uyNL/wCb/gNQdWThyXVeUd/eEfyqZeBpHFzUFmq+pwCsPNqr YeMT5UGLNiTGk5hMfPjtWXav3C14+C9K5ox9+2GuMf8Aak/7wUrKFw4puj+0CvchpSnfR72+ S1nzxPlrCSr+mbLcv9wP4VSJ3/eClYWFVR9ChRq3SULV34OrIpXklzNwMQQ0gOBH5f8AWqOW nDFu8cvkW7AqhnBzYT0Dgc+fp86UGu8XmHbbZhmbBsq3X9paSIuB72BAcj44DbrWXzEatDSy rBcUxVREBExDaiiHmA1L3FD3jApllZ1ZYQRUBIq3aecKangHp86jYtrK3VPclsbtki575jHM AZ9RHw6hXsu/sPTNgnaLwdsuyMOeYjcyZnIG7qIZzjrttnyqNmoiHt9MZi24KONKHOmdcpVQ DQXWO5B8RHb5ZEawuDty7ZF5KREadwUY8yhXKJHIlJqIG4etLLWJeba207hck0NTt+0CQHeV QSDxEPTA7Vpa7emiW73RHPJVnFpNCrxbtV8Zy6amcAc+gQyfGOvTHrS7H2qdSQbvo1PBSJg0 ZqKFzy0zBubfqHX/AArzjacZOXbMIs4d0sZ0JckVcLmIUpf7w0lcTB1CSQIOJsr1xjdRq5Mp p6d0RrfmdY+lxvM48KWz+IfZmzdZT2imoRTmbqbF29dOBx18agJBmrcvDv2zdkVFtHLWM5UY +bre8Ux8JRDOwiIjtgeo7ViBTm3IQy4/aIGrcfUPEausfwxuV9FtHRHTNMHSIuGzM646zlL1 28Kil3r6Rpko5bQJuGNx3CyM8KzZimpoOBjpnMYNI423/DoIVf5ZeKc3Uk4IcsgMhDAIpLrF ARwpnA77CHlnavKFvxMjPSyUQw3dKn06FjiBSbh18qmbysCXtdiaScum8i1I47MdVqJh5amO ny261nZ/4DanklGNOMSE2u5aItGNsqouSkUAeWffCQY6juGwD91eZS/DqLsBjCYA8gEautm8 O5a6odaXbuGrJmQ6ZdbnVqVMfGjT5gPnUwnwZuQDAi/k41o8UWUSbtsiJlBJ1H90OgZHzpc/ O8OR7WZUKt1x2DcNu2qxnpLsaoPXgMyIoH1HKcc9fwGrB+pO7SSEE0fOWTH2owWfGE2RFEie NhD7WB6V5pW5R9SsmY0K0n9UM4N1W/DtX5XaE2ioqm6BsYvLAghnUX6vzNjrTW0+Fs1cMxdk em5Il9G+0Ao4FEeWqZIB2A3TI4zjrgQ2rmJkoFCtKkOD8ux4flucZhFZYsYSTWacnSBETfv+ J/3eu/Ss6Zt3DxQiTVBZdVT4E0yCY4/dXNuvkIUKmU7VupSQTjyWvMdqOmZUE+zGAdBR7xvk HnXGdsXO67V2e25RTshxI50tze7EAyOfLaq25GSHoVLfR65Bt0lwhb0j7LUxocil3TZHw8/9 KNLWzckN2Q8xb75ik5XKiQ6xMAIm/kfwrmMhD0KuV0WDMM+IjyzYJm6l3LVIqpxKny9sBkd+ gBnqP4VWJJg8i5BxHybYzR41NocIn6pm8hpthtQqbb2nc7t1GNmcG8XVlGZ3rMCE/aIl6qB+ 7sO/pRris+77eiUpWYgF2bRVcqBFFDBjWboA46bAP4VzCogqFa5B8IvafHOM4f8Ab1UG68WV 84cHKXJcp6h0gA94NWC+AjuI4qnwvD29JySmGMVBgsMQ6Fq6OZwQhCq5HuAYdhNsOweVa7NR U6FWprw7vtzb7ibJbavY2qaqqxhVKAlKkIgoIF6jp0j08qQWsm7kYe35gYQTs7gWSbsFE1im 1qqfAUfsiPr5DUbchXKFXhbhPxFRlmUarbYJqvu08kTOiaMN8c4xh+qUomxqNgM0GfCi/wB3 MPY0sSzTFmVIx3Cr4hEDc39npUHumE3lVbExR6FT7e0LocxVyyDWIOdK2jgnJGzsmbVpx+8O c7B4BmtmR4ExTxu5jY9tI+1ErbbyiUsqrpbLOVMe60/VAdRfHIYHIdK7Th61U89YoVfoexTQ j7tfExouwiyLuWZG6WrnPHSRMlTKAAJ9JjCHexgemQq3yXD2w4rioxto8RLyKz+LbOjxhXQA aOVPkVirDn4ky97GRzTl6s8mJUKsXEiEa23xGuS3WAnMzjZFRs3E/wAWgvQB8/n41NNbOjj8 L7TmXixheXZcIMUdPRm3TOUph/eMYR8dsVEYZKUXTQ016Uu/gGxWhbiTti3/AGJIx8mVCLXc ujiV8gGoDa9YYAR0ZAQql2FwtUbMn0nd0OEu+CGSko630znIooBl+UY58BnuaTGwXVtV7PXR EZsgxQxXo5HhpwtYcabh4fniZGUVSX551VR5aEWy7GVXXrAe+IHMUvewABimcLwns9bgp7cJ EEOc1oO5dOTOuYHnbElMFKCIbAkAY72BzTbo7k8+aaFb+14b2DCl4QsLmj0De30QfycipI4I YOXq5Jih0L3kgA4GDoaoWVs+KZca7BYXBY0bH29NSHIQJFvRVK8KdQqZTGP4aTCXUADnAiGa uvD1pDV3JjWmi16K4QcIYe4uOd2+1W5jWnCT7mMbx5AMIqn7+gpjFwJCEIXVqzuOkKl+BXCK 2JGyrEcyloM3Zpf2mEyu6N71M5FRTRKQBEOgAPQPCsoQjUyeXqLWgjb0Mb9Hhe40WXZ5aEug Yoy4GEe1JHLq74dAx6B4Vn5qiSxaFChUAUWjUWgFChQoBQoUKAUKFCgFChQoBQoVypHaFCuU BaT+tSlJUCxaXpAtK0BqtnC//vkz67ah/KqnVy4SlzeCXomI1MvSLLxecFI8aJac9ys5WOXV 0q78XN55MvkkFURT4grz8H+muZCeLpcVHF+Kpq5i6TF+VQteqPpQvrNx/U5VvImPvqnvv2w9 7I+NTGvlxaJQNsfeoV58VZwDejUWjVoDp1Y7BXSbXUyVVHCesNXh41XE6WboLO3CbduQTKKG ApC+tKKeqk0olwzkkXkdHotFn5TB2hYBBYu+T+mw0e02dvNZrXBow6QgyMVkoXSU4ABwyIj4 eNYDNcO7kiYdSTeO2roG5SiqgkuY50wH+fCq5CsFpiUQYMcguuIFII6gDqHXyr6U7tfNWcXq q1yRbZ1dHYzxiLhzJKKLrayZFMyfXV8/WmMW9gvoayRkXceVkSNO3XUE4cwxtWxMeIDnpjfN YM14ezLm/HtnpKodsZbqH1m0GDGrr08S/jT9vwmuQ8SZ+o6j0ze8EjbWInUBMO8PpVxl3+HG x3hOto8rI1sM4sq4qJA2UUVIUpSY8ALuXr1HpvRoMlnx0wmu5bwLW43LVwZz2QyejUbxyI7d furzhbMC8uF83Ys0DI9oENKzhMwJhkeuae3ha6VtzBoUJRKYfJn5aqbZA2SCH8fD03rPKkuu juL0JaKtkDKTTt2vFoqnIUqyCjkpi40jq6Y1G6bZosHOQjWPi9DuI7LHlWIquZcAUTLnJeWG Q/ketYRbtgSk9FyjxuUElYxEyotjpG5qmkMiAB/PWpG3eFj+TiWck9kmkao7Ny0GooiY+rAD 3vs+WfWtbc/+LhpwxlGUbxMTknBwTaC7MYhzbBpE/jXot5dlrAV0jKSVvpondiqCaBin5ieB yJgD6w5D8cV5aThnytzK277sHibgW58/BkBwI/KrheHCR5bkS+ftpEsuMesVBymk0Eu4+JPt B8qzsXMJycm2ONu22S9o9mz0SiCyaKjZI6hQKgQojku/1vHx6+FOvp5ay7jtEdNQ4tWj5Qx1 HRtKmkcd5POBMI4H57b1g1g8Nnl1N1n7xb2MzSJzCmUbCZRUc4wUviGdqsf6jHSBlyy1wJom B4m0aFQac4TCYAEBPj4A9egZqoy1cxTNwTsIlwtaOWz6LerpXR7WTYisXXy99hL1Aem+nO/x Vf33FCzJh5a1yKuWLKRVbOiuWx1xPyOaAABTeQbB5VkUxwV9nMZPRd0e7l4xJRRykkiHKTAv gY/XV0HGNs00R4ROVn1nNgnmZk7haqullyJZBICY+H7Qj66am751qN/ieJ1mJxrKEWuuOZyR CalF0TCDdMoKB3CnDAZEC9ACoe2+INhto+6mv0oZtEV379bSAY7YVZPBRD7Q5x138xGsgU4O N/pdbUU2uYPZk8RVRFw4agCvcMAY0f5iHWmti8Kfb0lefb5UWUbaplkzuCNwOZUxBwAeXgI7 VnjiYr/PcQbS/Uj7CLMpLB9HU40kWmQdfagHZQemChgPT92sy/R1kjQnE6Mc9m7Qr2Y6OwgA lExcagH0pSe4YPWfDGAveGMvLtXxDi9NygLyAL0MH1hAQz4eHWqVDtH0nIItIlNVd2rumVIc G6dfT51EvRR2L19c16W1avsaHnH4IvVIAyf9LERENK2QTVEneDoHoON6ptm8YLSj5G51pKYH D24GzpHs7c4FVRTQKmcSh4BkPEQzt0rIuHvDWfu2/IeDmE3cYlK80/bnAaz8tL4hDPXyAR2E aQW4fzUnc1wM7Mj3EjFxDgW5nLsSoCBg6lHVjfYengGa1+ODmLYLs4wWo64biwhnjNJ4aONG mQUaHMqcDK58e4BNIjnOvceg1m/6Qd4t7qvdl7AnlXsEkg11F3KmRdPBRNgfHAf6VmyhRTcG RVLhYqnKMTxA+caasyfDu9jz0hAtreVVfR5UjOUiqFyTmhkgfMc9OvpTerhhQw66tcuDiTZL /iVdrlGbXSjrgt5GNCRKgYOUongBDHxbgGfLzCsoNaMxd8tLHtNc0/HoCVD2k/WK3UXHQG+D 7464+VNrwsK87Oaou7rt5aKQcrCgic5gHWcMbbfx8fCmLO3pl/bas+yZqrMUH6UecxTCHvlO hQDx8K7WdfRUpF6MtHjTYdscOY60ptk5+lcPFHjDLJtinTIcCiUCc0O9gdX1fKsd483azvOQ hUYCSXWYNYRqyckUAxCdoS2EwAPX50i+4Q8Qo9i8duodmiiwIc7jL0mooEDJu71EQ8qbvrPE 3DSyZ1D3by4ZQzQ5zqFBEO8UC/3evXG2B3GmFfhQXmR4owCPH+0r7jTunkXDRaTB0PKEp8gm ZMwlKPUO9nbGakOHvEyxbUa3BCN3Eh7PcToS7F45Zc5TVoAqhQLnYeuk4j6jVa4k8JJJhxvd 2DaHKeEBgV8QyyunlJgUNYqD4eP4hUS04Q3+6mHEYRrF6kSoHKoZ6AJKlWH3ZiH6DkdseA+F dpSUq9KDS0uIcfD/AKPziVMj2uYnJeSTRbdpAp26LvIGUOQAH7h0j865cnGO0Jq27IgIFo4Z u4adjZICOUdLdIyAaBS1eBd86gxisja8Nrzcw91zSUa1EbXcKtpJPne8Lyg94IfaAv8AIVIm 4RX/APR9GZIzjjJKpsTi37T75PthykQKcBAO8ImDuhuGQyFTOmo3O7eJ9t2aETHHUQdg6TlU 3RWC3aeQk6OUxVBxsc2oOhg3AR3qkQ/GW3Urwk3soeZWiVk2pEv6CmPNBIB1gKO2gB1d0QHb HSqW+4JXvGTTOM/qce0nVSUcEWHloHSANQH2yHoPQaYMeGlyveJCNjMjx714s0M8I4br5RMk BdQDnwz6+IhXollSmWiYu/rGnGbG9YeA5bOFup6ZwZutkx2xRN4D9oxcFNnYfKtKT4528MPy XLacOq5hkYdyyIkAt00ygUDqEyPxCUoenpRuEnCODkLHth/clsdukZiSctn6qzkURYFTOKZQ KXIahyAGx6DvVFnOEM/bbh5LT7tNK0mR0VlHzcQUMdBRbQBCdCnVx9UBHGQzWXdi0WWb4yW3 c9zQU7cUC9FaBeODsNBNYEbHAvIKbcNRyGLnoHTqNVx1dHDVbiEpcq0ddC2rluQdGMHPF4U2 oxxKAgGkdg6+HSrHcnDi37nh7X+hEMjbUpMrulmwLKHEF4tEue0qAbIkEfABxnfAjWT3hA/R yYTYEmo+aSVQBdN4wNqSMUR6fOlyfxSUv6e+ld9zd0dm7N7VeGcFQzkUy4DBRHxHapJjepiW DB2uozSVVt+YLJxa+oQ21ajpn+YhsNPOHsDGOuGvEm8ZNEXRrfZN27Nv0LzXRhICo+pNhx41 scDwgtU9mwSX0ej/AOn2L7UNLnUNzyPzJgcBwH1C+hR9azsUpX/t2XRB/r5t5KQeSBLVlHKk hJJSiqazkEipLJCJkgASBqMUpzAONs6cD1qqynFhhcV0Mp+5Yt924kaVq5cMHIpnUcFU1FWK HQC4EC6N/HzqWsLg0SKvmDHiVJRZrfdyCrZBE6wk9pkKgJirEEOiXM0B3hLnUFT0lZ9uxNy2 omtw2j3Vzz8IAEiU8CwTWBfCqxzZHl4T3z3yhgQDzq6UpDrV5+nshluNtryri6l7jstwqNyv 03DorV4JBWbJolTRbKnDBhKUQA46NOelQxeLrdCxRhELfUSl/o6e2u2mXEUQYmOI/D9vcAyO cb+dbBYHDvhPNzNwPomLiXsWtdvs5EzxLCRUitCiYjfA75UzpHbbAhWT/RC24b9GWbuJzDsn sq+unsRRWVEHEemU+ATDrk+wiJfED58KmNKaat1Ru68oe5foQieFBRG14ska4TVUz2xMmMDt 8PUfvGptxxJhvblhLM7SWQgLIUVXYsReZVVVUUBXUJ8dCnKT54HNWP8ASKiob2EvOWRFWYtZ LOQaplXitnmoSAIpKjvgB3Hz3LkNqfSHC+EuH9IKNhGSPs63Wdstpp83QKJxVKAFExALuJjH EShgN8ZxVbdKRXHuoqUHxneW1xgkr7jGy6MXJOVnbmC7XpKosoTGow43EDDq9cVI2jxzNb7C GS+jPbFoRR4pEq9sMUodqETG5oY74gJvT860yWsi3Im5eIkqzhrbSOhcjBqkSQSAUEkezJKn KmGBwc5jdPUMVg3HGJaxPG+7oSHaclm1clOkikTupFMmQw48gyNRSVceiPdFOLnW/Vy1shu2 K3ZFfGkZBXOTPXPQpv3ClLtpDqIZGqwU5FfgOA1Z+GMe1meKVpQ8imC7J7NNknCQ9FExUDJR 9Br0rxM4aw1yW1KMSqwEXJhdZ20WsxbAngBIYUmh9IYAxhwGR23DrWWmdVVli8i6aLivRfCb gqlG8TkFZycTVXtoIv2vGGbFVDtb0ccjVkCiUoCA6gE3oFPLOsCHZvuKF0PhTEz36RNIiN5A GTTIh/a/uiGdIBp22xU4OvMpVEzY0n69K6buF1G6BXqRzbsSPBBnFNGcYCy9gR75NmVACuBc rL4M752NwDX3i7j0+Go6P4Z2fwbvWCuy6J9V9GRskpHvEXTUDc4x2hhIsmQmodIKbd7Hw5qt nKmrmrzVzUzf6gIUUyyQGEgm3DYdhr0zaNsGuL9IHh27uuVjLhhpVk8fRnZWPZ01BS1mwYgA GMCAGyPXABTzhiujKwlzXKwXgmstM34nEt3BY/LdymCPdTKURymU+RHqG+KnCK3l7um7vj/0 /wAwrnkP2gyHyr05aHDZpCcFOIss/STdXPIMXx3IAUCpsOSqYopgA75NufOMbBWXFRbv/wBE RtKuWyIPIq7Aj2axS4MKR0uYYB+0OTdfIADwpWzp5GaUWjGotYgUKFCpAoVyu0AoVyhQCkqP SRaBYtK0kWlaA1Xrg2X/ALVD/wD44/xqi1oHBcP+0i//APj4/Os7npF1vq0Jdy3VuY8Q6GJT ACnchgShisucJsPq/a/KtO4kcRrtNDr2em/SQi8gJ9CfvlA+yJvs7dKyRwXTjVWHD+hvKIl0 B7tLzDaq9VhntR2aannVdr0x9LA97YqZMCeAdKIoOv4qImQ2nNKuG50cai4yGaoI0ak6UoDl qUgVyN5hksc2AIuUwj99RJaVKkdUwEJ1MIFD50Hq5O4YEE3Tg0hBtWrpAA1isAqKdNhDUPr4 U3i5yzQuRuLKXhW6JSqpk3KHfMX9p6BnG+1Y7+qSQIzTU9ptVnpmIvgapoiPcDO2rz26etUy Phn75wVv7KcJ6lSpn1tx7ph8Br6FZ1wPk9Qw9wW42uaf03JEJunPJOZyC5QA2gAAwas758qZ RN02q2Zrcy4IzsaLpxziCcBOoQwDjR4iHy/OsWdcLpJG/I+0iGIsLhoDoVyNsgmXOB2+4evn U2z4LOjrSZV5lAgtnnZW5E2+vX3c5N00h6/nWkZS1Qv11XpC/RFkS35OISNyEiInOplREdXg ToHQO8Pn0p1C3TZ8U8ZOZieh5CfMcRF83wAAAl+sPhvvWBsbOnXL7k+yFkkecKXaxRHQOBxq DzD8qlr+sZpbUp7GYO301JiJSiQjHSTfHQQzmohlT+jraoe87VLdDlw4nodoVNgq3IdNTOoR HbcdzD/n0o/6xLTW5vYZ6NboovgUPz08GULoADCT1HG3TrnNedvolcntD2b9GXnaMCOjlbF0 9cj0DFWnhzwqm7slHaL8gQ6DIo8xVUoGHVjugXw/Ou7ssjREmmGRuLT64iZBktKC4IJ+ujUG 416CdcUrP/piq10tRScrpqppNkhE5AzkdXTy8RHrXl5u0O4lPZxOvaBQATdOuM1q0twTK2i3 3seRfSEgxQKqcDNylRUEQARAo/yO1ZRjlOpJemPE+zDyXa0Z1KPFRookQvIHQiAmAcB6mpcv FSyV+1Joz6bMpHyavNWRNlYATADGLsPUfv8AIQrJOG/C5/cbw/t8jqHaJkUECkTA6yhyAA4K UfD18atJuB8e2Ku5cysk5T1okTaopF5qfM+3t9XA1vHOqOh3f07w+lbbmiQl79jVlnBnbxMj Q/NdG+qkIiGAT8R2HIjTKSuq2CWrYTRheHIkYREUllEWxh5esS5ENsbY6Y3zURc3ChjCW3es gjNrO3kE4RIg3BAuDFU04yPUR73QAHpT1Hgcf6D2/LSkyZvIzEi1TVbJp5Fs3VHx/f26bAGQ yNZSu5CduLiHakrxGsN8e5BWaW4CyrmQ7IJAUUMJBAClxtnSPTGM1HQ/EK3Ir9aCSM+5M3uM 660cQiJg1Kq/W9PLfO3hXb24FOUYtVzZzKTVXSkeych6YoAolpzztXQChp602s/gyKlvvpO6 270XaDlFJs1YKbKEU/tNWN8YHp5V30dRMWjxTs23uBrSAWevHM6jGOWhWZETcvWsTTuboAB5 1jfC980t+8IWUlHLpu0YqlUWM2DKg4xsHn0/1rfZL9HG1o1F4HtSWcGBBZz2nJQTa6EwMRP9 8xv8K81QrZ/LrMmLBHmvXhypJE8zCPj5B6+FZXXYvQqfGm1FuLFu3oc8mybMUHaDlqRLJdBx yTHmYfEOgYDvVWeFfEW2INxcf0keyKrJ/LmkG6ZWvNFQPXcBAwhtnPgFd4gcFpSOkLMgLdQ1 TUhGOXEsVwuAJpmQMGsQP0AA1flWa3dbkrasigwmCogdy2B23OkfWRREehgH7q13OnhGiY+h kxcKz26YUYaPjV3p3TVF5IlIsmXVqKAgO+fXxGtTg+PdvsnDGcCFep3K7WQC4nqfwLoo9ATD qJjbd3YAxsNZRE8Mbtm2sA/jYpNwlOnOVocTeBOpj/YL+8bAetK3twzuy0rZ9uyq0SRI5SmR TTcgZRQpjadQB4hmku5TSOIvE5bjXahLO5LWKkUJr2i3cPV+W3BoUogUpzmz70RP06YDrSvB 6/4nglFyNtXWyb3KMi5LIIHilSLppjpAhgMI7AON/wAqhP1YxTjirw0ttzobxs3DovnQqqiP PMYR6Y6CbBQANvHpUMnwimZe/r2jbcOzQiIGXFpz1R2LqPoSTDHU3QPTxqdLcv5qSnGzijCX 7aYx8azkGT48+eUwp+zBISaADP2sY2xt5jVXnbninnAu27EbIOvasXJqPllTlAG5imzkAHxH cPDwGpOB4LXrMN5RZsvGm9nv1mAl1m94qkQFBABx00j8XT1qNLwru4/Dy3LxJ2fs88+QYt0z 5IIGVNpII5+qIh18hqtUr+bjTbn60Ppunbz9NzIwZ4qZUAcn1CUhQOkUREogXll2HrU3YnFK 3TTF+Xe/N3SxbZCIjpBbSs9UQyoUO70DWBe6HXPSqN+oO8TyANW8rGqgD9dksqBT4IZAupQQ DTkQ8h2ztRS8B7qNLLEcyjNKNQYovAfcgxtXNMIEAC+ew7eHjirjSUU9Fiiv0gG/6uJqEmLZ VGWmk35VVmZgSRDtmROcxMYOYoiG5gEcBjVvVmR4s29bvCpBwjKMJOfM1hSJs23MIoZZocom BQA2IUAIHQcd7GKxeJ4Z3RMN73WjTorI2kB+cuTcFhKAjkoeWkpjfhW6xXBy0ZCz2SfsCMbq L2MWSLJHOPaAfmKU3MHx0hq37tKaU6VPSod08b2Etd0TMEiJdJm1WduFyGdACgHcBty8BpAC YDwybfI1Vrm4sSa3ElC9rU/qZw1jgjUeYBTHUS3yKnmYc9fDAeVOzcOVOHrxlJ30glNkcv1W kVFJgI+0wAgaF9u9ytYh5COQxWpocO7AKrccijbdvBcEPFRKD1g6XN7ORkHB/fEyHQR7pQHU OBHpWkqypDGqejMbD4ttoG2YOPlYR1KPLferP41wRzoKc6oiOFfPviA6g3xkPGnFx8ZW8/aw WvJWizPCkFBVJr0Km4IqKiqwfW1K6zBuYeo7b1n3EKNPD8QrgijsEo0Wz4xexJG1EQDGQKUd shvVujbbiv1P2K9cIAo7uy7CoOV9PeSbpqATll/j/GsdyUujf4p+U43wLm+Gt1xVmKpSJSHR dGVfauY2MnywQIGNJClKOwFAN8j41lt5yMI/lE1oCBJb8WkiCKTMFBOIj11nOO5jDnrXpe7+ FNtz0Tc8S2JbFvOm06i3inLNPKhM90jdTp31Bx95wqpcOeF6FrPJWOuQ0HIXp2Fgo2YvlCig 0MqthdMR2TMpysCGBHrkAGtK016PPGVIsism9ht2DueB7MhIRdzMyt3aJzYFNQv7FYo+ZRN8 PjV5jeOx29sw8V7BIq+jYVOEK57VlFRqBSgIiljGoSbZ3xWj+zLDgOKd8RLyw4z6MxDgXszI rpB7sqrUBRbIB9oxzbFLpHxpq+tC1f1BAk2i4o6v0CLLEb9m0PDLCfIuuZv3C53Lk2QxWNrS laNGa3ZxpWuXkJXDbsc8aN5XtzRBVQfct+WCfYgxjBMYHUXTS7HjOxSnG75GzEAYs4kYZgyI 9PlFAxgMcdYhkTGzuPlV/kW/DWx7u4MspVrBqQRLdO9fP+xiftJ1Eu4qYNIiIGUwJc7hnfYK giRn/wDP3DpzPBAXBC3AQwMFGLQG6IlFQe/y8fFnz8BAPCtIXOjsYoq0+Og2yEilD2FEIRzq QLJsWabk5E2iwJFT3+0HdA2AxVBeX523hh9ATs2+DzXttWRAw61XJg0j3cYDuiAVuf6NHDaF l71vS5H7Nq/I2m30SzZq4EqBdJjc3HnjBA8sjirFwiteB/V9Zce4bRAovrbXUctjNymVdHOV UTKatHhtgdYVnnSPamfY8+XBf6cla5LaZ2hDwscs+SfSaTQxv6comAAAD9go4HIF8RpS+uKD 247uiLtJFpQrqOTSQMm0XPh0kmYolTP46cBjHqNUCNRcngyvxSU7OCnI52kdOvHw588eFa/+ itEoSt2XgsoRAXTG1nKjBVYoGBusYSlBQAEBDIZ64Gm7KtWuhu444SUtMTklJWxFSLOZeN3p 2CqigJoLoJkTKJfHvEL3g8cjUGnxFfmd31Jv2ibmavFsDY7j6jZLIaygXx6EAo+Gmt54mcF4 6/5S2ncPJdllCRbBSS5SOgizUxz8xwAaQAynd+DIfIKq1i2bAQ/Aq9LhZu3b9a5oR6uyK4RA OzIN1xRJn6wnNrKPw42q7csqdPCI9zz/AAb9aBlIybYKcpzHOUlmyg9AOUQxmtR/X9dZyrli 4WDiBcOFXqiiSJhV7SqTQK5BPnScCiboH1hrRXnD2GtXhpY1n7SiqfEaJLJqrJlAhxXblUMQ uBzy9KhQ3xmpniNYMbxFmLZju2j2duvOOHK5SEbLYROmCaQd34cn+LHw43HrWcelHZMfg+P1 8w8gV12GLklDM2rRUq6KhzKi1H3Sqihe+ZTvDkTGwOdqbQ/G+6o9nNRvsuIdJSizpwoVZI+t v2nHPKXGAAB1eXjvWjW2ja/DCTnbNi7neMJG7m8UowekaleCwOJzAZI5g7g9Q3zgc1HxCH0K 4dceXbuSI6uNGQTjXDgzQpictQRKUSbfXE5shju6SjittaQ6VRGuvhmi3Fi6nNjtLbIRqi0R at2QSREDA4O2QNrSSE/TSA+FOZzi9dMrIR0s5joMqzd32odDYwldLiXTlTPoYcAXHWtfve2T ynB2FtuIl0Y1ilasS4etDNS8v3ioa1wUH6+45DI+A7VX/wBLeJibb4ScNG9r9kSj2Dx0DU7d bm83cuFtWO8JhLqN5COKiVa0a/Rnn62rubX1GXUm0im7yDbKtI5kCAkbtSqZ1jp6iY2o24j4 1H2TxNuezmbtnD9gURcPhkSFcogfszoSiTmpfZHSIhU7+k+i2JxBhHaSKCDyRtdm8lE0AApe 1m1Abuh8OwBtWV1jOu3LRWKz2/fFwwLG6GTBwQ6d0kFKVOuXWc4DqyJfIR1m39ajpC4JR9bU RbSy/wDVEPrFo3KGA1nNqMofHxG36j06BUTQrLcBaJR8VzTWYLQoUKAUKFCpHKFdrlAKQLS9 IFoFy0pSRaUoD1o3BEv9dPT+SRf41nNaXwNJ/WEj/cJ/Eawv/pVVE2vRY3t5wqIZAhsfhUK+ cPJTGtEEylDAVJ3I5SVmlu7sVQf41L8tnyQMUpcCWsYyxhRUmfPl0VoVMhR94XqFQNKo5NnT 5USvbFmmYvQMasT63+FFnDc1QuOhSgH5UlDhnPXH1/lUjLMwRZ93f1qfkK/RqFCqHS06anBJ RM49CnAR/Gm5aPig9OQvES2CRca4UuOObppMOQdMCAKwm73TbPiHiHypBPiRZnbmZ0plNMrV ZPOUxyqPiobyEKocLwdbLwsW7cSbkZCTTMoQiSBeWljwMI+dUr6HXQR0ogeAce7OVM5gDbAj jIefyr291IRqfJvid+2OjdRT/SpESnjjtzvNA7DryAdPypu14hWQi+mdFyAkgs/Tc5BE2XBS l7xQ881m85wokGc9bUGzBZdeTRMo87oADcSD3vwAfHHSp4vBeO9uSzY8q7cFaikVBNIpQHBg DcR8i/zit9Z5ff7IWSW4qWq4t04RsqlHqmIokRLswnWT1D8RNtJdh9fCmEDxBtCCh26Lm415 16oqkpzFUBy1x4av52rPVOF91e2HyLJhzI1s8FsV4c4AKgB9YA8af35YDOCZsW8LHy8k+XSK Y6+3KIYw4wOOn+lKyn1o6v8AKcVLTdyCzEJ7lNVm66faW7QxCp6w6+ImNnI5qH4b8VI215xe PdygvoAxQMZ85bGFwooAbaSh0DcQ3GqQjwrvX28ziHkUBeaoBFjpLAYEeg94ehRx51ay8F0n HE5aJSk1UbfatU113IABjGMJg2L4D+P4V2m5X4o6MwcPG30wdyiP+ynkTOE+7ju6s9K9A/rs s/suXcpJLio3BLsiLc2hMduoj16V5/uKNLH3hJwqIjymr8WyZj7jpzsI+Y1syfBWIWi0OyNp Ey6kULv2ic+EhW+yHgAbfl0rOOW9VXxSCfGa0VphJ+p7RZiVNVuU5EM8lI4eHmbf5UDcZbQW RUju2S8ciQiBSPSNgFZcUxznHhn5/dVK4e8IZN5OJp3mTs7LUYhE26vfcmAmch5E9auv6krd LzngR7twuDQDEjgcByyqCbG6njjr/hWsayyyZ9EM+4m2dIs72FZWRScXAZLs6ZG2rAJFKBBN nx7u4b04jeOaCvD1lE3ICzqaav2yxDINgBMqSONhHz3H5eA0WW4R2qzUuxMish2xrEdtapZ9 2l3emd9Q5Dpv/dphdHC5mzsG3fo9by76UkY1JdV8LnvJqmNuAk8CgAhvp8B2rO7D2r9VZLs1 /SFtNh2tFBGYeJyC5lFnDhsX+jlEohpIX63xeOOm41CJ8bLcP25g4PPJNFhSOk8KgQVhEg9C p/CQu/8ApVJY8HJxxd0bbppyMMuqqBH5W58qNihubr46fu6VfXHBKKW42MmTBEyNntI5Jw8O 7UMAqGE+NOfrGHAbAIee1c6h5KfpGwD3L4YGSB2zTWRjW3VMwHT0AZU3h4bFD76892DJ/Ri5 oeY0AqMe4KsJAwGrBs7VrEXYFqHlOMTY7ZUXVug6PF98QImRMO6PXc2wefTpWHNzCdukc3US AI/hXnu4ydi9G3Jx7tWRuJlItoOW5JWLxk514AdLrGvSHjjAfhVDvJ4w4p3IzWYyTK14mEik opkWUU94omQREOm2d8bVmNWyx+H03e0LOSMMRNQ0Vyw5Ihk6hjD9X0D0z8qdDFsPDnj4z4YW gWxSxH0j9nmOVF+3W0IqAO4CG24ZrLeM15teIJbb7MwWZGiI4zNwZT+0ExtWS9dtxq0SnAl/ CQa0rN3fGx6SBUgOQyewKqEExE89N8Y++q0FutP/AIbPpUbkdr+kxGqzkAEVCk0j3Q/d8eg5 zV17fLqRuTiYg9uzh3cEbEqImstkg10LiA9p5QgPh0Dr6+NWmF47RsZcl0SLO1XbFlcS5Hap GrrC4OCm1a9XhkR38/IKU4jcI42U4q2RZdkvU2oP7cK7dLmJ3TFKA+/3Hc5sD3dsDjwqUsDg /GRV7T1sT6/tRq+s5aSauzoaVmZwUKnkEwz3u9kN/DpXIVjTw5JGwnFxnAcGriNE9jTu2YuV eQbNFAFRRikumVIyhTiHxgUBDUP2/GmEzxy9s2PA2ovAC0VjjsBPKFX1G1NTF0qFJ0DYBHTv vmmsXwBnVvp0keXHmWrkE1eSHLdiCJVcZ8Mh88Z3qvzXD+Kt6yLenJW7v68lI1tMpRPZvdKN 1DhgBUDxHxDwzXa6eXWu3Zx5gYZONNbXIm3ntNZ+5M1bdlTImsTSfOoO8sYRE+cbZxmqO144 ERvpe5D2wush2FFk3bjJKc4hUjaiidXqffqA7DTv9LPh6wtK4l7lZnSZIy7tFGNikSAAcoES istt8IAccYHG5ttqpfBvh+jf8lJovJhaNQjkAU0NkSqLrCI/VA2A0l8fur0UvS8QY4UQ0peU 88mLmfs3akYlc6gmftkDbGT/AOHnxDf760Vjx6dNbfZMBtNs4dt4ckGqss4EyCzQMagFHpqM AYyOcb+dMrHsho2muMUCdczha34FwZqdygIG7gAInxtpNt+ecUpD8DyS/DKHn4q5XgyUhD+0 QQWRKCRAIqRNUudzdThgcDnyqKVpTzVsOnx5mFrhZTU3bcdKrx75V0w5hgAzUhyaAQIOnAFJ 1AQABpojxjbNnkiCPD+I9hySCJH0YdYwi5WSVFUi6i3xnNqEcgYRzXOK/CGOs2ylp9pcMjJK NbjShlUlmxUiiPL1nMGMmHfYPxxV3vDhGxvP9I3iC2ROvGREG2YH7OwIUBOZVBMdtXdAod8R D0wAVWUtcGWEPLBbwnnl0XZKXPJaQeya/OVKT4SbAAFL6AAVJRt4STSy29sckqjZlJkk2Cph HLVYo57ofvedI8SrbJZ/EKZtdF0L1GPVKCTgcCKhTEA2+Ns96rGyjWY/osyUwYoAsW9UUVjg XJtAJBsA+Xe6edef0yaRWNP9ICcbOlnkba8OxcvF+1PlCmMfnr6dIG72dABkx8Fx3hzmq9+t SQeyjJ/cVvRlyqNI0kd/TxOcyxSH1lUOb4jGyIhuI5zWlvP0ZItacYsIm65JNMJQrR8LlIph 0C17Rkgl6Dp7ve0770ThvwltEl6W1fCEhLDAJs20mmyX0isZwd0CJCmHYugBwI4znwr0VrOS IxU1nxvmkwlvbFo2/PLSsh7RXGQA4gVXlgmUuAx3SFDBfEPOopxxauJxZP0VMwjQMMcESeWA B7ULADZBv5adxDetRi+DVt3xd1/T81IumBvpq8i0SJKESTSKUgHA+BDvDkxQ07BWaQvDiIdc HpG7nVwprvWlxIMgbfCXlcwA0GLjInNkDAHgHnWVJ9MzL2RUnxIkJa4LVnDwDBIbYYEjWaQo qC3cIELgpTib0Eeg+OQqR/W1OEvqEupG3ofmQTczeJi00Ti3bgce8cADvCbIjvnxr01fVr2z cUdfMJPSqy7UZCOSQQatgAYs5lATTBLYurVkNQAIgAbAFZXB2jB8Gp40O9mFELllLdMVOYFH mokWFxjSngg6dRAKXIgbBh3rSNaTk5kyi2eJczA8UH1/xMI3GUX5oqMxbqi3QOqAazgBcCBt x6+Y1IxPGO6o22W8O1aQ4qtWqjRlKnSEXbdBTqUg/DnvGABENs1ubWRCK/TCnoBuZRhEvV2p l02zIBI7cGaEECKK492XBhNgOo4zXlG7CGaXJcaJSlKKEk5KBUw7gCBx2L6VytKUpmv1JJ/c yyvDSEsYrDksI5+o6OuUBOLtycNvDu6S7YDcaUsu5JyyZZ06ZM9Pb2Z2bxrINjcl03NsYhgE NwrbrKiWCd9/o9xyTNMY5aEUkD4AMKOxIdQxhEOpimAN+oVdZCy4Hilw4Rh3MrIST/2k77A/ OgKZU1yogb3g+80JfveI6Q8q5GtJ9arw6asIdcY+I0k6RO10F7I4RdESYNlBKnyA92mIhk3K 3N3MhnI0RDjXxDWsuVgyItHUQ+55Xa4RI+7KsJjqAGC6Q3OYQ22zWy8PIm2LJu15w9ipSRiF 0rsjTHfGZqf1kUqJDdnObfSU6mcbgA52yFM5aTnYaJvw7+NH2MK8xDW3AsmWBe8xxlV4cAKI ctHAd8SiG+M9NVW6x00Y1rRkk1xd4kyNnw6EhqRjY1wg7YyIslCmFZPZIwqj1HqHrSv61eKL +4ot+1bH5pmzkzdg1ix7M5SWNlwoZPT39Q7ibwxWzcdE4k/Da94tdR3yGK9vJOU9ICi0THlA PY/MRL1ARpLibfxLY/SdkY4rSfcM2VqDHoN4xuBztDK8s4rJB4FKQA69BDpUyrrPGjRjbXiN xSbXpKSBIpRWYkkkgctlIkTFImn3SaS47oFyNQZZ2/3sDdcJ7PkXTSVe9quA4sTCpzw73eHH dAOuK9BwdutrSt+8HLu45d6lIjCPQeOdQvSFEMkROYvxDkoBgB3AcYGtFmpu3VeMKMAgZ6wW h0HyjhsDQwM5AVWyZxMKhR09wAEB1BnOwVrX6/Vzq8ZynEW7pWzU7QeSpFIgEEm5tKRQWVQS ERSSOp8RiFER2+VRry6pp5bMFbTlZFSIgFBVjUOUHcMYwmMJh6myIjV94jWfaVqWCzj4y136 8l7GZyJ7l1jyeYsOTpGAMkDbGMGHp99ZzIQUowtuFuF235cfN83sKmoBFQEjaTjp6lDPiOw+ Feaeq/S68VuK8LicPFSPpyXclFVUSEFQ/LKHhj4SFDGA8KjnzF4weKMX7VZm7T/aILF0nJ8w ra/0Z0GKnDriv21V23KPspMVmhQFcpTKHyBciHUQDIZDbrWq3Tw8su9rgLMyUau4WiSNU9QK jqkcNNZW4CAj3gx3hyHXrVxtRuW8lY9uTyG1jXzuPeyCDZVRmw09pWKHcS1dNQ+HQaL7NkfZ rWSJHuVWbtx2ZsqRPIKK/ZDzHrt6V6MUtJjA/ogXA1jGB+1TEZDSD96GR5iyr7BkgAA0gCZS 47oj1HIBWku7cjLdlOHlvW/HEjYuLu5cqfN1KZKRsYTHETdDGHVvsADWdq3CVdB4wnIKZgVk m89FO4xVUBFMjkmgT4HA4+Q0rB2zcM+m4WgYd1IpNRKVydIO6mJgyACPmIAO3pXqZe1ravGL tJ1MNXAM4uDm5BtGvza1lFRdEAvN+uYP7pREcdahI1vBMbuneF0Vacl7DkpRgZ4/jlzIlaKc sO8IDuUm+cZDoIb13Z18GMnm9rb866NJg2iHa3srPbtBBHk465/A34DXVLcn0rdTuJxDO0Yh QoGK6OXu4Hp+OB+eK2VYkba/6OnEpjFpuhVJd4Rijvm7rlKPdE23w4zt4iNXTi7b9uzMVIup p/JRMVDR0Gk4XQNzE3aRjBrIUmQARKAB0MIgIdKuNmFY1qRjJ5dcxUihGR0mqzWIzkziVkoY ogCwgOB0+e9JyjB1GvlWT1EyDhEcHTOGBLt4hXoP9LFzHyPC7ha8tQ+WPanhIwECiA8sDkBP GwDnuB4daz79Jpw1ccVEeyrJLC3hGaLk6YgIc4Cd4B3HvemdulZbUcNVfFmVChQrypFNSZaU NRE6BWj0mWj0B61LgeX/AHof0J/jWW1q3BX/AHXKH9Q/IK83Efp1UpM45/rJcxf+Kb+NSsG5 O6biT6wB3arkljtSptWcnMO3zGpG033ZphDWHd1AA0x7HfkrUX/af3BptTiN2UHu57o9PlTc 1elCatnWcyiZMbhTmSUP2PknD4Ns+NN7TR5rg2BwJS5pecH3g+tR8hB1yu0KsGpUo0lR6D0B Z/F23GVqxbN5JvGijAmgWyCRjCp45zsHhRJDi7a7oqSZCSSSSRiqk7m5jgbOTem9Q1g8LIeU strMu20hJO3bgpB5R9JECac526/6dar89wuuljNPUGrdFRkgc3LWFT6oDsA+RvSvfHLa6EvL RXXF6zPpEykEVJAyZCrAuIoDsCoBkC+f5U2W4r2WaQeaBlk2i6RCgpyMqHEg/wAB9RqvXFwl WRi7cbMExGXduSFfhzgEEyjuOR6Bjbw++rIbhLaTe5km+FnWI7WCfPwkZQDYyY3h+P3Vtjdk hx5xtiHbN7ySSEasocwoEQRA5sCXG5h2L55D8ag7Z4l2zbcGLdijLvnzgCg4BzummGeoCO49 A/jTaW4Py7qefewVUEIhE5CJ803fMIlDIF9Ou9PbksBiyt9ozgrcReSnLN29yo876AlEcjp8 R+7wrnfkJdxxxifbCLzRKrNc6lA5RSAQRDfSAd4w79RGo03GhJrfzeVh+3IQZGwIroGRKKyo gbIee3302ui0bDtWHtP2qwdOTPUecsZBQTqKqAb4dIdCdPLPSrPG8PbBeTyR/YhUnXYVFjR3 MHko/Z5huoG6bVOUpjFbymkp2+Ja5EEjJJyDztRUz9QDyH8K1iL43wrRqz7TFybp2gz7Lycl Kjjz887ht02rN+LEOwt++l42KIBWnKIoTT8GRDfT5hWzWfwwth1bcMPsRmqL1iody7XV99zf qiUMh/CpjD87A+CvfrzZjIIvFreWKLYQIhoUEeUjp0iAeYjXDcboY6fs72HJIRANhSJoXyuY dWrfwx6eNNLR4Odlmmbu6XST6IUcppNmyfxOsj1NjoQMbjWll4YWSM0m/wDo9GKqpt3Ackoj 2Uo6g0iPmP8ACtO9HpZujxliDupx05gHintCNCNbJgoAgmhgQ74juYRzny67VxrxxbsIFmwY W8btyDAscCyqoaCNwNnAAHUfyCrj9ALLLdQtDwaCjtzarp5zEx9yRUgCACUPPp1Hw2CohnYT RxwdtZvbtvw68pKw5nDpVzkFtQfXKPgBQ6hXMvztHPUol0cSEXk4WftiKXgZlVYir6QKoAqq Y+qQOhQ2D8Kuv/xFZuBKSeWwsu0KwI0US7T31TFNqAxh+fUPH0ql3BwtJGPI2BaXQaRn1lEU 3DVNpkqevcRA3jtj8autq8GGcDx6gbfuZ4lLRblgd6VI+A1mTOBdJg8s+tR3K7VUi+MEcxnL 6lXFt89zdwKEOQHOCIEOUAMUfE3h/I1lqZA7oFNhPbAj0KWvVHD+AtuSi7rmUYyBRXG7CtBc HbiYgtygHdSyXbV4Y2361gvF6KRjONF0QMWiVFBOV5TYnQhANp6j4BvWEyMgUt6xi8rTxEWM bIa8Ro6QDxx51cOHfEZjwbdOlLIe/SkZMoA57WiKJUsfCIY3EfyqWU4CMfaEWzRut4oK5yA4 cg1KKOBLkRJjqG2AyIeo02t/gUi+dW+m/uR219qsX7wxCNwMJCtjlx5fEUfLywI1tONIdZGS L4ocapK/7ZmIWSt5k3NKOkHBlyKCPJ5QABSlAevjv6jVRC7zl4PuOG3s1LsriRLIHemP3wUD AYAOnTatFuDgrb1qRcxPXXdUklFJPEGjDsyJFFTiqnqAVADp/IbViyiX9M7MQ3/zAJEOfbYT Y1D5VlV2LUmvG2fauraeowsZ7QgWoMivRDK7lDGkEhHHcJgw7F885peI44PY28F7kJaMWrzo j2ODRVQ5i9nE4HHWI945jG65HGKskfwyibJvKw5pg/eyYqzzJm5UVAgoqFXHvGKAAOkNxDfH nkKrX6UljMLOvhOVjV1TN7keP1+ScoF5B01AASlDAd3fb08a3lrb7EdDuL/SFvRFOaRWioyR NLuTuTitq9xqTBMxSAXG2gMZqsS3Ep1LWvHQb+3YddWOapsG8gcBFYrUhgEEg8MeG+ak/wBH NgjIuuIIGxz0LNeqo5JqEBxjIeQ71YbI4FQVycHom4mktIoy7+GdPgKbHJKLZQCGLpANfeyG 4Abp61jGUVK3fXFeS4kcqLvZJJpD9uTenOwLrWSEhNAEJq2xuIj0yNNou6resOU7dZLF5Lpv EdDlOcT0BjOSiTTuNaOt+jnbkk+CEZzkg3cx0sgwk3Suk4LAZuCxjJgGxfINWPMdqtHEXhtB 3zxbiu1JPWkVGWAi5RbgYE1TGBY5SFUPgShgBDVgc7bVpWuPlxgzPifcaE5d04qizdvrtZmZ SBlQHCaJi6dKePIoAAZ22o8PxUuuMtVvbDQ7X2c2YHjSaiiJgQUOB1NvhEwiHUQGtQg+CHDp acuVmSTkpTssgk3aEKsVMEUTtyqas/2pgMYAxtsHrWeW7w8g1+EUzdMrM4mGFxIMiMT/AFAB QA5Rw8TGz1DOweNdrr6nKSol+MHE9td3D5pbUdDziLc0onJLu5FPYpik0FSIboYPXxxmof8A XHeB7ufXG4bxjt1LNk2T1sZARRdFLsXUAb/d09K9S3nbUBcUffEFPSLmTYrSEemVgiUA9mHE SEICe/qBhDPw9ArEIyx2fCv9IjhdCRyppJy5KIu34l1JralDFyn104KG/l512s+7UgzJjIW9 cspMzt5wlxy0y5ciqseLREqSIafhEMbY228ALTNOYuEeHr21Y+Bep2a8fjJlVO1OIgIY0iKu NOAAv34GvT/6PSTZszurmA5RItxIdJCDYoZWKZINJT5/s+9nbeqdPn+nFgyNvMJW4oRW17cd OHCKbcSxskRBTJgyb4tQ9OuMVpWNK5OswU41cQ1lklzzCYGTdFegYpP7UqfLAf3S6BEMFx1p 6x4vcUgvJrKxiJjSR48Ct2baNEURa6tWrQAd4NWodXhWYwJW7uYg03ZC9kcP2xVyj00CcuQH 0r1dApcrjpxi7UdVoknGtkmKiRN022SZKluXu7dAEOlZW669FsVT4tcSYWQlSnc9hev3hnrl JwzDUg6MTQKqYGD3ZtA42qhFQeez136aEgqyZLFMssQhjJpqiOS5HoB9q9jXXwws3iBIW5Ly pHnNYR0eZZdQxgF6kKZxBuP2lTCAZwfIAPWslWkGlu/oerpwjZ4zUdXkZq+QOAGIsfqJNw+D QQgdM6iVVa0Z0V11xe40skWbk3a2QyAlKm5LFFKo8MIaS94S5Ee8bGPEaYR89xdirhjIUkTL HkmjFVJkxcxvMHspjalRMUQ7/ez3zZEMda9E2E7uVtdNnQd4NnUhJOJNaUlFTo5aQ6vYjlbt CH0iQDaQ1aSiXSPnmsxvr22znLMmISSvJw0lGDkXjUptUgk3ScgGNWnWYomEOvxAXxpWkckR qpcXxA4x/SyYjmjp+a5HhjO36R2JTLpHInpE5AEvutKYY7vTaqAnDzzi3jXOlASikRkRO95B hIYc7jq8d/GvdduWtDo8erovgqXbZd3KJRWsD7MkSxaSgjgurcxigXv6MeH71G4dJEDgNFR6 XORcBYb03eKJ2m6/fDRgQMqYQ64MIeADmvNG5RvXtebin4mQ1uwT0kbPNIxm5ItCrAkYATUV Hu6P72+3j0qbvi6+MzNv2O8FpOIaP0lEOzcgqCKxRN70BKUAARE3UR8sV7StgYxvxJvQdbpI 2phzxciJW+rk+7BER26BuAdB8N68z8emqQcDbdjW3tLta93GEiclsucRKbUIBqMOjVt6jvXo pLKmioR1iy2P4pcQ2Dx6+Z3Q4I8fgUHK5yEMcdJdBRLkO6JSbZCpy15jje+4f+zbbSlHdpik skOhsQ4HTMJjL94Q1Gzk4iPnVBuqHc25cD6CeaBdtMaxSNrIOooGASj49a9efo9lYBaHBw50 nnPTj5AUlEx9wmA8zXzAwOBHAYHbxCsqylGfVnWLytMX7dE5b7OIlricPYtiJDopHxjJPgEw 9TCXoGafy1z8Q426Iy9pWQeJTc41AWb8yZMuW4jgAAMY07BtjyrcpThDw3bmZcmHZtzyM1Fp S8cd0BvYpRTA4oCYDiInV8cmEAyOPDVYbstqHneJNsEm7abciEsx88YQ2o2gVkF0ypp4ABMI ad+6Bh26DV59NxTDI0/Hj9YFxkjUZpa4keR7ZN3BAuSAZABz3S934Q8PCqq+vq92LOXt5/c8 iik4XUCUaqCGTKiPvQHbbVjcA617BYk5PGTiEsdodfn3HAY0HxoKVon7w2PqlwO3pVYeWDw/ Vgp6dfxzKTeSjqddvXfZhWPrTVUFMxRxpSKBSCOBDcR6jXIX6s6vPN0M+LafDFAbk9ofQ0ia IokcOExDSOOSGn4x6bB4Y9KZPofiNPsbKgvYLtwz7IsFvNSFKQATzrVOPkJviEx/DpWj8SW4 Xjwak72uW01YWUg2sQhGuO3ConIoKK6BAA6AIBvgBMIb9K06dkkP/irRYEjzdljrKcqt2x3G QXMYgAJU+unukAm32BGruSh1b4vMzVlxCsa9krbZkkYafkgIUrZsoU3aSibBc4yUwZAd/DFK 9p4nOJCXcFlJ1R1ay6h3RwcYFksfuqGKHgfunDuhkAINeiLKbWHaXG+GSWFUt3ScNH9iRdnO 89nG7wOUM57puUGAMJxxkdvtZ5bB04bjfxvnHjnlQTZGTQXUUHui5XUEESY8TCPMAvyqc/Zx jv0suT6O+wAuGR9inwJmPN90ffO4eO4ZpR5ed3vCsgeXRLLBHjqZalh/o5sfEQfAfWq017jV IpuugKUrHfm5pFOmu+6Tznt09ySYy2gEgd84dYED6oenpXGd13SwcO3LG5JRuu8HU5WTXEDq D5iNQOaNU78zQ+9qyXsf2N7Qd+zBPzTNBPlMx9u8IeI7BvRpCZlpBihHSMu9eMm+6TZdUTkI PmAVG0KndkpIKTEqfseqVej2D/Yg5o4beqf2R2CmChzHMY5zCdQ5hMc5upjD1EfMaLQrkrkp AtChQrMFN8NJlpQ3w0QtAoWj0Wj0Bq1PhT3LTmFfmP5Vlha1Lh6bRw5l1PU+9ebiP06qizUx sqKG/eH+I0G6wpOij5DXUw1Z+Y1JxsCq/wC9nkJ/bMH85rWvgQ9vq8mQKemS37QfnXEz8o2Q opjZ3rRKSgV+U4p9LLa8VBtT6FKkHDghy1IZUKFCqApWiUeg1WxeKUZC2mlAyTCQV5KwKk7N pwcQDobPQN/nUnIcaGT7Uma21StzGMocnN+I/gJvPFVzhnFQh7HuabexaT56xSMKHOEdIdOn T/Gk7TiIKQ4U3BKmYapJuTmc05unTYodMb+Q17LVJY00JrU841sF+xHTgXQLoKkUVOJvi0hj b8a464zRqksm5Stl0k1BsducnNDWbUOfuCoqLt5pdHCdoaGi2jOXM+atyLeh/iEw+tTr79HS 4mOTuLljezp5FU5SDsAB0APEdulaUlOXhJt+u85k1kTwiyaQ6QbFQX0CUChgNRuvzquxfEJl Fx7xJpb4+0HpTJrOjK/UN1D1Hfr9407Nwp5XMWWuAE2ZWgu9fI7+kB3yHgO3T8qVgeEJ5W3R nSXCUyCgidsBSlKBkwDOowj0qqbwiXl+MHL62XK1ucwlvoclMDq5FTfOfIPuqc/XA2SmlpFv aJSg419pKZ0InWEwAHeHwDYNgquSEBFuOHv0gj9SCjA4JOeZnC2ofDPUfQKpVebKUKCdva41 rquL2wu3Ta4RK3RQTyIJplDYN+tXe3+NDyHjWbb6PpOnDJIUW6p1xApSj17oeP8ACsortTuy yzVi1dTjfcCpimViGXcEgp4MPudP2PIfWllOOcwd1q9gMk2Og5DMyLGwpr+ITm8c1kVd1VXM STi1RrxokkJz2v8AR6PFQjA0c2SA4gmiib4g+0YRyPjScfxpuGOg04plFxqYopnRQcmyIopm +IpC9A+/NZdQpu1MWlKcXpo0g0lEYWLQkW/L5jzcVnHL+Eph+qX5U5ecbbmeXtHXg4iov2hG oHQaJl1AmQpxyPr1zWWVyp3ZGLQLb4pTUCm+RJGRj1J6/GSOksAlIRx9sAL4+tVKemH09cj6 4JZTnvpBxz3JsAACbbYPTbpUZQpWeRi1BPjFcC/spq7SQZx7JVNRXsQCCq2joBhHw9Axmp2/ OPT9/LQ7u1Gpmfs1u5QFy+wZRUFxLq7vwgAFLgPxrEqFc3DFpn67L30r9oGNec3SJQcpCcET FLpKcnkYAEceXhVfj3lg+yzKy0TLyE8oJlTrArpRMsORAcfZzj549aqNCu7o0hTjFeiicYQx 44pY1wR0kQiGAMqn8BjfL0pCe4gnve4kZPiWiaXatE1CtWjH3JCHOORNt4ibcR8cYqgUK5kY rowvYtsTT95w8YexGsixMxcJuffKGTMPe3Hptj7wzQheJV5w1vo29GTAoRaDZVqkhoAQBJUc qFEOgiYfEapdCu5jQH3F2/3xY0F54Q9mqFWb6CAA80oYAxvMceP3Us+4z8RXlwBPrziYvwaG YjhuQEztzDkUzExgwZ86zmhTOScV6Y8WL/ZOpF62n8OJJTnOVBQII8zSBAMTb3eChgAL0qma /fc7UYTateRHPeznI+u3Wm1GpuSVi0A3GLiUZNMn0qWT5YBhQiRAUHAYARNjIiAZwPhUPH31 dce8jHrOZUTdRCaiUaoZMpxbFU/aYz1E2/eHI1VaFNyScV2Y8UeIDBZ6uwup22VfnFVyKZSh lTTp1l27htO2S0w+nN2/RX6KhcDssGIYO0LgAOXOdJh+IQzvjxqsUKrdkYlNvh07dMVYI+9b rYSScm1uF4k8I2BmCuQERbh/ZjnqXaq3QqY3JRUtjziBe7xwk5d3dLrLIr9pROZYfdLY08wn 2R07bdKj1rim3EOnCLSi6sQmt2gjI2OWC2c8z+9uO9QdCq3ZmK3SXEW/ZPs/tK8Zd12VUq7b UrgU1S9FAx9YPOkvp3eft76Q/SqU9scsEe2c33nK293/AHdulVajU3Zpxiskbe94xjp26jLr l2Tp6bW6VRX0mWN5m9abFue4ywKlvFuCSCFUNqUYFVwiccgO4eIZDOPGoSi1zdmrFY1ryu1d u1buLqmFUmZgM2KZyPuhKHdEvqFJPrquKRlmUrKTr6Rex5wVaKOlNfJMA5AS/eADUDQrm7KQ eST91JSTiSkVzunro4qOFzYAVD+e3T5U6a3BONIk0M2nJJCLP8bEi4giYNsgJfIcffUTQpuS oYpFSWkjqKKHlXxlVTAZQ4rDqOYuNIj5iXG3lTpa57icPkH69yS6z1t/s7lR0YVEvQo+AbVC UKrfmJhO47gI8WekuGXK8cF0ruSujAqqHkYfHFN05SRSjVIsko+LHqbqNSrmBE/94vj0++o+ i1nnIxP3Eo/cooN3Ug8cINhygiqsJyJj5lDwGuKST874H55J6o9LjS5MsIrF9AN1APSmNCmc lHnb3nbO39vd9uH/AOa5o877j9QpAyyo5KKqogc2pQBMPvDeZvMfWkq5TKQ7XKLRqgChRaFA ahRaFAKFChUgUKFCgKp8NELR1KIWgVo1Fo9AYtavYaJluGL4hC7qCf5eFZQWtgsM/J4Wuj/+ oNeXiv01RZ21QIRxlXcC5286ex8qZCSRcuUtSCZgEUQ8QqCUklqJ7QPWlIiJoUtqMei4rZJM tLKJCT4qVYh8an2QpA26mqgUoVyu0Ao9Eo1BbLHvP6OxsnGjGFkEZEgkUA6ugMCAbD5htTm2 71Rg7dkYZvbyKychkFTnWwAFEMaQAPDaqQWl61hdlDwLxD8QnEPbqMJFwjRBBM5VDHOoImUO UdhH+fvqYY8bLsQ7XzkW7wHiwLLFOYQAR+yGOhfSsvrtd3JDQpDivMvE3iRoqOKV02M1wQTA CSRvAvn1GmUXxImI21Qt5FizWQIXSmorqykGNOSB0AceNUqhXd+Ql5i4H0lEs4cSpIR7L9mi kGAMb7R/M2/WoehXajIcoUKFSBQrtCgJQo9coC0KNRaAUKFCgFChQoBQoUKAUKFGroLQo1Cg LQoUKAUKFCgFChQoBQoUKAUWjUKAUKFCgFChRtNdBaFGoVwFotGxQoC0KNRa4OUKFFoDUWhQ oBQoUKAUKFCgFChQoBQoUKAUKFCgFChQqQKFCjUCanw0UtdU+GuFoDlo9Fo1Acta5A+64Orm 8yKb/fWRlrUHTzsHCFsXRqMvkM+HWvLxXoVH1MtW7xqT008Kp77oHWrFdzdv7PYOEEip6iYN gMb16KeEquiTvelFdE+tUhjSWkjF1IjVBNNur7LUW8MhTCptNy3CLUbj1GonAUAoUahQFo9c o9Bxmio4cAg3SUWVN0IQoiNOnDV20U5Txsq2NjIFUKIDitU/Rt7IW5JHnG5OWCpecAAJy5L9 X1/nFX+4LJtu5YuIWfg6Km1bDhyfAKFLqDbr3jD/AIV6bFrOlSTzc3ZuXPMFugoqCRRMcxQy BQ9aBWjk0eV+k1WUbmUKkBykyGo3QPnXpS27TjI2055mwjjIGkO0JrmObUdMvL2x93n+dOWc IziOHcM0jWwFRRWaLcw+46wHcenXb/pWlOGxp/dOTzTKRElGYCUYLMxN0BUuKPEwkxMFVPFR q7xJD9soQvcT2zuPSvUk9bNvXO+bjPI5ZN3SxyJrqY55sbGz9nPgHXzqvGLGNu0WZAxC/s91 pUdKIZRwbUPfKH2e7vkd8VdeGjFOTz41hJVz23kxyygMRw6OAZImPkI+fX8KQTYOzw5pjsy3 YSKFSMuJBAmowbBnzrenjWMguEN4wcZ2gEEZdNNRzrADqAOMjnxDrt3s43qydjs65+DcTFsB /qFo6a60SBo5hwHfVn4s9RHx8wrCkY0/7aPLFS9v2zcE+VweEi1XaTbALq7FImI9AER8eu1X HjUz7JMCRC3GcLGkcnTZHRHvOyB9bT4F2Her7+jysxHh3IMHLQXih5FNUjMggXmCA7mN+6HX O/SpnDCeifiwOUZrxb5Vg/SFF2ibQdLqOrbYPPrU28sO8Wke1eqwDjlujJgkQN1O8OAyXw8f wr07clvWgvcy8ytHxy00bIMCnVAdwTDUoruOkC42H0qYTkmCcai8WeJogbs2t4KgCo7OUQDB d9il8ADy8K9NLEeqcnlF5w7vVo6athghVVcKgiBW6gKaTfvY+H5jRIuwLtk3Uy3axQYhl+zv VFVipkIr9jI/W2Hb0r0bcCxCFiGEekDFdxdCboEinDW5RKYRUX6fCONxH/3Udi0bOXl+wjky CiUjc4PgysAACOC6lBHPUN+oj867O1GNzF15IWJyVlkVdlEDiRQOuk3lVgj7JumThY6XjYgz hvIvAaNh1YExhDqIeBeveHat1uSHgW1tpsbPbxCkLqW9pPXJiiYw57uB6mMICOMAOdqtt6ST OEse3PouVkVqhJNvZ7YpgDCejSc/XIZyPernLRi5k88/qcv/ANrdgGOZFDkmUM4M7KCQaRwJ c+Juu1Vm8rblbQuBW35tNNOQRIU5ypnA5cGDIb16Wu76NSvELhjFSp27VnHEePX7EjkDETNk pk9Y+I5DfOOohmvNl+TD24byn5t+5Fy4cu1NKv7gbEAv7oAAAFTOHlSDN3cas97IhsI9P+tA ve06QUHWYCl7g7iIhgPzr2PwxjOFKPDe2rnlV4cs1HwZ26TZQ5RMBzZ1G0dTKGyAZxnwCsl/ SQmU/pRbNsQ5GBmJU2jtUUMCJXOrBgMIZx13D+GKzjDKmoobPh1cbviMaxUGyakqm1FyoUpw EpC6Ne49PEPxqnp+95nKQcGFLIHAqJhEvz8uterGNzRUH+mKaQRkmhYt/CFScKpiUS8zQAAU x/q94A8QDzxiucJ1bUt2yLlZPZGPkZcs64XeuyqkIV0Tl4Acj1Jkc6Q6+dbbNNdHXnS6LSlL cte27ifgAsrgbHctjJZNoKUQ2P5D3gqBUKZPk601Q54ZSDlm95/d869at5Wzv/hzhYe4ZKPK j7PVQM1LpMomsssAkEC+YFz4D18am5yZ4aNL44fSDd/EaYVBygnpMCpkinSAqGofA2Qznu6R HrUbOqZPKdo2TMXIzuByiQWvsJgZ84I5TMQxyB9nPj4VWdA7ayGTHACJThgQ2r1LwunEIriF PuuI9xwUuH0dBmsJDFFNYxlgEER274iHUu+M4xWL8RIeZuPiddMpCNFp1mo+1FetUsJadIYK UPqlKAYAPIKqdnRzJXjW45Jw/RvHUHZV5T2ail/aHPpyJgD7P8RqJUZvk3CSCka/TVW2TIZq cBP8gxvWuNJBFn+jFDQTl4ijMs76I7Ky1Bzk0igICYQ64ARHet3muJHDp3cZHjWaZC6I6clj HBi/7OJ2xSAYob6A5me8IF61EaR96Kq8lWHZstdt/srNQbOWbtfUJzLNze6KUM5EPuxnpket RryClUZCVapxr54WKcnauF27cxyAJBwIiIdOmflXsy0uINhNbh9nDc0enJNYyMbPJQTF/pIo GMZUObjfOSh8Q9egVXYHiBYcVYU61K/jhUTfyyp9aggDnnCcUzFIAZUMbuFDyDxrTCCMnkpR hIpRJJZaMfIxymBI6O3MCRvLA+OasnD2w5W87gGKTP7MRJFKzCrtZMcdlTwGogfXyYQCte4p XfbUz+jyyh1JdFWT7LHIosGxhEBFIO+Bg30FLt4+lPbP40W9McQGryRiWsMkjZakCCqpfdqL iZMwJ4DYqOSiAZCscHYse4kcOJiyfZTj38xHSrciqDtNsYmkxjaQTMHgYcfMasMDwMuGVsMt xLSPs16u2eOW8Yq1Nr0thwoCg/UNnwEPEK3n9cFhs/ZhJmday523Zk+zNUQACuebqF1qDSUp UiiG2d8+dRUXxPsphw2eRpr0I95CcsksUyQlPKGcHMKR8aeo6gHptnxrRnGUtGH3twckrUsN zcTqbTcu40jL2ow5OjkC5ANIFP0UEMhkA86o9qwb+5bqjbbiUec/kVwSRLnAeYmEfAADI/dW /wDGfiNbE5welINjNJPTPk4xKIjuWPNYcjHOE5vHp1Ed9WMVjfCOfb2jxSt66HZDKNY9wPOA nXSYol1B54znHjXLkaatorHa/CJGcUuB6a6jNYeLmiwyCqTLmHcL4DV3fqlDz8c1Wr2sC5LV vKQt1aKeu+ylcKJOU0TCVdBEO+t0+EPEfCtn4V3zaMAyu6ETuRu07Zc5pRm5cNwMVRscgFHT qKYAN4b771ZLs4y8P5W356HJcK3Mlmj7S8TbGAG4GMXlNA7ve5oZER0iAatxqp6MspZsAlOH Umw4KQ3ERUHHNmJYse2jRbjqMUxTCVQo9TauWYADG+QxmrYbgTIJXnH28/llWQ/RL6RSOG3M VRED6TIFIGROYDbbda1y8ONPDl8lbEijLC4M3uRrKKRwImEzJIjUURDfJcFMOruiXr0zmmT3 ilYCXEpGVbXid8JrLVhPaQtz4I5FYFCibVkwD1+0HTI1zq2YfenCe6oa/Jm14Jg8uNOJIkZZ 2kloAvMSBQCm8ANgenpS8pw2iIThXEXjNzsqnIyzRVdtHtmHMSAxDadJzh8IdN/XrW+R/HTh v7anVzShQD2m2dIvHLNbLsiTdNMTkABzq1EECgOnrkQrN4riZFI2PdbmWvWQfO5yMfM0LaM1 AU27lwfJFiiAAUAKG4h67DWkKR8s+uWirxfBV49i+HpFbi7NMXgcqxWnZs8ppp1Crq6GECgA 6ch8YBTaT4Udt4lQ1lWNKP5k73WLtZ8y7N2QiZ9Jz7huUA3yHUdIBkRq7frVgmd3cHJNzMOJ RG1YgzWZIRMfcLGSBMTb41jsHTPwh41KyXHGIiLitlCJVY3SkDZVhcMu8bKEE7ZVYh9JQ2zp IA9c+VZ9ujRnDHhOR/xxuThelOiV6xbKGjROkGHaxUyqaBH6gYEd/SspKOsurp4D863lxxLt Fj+k3cnFtqdZ2zRaCWERTREoPXBm5Ue/nchPjERxnptWDJgIJ9/4hyJvmNY1dcoV2uViC0KF CgFChQoBQoUKAUKFCgFChQoBQoUKkCjUWjUBaNQrtAit8Nc+rRlqBaA1HrldoDVol0bcNYUn 2jCP5Vnfh91aDfXcs2BT6dwRH8Kyu+ylAL8VT88r/VbJLyII1BIl1qB86fTS2tQpPsEAPyq0 meoxzd7pTrQQxdJKdYLXMfu0EQoicv1aT5R/KrB3T/F1ocktMhAaa5T2QJpUppVAUKNQoJW1 T3B7aRb23zvaKnwFSwI48xzsAetWG6lL+ijJmuOUe98cE98AkAweG2wVIfo/vGzDiEk5cH5Z eQYom6D1DYP+tbTMMLecQ5UJZk0RaJqmU5KqgCcf7vXvGH/rXr4aGZJgNsu73nVHDKFlpBQO WZVxhXGQKH1h8flXI9W95e21n7N/IrxTNQpQJrwTUYdtJfrVvljtodj7Y9noRzJRcQycqgZI hoENAm8B9KRhUYuN4XosI0Y9k1RAAVwcAFRQD5z+8PrWu1X/ACzyYrdEbf1vJpTFwSDtNQpi JAftIHMkYfhLgPhH+FEs+Nvu51Hy0NIvClRJqeO1nPLDHlqHr8q354e23HZfbp2YtVHaThqg c2o6wl+scvUfLP51Dzkhrub6PwjSLSaLon9oc5Uuk4Cbcp9I6ShpHp+Na1te9DJikLbdzzft NjHue0R0WQTu1Acf0cTCH/7GHy/GnRrJvhtb7F4qsCCbgAUasgc7jkcagLWpov7di7Xvhhb4 R7dipgCDrACrKaS6gAPrdNuvyqTZydsOrfgZKVdx6SbJgVAg8wOcK2chpL9n7vHpUVh/9dYx d1jXZEx7iVnXoPOxnIi5DnCoZERAMF/0prYNs3LcvbTwj80cyaEAzpyZYSE36E9RHyCtf4wX BDm4fzzfnNOZJrJixSSOBllPh1GOHgG3Wq3+jrKsmEHMR7wzfmuDgKZHBwIlsAbnz4fziuzh Dci7Fm92QkxbcsMZIKunCpil0nR1HBUBxgAx/CrYpwlvw8Szf9oAzxVMiqLEy+ToFMIB3vsj /CtsmrwstVwmupMRi0kVIEm6pSlEjbuiArF9cjsPpSbe9rXZQLTtM81MgCBG5Ew3cLKgbPM8 9Hr61UrUcnO5i05wrvFgZQ7eYLIu0naTFyYixg5RjiG2sfAPHFRheH9xueKj3huyUFw9aGw5 XBQQRAuCmETD5bh16jW2XpdUI/iwjUpOOSVfzbV2iigcB0pkOBjKK/ZHbcTedIxfEK24TjtO rEUZvI6fUTWfyIK4BIqZSgBc+OcZ05CvPL1EJMUZ8PZ91C3VIdpSBrbi50RS5g5WMTACYhfL cN/X0pZ9w9kmlgqXcjNoyCzYjfntW5xOKB1jABEs+J9y5KG4Z3CtBg5e3Oy8W1PbTRo0n11i RuTYFYMbGAOuB+/OaLZt029w+4TgzWkUJp6JklmMY3KAaVyjkTn8g2zqHPgABW9dP8uq8XgP dvtCDYSTpvHqScYvJvyqZMdqVPT7s3iZTcO6HQfGqdxGtNzZVwJRTlwDjntCvETgGB5ZumQ8 B26V6UW4tWlJPrZmHT1s3mCxTlN2XUJgaqriXAGMOw4xv5VhX6QVxxFz300dQjrtyTOMKzXe 6RAHKoGERMQB+pvtWHwrq58ka64cyROFsfxCblM9Sdu+WdBEgiKAAGdQj12x5eNVn2dJIxrB 77LeFbyBwK1Pyze8MboAD45/OvQ3Ce/7MtvgOhDzkyX2gXtBvZ5CahMKpNBc7dQznONqmn3E /hk2teyY2NcJf1LINXZGoIauzgmUSiBjD1P3s5DFKaYuSYjYvC6YmbicW9Mtl4IycY4fkKqm OpTlAG3puNVaNtW45BvrbWy8UBIievSQdJdfwh6iPlW927fVpQnGJW6ZC+FpqPFo8MCB2wii iZYwctAviYeufLbNX7hdd0Lc1wy0g2eKqtBmG8gu4UMVHBipadIAb+wTANh8cV3TroZPJZrP udNmvKntp8VuiYwKKnTHYQ2H79vypb6CXWkm3H6KvAK7xoHR12zv5dPGta4w8QIF7bUZBW9N i5Mlcjl7IEQKIJKNlFxPgRwGrIYHx6/ENXk/HSw2lwe1EXDl2rJSST5YgpjpYkIhydORzkfH u6a1lG25lV5la2fcjl8zjm1tu1F3DUXyBNGNSOvRzA8wznf0rQ+CVjX1MSlxw4O5e24uAaKq ORR7pe06AEqf97AiPyAPOr3KcWLGLxOQuFg/dLs0bNPb2oURDKplAMU2+duu+9W1H9IThu4U mTu3z1qgdcV2wFamEVxFqVDHoG23w158q08KeO2f9KMktoy5ciBPM5zGHp6iI1ZmfD+8XkhK MWdruFVIlcrV5sAcs4hkCj69dqkrLsKfQThrvBaMTi2LpOQLzXRSqikmcDfB1zsO1ejH36SH C1ysy9lpvmaftArx8qZny9ZS5NkNO5jGOIBgceI1pW3WNeo882TwvlJPinDWJcbMYkz1uq77 oAqYpCFMICABsO5RDrRbV4cvJvhJeV9d1P2A4Ik2RNj3hCmDmCPlpKIY8xAQqX4dX+wiP0i/ 1gTsg7UhUFXgt+7rUBFUpippgX/m6Vywrzs+Ns3iRatwJyHYblXBxHihnXqIYTJgfHQM6c/I QxXa1oKepY15o2s1ug1tqgxeFRMiYPjOCpgKmIFAMiBhHbzqRfcLeIDN4kzdW931EllRKRUF OWCQZOBsfCIb1sJeP0A0s23WjDtntKPbxjZ02BDSVQrRQpzDzQwOOu3TcdqH68LAZyXKjSTC 0bJO5GQlTqNgAyKrsukCph0OBd/D765GkVM+4W8H5ifui4ISdaezVIuANIFJzSd5ZQoCgUw9 ClHIibyxgcVn0LAz8tbszORcT2trBEIL5cmNCeoQKGPteOxfAM1tCnF+zD8c5S8DNpQtuSts jBuS6P6QXOjvFL4/AAVnMPxDk7Zt27LVtJFJtA3ArlIjnvqtUg28sGOYndMI0rilqH/w8x60 S9aRTmRWuJtEIPu0n0lbKrKABhSx9UNw/Cqhwx4OTcxcChL1YOYyMIwfOkiIqlBw8M2EgCUh R72nUcO9jfwGtFR/SCsv2WQjkbiBRZg3YuGaKWU0CkxzDk7wAJsFAAHx8Qpm+/SAtmYnkJKR iZFkJo1/FOFG5dQotlxKKRiB8Jjhp3DTj1q7mNfSoQOANqspOfcyQz7tmy7ERFg20mcIGXT1 HA+4AOjIDsO+9efZZIjKWkWpOZymjlRInMDB9JR21B4Gr0XHfpB2j7Wc9rbTyUS3VYqxyiZN a64NS4AqwCP1jb5z4V56uyU+kF1Tk8ZHs/taQWecnORTBQwjpz4iHnU350Sm7yt1rbPDG05l U5jzNzgd6TGOUg2KbToHzMbJRz8wqyXVwmmycRGFmWy2SWcKW6jKK9pWKQDdOYIDvsA+Hpmq 5eVzsLn4Y2pbSzNVKYt7U3Tcf2Rmo7/ecRxtjbHrV8e8X4AOKsbd8dGP1I5ha3sIEF+6oY+k S6vHu97r1HFI17FfFSbg4aXrAouDysa2TBtJto0NC4HA6q5QMXTjqGB/0paS4W3vHQVxTyzB t2G3nnZHpiLgJymwXIgHUQDUX8av63HqLeXA8VlrbWlYDs7RVgxcd0ycg3AAIsIgOQLsOdxy ABtS0h+kCwmODklaE3BvDz0k2XTXct9JGnNUUE4KaQ9R3/u9d672ap+TM70ttpE8EuHt3NTm 9o3Es8B0JvhKCSugoB6Yq3PODr1/xtjLHt5AfZxIlpIySyigB7kwl5pwz0HvYAPvqn3VdTCc 4QWPYgM10nttruDLuh3TOmspr7nmPT8PWtJS46WyTig8uQLek/Yz6AShnCY47QAkNnWAdMbA GPGkMMOvlaOiuGtrvv0mrr4Yc54gl2dUsKYu/KWBEFe/6dfnjHjWHpmMZEDG69B+YVrZeK8a 0423NxVZQzjt79oZKGQUwHZlTJlSFRQfDBQNsHXOMVkiYaEwJ18x8x86803HKFChWLrlChQo C0KNRaAUKFCgFChQoBRqFCgFFo1CgFChQoBXa5XakJLUC11xXaA1HolHoDfVrRL+aLrQ8Kk3 IJsNwEf/AGhWelrcHzTWzY6fBuT+FZXfZTJ04t4gnr7KpzPDbpTU0XIm37Mr+FbEml9ou9Mb iWIwh13GnoXu/Os90ZvQrlCtkhQrm9KFLQRr+mlP5IKZVYLQoUKB9Cxz+VlmkfGlEzpdQCp4 NjSP2hHwAPOrXd1gzVuN1nS0l7T7M5BuqZIxhEh8VG8OZFCMuyPeOz4RIcNX8/z869APLztU 3a/aEpHpouHPaCt24AcRJ9k+Oph8Q/OvTwula9U3WA2bbErdUwlFMQWR1pisJz6gJoD+NPLX sabn/byrfPKhjKJ6jahBQ5Q8K2aBvS1+2OliSrRlz0gzpKAckpR2TAdvwo0XednI23JM/bbd ojzFxImQMCuKgfEIeI+vj616YQh7udzJLg4aSkDavt5y9TcKlIiKqKWREgqCAAQB8TegedI2 Xw7l7heLNnfMh26KB11FViDkwF8MeI1sBeIFnIxLHtUkRcwAkCLIpc8swD+0Hy+f4BUfeF/R srMNWkbcbNi0ExlHC6Rc6SiPQxh2EeuwdNs00t/4O5mVp8PfpPcEk2jX/wDVkQ1Ous8VSEgD pDoUviI1WkYR+8UVVjY9V2iRYEiuMYJv0N6BW1l4hWs3kp3sEpyWZoYzFNUE++6XEP2hfHG/ n/y03sG9bDgeE/0ecORTeKJ6FyFS1CobHxD6fziopSkpaOqhenCkbTtVScPLFeLIcoq5SJ4J lTwKPjjb/Gofh3ZP0zePSrOxaMmCArLKFJrOYQDYpS+I+lX7ilxBtyY4dqQzN0Lt445OhsBB 5bMCY3z9oarnBG6mFsPpIZF12UHaHKKvjPLHz9f52pc0ygQR99cN5K23DEI1i6kmjxIhyn5W DFMY2AIIee3SrNH8DXKsCk7cyHJmVkBUURAgclsOcAmY/iYfLG1XZTjPabXldhdul3aSYIFe ckQIQv11CF8VBz3R8KaM+LVlRsSgVE7xTsxDN2jIxRET6hzzVB8BDPWt/wAvJHcqVycFmcbE yHY5tVR3HnbkdLHQAiJxPpzp8R6ht+VNVODjxzxmT4eRTsBYptE3j2QUTwCaWA1DgMhq8ADO +d6t13cVrem4d0w9pLHNJqIiolyR5LJIglzgfrGNjp0pu84vRbPik1noBwb2Ysgk3lV1kO8Z ImO6XxN02DpnA7VN3b0djkrEXwpYyFycQ2ftjSFrJKizT0BrX0EzqEehS/LOc7BSln8N7JuC xvakfcL32kTs7ZZZQoIondK47pBMG4BkPAflUzG8SLOJfXEO63Kz1NO6Gx27VAjcRPpMUC5N 5fj91Up7dkaPDG27JZc1A0ZKhIrL4xjw+Qn6eHh1rCMnVwvbgQZNFihZvbHrxeXJHKdoIBSi XTqUXN10kAQxqqmcarOZ2FfCVux7wXyHYE3HacYA5h2HAeVaBcHG8ja3YyJs9w7UcJuyuHL1 6ngEk8YFMn2th64ql8eb8YcRrxYTcaQ5UmcaVkcVCadZs51B6b1c5U6iHtnh7c9xQatwRUam qxSMJOcc4AImAM4AOvgP4VZZDhS8jv0ffpvJIqN5t/JNkmLcB25KogXJg8zCI1bOFfERlYf6 OzvTyHU+tMGMxZGENRSmIBOdjGwBkd/Om3ELjFCXZwtLbPZniMuoqzMu40CKaZW5gEMCPUfu wFYezqI4qcLoi0b6sGxkXi/bZXke03IgAkHWoBTCmHluOPluNMp7hRcL/iBd8JaDY6sTEyxY 4hTuALnWACAGEcFHpv8AwpHiRf7C6uMVu3s0bukWkOVsU5VQ75+SfVkofz57VdrX48xEPdV1 TZ4R2KE5JFkkkQHvJqlIBQA3p4/4VdfWMzb8NLtWtl5P8lmzaNzrAXWfvKlSHvmKHUS7dcb+ FWjjTww+jVpQF52031wjqHaLPSHOPM56493G2cYENvntT9jxdgm1lzMMeIeuFZE7jkomEOUm C+fi8gDPTA5ol8cZGkzw3LZcVDqtSpNGDJN0fACQjQdQCAeIiP3BjpWt/b/8aOo1g8FJL6WS UffUaqXslsqTTdiQw6lFc4IQxgzjA5yAb5p/xI4AzaMpAnsuNAW8i1bi5ZmUydssfOscjtyy lLuYRCoG0+NUyzuaSm7pEX3b4cYbUn8aKQiHeDzNnfy9KtgfpIpJclGKt04N00kWQncDqOdi kUfdmH4jHOJh3yXpWWddCStRPCUheAV33pcR0llgFI8MoiqOBQKsBDqaeve8OuwbVziJaNnp 8B2V9W3CuotwMsgxLzVhUOskYgiJjh9U2Q/L1p9IccYdzwykLOcW0sQztqDNM5FA0pIgcTgA 7dcm9elVC8OIUDJ8OUrDti31Ilod8SQfHOoYwHVIUChoz4dM/LIV6JVphXF1nxhomqjUXQby rwNA1moa65QrgGaFChjVQDNd1UX+z1/VDqbwrtcA10WuUWuA9DNEoUCmquZolCgNqruaJQoD UWhQoC1yu0KDlChQoBQoUKAUWjUKkFoUahQFo1ChQChQoUArtcrtByu0KFAmtXa4tXaA1Hol HoF2/wAQfMK9ALE0otyeSJP/APkKwSP/ANoS/vhXoB10T/uF/gFeTifio20Fqj8UHfu2seT6 5hMb5eVXzIaazMxzz1+aOqZD6fw61FvumIrlUOVTrFCvSk10UbRS+mhpoIiULUZU3LE93ULV jlChQqg5j2C0g+QZI41LqFTyPQM+I+laZOcJSMGL32Ssq9dsxKHfKUhVemoQ9ArOoN4RlKNH am5UViqCHyGtsU4tW2fmrOVnjwzjSItiEMCaYBju58RHAZr08Nj11JM6tXh9NTc4xZO2As0H GVTqHD4SAbAj/GrBbfC72tdlyonMZOLiDqIN1hKHvVAJkoBVgj+LNve1O2PyuygdIyKvdEw6 MhgpfPGA2pxF8XrWbe1uai85DpYVkUypiJzGEuMj5B03zW9NnVnLJAqcJWbfh6nMpOXDiQFl zhOCeCnV6AmUOoiPlim9o8H5VWYIneCRY5iVPK4EOAmBXTkCD5DU+34wQTOJaolZOnDpuj2d JI4YSSTz8Q/vUzvTivG3IZqkod4k1Kcqi4Jp6UwHxAPEw7hv6VyOGH1c7zC1eGbe4OIns07J 3Ew7Vmq4MZXc6ol8AHp92aJw/wCGhbhTuKcckVZxbcqycaB/jUOUmw/3fXx8Kfo8V4hrcSLx q0kQjWEYqyaEN+0UMp9Y3kHr40jZPFSKty1VYdzHuXA6VOzFJ0AThvq8utcyjmruP0+EcOjb KJilcKLlhBeqvzbEMsBRHSUPANvHy6VR+CdsMbzuYW0vzuxoslHBkEfjVOAbF+X8as7ri219 iii3ZOxkfZwxyQDsgkkYByI+Zv8AKqbwruj6EzQyJOZ3mwt9RPiKA9RD1qJS6UdXu+uD8gk1 h1rWYJlWcp+/a84BwbUH8A67bVN2/wAHYT6NiD8e2yHve1OwNgiZih3Sph9f8PDxqKU44pN2 qLOHhl0AST5BHKqmVE085MJf3zY60mjxsTbNxM3t4QcF1AyT5o8tuBw7xhHxMPnW9ucNdZIx knZbhLbzS23v9HMggzjSr9uEdSyqmMmwXwD8RH7NVu6rVsmB4hW+j2F28ZyEIidrHFyJ1nKh sFFQfqlDbPjt0pCY4vdvh12ZI0xXj5uVo8cnHJSIfWAhfER6YHb0oynFqGG8GNwlthYisbGe zmYmU1mSJ9ovgBgDIZ9RqpXYdNHcSl1cLEVJybcRkkziYiLMRqtr3AXYhkSk9A2D51IyVjQo WHGtrbYR8rKFaHWlXplMqhgciJS/L09agXHFSKcR7yNVs/VErHBRNkZyIiKhQ7h1T9TD4j51 HwvERvCwb1mwgEE5KRKZJw+8E0T/ABlKToI+WenUc1NJwz1cxkufEjh7b1vHhL0bRfbIbsbR NaKKcxOauvgC6jbj5CON9tsVU+PjKBh7ii4OIjW0fItWeqZRRzgix8CCY9ciUPyEKe3txkc3 JEw8KjBJR8dGrtlz+81KrihjllHwxt+NUK+Lkd3bd0hc79IqTp8YDHITcC4DAB+VYyuqaXwp 4dtr54MzqjJMqM4jLplM/Ux7luUuo+M4wGAH86Tuay7YjeAVqz5HPaJVafBN3kBA6wczGn90 gFKHQNxEOtV3h7xOe2Varq3mEWi6Rdu+2OTqKCUVDadIJjj6uOvnSKPERf6H/RVzEM3DQX/b SnNsCA6sm5ZOmodw1D0CohLo77tX4ucD27q/mattv0o+PkXKTMzUpcgiqKWrbrnOM5HABmqj avBb6RXNMs2FzCsxhiEK5VTQDX2gxsAnjp4Z6jR3H6QVyuZhpILwrIxGjvtqSInEfegnyyZE egFKI/DgfWq3Y/FSYtKQnnrZmk4Cdc9qdthUEhBPkRxkO9p3H516NyGKMZJ9nwNmFoO+pD2p /wB21FiNu6Ag65SYHN9/hjzHpUleXD5raf6KScgsKbi53b5i6cKae+3IsXuo5/j86gmPHO62 dvykN2NkqlKHVO4x3CFBX4ylKHgOevXbrTG6uLs3cfD0lkPI1oDMDJCd1qEVDcrGgoB0AAxj HlWUsVNG4b8HPYnEJoSbPHyR1bNcyaKCxg5abwDFIGoOugNXxVJX5wPRu1a2D27Ismr4Y1EX vZSABFicz3rgM4DSAYx55CsMtO/5+AnlZkzpSTVUYDGGI6NkOyjj3IeRNulWpxx7vQ3ITZto +MZocgpUG2Q1JIjkiBjfEJBETCYMhnOKRmmUeq2cJWlqSETelt+zY12xhGL5Rss4ARdSJk9w W32IQu22+dQVE8XJiNPwFthJa3o2OlrmVI9aFaIY7KyQAC9447mOcw58hAfSqsXi9cKELMsG 0dEouJoq5HL4iek6ZVxyqBADbfI7j0qqXRc8hcLKCZPxDs8AxBgwKXwSDG4+Zhx1qp3TFZf0 dbdjbt4423AzKPPjzis4WS6ApykzHKUfTUAZDxqY4ONULouvi0/ftGqb1G3ZF02QBH3aJsh+ zD6ukMAHlms2t2afwE8znYpYUHzM+pI4dfUPvqft/iJNwk9c081RZmkLmbKNX5jhgpCKiAn0 Y6DtWcJrX2zeA7G4eFMNczO4Xib6QjFX3JMQughUFSpqB9rxDGw05jf0fXMnPXRGtXkgCcbL MmrE4pl9+kcMrmER0gGkoCP+FUCP4nXbH2WnaLJ4QkWmwVjyE+yisbWrt0Ewj4jnalkeLV7p OLcW9p6gtxEUWJDdBKJdI6/McZDPUAEd6Rn06uVi0m2eGsRZ36X9rWz2r2xEO2ar5uJ/EBQV 05x1wJM5qkcKolm6t3jMc4f0tnFKGQ2zpDmDnHrsAVGyXFi8ZLiHH8QHi7Q07HIii2MVPSmB BA2QEA/vm/GoqGvibh29zpM+z/8AakhiShjk3wbVnR5fGP5VtG5ClVtWvOxIS0v0NtTcx3Up I+y5Z2sdLHL54BpTKPkAeH3iFVHjQg0ccMeEly9iRaycnFu0XmgMcwqJyAmYfnkR+/aoaY4o 3bK8PUrDfLNVIZNJJDOj33LS/Zlz5Fx0qvXRcUpcKzE0ksApxzMjFikQMEQRKAbAHmOK8+SU PRaFCsVBQoUKAUKFCgFChQoBQoUKkFoUKFUOV2hQqRyhQoUAoUKFAKFChQChQoUArtcoUArt crtAKFChQJLUairfEFGoD0YtFpSgfwpcyTUv/ml/jW+uC97/AJQ/hWEW2XXOMS+a5f41vawV 5OJ9hB3M+LHwrhx4gQdPzqrcMWWe0PlMiYdij65ocUnmezxpDbmMIiHpVwtNgDGHQR0741D9 9RHthkpRDNKJ2OpQxO9RDV60o7sddKzNT6lE6CuTzTQ3zVaq8XITMeNUo1WEqLSlFoC6c/Wx 61fL8ioeIj7WYtm/J7a2Bw6d7ice/wBMefSqHqq0zlzNpuNjGizDAsClIVURyIlAegeVXbl5 FjvCFtyHvC10W7BQzF6yKYUznHvGE+MmH8PKrWpw/iJGUuuOimaSbxPlGanMfBEclDI9fXxz 8qoExebOVlod6vD+5iCgVFIVAEVMDnA+QVKt+LD9B5KPEopDnyeCnyoI8tMAxpDzr0Zxy/sn FP23w3ZM7JmpCcMV64Oir2AxOmCB8X3/ACH0AaZ8RLGjm0DDXGx/orFNg37UiTIiYTG6+Yj6 Y+4KY/rff+x3UaeJbiDkopibVsmQwd4Ch/ntUdcHE13MW+zgDRDdGNbcrWQDZMuCY5KU3kX0 rXO1/lOMkdxEgW8O4YvGR/6FJois3If4yhn+HrVUp/cU28npRSSf8sFDbETTDBEi/ZKHgHpU bkteW757Wjuqu0nktDVWIPqoaqTyFDWWgPQpPWWhrLQKUKS1hQ1hQK0WiawocwKA9DVSfMLQ 5haBTVQ1UnzC0XmloFaFI80td5lArQpHmloa6oKVyk9dDXQKUKT10NdArQpLXQ10CldpLXQ1 0ClCia65roDUKLroa6A1Ci66GupBqFF10M/u0BqFF10M0BqFFoZoBQrmqhQdoVz/AJa791By hQ/5a73vKg5Qof8ALQ/5aAV2uf8ALXfuoBQrm/2aFB2hXP8AloUHaFc1UNVB2hXKFARX4qPS ZqUoO0pRaPQTtmhruaO/9cK2d4rysn+rWP8AD/H0wjdXTm/4VpXEK6WKUGs2YkTMutkgGL1J 5jXlvqU2L/7R3oLjqiQf/wBQzWrI/Lwqt8GUYxlFmWcHaCsr/wAU25Qq6fS22QlCx2tjzx+/ NRd/2JZsoSkdFPNFE0V6g3KSj6KW0UMUEXOE/q9T5VQjVoNwbRqvqFZ0arArlFzRMmoOGCuV 3VXKDlCu0KDlChRaDmmuYo1Cg5ormijUKAuihoo1CgLooaKNQoC6KGihmu6qDmihooZruqg5 oruihqoaqAaKGihqruaDnKrvLrmqhroO8uhormqhqoD8qhyqJrruaA/Locuua67mgHLrvJrm aeMWbl8pobkEw0DXk13k1dYXhtccmbS3O0KPkdTFRt2WVclsG0ybHJdh5qI6yYoK5yqHJouq ua6A/Jocmk9dG10CnINXez0lzaHNoFezDXeQNJcyhzqBXs1Ds/ypHm13mUC3ZqHI+VIc2hza BxyPlQ5HypDmDXebQL8iu9mGm3OrvOoHPZjelDsxvMKQ51F5tA67J6hXOzG9KbazUbWagX7G bzCh2Q3pSGs1DmGoF+yG9KHYx9KR5tDm0C/Yx9K52MfSkebQ11IW7H8q72P5Uhroa6oLdj+V d7D8qQ10NdAp2P5Ums20UNZqGupCPLNR9BqPrruugsnDkpfpUz19Mj/CkJ5Vv7QcAj/xDfxG krRU0XEzN+//AIVGSRsvlv75v41HzUMXRq+L86VccnYUz970qPKUw/DT9aJkGjftTloqmj9s Q2q0vQy3Dm6g/wDpZvu6/fTNaw7nJ/8AR1x88V6bR/d8vvpX/mGvz8v4nOL3cq8rmtCcIbSe LcB/y0gpbkuT/wCmuv8A2V6y/CuaCfZD8Aq/xT6Ocq8YXhFv0YFdU7NdIClz3y4rKjV7X/SO R/8A4rkNBC5wOcBjbFeLTF7ofIK+pw1/di8ko4yNcUSnNE0160kcUKU00NNAjXKWxRaBOi0r iuaaBOhStc00CdClaLigJQo9coE6FKaaFAnQpSi0BK7RqFAWuV2hQcoV2uUBaNQoUAotGotA KFChQCjFotGoHkegLt0VEn1vHyDzrQYtqkzRBJIMf41WbBIBpBfV4Jhj8auTgug3c6Vhdl7B 43cnD6wh8hqbRl1uz8lY3OSHYSH3AQ8aqHPOBu+QQCn6K5+x87FYCkX9EJR8hz2oYbr7gH2T eVVetH4gB/2b5pw3IcohnzEazg1eq34HKFCi1oDUKFCgFChXaDlChXaDldoUKAUKFCgFGoUK AUKFCgP/ACGN651rUuBslHW1LJTLyKSkMgP7QoDjw28M0Xjs7h5uQLNRcYlHKCbSciWwGCoz 9hltHolPoluC75NM/TORqw01E+1Rq9FN560j8PSwC9rNcgX9rywznzz1yNefJRAjaQXQSNlM px0fLyqIzyCFc2DvGotadwXfx9vyBZp9DpSeCjpIfcAHzD1rozPUBulcrUOMz6Fnk0pdhDpx joPjIToYKy+uRlkBSzdM6ygEIGoxugBSNWexdaLrtiRcnJ09K76Rav1C8Tvo+nNeyW4JH3Kl zw14+X3VnMkxeRr5Ri/bGbukhwdM/UK9COr7uFs3Qanfq8tqQBIlq2ERDp6Vl3E58WZ5UoqX Dn4TeteWHEZyFDoUKFeoTNpk5s8zLqxlUAzVyU4Xv1HRx7YjpE2c1V7BS5l1RxPNWt8UUSbJ qdMlqJyxFHtvhiDB8m7kFgWKTvaS0XjQsXlsIsmPeH+Hb4Q/kKjJ6+JDtyrbncoue6YPEPOq eo+drzCS3OFUSm1F1jkP9KzjKUq9Vbb6CuklEVMfVzShd6lphp10+NQSJ9CnJPtXwOLs+73W L3sfaaGmlih3e7XNNeGL1KDx0ado4byRf/LGvDun3YfKvoFxAZ9stGRR/wDJHavBDxEyayiP 2DiX86/QfwyXY+Zf9SNMFJ4p0YtJ6a+mwNqGmnGK5prob4ouml9NcxQIYoYpbTQ00CNc00rQ oEtNdo9FoCYotKUWgLXKPRaDlChQoC1yj0KoEotHoVIJQo+K5VAtCjUWgLQo1CgLQo1CgFCh RqCZtN32SS1D0OGk1aK3J+e9ZIU2mrNC3IdsXlr5MUPHxrzXYKi0DkkOYNZQEPKpfWnpACol DTVLRuqN094+BptKX2BERJHp6lPA5ugV5sZOicWpIn9Hi0v2gm5qunwAA2Cs/pZwqq4WM4cH FRQ+4mGiV7bccYoJUau0K1BMUbTXaNQE00NNHrtSCYoYpWhigSxQxS9c00CWmhppbFCgR00N NLV3TQI4rmml9NDTQPYmVcsO6TdPyGk5SQcSJtSnQOgBTbTQ01wJaaUbnO3WBVLqWu6aNign fpW/M35eADbGraq8oJjmE59xGlNFDFAhUvCzbmMLpIAKJ9dA1G6aNigdzEq5ksa9i+BajdNK 0KBLTUtb8oaNU8yjUdQoLo6uVJx705tQ4+VVaUfneG/8sOgU0rlZxtRiC0au0Ytai18L0eZd jT90RN+VavPWweW98g4URXKXu77G9Bqp/o+xR1pxxJKkHkJJgUDY2ERGt3Rbk+qUPwr5vHcX hXRtbtZdXnCci3DA3ZphgYPI2n4g8wqvQsJJSSyxodEVRSybQPXH+NernUa2XT0LtklS/vlr jeFjEVAWbs0kD+ZAAK80f4nFvsvQaxNdVaYbCCgn3yFW2mb5uVQtem9F5FejXJT+6HY1SNQz xE7dbmB9UfvqRj3RHCYf8QPir4l23g90bmQzprzGqqJ+ioafuryxxc4NTTaYXfwrcV0VREwk KG33V6x+PekzAbV934Vpw1/aTOO48DqWHdhc5g3e2w92mxrHuf8A8Dd/hXv3R07oD9wUzWJ3 vgL6bBXu/E/ojlng36EXP/4I7/8AbXfoJdPT2I6/CvbM9JxsOnzXjtJApQ+8QrK57isd8sLO 149R2obJQPp/Oqjx05ezPaedXFlXC3LrcxiyIeZwxUb7FfGNyiIKKKfZKGRr0a1sm7LjUBzc sgLJLqKYdceXp4VbYu1YKELoZMwE3/FU7xhGrl/EMTYeWS2Lc5k9YRK++++21D6B3P8A+GK1 6vWJqNq+6mDgn4Vj+Jyacs8uGsK5v/DjUT6B3F/9iP416TeEqGknKTYonWPpAMAIjV/iEjYY L9Abh/8AtKjnVtvW63JOUOZ5BvWqSEy+mFBZxCWlPoJ6koG3EWmFVvfOB31Dvit+cl7p2mTt 7DnXBcg3xtnA9aX/AFdTu3uthrbykx/CiVl+ISVsMV/VvOeRKH6uJv4e55/dW0qEopQqeemr YYz+rea+sZMKN+rSY6a062TTQpz0zYY1+reVD4jl/Cufq6kimxzkq2A1IlJ3qrnZp2mVF4aS hv8A5gnTbau/q0kP/uUw+YVremi1POTNqLJ/1Zv/AP7tPbrgKH6sn2/9OT/9taxSJjVXN3Da YtdFnOISNB4quVQBOBMAGN6gCsNUGpKatir8nH3da1ziUTmWm4N/wjlP+dZzC6FrVuRkcwAZ MpXCWrz9K91i7KUNWEoqqY1F10XOe9Ra9bMfXXebSVCgV5tDm0lXaBcp60tjw67SxauQkdl0 ynDBfMKy8tbdwvlUVrTRIs4KCjc5k8GHfFebiZVjHo0iiv1a/akv/wBa4bhn/wD7H8qvvb2X /wByn+NcM/ZfD2lP8a+fzV1rtMmvS0iW9EpvDvOYKqnLITHjVI51X/jRJJuZBmxQOBk25BUM IfaNWc19LhpSlDuYSKc6u86kKFbpL86hzqSoUCvNpZM2aa1JW+l2iYZttWOYuUBH76VGpR/C xJRm3VcSBk1FEwOIAXpkKdfqoZ/+Kq9fs1fU12491NZPugAYAQp1t4V8OXGXXr2os4/VM00/ 7zV3/crv6qGm39bqfLRWj/4UYtZ85dVsxZr+qhtq2lFPUdNd/VQ28JY3/srTaTL8VOcup2ma /qobf+Kqb/uV39VDbf8Arcwf8laZooaac5dVsxZn+qhD/wAVN037tD9VKP8A4qO/7laYYKJT nLpsxZoXhWibP9amyH7lD9ViHT2mb/2VpIeNFpzd02Ys3/Vahv8A1qYN+milk+FDcTZ9rG// AB9K0Klk8U5y6bMWe/qfb7f10p/+PwpyXgu3P/8AWzf/AI60VE2MU+TNWfOXndmLLf1Jof8A jg+X7OjfqWbb/wBdm+5OtaT71KVl+IXlbEWPfqVb/wDjZsf+nSn6kmm/9dmyH/l1rmmlSkp+ IXjYgx39SbMf/rKv/sofqRQ0/wC/Df8A462MpC1zTU/iV42Ise/Uiz0/78U//FmjfqTY/WmF cY+x41r2K6YKr8QvfubEWSl4JxAY1yy4/wDL0qRZ8G7cRMB3Cy6/pmtJ5OrNdrnPXv3VsQNI WLZxjMrZiiCSQeH+dSNBMKW096vHKWrXFzHdpRMtcpWpU//Z --------------090008060702010503060703 Content-Type: text/plain; name="kernel-config" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="kernel-config" # # Automatically generated make config: don't edit # Linux kernel version: 2.6.23.12 # Mon Mar 3 10:25:53 2008 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_QUICKLIST=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y # CONFIG_SWAP is not set CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_USER_NS is not set # CONFIG_AUDIT is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=15 # CONFIG_CPUSETS is not set CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y CONFIG_EMBEDDED=y # CONFIG_UID16 is not set # CONFIG_SYSCTL_SYSCALL is not set CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y # CONFIG_ELF_CORE is not set CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_EVENTFD=y # CONFIG_SHMEM is not set CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set CONFIG_RT_MUTEXES=y CONFIG_TINY_SHMEM=y CONFIG_BASE_SMALL=0 # CONFIG_MODULES is not set CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y CONFIG_LBD=y # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # CONFIG_BLK_DEV_BSG is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y # CONFIG_IOSCHED_AS is not set CONFIG_IOSCHED_DEADLINE=y # CONFIG_IOSCHED_CFQ is not set # CONFIG_DEFAULT_AS is not set CONFIG_DEFAULT_DEADLINE=y # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="deadline" # # Processor type and features # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_SMP=y CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_PARAVIRT is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MCORE2 is not set CONFIG_MPENTIUM4=y # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_MVIAC7 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_X86_XADD=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_TSC=y CONFIG_X86_CMOV=y CONFIG_X86_MINIMUM_CPU_FAMILY=4 CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y CONFIG_NR_CPUS=8 CONFIG_SCHED_SMT=y CONFIG_SCHED_MC=y CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT is not set # CONFIG_PREEMPT_BKL is not set CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y # CONFIG_X86_MCE is not set # CONFIG_VM86 is not set # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set # CONFIG_X86_REBOOTFIXUPS is not set # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set # # Firmware Drivers # # CONFIG_EDD is not set # CONFIG_DELL_RBU is not set # CONFIG_DCDBAS is not set CONFIG_DMIID=y # CONFIG_NOHIGHMEM is not set # CONFIG_HIGHMEM4G is not set CONFIG_HIGHMEM64G=y # CONFIG_VMSPLIT_3G is not set # CONFIG_VMSPLIT_3G_OPT is not set CONFIG_VMSPLIT_2G=y # CONFIG_VMSPLIT_2G_OPT is not set # CONFIG_VMSPLIT_1G is not set CONFIG_PAGE_OFFSET=0x80000000 CONFIG_HIGHMEM=y CONFIG_X86_PAE=y CONFIG_ARCH_FLATMEM_ENABLE=y CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_ARCH_SELECT_MEMORY_MODEL=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y # CONFIG_DISCONTIGMEM_MANUAL is not set # CONFIG_SPARSEMEM_MANUAL is not set CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y CONFIG_SPARSEMEM_STATIC=y CONFIG_SPLIT_PTLOCK_CPUS=4 CONFIG_RESOURCES_64BIT=y CONFIG_ZONE_DMA_FLAG=1 CONFIG_BOUNCE=y CONFIG_NR_QUICK=1 CONFIG_VIRT_TO_BUS=y CONFIG_HIGHPTE=y # CONFIG_MATH_EMULATION is not set # CONFIG_MTRR is not set # CONFIG_EFI is not set # CONFIG_IRQBALANCE is not set # CONFIG_SECCOMP is not set # CONFIG_HZ_100 is not set # CONFIG_HZ_250 is not set CONFIG_HZ_300=y # CONFIG_HZ_1000 is not set CONFIG_HZ=300 # CONFIG_KEXEC is not set # CONFIG_CRASH_DUMP is not set CONFIG_PHYSICAL_START=0x100000 # CONFIG_RELOCATABLE is not set CONFIG_PHYSICAL_ALIGN=0x100000 CONFIG_HOTPLUG_CPU=y # CONFIG_COMPAT_VDSO is not set CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y # # Power management options (ACPI, APM) # CONFIG_PM=y # CONFIG_PM_LEGACY is not set # CONFIG_PM_DEBUG is not set CONFIG_SUSPEND_SMP_POSSIBLE=y # CONFIG_SUSPEND is not set CONFIG_HIBERNATION_SMP_POSSIBLE=y CONFIG_ACPI=y # CONFIG_ACPI_PROCFS is not set CONFIG_ACPI_PROC_EVENT=y # CONFIG_ACPI_AC is not set # CONFIG_ACPI_BATTERY is not set CONFIG_ACPI_BUTTON=y CONFIG_ACPI_FAN=y # CONFIG_ACPI_DOCK is not set CONFIG_ACPI_PROCESSOR=y CONFIG_ACPI_HOTPLUG_CPU=y CONFIG_ACPI_THERMAL=y # CONFIG_ACPI_ASUS is not set # CONFIG_ACPI_TOSHIBA is not set # CONFIG_ACPI_CUSTOM_DSDT is not set CONFIG_ACPI_BLACKLIST_YEAR=0 # CONFIG_ACPI_DEBUG is not set CONFIG_ACPI_EC=y CONFIG_ACPI_POWER=y CONFIG_ACPI_SYSTEM=y CONFIG_X86_PM_TIMER=y CONFIG_ACPI_CONTAINER=y # CONFIG_ACPI_SBS is not set # # CPU Frequency scaling # # CONFIG_CPU_FREQ is not set # # Bus options (PCI, PCMCIA, EISA, MCA, ISA) # CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GOMMCONFIG is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_MMCONFIG=y CONFIG_PCIEPORTBUS=y CONFIG_PCIEAER=y CONFIG_ARCH_SUPPORTS_MSI=y CONFIG_PCI_MSI=y # CONFIG_PCI_DEBUG is not set CONFIG_HT_IRQ=y CONFIG_ISA_DMA_API=y # CONFIG_ISA is not set # CONFIG_MCA is not set # CONFIG_SCx200 is not set # # PCCARD (PCMCIA/CardBus) support # # CONFIG_PCCARD is not set # CONFIG_HOTPLUG_PCI is not set # # Executable file formats # CONFIG_BINFMT_ELF=y # CONFIG_BINFMT_AOUT is not set # CONFIG_BINFMT_MISC is not set # # Networking # CONFIG_NET=y # # Networking options # CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_UNIX=y # CONFIG_NET_KEY is not set CONFIG_INET=y # CONFIG_IP_MULTICAST is not set # CONFIG_IP_ADVANCED_ROUTER is not set CONFIG_IP_FIB_HASH=y # CONFIG_IP_PNP is not set # CONFIG_NET_IPIP is not set # CONFIG_NET_IPGRE is not set # CONFIG_ARPD is not set # CONFIG_SYN_COOKIES is not set # CONFIG_INET_AH is not set # CONFIG_INET_ESP is not set # CONFIG_INET_IPCOMP is not set # CONFIG_INET_XFRM_TUNNEL is not set # CONFIG_INET_TUNNEL is not set # CONFIG_INET_XFRM_MODE_TRANSPORT is not set # CONFIG_INET_XFRM_MODE_TUNNEL is not set # CONFIG_INET_XFRM_MODE_BEET is not set CONFIG_INET_DIAG=y CONFIG_INET_TCP_DIAG=y # CONFIG_TCP_CONG_ADVANCED is not set CONFIG_TCP_CONG_CUBIC=y CONFIG_DEFAULT_TCP_CONG="cubic" # CONFIG_TCP_MD5SIG is not set # CONFIG_IPV6 is not set # CONFIG_INET6_XFRM_TUNNEL is not set # CONFIG_INET6_TUNNEL is not set # CONFIG_NETWORK_SECMARK is not set # CONFIG_NETFILTER is not set # CONFIG_IP_DCCP is not set # CONFIG_IP_SCTP is not set # CONFIG_TIPC is not set # CONFIG_ATM is not set # CONFIG_BRIDGE is not set # CONFIG_VLAN_8021Q is not set # CONFIG_DECNET is not set # CONFIG_LLC2 is not set # CONFIG_IPX is not set # CONFIG_ATALK is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set # # QoS and/or fair queueing # # CONFIG_NET_SCHED is not set # # Network testing # # CONFIG_NET_PKTGEN is not set # CONFIG_HAMRADIO is not set # CONFIG_IRDA is not set # CONFIG_BT is not set # CONFIG_AF_RXRPC is not set # # Wireless # # CONFIG_CFG80211 is not set # CONFIG_WIRELESS_EXT is not set # CONFIG_MAC80211 is not set # CONFIG_IEEE80211 is not set # CONFIG_RFKILL is not set # CONFIG_NET_9P is not set # # Device Drivers # # # Generic Driver Options # # CONFIG_STANDALONE is not set # CONFIG_PREVENT_FIRMWARE_BUILD is not set # CONFIG_FW_LOADER is not set # CONFIG_DEBUG_DRIVER is not set # CONFIG_DEBUG_DEVRES is not set # CONFIG_SYS_HYPERVISOR is not set # CONFIG_CONNECTOR is not set # CONFIG_MTD is not set # CONFIG_PARPORT is not set CONFIG_PNP=y # CONFIG_PNP_DEBUG is not set # # Protocols # CONFIG_PNPACPI=y CONFIG_BLK_DEV=y # CONFIG_BLK_DEV_FD is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_UMEM is not set # CONFIG_BLK_DEV_COW_COMMON is not set CONFIG_BLK_DEV_LOOP=y # CONFIG_BLK_DEV_CRYPTOLOOP is not set # CONFIG_BLK_DEV_NBD is not set # CONFIG_BLK_DEV_SX8 is not set # CONFIG_BLK_DEV_UB is not set CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_COUNT=16 CONFIG_BLK_DEV_RAM_SIZE=4096 CONFIG_BLK_DEV_RAM_BLOCKSIZE=1024 # CONFIG_CDROM_PKTCDVD is not set # CONFIG_ATA_OVER_ETH is not set # CONFIG_MISC_DEVICES is not set CONFIG_IDE=y CONFIG_IDE_MAX_HWIFS=4 CONFIG_BLK_DEV_IDE=y # # Please see Documentation/ide.txt for help/info on IDE drives # # CONFIG_BLK_DEV_IDE_SATA is not set # CONFIG_BLK_DEV_HD_IDE is not set CONFIG_BLK_DEV_IDEDISK=y CONFIG_IDEDISK_MULTI_MODE=y # CONFIG_BLK_DEV_IDECD is not set # CONFIG_BLK_DEV_IDETAPE is not set # CONFIG_BLK_DEV_IDEFLOPPY is not set # CONFIG_BLK_DEV_IDESCSI is not set # CONFIG_BLK_DEV_IDEACPI is not set # CONFIG_IDE_TASK_IOCTL is not set CONFIG_IDE_PROC_FS=y # # IDE chipset support/bugfixes # CONFIG_IDE_GENERIC=y # CONFIG_BLK_DEV_CMD640 is not set # CONFIG_BLK_DEV_IDEPNP is not set CONFIG_BLK_DEV_IDEPCI=y CONFIG_IDEPCI_SHARE_IRQ=y CONFIG_IDEPCI_PCIBUS_ORDER=y # CONFIG_BLK_DEV_OFFBOARD is not set CONFIG_BLK_DEV_GENERIC=y # CONFIG_BLK_DEV_OPTI621 is not set # CONFIG_BLK_DEV_RZ1000 is not set CONFIG_BLK_DEV_IDEDMA_PCI=y # CONFIG_BLK_DEV_IDEDMA_FORCED is not set # CONFIG_IDEDMA_ONLYDISK is not set # CONFIG_BLK_DEV_AEC62XX is not set # CONFIG_BLK_DEV_ALI15X3 is not set # CONFIG_BLK_DEV_AMD74XX is not set # CONFIG_BLK_DEV_ATIIXP is not set # CONFIG_BLK_DEV_CMD64X is not set # CONFIG_BLK_DEV_TRIFLEX is not set # CONFIG_BLK_DEV_CY82C693 is not set # CONFIG_BLK_DEV_CS5520 is not set # CONFIG_BLK_DEV_CS5530 is not set # CONFIG_BLK_DEV_CS5535 is not set # CONFIG_BLK_DEV_HPT34X is not set # CONFIG_BLK_DEV_HPT366 is not set # CONFIG_BLK_DEV_JMICRON is not set # CONFIG_BLK_DEV_SC1200 is not set CONFIG_BLK_DEV_PIIX=y # CONFIG_BLK_DEV_IT8213 is not set # CONFIG_BLK_DEV_IT821X is not set # CONFIG_BLK_DEV_NS87415 is not set # CONFIG_BLK_DEV_PDC202XX_OLD is not set # CONFIG_BLK_DEV_PDC202XX_NEW is not set # CONFIG_BLK_DEV_SVWKS is not set # CONFIG_BLK_DEV_SIIMAGE is not set # CONFIG_BLK_DEV_SIS5513 is not set # CONFIG_BLK_DEV_SLC90E66 is not set # CONFIG_BLK_DEV_TRM290 is not set # CONFIG_BLK_DEV_VIA82CXXX is not set # CONFIG_BLK_DEV_TC86C001 is not set # CONFIG_IDE_ARM is not set CONFIG_BLK_DEV_IDEDMA=y # CONFIG_IDEDMA_IVB is not set # CONFIG_BLK_DEV_HD is not set # # SCSI device support # # CONFIG_RAID_ATTRS is not set CONFIG_SCSI=y CONFIG_SCSI_DMA=y # CONFIG_SCSI_TGT is not set # CONFIG_SCSI_NETLINK is not set CONFIG_SCSI_PROC_FS=y # # SCSI support type (disk, tape, CD-ROM) # CONFIG_BLK_DEV_SD=y # CONFIG_CHR_DEV_ST is not set # CONFIG_CHR_DEV_OSST is not set # CONFIG_BLK_DEV_SR is not set CONFIG_CHR_DEV_SG=y # CONFIG_CHR_DEV_SCH is not set # # Some SCSI devices (e.g. CD jukebox) support multiple LUNs # # CONFIG_SCSI_MULTI_LUN is not set # CONFIG_SCSI_CONSTANTS is not set # CONFIG_SCSI_LOGGING is not set # CONFIG_SCSI_SCAN_ASYNC is not set # # SCSI Transports # # CONFIG_SCSI_SPI_ATTRS is not set # CONFIG_SCSI_FC_ATTRS is not set # CONFIG_SCSI_ISCSI_ATTRS is not set # CONFIG_SCSI_SAS_LIBSAS is not set CONFIG_SCSI_LOWLEVEL=y # CONFIG_ISCSI_TCP is not set # CONFIG_BLK_DEV_3W_XXXX_RAID is not set CONFIG_SCSI_3W_9XXX=y # CONFIG_SCSI_ACARD is not set # CONFIG_SCSI_AACRAID is not set # CONFIG_SCSI_AIC7XXX is not set # CONFIG_SCSI_AIC7XXX_OLD is not set # CONFIG_SCSI_AIC79XX is not set # CONFIG_SCSI_AIC94XX is not set # CONFIG_SCSI_DPT_I2O is not set # CONFIG_SCSI_ADVANSYS is not set # CONFIG_SCSI_ARCMSR is not set # CONFIG_MEGARAID_NEWGEN is not set # CONFIG_MEGARAID_LEGACY is not set # CONFIG_MEGARAID_SAS is not set # CONFIG_SCSI_HPTIOP is not set # CONFIG_SCSI_BUSLOGIC is not set # CONFIG_SCSI_DMX3191D is not set # CONFIG_SCSI_EATA is not set # CONFIG_SCSI_FUTURE_DOMAIN is not set # CONFIG_SCSI_GDTH is not set # CONFIG_SCSI_IPS is not set # CONFIG_SCSI_INITIO is not set # CONFIG_SCSI_INIA100 is not set # CONFIG_SCSI_STEX is not set # CONFIG_SCSI_SYM53C8XX_2 is not set # CONFIG_SCSI_IPR is not set # CONFIG_SCSI_QLOGIC_1280 is not set # CONFIG_SCSI_QLA_FC is not set # CONFIG_SCSI_QLA_ISCSI is not set # CONFIG_SCSI_LPFC is not set # CONFIG_SCSI_DC395x is not set # CONFIG_SCSI_DC390T is not set # CONFIG_SCSI_NSP32 is not set # CONFIG_SCSI_DEBUG is not set # CONFIG_SCSI_SRP is not set CONFIG_ATA=y # CONFIG_ATA_NONSTANDARD is not set CONFIG_ATA_ACPI=y CONFIG_SATA_AHCI=y # CONFIG_SATA_SVW is not set # CONFIG_ATA_PIIX is not set # CONFIG_SATA_MV is not set # CONFIG_SATA_NV is not set # CONFIG_PDC_ADMA is not set # CONFIG_SATA_QSTOR is not set # CONFIG_SATA_PROMISE is not set # CONFIG_SATA_SX4 is not set # CONFIG_SATA_SIL is not set # CONFIG_SATA_SIL24 is not set # CONFIG_SATA_SIS is not set # CONFIG_SATA_ULI is not set # CONFIG_SATA_VIA is not set # CONFIG_SATA_VITESSE is not set # CONFIG_SATA_INIC162X is not set # CONFIG_PATA_ALI is not set # CONFIG_PATA_AMD is not set # CONFIG_PATA_ARTOP is not set # CONFIG_PATA_ATIIXP is not set # CONFIG_PATA_CMD640_PCI is not set # CONFIG_PATA_CMD64X is not set # CONFIG_PATA_CS5520 is not set # CONFIG_PATA_CS5530 is not set # CONFIG_PATA_CS5535 is not set # CONFIG_PATA_CYPRESS is not set # CONFIG_PATA_EFAR is not set # CONFIG_ATA_GENERIC is not set # CONFIG_PATA_HPT366 is not set # CONFIG_PATA_HPT37X is not set # CONFIG_PATA_HPT3X2N is not set # CONFIG_PATA_HPT3X3 is not set # CONFIG_PATA_IT821X is not set # CONFIG_PATA_IT8213 is not set # CONFIG_PATA_JMICRON is not set # CONFIG_PATA_TRIFLEX is not set # CONFIG_PATA_MARVELL is not set # CONFIG_PATA_MPIIX is not set # CONFIG_PATA_OLDPIIX is not set # CONFIG_PATA_NETCELL is not set # CONFIG_PATA_NS87410 is not set # CONFIG_PATA_OPTI is not set # CONFIG_PATA_OPTIDMA is not set # CONFIG_PATA_PDC_OLD is not set # CONFIG_PATA_RADISYS is not set # CONFIG_PATA_RZ1000 is not set # CONFIG_PATA_SC1200 is not set # CONFIG_PATA_SERVERWORKS is not set # CONFIG_PATA_PDC2027X is not set # CONFIG_PATA_SIL680 is not set # CONFIG_PATA_SIS is not set # CONFIG_PATA_VIA is not set # CONFIG_PATA_WINBOND is not set # CONFIG_PATA_PLATFORM is not set CONFIG_MD=y CONFIG_BLK_DEV_MD=y CONFIG_MD_LINEAR=y CONFIG_MD_RAID0=y CONFIG_MD_RAID1=y CONFIG_MD_RAID10=y CONFIG_MD_RAID456=y CONFIG_MD_RAID5_RESHAPE=y # CONFIG_MD_MULTIPATH is not set # CONFIG_MD_FAULTY is not set # CONFIG_BLK_DEV_DM is not set # # Fusion MPT device support # # CONFIG_FUSION is not set # CONFIG_FUSION_SPI is not set # CONFIG_FUSION_FC is not set # CONFIG_FUSION_SAS is not set # # IEEE 1394 (FireWire) support # # CONFIG_FIREWIRE is not set # CONFIG_IEEE1394 is not set # CONFIG_I2O is not set # CONFIG_MACINTOSH_DRIVERS is not set CONFIG_NETDEVICES=y # CONFIG_NETDEVICES_MULTIQUEUE is not set # CONFIG_DUMMY is not set CONFIG_BONDING=y # CONFIG_MACVLAN is not set # CONFIG_EQUALIZER is not set # CONFIG_TUN is not set # CONFIG_NET_SB1000 is not set # CONFIG_ARCNET is not set # CONFIG_NET_ETHERNET is not set CONFIG_NETDEV_1000=y # CONFIG_ACENIC is not set # CONFIG_DL2K is not set CONFIG_E1000=y CONFIG_E1000_NAPI=y # CONFIG_E1000_DISABLE_PACKET_SPLIT is not set # CONFIG_NS83820 is not set # CONFIG_HAMACHI is not set # CONFIG_YELLOWFIN is not set # CONFIG_R8169 is not set # CONFIG_SIS190 is not set # CONFIG_SKGE is not set # CONFIG_SKY2 is not set # CONFIG_SK98LIN is not set # CONFIG_VIA_VELOCITY is not set # CONFIG_TIGON3 is not set # CONFIG_BNX2 is not set # CONFIG_QLA3XXX is not set # CONFIG_ATL1 is not set # CONFIG_NETDEV_10000 is not set # CONFIG_TR is not set # # Wireless LAN # # CONFIG_WLAN_PRE80211 is not set # CONFIG_WLAN_80211 is not set # # USB Network Adapters # # CONFIG_USB_CATC is not set # CONFIG_USB_KAWETH is not set # CONFIG_USB_PEGASUS is not set # CONFIG_USB_RTL8150 is not set # CONFIG_USB_USBNET_MII is not set # CONFIG_USB_USBNET is not set # CONFIG_WAN is not set # CONFIG_FDDI is not set # CONFIG_HIPPI is not set # CONFIG_PPP is not set # CONFIG_SLIP is not set # CONFIG_NET_FC is not set # CONFIG_SHAPER is not set # CONFIG_NETCONSOLE is not set # CONFIG_NETPOLL is not set # CONFIG_NET_POLL_CONTROLLER is not set # CONFIG_ISDN is not set # CONFIG_PHONE is not set # # Input device support # CONFIG_INPUT=y # CONFIG_INPUT_FF_MEMLESS is not set # CONFIG_INPUT_POLLDEV is not set # # Userland interfaces # CONFIG_INPUT_MOUSEDEV=y # CONFIG_INPUT_MOUSEDEV_PSAUX is not set CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 # CONFIG_INPUT_JOYDEV is not set # CONFIG_INPUT_TSDEV is not set # CONFIG_INPUT_EVDEV is not set # CONFIG_INPUT_EVBUG is not set # # Input Device Drivers # CONFIG_INPUT_KEYBOARD=y CONFIG_KEYBOARD_ATKBD=y # CONFIG_KEYBOARD_SUNKBD is not set # CONFIG_KEYBOARD_LKKBD is not set # CONFIG_KEYBOARD_XTKBD is not set # CONFIG_KEYBOARD_NEWTON is not set # CONFIG_KEYBOARD_STOWAWAY is not set # CONFIG_INPUT_MOUSE is not set # CONFIG_INPUT_JOYSTICK is not set # CONFIG_INPUT_TABLET is not set # CONFIG_INPUT_TOUCHSCREEN is not set # CONFIG_INPUT_MISC is not set # # Hardware I/O ports # CONFIG_SERIO=y CONFIG_SERIO_I8042=y # CONFIG_SERIO_SERPORT is not set # CONFIG_SERIO_CT82C710 is not set # CONFIG_SERIO_PCIPS2 is not set CONFIG_SERIO_LIBPS2=y # CONFIG_SERIO_RAW is not set # CONFIG_GAMEPORT is not set # # Character devices # CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y # CONFIG_VT_HW_CONSOLE_BINDING is not set # CONFIG_SERIAL_NONSTANDARD is not set # # Serial drivers # CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_FIX_EARLYCON_MEM=y CONFIG_SERIAL_8250_PCI=y CONFIG_SERIAL_8250_PNP=y CONFIG_SERIAL_8250_NR_UARTS=4 CONFIG_SERIAL_8250_RUNTIME_UARTS=4 CONFIG_SERIAL_8250_EXTENDED=y # CONFIG_SERIAL_8250_MANY_PORTS is not set CONFIG_SERIAL_8250_SHARE_IRQ=y # CONFIG_SERIAL_8250_DETECT_IRQ is not set # CONFIG_SERIAL_8250_RSA is not set # # Non-8250 serial port support # CONFIG_SERIAL_CORE=y CONFIG_SERIAL_CORE_CONSOLE=y # CONFIG_SERIAL_JSM is not set CONFIG_UNIX98_PTYS=y CONFIG_LEGACY_PTYS=y CONFIG_LEGACY_PTY_COUNT=256 # CONFIG_IPMI_HANDLER is not set CONFIG_WATCHDOG=y # CONFIG_WATCHDOG_NOWAYOUT is not set # # Watchdog Device Drivers # CONFIG_SOFT_WATCHDOG=y # CONFIG_ACQUIRE_WDT is not set # CONFIG_ADVANTECH_WDT is not set # CONFIG_ALIM1535_WDT is not set # CONFIG_ALIM7101_WDT is not set # CONFIG_SC520_WDT is not set # CONFIG_EUROTECH_WDT is not set # CONFIG_IB700_WDT is not set # CONFIG_IBMASR is not set # CONFIG_WAFER_WDT is not set # CONFIG_I6300ESB_WDT is not set # CONFIG_ITCO_WDT is not set # CONFIG_SC1200_WDT is not set # CONFIG_PC87413_WDT is not set # CONFIG_60XX_WDT is not set # CONFIG_SBC8360_WDT is not set # CONFIG_CPU5_WDT is not set # CONFIG_SMSC37B787_WDT is not set # CONFIG_W83627HF_WDT is not set # CONFIG_W83697HF_WDT is not set # CONFIG_W83877F_WDT is not set # CONFIG_W83977F_WDT is not set # CONFIG_MACHZ_WDT is not set # CONFIG_SBC_EPX_C3_WATCHDOG is not set # # PCI-based Watchdog Cards # # CONFIG_PCIPCWATCHDOG is not set # CONFIG_WDTPCI is not set # # USB-based Watchdog Cards # # CONFIG_USBPCWATCHDOG is not set CONFIG_HW_RANDOM=y CONFIG_HW_RANDOM_INTEL=y # CONFIG_HW_RANDOM_AMD is not set # CONFIG_HW_RANDOM_GEODE is not set # CONFIG_HW_RANDOM_VIA is not set # CONFIG_NVRAM is not set CONFIG_RTC=y # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set # CONFIG_SONYPI is not set # CONFIG_AGP is not set # CONFIG_DRM is not set # CONFIG_MWAVE is not set # CONFIG_PC8736x_GPIO is not set # CONFIG_NSC_GPIO is not set # CONFIG_CS5535_GPIO is not set # CONFIG_RAW_DRIVER is not set # CONFIG_HPET is not set CONFIG_HANGCHECK_TIMER=y # CONFIG_TCG_TPM is not set # CONFIG_TELCLOCK is not set CONFIG_DEVPORT=y CONFIG_I2C=y CONFIG_I2C_BOARDINFO=y CONFIG_I2C_CHARDEV=y # # I2C Algorithms # # CONFIG_I2C_ALGOBIT is not set # CONFIG_I2C_ALGOPCF is not set # CONFIG_I2C_ALGOPCA is not set # # I2C Hardware Bus support # # CONFIG_I2C_ALI1535 is not set # CONFIG_I2C_ALI1563 is not set # CONFIG_I2C_ALI15X3 is not set # CONFIG_I2C_AMD756 is not set # CONFIG_I2C_AMD8111 is not set CONFIG_I2C_I801=y # CONFIG_I2C_I810 is not set # CONFIG_I2C_PIIX4 is not set # CONFIG_I2C_NFORCE2 is not set # CONFIG_I2C_OCORES is not set # CONFIG_I2C_PARPORT_LIGHT is not set # CONFIG_I2C_PROSAVAGE is not set # CONFIG_I2C_SAVAGE4 is not set # CONFIG_I2C_SIMTEC is not set # CONFIG_SCx200_ACB is not set # CONFIG_I2C_SIS5595 is not set # CONFIG_I2C_SIS630 is not set # CONFIG_I2C_SIS96X is not set # CONFIG_I2C_TAOS_EVM is not set # CONFIG_I2C_TINY_USB is not set # CONFIG_I2C_VIA is not set # CONFIG_I2C_VIAPRO is not set # CONFIG_I2C_VOODOO3 is not set # # Miscellaneous I2C Chip support # # CONFIG_SENSORS_DS1337 is not set # CONFIG_SENSORS_DS1374 is not set # CONFIG_DS1682 is not set CONFIG_SENSORS_EEPROM=y # CONFIG_SENSORS_PCF8574 is not set # CONFIG_SENSORS_PCA9539 is not set # CONFIG_SENSORS_PCF8591 is not set # CONFIG_SENSORS_MAX6875 is not set # CONFIG_SENSORS_TSL2550 is not set # CONFIG_I2C_DEBUG_CORE is not set # CONFIG_I2C_DEBUG_ALGO is not set # CONFIG_I2C_DEBUG_BUS is not set # CONFIG_I2C_DEBUG_CHIP is not set # # SPI support # # CONFIG_SPI is not set # CONFIG_SPI_MASTER is not set # CONFIG_W1 is not set # CONFIG_POWER_SUPPLY is not set CONFIG_HWMON=y CONFIG_HWMON_VID=y # CONFIG_SENSORS_ABITUGURU is not set # CONFIG_SENSORS_ABITUGURU3 is not set # CONFIG_SENSORS_AD7418 is not set # CONFIG_SENSORS_ADM1021 is not set # CONFIG_SENSORS_ADM1025 is not set # CONFIG_SENSORS_ADM1026 is not set # CONFIG_SENSORS_ADM1029 is not set # CONFIG_SENSORS_ADM1031 is not set # CONFIG_SENSORS_ADM9240 is not set # CONFIG_SENSORS_K8TEMP is not set # CONFIG_SENSORS_ASB100 is not set # CONFIG_SENSORS_ATXP1 is not set # CONFIG_SENSORS_DS1621 is not set # CONFIG_SENSORS_F71805F is not set # CONFIG_SENSORS_FSCHER is not set # CONFIG_SENSORS_FSCPOS is not set # CONFIG_SENSORS_GL518SM is not set # CONFIG_SENSORS_GL520SM is not set # CONFIG_SENSORS_CORETEMP is not set # CONFIG_SENSORS_IT87 is not set # CONFIG_SENSORS_LM63 is not set # CONFIG_SENSORS_LM75 is not set # CONFIG_SENSORS_LM77 is not set # CONFIG_SENSORS_LM78 is not set # CONFIG_SENSORS_LM80 is not set # CONFIG_SENSORS_LM83 is not set # CONFIG_SENSORS_LM85 is not set # CONFIG_SENSORS_LM87 is not set # CONFIG_SENSORS_LM90 is not set # CONFIG_SENSORS_LM92 is not set CONFIG_SENSORS_LM93=y # CONFIG_SENSORS_MAX1619 is not set # CONFIG_SENSORS_MAX6650 is not set # CONFIG_SENSORS_PC87360 is not set CONFIG_SENSORS_PC87427=y # CONFIG_SENSORS_SIS5595 is not set # CONFIG_SENSORS_DME1737 is not set # CONFIG_SENSORS_SMSC47M1 is not set # CONFIG_SENSORS_SMSC47M192 is not set # CONFIG_SENSORS_SMSC47B397 is not set # CONFIG_SENSORS_THMC50 is not set # CONFIG_SENSORS_VIA686A is not set # CONFIG_SENSORS_VT1211 is not set # CONFIG_SENSORS_VT8231 is not set # CONFIG_SENSORS_W83781D is not set # CONFIG_SENSORS_W83791D is not set # CONFIG_SENSORS_W83792D is not set CONFIG_SENSORS_W83793=y # CONFIG_SENSORS_W83L785TS is not set CONFIG_SENSORS_W83627HF=y CONFIG_SENSORS_W83627EHF=y # CONFIG_SENSORS_HDAPS is not set # CONFIG_SENSORS_APPLESMC is not set # CONFIG_HWMON_DEBUG_CHIP is not set # # Multifunction device drivers # # CONFIG_MFD_SM501 is not set # # Multimedia devices # # CONFIG_VIDEO_DEV is not set # CONFIG_DVB_CORE is not set # CONFIG_DAB is not set # # Graphics support # # CONFIG_BACKLIGHT_LCD_SUPPORT is not set # # Display device support # # CONFIG_DISPLAY_SUPPORT is not set # CONFIG_VGASTATE is not set # CONFIG_VIDEO_OUTPUT_CONTROL is not set # CONFIG_FB is not set # # Console display driver support # CONFIG_VGA_CONSOLE=y CONFIG_VGACON_SOFT_SCROLLBACK=y CONFIG_VGACON_SOFT_SCROLLBACK_SIZE=128 # CONFIG_VIDEO_SELECT is not set CONFIG_DUMMY_CONSOLE=y # # Sound # # CONFIG_SOUND is not set CONFIG_HID_SUPPORT=y CONFIG_HID=y # CONFIG_HID_DEBUG is not set # # USB Input Devices # CONFIG_USB_HID=y # CONFIG_USB_HIDINPUT_POWERBOOK is not set # CONFIG_HID_FF is not set # CONFIG_USB_HIDDEV is not set CONFIG_USB_SUPPORT=y CONFIG_USB_ARCH_HAS_HCD=y CONFIG_USB_ARCH_HAS_OHCI=y CONFIG_USB_ARCH_HAS_EHCI=y CONFIG_USB=y # CONFIG_USB_DEBUG is not set # # Miscellaneous USB options # CONFIG_USB_DEVICEFS=y # CONFIG_USB_DEVICE_CLASS is not set # CONFIG_USB_DYNAMIC_MINORS is not set # CONFIG_USB_SUSPEND is not set # CONFIG_USB_PERSIST is not set # CONFIG_USB_OTG is not set # # USB Host Controller Drivers # CONFIG_USB_EHCI_HCD=y CONFIG_USB_EHCI_SPLIT_ISO=y CONFIG_USB_EHCI_ROOT_HUB_TT=y CONFIG_USB_EHCI_TT_NEWSCHED=y # CONFIG_USB_ISP116X_HCD is not set # CONFIG_USB_OHCI_HCD is not set CONFIG_USB_UHCI_HCD=y # CONFIG_USB_SL811_HCD is not set # CONFIG_USB_R8A66597_HCD is not set # # USB Device Class drivers # # CONFIG_USB_ACM is not set # CONFIG_USB_PRINTER is not set # # NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support' # # # may also be needed; see USB_STORAGE Help for more information # CONFIG_USB_STORAGE=y # CONFIG_USB_STORAGE_DEBUG is not set CONFIG_USB_STORAGE_DATAFAB=y CONFIG_USB_STORAGE_FREECOM=y CONFIG_USB_STORAGE_ISD200=y CONFIG_USB_STORAGE_DPCM=y CONFIG_USB_STORAGE_USBAT=y CONFIG_USB_STORAGE_SDDR09=y CONFIG_USB_STORAGE_SDDR55=y CONFIG_USB_STORAGE_JUMPSHOT=y CONFIG_USB_STORAGE_ALAUDA=y # CONFIG_USB_STORAGE_KARMA is not set # CONFIG_USB_LIBUSUAL is not set # # USB Imaging devices # # CONFIG_USB_MDC800 is not set # CONFIG_USB_MICROTEK is not set # CONFIG_USB_MON is not set # # USB port drivers # # # USB Serial Converter support # # CONFIG_USB_SERIAL is not set # # USB Miscellaneous drivers # # CONFIG_USB_EMI62 is not set # CONFIG_USB_EMI26 is not set # CONFIG_USB_ADUTUX is not set # CONFIG_USB_AUERSWALD is not set # CONFIG_USB_RIO500 is not set # CONFIG_USB_LEGOTOWER is not set # CONFIG_USB_LCD is not set # CONFIG_USB_BERRY_CHARGE is not set # CONFIG_USB_LED is not set # CONFIG_USB_CYPRESS_CY7C63 is not set # CONFIG_USB_CYTHERM is not set # CONFIG_USB_PHIDGET is not set # CONFIG_USB_IDMOUSE is not set # CONFIG_USB_FTDI_ELAN is not set # CONFIG_USB_APPLEDISPLAY is not set # CONFIG_USB_SISUSBVGA is not set # CONFIG_USB_LD is not set # CONFIG_USB_TRANCEVIBRATOR is not set # CONFIG_USB_IOWARRIOR is not set # CONFIG_USB_TEST is not set # # USB DSL modem support # # # USB Gadget Support # # CONFIG_USB_GADGET is not set # CONFIG_MMC is not set # CONFIG_NEW_LEDS is not set # CONFIG_INFINIBAND is not set # CONFIG_EDAC is not set # CONFIG_RTC_CLASS is not set # # DMA Engine support # # CONFIG_DMA_ENGINE is not set # # DMA Clients # # # DMA Devices # # CONFIG_VIRTUALIZATION is not set # # Userspace I/O # # CONFIG_UIO is not set # # File systems # CONFIG_EXT2_FS=y # CONFIG_EXT2_FS_XATTR is not set # CONFIG_EXT2_FS_XIP is not set # CONFIG_EXT3_FS is not set # CONFIG_EXT4DEV_FS is not set # CONFIG_REISERFS_FS is not set # CONFIG_JFS_FS is not set # CONFIG_FS_POSIX_ACL is not set CONFIG_XFS_FS=y # CONFIG_XFS_QUOTA is not set # CONFIG_XFS_SECURITY is not set # CONFIG_XFS_POSIX_ACL is not set CONFIG_XFS_RT=y # CONFIG_GFS2_FS is not set # CONFIG_OCFS2_FS is not set # CONFIG_MINIX_FS is not set # CONFIG_ROMFS_FS is not set CONFIG_INOTIFY=y CONFIG_INOTIFY_USER=y # CONFIG_QUOTA is not set # CONFIG_DNOTIFY is not set # CONFIG_AUTOFS_FS is not set # CONFIG_AUTOFS4_FS is not set # CONFIG_FUSE_FS is not set # # CD-ROM/DVD Filesystems # # CONFIG_ISO9660_FS is not set # CONFIG_UDF_FS is not set # # DOS/FAT/NT Filesystems # CONFIG_FAT_FS=y CONFIG_MSDOS_FS=y CONFIG_VFAT_FS=y CONFIG_FAT_DEFAULT_CODEPAGE=437 CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1" # CONFIG_NTFS_FS is not set # # Pseudo filesystems # CONFIG_PROC_FS=y # CONFIG_PROC_KCORE is not set CONFIG_PROC_SYSCTL=y CONFIG_SYSFS=y CONFIG_TMPFS=y # CONFIG_TMPFS_POSIX_ACL is not set # CONFIG_HUGETLBFS is not set # CONFIG_HUGETLB_PAGE is not set CONFIG_RAMFS=y # CONFIG_CONFIGFS_FS is not set # # Miscellaneous filesystems # # CONFIG_ADFS_FS is not set # CONFIG_AFFS_FS is not set # CONFIG_HFS_FS is not set # CONFIG_HFSPLUS_FS is not set # CONFIG_BEFS_FS is not set # CONFIG_BFS_FS is not set # CONFIG_EFS_FS is not set # CONFIG_CRAMFS is not set # CONFIG_VXFS_FS is not set # CONFIG_HPFS_FS is not set # CONFIG_QNX4FS_FS is not set # CONFIG_SYSV_FS is not set # CONFIG_UFS_FS is not set # # Network File Systems # CONFIG_NFS_FS=y CONFIG_NFS_V3=y # CONFIG_NFS_V3_ACL is not set # CONFIG_NFS_V4 is not set # CONFIG_NFS_DIRECTIO is not set CONFIG_NFSD=y CONFIG_NFSD_V3=y # CONFIG_NFSD_V3_ACL is not set # CONFIG_NFSD_V4 is not set # CONFIG_NFSD_TCP is not set CONFIG_LOCKD=y CONFIG_LOCKD_V4=y CONFIG_EXPORTFS=y CONFIG_NFS_COMMON=y CONFIG_SUNRPC=y # CONFIG_SUNRPC_BIND34 is not set # CONFIG_RPCSEC_GSS_KRB5 is not set # CONFIG_RPCSEC_GSS_SPKM3 is not set # CONFIG_SMB_FS is not set # CONFIG_CIFS is not set # CONFIG_NCP_FS is not set # CONFIG_CODA_FS is not set # CONFIG_AFS_FS is not set # # Partition Types # # CONFIG_PARTITION_ADVANCED is not set CONFIG_MSDOS_PARTITION=y # # Native Language Support # CONFIG_NLS=y CONFIG_NLS_DEFAULT="iso8859-1" CONFIG_NLS_CODEPAGE_437=y # CONFIG_NLS_CODEPAGE_737 is not set # CONFIG_NLS_CODEPAGE_775 is not set CONFIG_NLS_CODEPAGE_850=y CONFIG_NLS_CODEPAGE_852=y # CONFIG_NLS_CODEPAGE_855 is not set # CONFIG_NLS_CODEPAGE_857 is not set # CONFIG_NLS_CODEPAGE_860 is not set # CONFIG_NLS_CODEPAGE_861 is not set # CONFIG_NLS_CODEPAGE_862 is not set # CONFIG_NLS_CODEPAGE_863 is not set # CONFIG_NLS_CODEPAGE_864 is not set # CONFIG_NLS_CODEPAGE_865 is not set # CONFIG_NLS_CODEPAGE_866 is not set # CONFIG_NLS_CODEPAGE_869 is not set # CONFIG_NLS_CODEPAGE_936 is not set # CONFIG_NLS_CODEPAGE_950 is not set # CONFIG_NLS_CODEPAGE_932 is not set # CONFIG_NLS_CODEPAGE_949 is not set # CONFIG_NLS_CODEPAGE_874 is not set # CONFIG_NLS_ISO8859_8 is not set # CONFIG_NLS_CODEPAGE_1250 is not set # CONFIG_NLS_CODEPAGE_1251 is not set CONFIG_NLS_ASCII=y CONFIG_NLS_ISO8859_1=y CONFIG_NLS_ISO8859_2=y # CONFIG_NLS_ISO8859_3 is not set # CONFIG_NLS_ISO8859_4 is not set # CONFIG_NLS_ISO8859_5 is not set # CONFIG_NLS_ISO8859_6 is not set # CONFIG_NLS_ISO8859_7 is not set # CONFIG_NLS_ISO8859_9 is not set # CONFIG_NLS_ISO8859_13 is not set # CONFIG_NLS_ISO8859_14 is not set CONFIG_NLS_ISO8859_15=y # CONFIG_NLS_KOI8_R is not set # CONFIG_NLS_KOI8_U is not set CONFIG_NLS_UTF8=y # # Distributed Lock Manager # # CONFIG_DLM is not set # CONFIG_INSTRUMENTATION is not set # # Kernel hacking # CONFIG_TRACE_IRQFLAGS_SUPPORT=y # CONFIG_PRINTK_TIME is not set # CONFIG_ENABLE_MUST_CHECK is not set CONFIG_MAGIC_SYSRQ=y # CONFIG_UNUSED_SYMBOLS is not set # CONFIG_DEBUG_FS is not set # CONFIG_HEADERS_CHECK is not set CONFIG_DEBUG_KERNEL=y # CONFIG_DEBUG_SHIRQ is not set CONFIG_DETECT_SOFTLOCKUP=y # CONFIG_SCHED_DEBUG is not set # CONFIG_SCHEDSTATS is not set # CONFIG_TIMER_STATS is not set # CONFIG_DEBUG_SLAB is not set CONFIG_DEBUG_RT_MUTEXES=y CONFIG_DEBUG_PI_LIST=y # CONFIG_RT_MUTEX_TESTER is not set # CONFIG_DEBUG_SPINLOCK is not set # CONFIG_DEBUG_MUTEXES is not set # CONFIG_DEBUG_LOCK_ALLOC is not set # CONFIG_PROVE_LOCKING is not set # CONFIG_LOCK_STAT is not set # CONFIG_DEBUG_SPINLOCK_SLEEP is not set # CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set # CONFIG_DEBUG_KOBJECT is not set # CONFIG_DEBUG_HIGHMEM is not set # CONFIG_DEBUG_BUGVERBOSE is not set CONFIG_DEBUG_INFO=y # CONFIG_DEBUG_VM is not set # CONFIG_DEBUG_LIST is not set CONFIG_FRAME_POINTER=y CONFIG_FORCED_INLINING=y # CONFIG_FAULT_INJECTION is not set CONFIG_EARLY_PRINTK=y CONFIG_DEBUG_STACKOVERFLOW=y # CONFIG_DEBUG_STACK_USAGE is not set # CONFIG_DEBUG_PAGEALLOC is not set # CONFIG_DEBUG_RODATA is not set # CONFIG_4KSTACKS is not set CONFIG_X86_FIND_SMP_CONFIG=y CONFIG_X86_MPPARSE=y CONFIG_DOUBLEFAULT=y CONFIG_KDB=y # CONFIG_KDB_MODULES is not set # CONFIG_KDB_OFF is not set CONFIG_KDB_CONTINUE_CATASTROPHIC=0 # # Security options # # CONFIG_KEYS is not set # CONFIG_SECURITY is not set CONFIG_XOR_BLOCKS=y CONFIG_ASYNC_CORE=y CONFIG_ASYNC_MEMCPY=y CONFIG_ASYNC_XOR=y # CONFIG_CRYPTO is not set # # Library routines # # CONFIG_CRC_CCITT is not set # CONFIG_CRC16 is not set # CONFIG_CRC_ITU_T is not set # CONFIG_CRC32 is not set # CONFIG_CRC7 is not set # CONFIG_LIBCRC32C is not set CONFIG_PLIST=y CONFIG_HAS_IOMEM=y CONFIG_HAS_IOPORT=y CONFIG_HAS_DMA=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_X86_SMP=y CONFIG_X86_HT=y CONFIG_X86_BIOS_REBOOT=y CONFIG_X86_TRAMPOLINE=y CONFIG_KTIME_SCALAR=y --------------090008060702010503060703-- From owner-xfs@oss.sgi.com Thu Mar 6 17:21:13 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 06 Mar 2008 17:21:34 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_50,UPPERCASE_50_75 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m271L7qM032067 for ; Thu, 6 Mar 2008 17:21:09 -0800 Received: from [134.15.251.7] (melb-sw-corp-251-7.corp.sgi.com [134.15.251.7]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA25686; Fri, 7 Mar 2008 12:21:27 +1100 Message-ID: <47D09840.3030203@sgi.com> Date: Fri, 07 Mar 2008 12:20:00 +1100 From: Mark Goodwin Reply-To: markgw@sgi.com Organization: SGI Engineering User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: Kris Kersey CC: xfs@oss.sgi.com, Bill Vaughan Subject: Re: pdflush hang on xlog_grant_log_space() References: <47D062AF.80501@steelbox.com> In-Reply-To: <47D062AF.80501@steelbox.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14791 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: markgw@sgi.com Precedence: bulk X-list: xfs Hi Kris, thanks for the report. We're digesting this and will get back to you. Cheers -- Mark Kris Kersey wrote: > Hello, > > I'm working on a NAS product and we're currently having lock-ups that > seem to be hanging in XFS code. We're running a NAS that has 1024 NFSD > threads accessing three RAID mounts. All three mounts are running XFS > file systems. Lately we've had random lockups on these boxes and I am > now running a kernel with KDB built-in. > > The lock-up takes the form of all NFSD threads in D state with one out > of three pdflush threads in D state. The assumption can be made that > all NFSD threads are waiting on the one pdflush thread to complete. So > two times now when an NAS has gotten in this state I have accessed KDB > and ran a stack trace on the pdflush thread. Both times the thread was > stuck on xlog_grant_log_space+0xdb. So now I'm turning to you to help > me figure out why XFS is locking up. The box has been left in this > state so I can run and KDB commands you wish or if you have any > questions about the setup, let me know. The system is running a mostly > stock 2.6.23.12 kernel. My config file as well as photos taken of the > stack dump are attached. > > Thanks, > Kris > > > ------------------------------------------------------------------------ > > > ------------------------------------------------------------------------ > > > ------------------------------------------------------------------------ > > # > # Automatically generated make config: don't edit > # Linux kernel version: 2.6.23.12 > # Mon Mar 3 10:25:53 2008 > # > CONFIG_X86_32=y > CONFIG_GENERIC_TIME=y > CONFIG_GENERIC_CMOS_UPDATE=y > CONFIG_CLOCKSOURCE_WATCHDOG=y > CONFIG_GENERIC_CLOCKEVENTS=y > CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y > CONFIG_LOCKDEP_SUPPORT=y > CONFIG_STACKTRACE_SUPPORT=y > CONFIG_SEMAPHORE_SLEEPERS=y > CONFIG_X86=y > CONFIG_MMU=y > CONFIG_ZONE_DMA=y > CONFIG_QUICKLIST=y > CONFIG_GENERIC_ISA_DMA=y > CONFIG_GENERIC_IOMAP=y > CONFIG_GENERIC_BUG=y > CONFIG_GENERIC_HWEIGHT=y > CONFIG_ARCH_MAY_HAVE_PC_FDC=y > CONFIG_DMI=y > CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" > > # > # General setup > # > CONFIG_EXPERIMENTAL=y > CONFIG_LOCK_KERNEL=y > CONFIG_INIT_ENV_ARG_LIMIT=32 > CONFIG_LOCALVERSION="" > CONFIG_LOCALVERSION_AUTO=y > # CONFIG_SWAP is not set > CONFIG_SYSVIPC=y > CONFIG_SYSVIPC_SYSCTL=y > CONFIG_POSIX_MQUEUE=y > # CONFIG_BSD_PROCESS_ACCT is not set > # CONFIG_TASKSTATS is not set > # CONFIG_USER_NS is not set > # CONFIG_AUDIT is not set > # CONFIG_IKCONFIG is not set > CONFIG_LOG_BUF_SHIFT=15 > # CONFIG_CPUSETS is not set > CONFIG_SYSFS_DEPRECATED=y > # CONFIG_RELAY is not set > CONFIG_BLK_DEV_INITRD=y > CONFIG_INITRAMFS_SOURCE="" > # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set > CONFIG_SYSCTL=y > CONFIG_EMBEDDED=y > # CONFIG_UID16 is not set > # CONFIG_SYSCTL_SYSCALL is not set > CONFIG_KALLSYMS=y > CONFIG_KALLSYMS_ALL=y > # CONFIG_KALLSYMS_EXTRA_PASS is not set > CONFIG_HOTPLUG=y > CONFIG_PRINTK=y > CONFIG_BUG=y > # CONFIG_ELF_CORE is not set > CONFIG_BASE_FULL=y > CONFIG_FUTEX=y > CONFIG_ANON_INODES=y > CONFIG_EPOLL=y > CONFIG_SIGNALFD=y > CONFIG_EVENTFD=y > # CONFIG_SHMEM is not set > CONFIG_VM_EVENT_COUNTERS=y > CONFIG_SLAB=y > # CONFIG_SLUB is not set > # CONFIG_SLOB is not set > CONFIG_RT_MUTEXES=y > CONFIG_TINY_SHMEM=y > CONFIG_BASE_SMALL=0 > # CONFIG_MODULES is not set > CONFIG_STOP_MACHINE=y > CONFIG_BLOCK=y > CONFIG_LBD=y > # CONFIG_BLK_DEV_IO_TRACE is not set > # CONFIG_LSF is not set > # CONFIG_BLK_DEV_BSG is not set > > # > # IO Schedulers > # > CONFIG_IOSCHED_NOOP=y > # CONFIG_IOSCHED_AS is not set > CONFIG_IOSCHED_DEADLINE=y > # CONFIG_IOSCHED_CFQ is not set > # CONFIG_DEFAULT_AS is not set > CONFIG_DEFAULT_DEADLINE=y > # CONFIG_DEFAULT_CFQ is not set > # CONFIG_DEFAULT_NOOP is not set > CONFIG_DEFAULT_IOSCHED="deadline" > > # > # Processor type and features > # > CONFIG_TICK_ONESHOT=y > CONFIG_NO_HZ=y > CONFIG_HIGH_RES_TIMERS=y > CONFIG_SMP=y > CONFIG_X86_PC=y > # CONFIG_X86_ELAN is not set > # CONFIG_X86_VOYAGER is not set > # CONFIG_X86_NUMAQ is not set > # CONFIG_X86_SUMMIT is not set > # CONFIG_X86_BIGSMP is not set > # CONFIG_X86_VISWS is not set > # CONFIG_X86_GENERICARCH is not set > # CONFIG_X86_ES7000 is not set > # CONFIG_PARAVIRT is not set > # CONFIG_M386 is not set > # CONFIG_M486 is not set > # CONFIG_M586 is not set > # CONFIG_M586TSC is not set > # CONFIG_M586MMX is not set > # CONFIG_M686 is not set > # CONFIG_MPENTIUMII is not set > # CONFIG_MPENTIUMIII is not set > # CONFIG_MPENTIUMM is not set > # CONFIG_MCORE2 is not set > CONFIG_MPENTIUM4=y > # CONFIG_MK6 is not set > # CONFIG_MK7 is not set > # CONFIG_MK8 is not set > # CONFIG_MCRUSOE is not set > # CONFIG_MEFFICEON is not set > # CONFIG_MWINCHIPC6 is not set > # CONFIG_MWINCHIP2 is not set > # CONFIG_MWINCHIP3D is not set > # CONFIG_MGEODEGX1 is not set > # CONFIG_MGEODE_LX is not set > # CONFIG_MCYRIXIII is not set > # CONFIG_MVIAC3_2 is not set > # CONFIG_MVIAC7 is not set > # CONFIG_X86_GENERIC is not set > CONFIG_X86_CMPXCHG=y > CONFIG_X86_L1_CACHE_SHIFT=7 > CONFIG_X86_XADD=y > CONFIG_RWSEM_XCHGADD_ALGORITHM=y > # CONFIG_ARCH_HAS_ILOG2_U32 is not set > # CONFIG_ARCH_HAS_ILOG2_U64 is not set > CONFIG_GENERIC_CALIBRATE_DELAY=y > CONFIG_X86_WP_WORKS_OK=y > CONFIG_X86_INVLPG=y > CONFIG_X86_BSWAP=y > CONFIG_X86_POPAD_OK=y > CONFIG_X86_GOOD_APIC=y > CONFIG_X86_INTEL_USERCOPY=y > CONFIG_X86_USE_PPRO_CHECKSUM=y > CONFIG_X86_TSC=y > CONFIG_X86_CMOV=y > CONFIG_X86_MINIMUM_CPU_FAMILY=4 > CONFIG_HPET_TIMER=y > CONFIG_HPET_EMULATE_RTC=y > CONFIG_NR_CPUS=8 > CONFIG_SCHED_SMT=y > CONFIG_SCHED_MC=y > CONFIG_PREEMPT_NONE=y > # CONFIG_PREEMPT_VOLUNTARY is not set > # CONFIG_PREEMPT is not set > # CONFIG_PREEMPT_BKL is not set > CONFIG_X86_LOCAL_APIC=y > CONFIG_X86_IO_APIC=y > # CONFIG_X86_MCE is not set > # CONFIG_VM86 is not set > # CONFIG_TOSHIBA is not set > # CONFIG_I8K is not set > # CONFIG_X86_REBOOTFIXUPS is not set > # CONFIG_MICROCODE is not set > # CONFIG_X86_MSR is not set > # CONFIG_X86_CPUID is not set > > # > # Firmware Drivers > # > # CONFIG_EDD is not set > # CONFIG_DELL_RBU is not set > # CONFIG_DCDBAS is not set > CONFIG_DMIID=y > # CONFIG_NOHIGHMEM is not set > # CONFIG_HIGHMEM4G is not set > CONFIG_HIGHMEM64G=y > # CONFIG_VMSPLIT_3G is not set > # CONFIG_VMSPLIT_3G_OPT is not set > CONFIG_VMSPLIT_2G=y > # CONFIG_VMSPLIT_2G_OPT is not set > # CONFIG_VMSPLIT_1G is not set > CONFIG_PAGE_OFFSET=0x80000000 > CONFIG_HIGHMEM=y > CONFIG_X86_PAE=y > CONFIG_ARCH_FLATMEM_ENABLE=y > CONFIG_ARCH_SPARSEMEM_ENABLE=y > CONFIG_ARCH_SELECT_MEMORY_MODEL=y > CONFIG_ARCH_POPULATES_NODE_MAP=y > CONFIG_SELECT_MEMORY_MODEL=y > CONFIG_FLATMEM_MANUAL=y > # CONFIG_DISCONTIGMEM_MANUAL is not set > # CONFIG_SPARSEMEM_MANUAL is not set > CONFIG_FLATMEM=y > CONFIG_FLAT_NODE_MEM_MAP=y > CONFIG_SPARSEMEM_STATIC=y > CONFIG_SPLIT_PTLOCK_CPUS=4 > CONFIG_RESOURCES_64BIT=y > CONFIG_ZONE_DMA_FLAG=1 > CONFIG_BOUNCE=y > CONFIG_NR_QUICK=1 > CONFIG_VIRT_TO_BUS=y > CONFIG_HIGHPTE=y > # CONFIG_MATH_EMULATION is not set > # CONFIG_MTRR is not set > # CONFIG_EFI is not set > # CONFIG_IRQBALANCE is not set > # CONFIG_SECCOMP is not set > # CONFIG_HZ_100 is not set > # CONFIG_HZ_250 is not set > CONFIG_HZ_300=y > # CONFIG_HZ_1000 is not set > CONFIG_HZ=300 > # CONFIG_KEXEC is not set > # CONFIG_CRASH_DUMP is not set > CONFIG_PHYSICAL_START=0x100000 > # CONFIG_RELOCATABLE is not set > CONFIG_PHYSICAL_ALIGN=0x100000 > CONFIG_HOTPLUG_CPU=y > # CONFIG_COMPAT_VDSO is not set > CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y > > # > # Power management options (ACPI, APM) > # > CONFIG_PM=y > # CONFIG_PM_LEGACY is not set > # CONFIG_PM_DEBUG is not set > CONFIG_SUSPEND_SMP_POSSIBLE=y > # CONFIG_SUSPEND is not set > CONFIG_HIBERNATION_SMP_POSSIBLE=y > CONFIG_ACPI=y > # CONFIG_ACPI_PROCFS is not set > CONFIG_ACPI_PROC_EVENT=y > # CONFIG_ACPI_AC is not set > # CONFIG_ACPI_BATTERY is not set > CONFIG_ACPI_BUTTON=y > CONFIG_ACPI_FAN=y > # CONFIG_ACPI_DOCK is not set > CONFIG_ACPI_PROCESSOR=y > CONFIG_ACPI_HOTPLUG_CPU=y > CONFIG_ACPI_THERMAL=y > # CONFIG_ACPI_ASUS is not set > # CONFIG_ACPI_TOSHIBA is not set > # CONFIG_ACPI_CUSTOM_DSDT is not set > CONFIG_ACPI_BLACKLIST_YEAR=0 > # CONFIG_ACPI_DEBUG is not set > CONFIG_ACPI_EC=y > CONFIG_ACPI_POWER=y > CONFIG_ACPI_SYSTEM=y > CONFIG_X86_PM_TIMER=y > CONFIG_ACPI_CONTAINER=y > # CONFIG_ACPI_SBS is not set > > # > # CPU Frequency scaling > # > # CONFIG_CPU_FREQ is not set > > # > # Bus options (PCI, PCMCIA, EISA, MCA, ISA) > # > CONFIG_PCI=y > # CONFIG_PCI_GOBIOS is not set > # CONFIG_PCI_GOMMCONFIG is not set > # CONFIG_PCI_GODIRECT is not set > CONFIG_PCI_GOANY=y > CONFIG_PCI_BIOS=y > CONFIG_PCI_DIRECT=y > CONFIG_PCI_MMCONFIG=y > CONFIG_PCIEPORTBUS=y > CONFIG_PCIEAER=y > CONFIG_ARCH_SUPPORTS_MSI=y > CONFIG_PCI_MSI=y > # CONFIG_PCI_DEBUG is not set > CONFIG_HT_IRQ=y > CONFIG_ISA_DMA_API=y > # CONFIG_ISA is not set > # CONFIG_MCA is not set > # CONFIG_SCx200 is not set > > # > # PCCARD (PCMCIA/CardBus) support > # > # CONFIG_PCCARD is not set > # CONFIG_HOTPLUG_PCI is not set > > # > # Executable file formats > # > CONFIG_BINFMT_ELF=y > # CONFIG_BINFMT_AOUT is not set > # CONFIG_BINFMT_MISC is not set > > # > # Networking > # > CONFIG_NET=y > > # > # Networking options > # > CONFIG_PACKET=y > CONFIG_PACKET_MMAP=y > CONFIG_UNIX=y > # CONFIG_NET_KEY is not set > CONFIG_INET=y > # CONFIG_IP_MULTICAST is not set > # CONFIG_IP_ADVANCED_ROUTER is not set > CONFIG_IP_FIB_HASH=y > # CONFIG_IP_PNP is not set > # CONFIG_NET_IPIP is not set > # CONFIG_NET_IPGRE is not set > # CONFIG_ARPD is not set > # CONFIG_SYN_COOKIES is not set > # CONFIG_INET_AH is not set > # CONFIG_INET_ESP is not set > # CONFIG_INET_IPCOMP is not set > # CONFIG_INET_XFRM_TUNNEL is not set > # CONFIG_INET_TUNNEL is not set > # CONFIG_INET_XFRM_MODE_TRANSPORT is not set > # CONFIG_INET_XFRM_MODE_TUNNEL is not set > # CONFIG_INET_XFRM_MODE_BEET is not set > CONFIG_INET_DIAG=y > CONFIG_INET_TCP_DIAG=y > # CONFIG_TCP_CONG_ADVANCED is not set > CONFIG_TCP_CONG_CUBIC=y > CONFIG_DEFAULT_TCP_CONG="cubic" > # CONFIG_TCP_MD5SIG is not set > # CONFIG_IPV6 is not set > # CONFIG_INET6_XFRM_TUNNEL is not set > # CONFIG_INET6_TUNNEL is not set > # CONFIG_NETWORK_SECMARK is not set > # CONFIG_NETFILTER is not set > # CONFIG_IP_DCCP is not set > # CONFIG_IP_SCTP is not set > # CONFIG_TIPC is not set > # CONFIG_ATM is not set > # CONFIG_BRIDGE is not set > # CONFIG_VLAN_8021Q is not set > # CONFIG_DECNET is not set > # CONFIG_LLC2 is not set > # CONFIG_IPX is not set > # CONFIG_ATALK is not set > # CONFIG_X25 is not set > # CONFIG_LAPB is not set > # CONFIG_ECONET is not set > # CONFIG_WAN_ROUTER is not set > > # > # QoS and/or fair queueing > # > # CONFIG_NET_SCHED is not set > > # > # Network testing > # > # CONFIG_NET_PKTGEN is not set > # CONFIG_HAMRADIO is not set > # CONFIG_IRDA is not set > # CONFIG_BT is not set > # CONFIG_AF_RXRPC is not set > > # > # Wireless > # > # CONFIG_CFG80211 is not set > # CONFIG_WIRELESS_EXT is not set > # CONFIG_MAC80211 is not set > # CONFIG_IEEE80211 is not set > # CONFIG_RFKILL is not set > # CONFIG_NET_9P is not set > > # > # Device Drivers > # > > # > # Generic Driver Options > # > # CONFIG_STANDALONE is not set > # CONFIG_PREVENT_FIRMWARE_BUILD is not set > # CONFIG_FW_LOADER is not set > # CONFIG_DEBUG_DRIVER is not set > # CONFIG_DEBUG_DEVRES is not set > # CONFIG_SYS_HYPERVISOR is not set > # CONFIG_CONNECTOR is not set > # CONFIG_MTD is not set > # CONFIG_PARPORT is not set > CONFIG_PNP=y > # CONFIG_PNP_DEBUG is not set > > # > # Protocols > # > CONFIG_PNPACPI=y > CONFIG_BLK_DEV=y > # CONFIG_BLK_DEV_FD is not set > # CONFIG_BLK_CPQ_DA is not set > # CONFIG_BLK_CPQ_CISS_DA is not set > # CONFIG_BLK_DEV_DAC960 is not set > # CONFIG_BLK_DEV_UMEM is not set > # CONFIG_BLK_DEV_COW_COMMON is not set > CONFIG_BLK_DEV_LOOP=y > # CONFIG_BLK_DEV_CRYPTOLOOP is not set > # CONFIG_BLK_DEV_NBD is not set > # CONFIG_BLK_DEV_SX8 is not set > # CONFIG_BLK_DEV_UB is not set > CONFIG_BLK_DEV_RAM=y > CONFIG_BLK_DEV_RAM_COUNT=16 > CONFIG_BLK_DEV_RAM_SIZE=4096 > CONFIG_BLK_DEV_RAM_BLOCKSIZE=1024 > # CONFIG_CDROM_PKTCDVD is not set > # CONFIG_ATA_OVER_ETH is not set > # CONFIG_MISC_DEVICES is not set > CONFIG_IDE=y > CONFIG_IDE_MAX_HWIFS=4 > CONFIG_BLK_DEV_IDE=y > > # > # Please see Documentation/ide.txt for help/info on IDE drives > # > # CONFIG_BLK_DEV_IDE_SATA is not set > # CONFIG_BLK_DEV_HD_IDE is not set > CONFIG_BLK_DEV_IDEDISK=y > CONFIG_IDEDISK_MULTI_MODE=y > # CONFIG_BLK_DEV_IDECD is not set > # CONFIG_BLK_DEV_IDETAPE is not set > # CONFIG_BLK_DEV_IDEFLOPPY is not set > # CONFIG_BLK_DEV_IDESCSI is not set > # CONFIG_BLK_DEV_IDEACPI is not set > # CONFIG_IDE_TASK_IOCTL is not set > CONFIG_IDE_PROC_FS=y > > # > # IDE chipset support/bugfixes > # > CONFIG_IDE_GENERIC=y > # CONFIG_BLK_DEV_CMD640 is not set > # CONFIG_BLK_DEV_IDEPNP is not set > CONFIG_BLK_DEV_IDEPCI=y > CONFIG_IDEPCI_SHARE_IRQ=y > CONFIG_IDEPCI_PCIBUS_ORDER=y > # CONFIG_BLK_DEV_OFFBOARD is not set > CONFIG_BLK_DEV_GENERIC=y > # CONFIG_BLK_DEV_OPTI621 is not set > # CONFIG_BLK_DEV_RZ1000 is not set > CONFIG_BLK_DEV_IDEDMA_PCI=y > # CONFIG_BLK_DEV_IDEDMA_FORCED is not set > # CONFIG_IDEDMA_ONLYDISK is not set > # CONFIG_BLK_DEV_AEC62XX is not set > # CONFIG_BLK_DEV_ALI15X3 is not set > # CONFIG_BLK_DEV_AMD74XX is not set > # CONFIG_BLK_DEV_ATIIXP is not set > # CONFIG_BLK_DEV_CMD64X is not set > # CONFIG_BLK_DEV_TRIFLEX is not set > # CONFIG_BLK_DEV_CY82C693 is not set > # CONFIG_BLK_DEV_CS5520 is not set > # CONFIG_BLK_DEV_CS5530 is not set > # CONFIG_BLK_DEV_CS5535 is not set > # CONFIG_BLK_DEV_HPT34X is not set > # CONFIG_BLK_DEV_HPT366 is not set > # CONFIG_BLK_DEV_JMICRON is not set > # CONFIG_BLK_DEV_SC1200 is not set > CONFIG_BLK_DEV_PIIX=y > # CONFIG_BLK_DEV_IT8213 is not set > # CONFIG_BLK_DEV_IT821X is not set > # CONFIG_BLK_DEV_NS87415 is not set > # CONFIG_BLK_DEV_PDC202XX_OLD is not set > # CONFIG_BLK_DEV_PDC202XX_NEW is not set > # CONFIG_BLK_DEV_SVWKS is not set > # CONFIG_BLK_DEV_SIIMAGE is not set > # CONFIG_BLK_DEV_SIS5513 is not set > # CONFIG_BLK_DEV_SLC90E66 is not set > # CONFIG_BLK_DEV_TRM290 is not set > # CONFIG_BLK_DEV_VIA82CXXX is not set > # CONFIG_BLK_DEV_TC86C001 is not set > # CONFIG_IDE_ARM is not set > CONFIG_BLK_DEV_IDEDMA=y > # CONFIG_IDEDMA_IVB is not set > # CONFIG_BLK_DEV_HD is not set > > # > # SCSI device support > # > # CONFIG_RAID_ATTRS is not set > CONFIG_SCSI=y > CONFIG_SCSI_DMA=y > # CONFIG_SCSI_TGT is not set > # CONFIG_SCSI_NETLINK is not set > CONFIG_SCSI_PROC_FS=y > > # > # SCSI support type (disk, tape, CD-ROM) > # > CONFIG_BLK_DEV_SD=y > # CONFIG_CHR_DEV_ST is not set > # CONFIG_CHR_DEV_OSST is not set > # CONFIG_BLK_DEV_SR is not set > CONFIG_CHR_DEV_SG=y > # CONFIG_CHR_DEV_SCH is not set > > # > # Some SCSI devices (e.g. CD jukebox) support multiple LUNs > # > # CONFIG_SCSI_MULTI_LUN is not set > # CONFIG_SCSI_CONSTANTS is not set > # CONFIG_SCSI_LOGGING is not set > # CONFIG_SCSI_SCAN_ASYNC is not set > > # > # SCSI Transports > # > # CONFIG_SCSI_SPI_ATTRS is not set > # CONFIG_SCSI_FC_ATTRS is not set > # CONFIG_SCSI_ISCSI_ATTRS is not set > # CONFIG_SCSI_SAS_LIBSAS is not set > CONFIG_SCSI_LOWLEVEL=y > # CONFIG_ISCSI_TCP is not set > # CONFIG_BLK_DEV_3W_XXXX_RAID is not set > CONFIG_SCSI_3W_9XXX=y > # CONFIG_SCSI_ACARD is not set > # CONFIG_SCSI_AACRAID is not set > # CONFIG_SCSI_AIC7XXX is not set > # CONFIG_SCSI_AIC7XXX_OLD is not set > # CONFIG_SCSI_AIC79XX is not set > # CONFIG_SCSI_AIC94XX is not set > # CONFIG_SCSI_DPT_I2O is not set > # CONFIG_SCSI_ADVANSYS is not set > # CONFIG_SCSI_ARCMSR is not set > # CONFIG_MEGARAID_NEWGEN is not set > # CONFIG_MEGARAID_LEGACY is not set > # CONFIG_MEGARAID_SAS is not set > # CONFIG_SCSI_HPTIOP is not set > # CONFIG_SCSI_BUSLOGIC is not set > # CONFIG_SCSI_DMX3191D is not set > # CONFIG_SCSI_EATA is not set > # CONFIG_SCSI_FUTURE_DOMAIN is not set > # CONFIG_SCSI_GDTH is not set > # CONFIG_SCSI_IPS is not set > # CONFIG_SCSI_INITIO is not set > # CONFIG_SCSI_INIA100 is not set > # CONFIG_SCSI_STEX is not set > # CONFIG_SCSI_SYM53C8XX_2 is not set > # CONFIG_SCSI_IPR is not set > # CONFIG_SCSI_QLOGIC_1280 is not set > # CONFIG_SCSI_QLA_FC is not set > # CONFIG_SCSI_QLA_ISCSI is not set > # CONFIG_SCSI_LPFC is not set > # CONFIG_SCSI_DC395x is not set > # CONFIG_SCSI_DC390T is not set > # CONFIG_SCSI_NSP32 is not set > # CONFIG_SCSI_DEBUG is not set > # CONFIG_SCSI_SRP is not set > CONFIG_ATA=y > # CONFIG_ATA_NONSTANDARD is not set > CONFIG_ATA_ACPI=y > CONFIG_SATA_AHCI=y > # CONFIG_SATA_SVW is not set > # CONFIG_ATA_PIIX is not set > # CONFIG_SATA_MV is not set > # CONFIG_SATA_NV is not set > # CONFIG_PDC_ADMA is not set > # CONFIG_SATA_QSTOR is not set > # CONFIG_SATA_PROMISE is not set > # CONFIG_SATA_SX4 is not set > # CONFIG_SATA_SIL is not set > # CONFIG_SATA_SIL24 is not set > # CONFIG_SATA_SIS is not set > # CONFIG_SATA_ULI is not set > # CONFIG_SATA_VIA is not set > # CONFIG_SATA_VITESSE is not set > # CONFIG_SATA_INIC162X is not set > # CONFIG_PATA_ALI is not set > # CONFIG_PATA_AMD is not set > # CONFIG_PATA_ARTOP is not set > # CONFIG_PATA_ATIIXP is not set > # CONFIG_PATA_CMD640_PCI is not set > # CONFIG_PATA_CMD64X is not set > # CONFIG_PATA_CS5520 is not set > # CONFIG_PATA_CS5530 is not set > # CONFIG_PATA_CS5535 is not set > # CONFIG_PATA_CYPRESS is not set > # CONFIG_PATA_EFAR is not set > # CONFIG_ATA_GENERIC is not set > # CONFIG_PATA_HPT366 is not set > # CONFIG_PATA_HPT37X is not set > # CONFIG_PATA_HPT3X2N is not set > # CONFIG_PATA_HPT3X3 is not set > # CONFIG_PATA_IT821X is not set > # CONFIG_PATA_IT8213 is not set > # CONFIG_PATA_JMICRON is not set > # CONFIG_PATA_TRIFLEX is not set > # CONFIG_PATA_MARVELL is not set > # CONFIG_PATA_MPIIX is not set > # CONFIG_PATA_OLDPIIX is not set > # CONFIG_PATA_NETCELL is not set > # CONFIG_PATA_NS87410 is not set > # CONFIG_PATA_OPTI is not set > # CONFIG_PATA_OPTIDMA is not set > # CONFIG_PATA_PDC_OLD is not set > # CONFIG_PATA_RADISYS is not set > # CONFIG_PATA_RZ1000 is not set > # CONFIG_PATA_SC1200 is not set > # CONFIG_PATA_SERVERWORKS is not set > # CONFIG_PATA_PDC2027X is not set > # CONFIG_PATA_SIL680 is not set > # CONFIG_PATA_SIS is not set > # CONFIG_PATA_VIA is not set > # CONFIG_PATA_WINBOND is not set > # CONFIG_PATA_PLATFORM is not set > CONFIG_MD=y > CONFIG_BLK_DEV_MD=y > CONFIG_MD_LINEAR=y > CONFIG_MD_RAID0=y > CONFIG_MD_RAID1=y > CONFIG_MD_RAID10=y > CONFIG_MD_RAID456=y > CONFIG_MD_RAID5_RESHAPE=y > # CONFIG_MD_MULTIPATH is not set > # CONFIG_MD_FAULTY is not set > # CONFIG_BLK_DEV_DM is not set > > # > # Fusion MPT device support > # > # CONFIG_FUSION is not set > # CONFIG_FUSION_SPI is not set > # CONFIG_FUSION_FC is not set > # CONFIG_FUSION_SAS is not set > > # > # IEEE 1394 (FireWire) support > # > # CONFIG_FIREWIRE is not set > # CONFIG_IEEE1394 is not set > # CONFIG_I2O is not set > # CONFIG_MACINTOSH_DRIVERS is not set > CONFIG_NETDEVICES=y > # CONFIG_NETDEVICES_MULTIQUEUE is not set > # CONFIG_DUMMY is not set > CONFIG_BONDING=y > # CONFIG_MACVLAN is not set > # CONFIG_EQUALIZER is not set > # CONFIG_TUN is not set > # CONFIG_NET_SB1000 is not set > # CONFIG_ARCNET is not set > # CONFIG_NET_ETHERNET is not set > CONFIG_NETDEV_1000=y > # CONFIG_ACENIC is not set > # CONFIG_DL2K is not set > CONFIG_E1000=y > CONFIG_E1000_NAPI=y > # CONFIG_E1000_DISABLE_PACKET_SPLIT is not set > # CONFIG_NS83820 is not set > # CONFIG_HAMACHI is not set > # CONFIG_YELLOWFIN is not set > # CONFIG_R8169 is not set > # CONFIG_SIS190 is not set > # CONFIG_SKGE is not set > # CONFIG_SKY2 is not set > # CONFIG_SK98LIN is not set > # CONFIG_VIA_VELOCITY is not set > # CONFIG_TIGON3 is not set > # CONFIG_BNX2 is not set > # CONFIG_QLA3XXX is not set > # CONFIG_ATL1 is not set > # CONFIG_NETDEV_10000 is not set > # CONFIG_TR is not set > > # > # Wireless LAN > # > # CONFIG_WLAN_PRE80211 is not set > # CONFIG_WLAN_80211 is not set > > # > # USB Network Adapters > # > # CONFIG_USB_CATC is not set > # CONFIG_USB_KAWETH is not set > # CONFIG_USB_PEGASUS is not set > # CONFIG_USB_RTL8150 is not set > # CONFIG_USB_USBNET_MII is not set > # CONFIG_USB_USBNET is not set > # CONFIG_WAN is not set > # CONFIG_FDDI is not set > # CONFIG_HIPPI is not set > # CONFIG_PPP is not set > # CONFIG_SLIP is not set > # CONFIG_NET_FC is not set > # CONFIG_SHAPER is not set > # CONFIG_NETCONSOLE is not set > # CONFIG_NETPOLL is not set > # CONFIG_NET_POLL_CONTROLLER is not set > # CONFIG_ISDN is not set > # CONFIG_PHONE is not set > > # > # Input device support > # > CONFIG_INPUT=y > # CONFIG_INPUT_FF_MEMLESS is not set > # CONFIG_INPUT_POLLDEV is not set > > # > # Userland interfaces > # > CONFIG_INPUT_MOUSEDEV=y > # CONFIG_INPUT_MOUSEDEV_PSAUX is not set > CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 > CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 > # CONFIG_INPUT_JOYDEV is not set > # CONFIG_INPUT_TSDEV is not set > # CONFIG_INPUT_EVDEV is not set > # CONFIG_INPUT_EVBUG is not set > > # > # Input Device Drivers > # > CONFIG_INPUT_KEYBOARD=y > CONFIG_KEYBOARD_ATKBD=y > # CONFIG_KEYBOARD_SUNKBD is not set > # CONFIG_KEYBOARD_LKKBD is not set > # CONFIG_KEYBOARD_XTKBD is not set > # CONFIG_KEYBOARD_NEWTON is not set > # CONFIG_KEYBOARD_STOWAWAY is not set > # CONFIG_INPUT_MOUSE is not set > # CONFIG_INPUT_JOYSTICK is not set > # CONFIG_INPUT_TABLET is not set > # CONFIG_INPUT_TOUCHSCREEN is not set > # CONFIG_INPUT_MISC is not set > > # > # Hardware I/O ports > # > CONFIG_SERIO=y > CONFIG_SERIO_I8042=y > # CONFIG_SERIO_SERPORT is not set > # CONFIG_SERIO_CT82C710 is not set > # CONFIG_SERIO_PCIPS2 is not set > CONFIG_SERIO_LIBPS2=y > # CONFIG_SERIO_RAW is not set > # CONFIG_GAMEPORT is not set > > # > # Character devices > # > CONFIG_VT=y > CONFIG_VT_CONSOLE=y > CONFIG_HW_CONSOLE=y > # CONFIG_VT_HW_CONSOLE_BINDING is not set > # CONFIG_SERIAL_NONSTANDARD is not set > > # > # Serial drivers > # > CONFIG_SERIAL_8250=y > CONFIG_SERIAL_8250_CONSOLE=y > CONFIG_FIX_EARLYCON_MEM=y > CONFIG_SERIAL_8250_PCI=y > CONFIG_SERIAL_8250_PNP=y > CONFIG_SERIAL_8250_NR_UARTS=4 > CONFIG_SERIAL_8250_RUNTIME_UARTS=4 > CONFIG_SERIAL_8250_EXTENDED=y > # CONFIG_SERIAL_8250_MANY_PORTS is not set > CONFIG_SERIAL_8250_SHARE_IRQ=y > # CONFIG_SERIAL_8250_DETECT_IRQ is not set > # CONFIG_SERIAL_8250_RSA is not set > > # > # Non-8250 serial port support > # > CONFIG_SERIAL_CORE=y > CONFIG_SERIAL_CORE_CONSOLE=y > # CONFIG_SERIAL_JSM is not set > CONFIG_UNIX98_PTYS=y > CONFIG_LEGACY_PTYS=y > CONFIG_LEGACY_PTY_COUNT=256 > # CONFIG_IPMI_HANDLER is not set > CONFIG_WATCHDOG=y > # CONFIG_WATCHDOG_NOWAYOUT is not set > > # > # Watchdog Device Drivers > # > CONFIG_SOFT_WATCHDOG=y > # CONFIG_ACQUIRE_WDT is not set > # CONFIG_ADVANTECH_WDT is not set > # CONFIG_ALIM1535_WDT is not set > # CONFIG_ALIM7101_WDT is not set > # CONFIG_SC520_WDT is not set > # CONFIG_EUROTECH_WDT is not set > # CONFIG_IB700_WDT is not set > # CONFIG_IBMASR is not set > # CONFIG_WAFER_WDT is not set > # CONFIG_I6300ESB_WDT is not set > # CONFIG_ITCO_WDT is not set > # CONFIG_SC1200_WDT is not set > # CONFIG_PC87413_WDT is not set > # CONFIG_60XX_WDT is not set > # CONFIG_SBC8360_WDT is not set > # CONFIG_CPU5_WDT is not set > # CONFIG_SMSC37B787_WDT is not set > # CONFIG_W83627HF_WDT is not set > # CONFIG_W83697HF_WDT is not set > # CONFIG_W83877F_WDT is not set > # CONFIG_W83977F_WDT is not set > # CONFIG_MACHZ_WDT is not set > # CONFIG_SBC_EPX_C3_WATCHDOG is not set > > # > # PCI-based Watchdog Cards > # > # CONFIG_PCIPCWATCHDOG is not set > # CONFIG_WDTPCI is not set > > # > # USB-based Watchdog Cards > # > # CONFIG_USBPCWATCHDOG is not set > CONFIG_HW_RANDOM=y > CONFIG_HW_RANDOM_INTEL=y > # CONFIG_HW_RANDOM_AMD is not set > # CONFIG_HW_RANDOM_GEODE is not set > # CONFIG_HW_RANDOM_VIA is not set > # CONFIG_NVRAM is not set > CONFIG_RTC=y > # CONFIG_R3964 is not set > # CONFIG_APPLICOM is not set > # CONFIG_SONYPI is not set > # CONFIG_AGP is not set > # CONFIG_DRM is not set > # CONFIG_MWAVE is not set > # CONFIG_PC8736x_GPIO is not set > # CONFIG_NSC_GPIO is not set > # CONFIG_CS5535_GPIO is not set > # CONFIG_RAW_DRIVER is not set > # CONFIG_HPET is not set > CONFIG_HANGCHECK_TIMER=y > # CONFIG_TCG_TPM is not set > # CONFIG_TELCLOCK is not set > CONFIG_DEVPORT=y > CONFIG_I2C=y > CONFIG_I2C_BOARDINFO=y > CONFIG_I2C_CHARDEV=y > > # > # I2C Algorithms > # > # CONFIG_I2C_ALGOBIT is not set > # CONFIG_I2C_ALGOPCF is not set > # CONFIG_I2C_ALGOPCA is not set > > # > # I2C Hardware Bus support > # > # CONFIG_I2C_ALI1535 is not set > # CONFIG_I2C_ALI1563 is not set > # CONFIG_I2C_ALI15X3 is not set > # CONFIG_I2C_AMD756 is not set > # CONFIG_I2C_AMD8111 is not set > CONFIG_I2C_I801=y > # CONFIG_I2C_I810 is not set > # CONFIG_I2C_PIIX4 is not set > # CONFIG_I2C_NFORCE2 is not set > # CONFIG_I2C_OCORES is not set > # CONFIG_I2C_PARPORT_LIGHT is not set > # CONFIG_I2C_PROSAVAGE is not set > # CONFIG_I2C_SAVAGE4 is not set > # CONFIG_I2C_SIMTEC is not set > # CONFIG_SCx200_ACB is not set > # CONFIG_I2C_SIS5595 is not set > # CONFIG_I2C_SIS630 is not set > # CONFIG_I2C_SIS96X is not set > # CONFIG_I2C_TAOS_EVM is not set > # CONFIG_I2C_TINY_USB is not set > # CONFIG_I2C_VIA is not set > # CONFIG_I2C_VIAPRO is not set > # CONFIG_I2C_VOODOO3 is not set > > # > # Miscellaneous I2C Chip support > # > # CONFIG_SENSORS_DS1337 is not set > # CONFIG_SENSORS_DS1374 is not set > # CONFIG_DS1682 is not set > CONFIG_SENSORS_EEPROM=y > # CONFIG_SENSORS_PCF8574 is not set > # CONFIG_SENSORS_PCA9539 is not set > # CONFIG_SENSORS_PCF8591 is not set > # CONFIG_SENSORS_MAX6875 is not set > # CONFIG_SENSORS_TSL2550 is not set > # CONFIG_I2C_DEBUG_CORE is not set > # CONFIG_I2C_DEBUG_ALGO is not set > # CONFIG_I2C_DEBUG_BUS is not set > # CONFIG_I2C_DEBUG_CHIP is not set > > # > # SPI support > # > # CONFIG_SPI is not set > # CONFIG_SPI_MASTER is not set > # CONFIG_W1 is not set > # CONFIG_POWER_SUPPLY is not set > CONFIG_HWMON=y > CONFIG_HWMON_VID=y > # CONFIG_SENSORS_ABITUGURU is not set > # CONFIG_SENSORS_ABITUGURU3 is not set > # CONFIG_SENSORS_AD7418 is not set > # CONFIG_SENSORS_ADM1021 is not set > # CONFIG_SENSORS_ADM1025 is not set > # CONFIG_SENSORS_ADM1026 is not set > # CONFIG_SENSORS_ADM1029 is not set > # CONFIG_SENSORS_ADM1031 is not set > # CONFIG_SENSORS_ADM9240 is not set > # CONFIG_SENSORS_K8TEMP is not set > # CONFIG_SENSORS_ASB100 is not set > # CONFIG_SENSORS_ATXP1 is not set > # CONFIG_SENSORS_DS1621 is not set > # CONFIG_SENSORS_F71805F is not set > # CONFIG_SENSORS_FSCHER is not set > # CONFIG_SENSORS_FSCPOS is not set > # CONFIG_SENSORS_GL518SM is not set > # CONFIG_SENSORS_GL520SM is not set > # CONFIG_SENSORS_CORETEMP is not set > # CONFIG_SENSORS_IT87 is not set > # CONFIG_SENSORS_LM63 is not set > # CONFIG_SENSORS_LM75 is not set > # CONFIG_SENSORS_LM77 is not set > # CONFIG_SENSORS_LM78 is not set > # CONFIG_SENSORS_LM80 is not set > # CONFIG_SENSORS_LM83 is not set > # CONFIG_SENSORS_LM85 is not set > # CONFIG_SENSORS_LM87 is not set > # CONFIG_SENSORS_LM90 is not set > # CONFIG_SENSORS_LM92 is not set > CONFIG_SENSORS_LM93=y > # CONFIG_SENSORS_MAX1619 is not set > # CONFIG_SENSORS_MAX6650 is not set > # CONFIG_SENSORS_PC87360 is not set > CONFIG_SENSORS_PC87427=y > # CONFIG_SENSORS_SIS5595 is not set > # CONFIG_SENSORS_DME1737 is not set > # CONFIG_SENSORS_SMSC47M1 is not set > # CONFIG_SENSORS_SMSC47M192 is not set > # CONFIG_SENSORS_SMSC47B397 is not set > # CONFIG_SENSORS_THMC50 is not set > # CONFIG_SENSORS_VIA686A is not set > # CONFIG_SENSORS_VT1211 is not set > # CONFIG_SENSORS_VT8231 is not set > # CONFIG_SENSORS_W83781D is not set > # CONFIG_SENSORS_W83791D is not set > # CONFIG_SENSORS_W83792D is not set > CONFIG_SENSORS_W83793=y > # CONFIG_SENSORS_W83L785TS is not set > CONFIG_SENSORS_W83627HF=y > CONFIG_SENSORS_W83627EHF=y > # CONFIG_SENSORS_HDAPS is not set > # CONFIG_SENSORS_APPLESMC is not set > # CONFIG_HWMON_DEBUG_CHIP is not set > > # > # Multifunction device drivers > # > # CONFIG_MFD_SM501 is not set > > # > # Multimedia devices > # > # CONFIG_VIDEO_DEV is not set > # CONFIG_DVB_CORE is not set > # CONFIG_DAB is not set > > # > # Graphics support > # > # CONFIG_BACKLIGHT_LCD_SUPPORT is not set > > # > # Display device support > # > # CONFIG_DISPLAY_SUPPORT is not set > # CONFIG_VGASTATE is not set > # CONFIG_VIDEO_OUTPUT_CONTROL is not set > # CONFIG_FB is not set > > # > # Console display driver support > # > CONFIG_VGA_CONSOLE=y > CONFIG_VGACON_SOFT_SCROLLBACK=y > CONFIG_VGACON_SOFT_SCROLLBACK_SIZE=128 > # CONFIG_VIDEO_SELECT is not set > CONFIG_DUMMY_CONSOLE=y > > # > # Sound > # > # CONFIG_SOUND is not set > CONFIG_HID_SUPPORT=y > CONFIG_HID=y > # CONFIG_HID_DEBUG is not set > > # > # USB Input Devices > # > CONFIG_USB_HID=y > # CONFIG_USB_HIDINPUT_POWERBOOK is not set > # CONFIG_HID_FF is not set > # CONFIG_USB_HIDDEV is not set > CONFIG_USB_SUPPORT=y > CONFIG_USB_ARCH_HAS_HCD=y > CONFIG_USB_ARCH_HAS_OHCI=y > CONFIG_USB_ARCH_HAS_EHCI=y > CONFIG_USB=y > # CONFIG_USB_DEBUG is not set > > # > # Miscellaneous USB options > # > CONFIG_USB_DEVICEFS=y > # CONFIG_USB_DEVICE_CLASS is not set > # CONFIG_USB_DYNAMIC_MINORS is not set > # CONFIG_USB_SUSPEND is not set > # CONFIG_USB_PERSIST is not set > # CONFIG_USB_OTG is not set > > # > # USB Host Controller Drivers > # > CONFIG_USB_EHCI_HCD=y > CONFIG_USB_EHCI_SPLIT_ISO=y > CONFIG_USB_EHCI_ROOT_HUB_TT=y > CONFIG_USB_EHCI_TT_NEWSCHED=y > # CONFIG_USB_ISP116X_HCD is not set > # CONFIG_USB_OHCI_HCD is not set > CONFIG_USB_UHCI_HCD=y > # CONFIG_USB_SL811_HCD is not set > # CONFIG_USB_R8A66597_HCD is not set > > # > # USB Device Class drivers > # > # CONFIG_USB_ACM is not set > # CONFIG_USB_PRINTER is not set > > # > # NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support' > # > > # > # may also be needed; see USB_STORAGE Help for more information > # > CONFIG_USB_STORAGE=y > # CONFIG_USB_STORAGE_DEBUG is not set > CONFIG_USB_STORAGE_DATAFAB=y > CONFIG_USB_STORAGE_FREECOM=y > CONFIG_USB_STORAGE_ISD200=y > CONFIG_USB_STORAGE_DPCM=y > CONFIG_USB_STORAGE_USBAT=y > CONFIG_USB_STORAGE_SDDR09=y > CONFIG_USB_STORAGE_SDDR55=y > CONFIG_USB_STORAGE_JUMPSHOT=y > CONFIG_USB_STORAGE_ALAUDA=y > # CONFIG_USB_STORAGE_KARMA is not set > # CONFIG_USB_LIBUSUAL is not set > > # > # USB Imaging devices > # > # CONFIG_USB_MDC800 is not set > # CONFIG_USB_MICROTEK is not set > # CONFIG_USB_MON is not set > > # > # USB port drivers > # > > # > # USB Serial Converter support > # > # CONFIG_USB_SERIAL is not set > > # > # USB Miscellaneous drivers > # > # CONFIG_USB_EMI62 is not set > # CONFIG_USB_EMI26 is not set > # CONFIG_USB_ADUTUX is not set > # CONFIG_USB_AUERSWALD is not set > # CONFIG_USB_RIO500 is not set > # CONFIG_USB_LEGOTOWER is not set > # CONFIG_USB_LCD is not set > # CONFIG_USB_BERRY_CHARGE is not set > # CONFIG_USB_LED is not set > # CONFIG_USB_CYPRESS_CY7C63 is not set > # CONFIG_USB_CYTHERM is not set > # CONFIG_USB_PHIDGET is not set > # CONFIG_USB_IDMOUSE is not set > # CONFIG_USB_FTDI_ELAN is not set > # CONFIG_USB_APPLEDISPLAY is not set > # CONFIG_USB_SISUSBVGA is not set > # CONFIG_USB_LD is not set > # CONFIG_USB_TRANCEVIBRATOR is not set > # CONFIG_USB_IOWARRIOR is not set > # CONFIG_USB_TEST is not set > > # > # USB DSL modem support > # > > # > # USB Gadget Support > # > # CONFIG_USB_GADGET is not set > # CONFIG_MMC is not set > # CONFIG_NEW_LEDS is not set > # CONFIG_INFINIBAND is not set > # CONFIG_EDAC is not set > # CONFIG_RTC_CLASS is not set > > # > # DMA Engine support > # > # CONFIG_DMA_ENGINE is not set > > # > # DMA Clients > # > > # > # DMA Devices > # > # CONFIG_VIRTUALIZATION is not set > > # > # Userspace I/O > # > # CONFIG_UIO is not set > > # > # File systems > # > CONFIG_EXT2_FS=y > # CONFIG_EXT2_FS_XATTR is not set > # CONFIG_EXT2_FS_XIP is not set > # CONFIG_EXT3_FS is not set > # CONFIG_EXT4DEV_FS is not set > # CONFIG_REISERFS_FS is not set > # CONFIG_JFS_FS is not set > # CONFIG_FS_POSIX_ACL is not set > CONFIG_XFS_FS=y > # CONFIG_XFS_QUOTA is not set > # CONFIG_XFS_SECURITY is not set > # CONFIG_XFS_POSIX_ACL is not set > CONFIG_XFS_RT=y > # CONFIG_GFS2_FS is not set > # CONFIG_OCFS2_FS is not set > # CONFIG_MINIX_FS is not set > # CONFIG_ROMFS_FS is not set > CONFIG_INOTIFY=y > CONFIG_INOTIFY_USER=y > # CONFIG_QUOTA is not set > # CONFIG_DNOTIFY is not set > # CONFIG_AUTOFS_FS is not set > # CONFIG_AUTOFS4_FS is not set > # CONFIG_FUSE_FS is not set > > # > # CD-ROM/DVD Filesystems > # > # CONFIG_ISO9660_FS is not set > # CONFIG_UDF_FS is not set > > # > # DOS/FAT/NT Filesystems > # > CONFIG_FAT_FS=y > CONFIG_MSDOS_FS=y > CONFIG_VFAT_FS=y > CONFIG_FAT_DEFAULT_CODEPAGE=437 > CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1" > # CONFIG_NTFS_FS is not set > > # > # Pseudo filesystems > # > CONFIG_PROC_FS=y > # CONFIG_PROC_KCORE is not set > CONFIG_PROC_SYSCTL=y > CONFIG_SYSFS=y > CONFIG_TMPFS=y > # CONFIG_TMPFS_POSIX_ACL is not set > # CONFIG_HUGETLBFS is not set > # CONFIG_HUGETLB_PAGE is not set > CONFIG_RAMFS=y > # CONFIG_CONFIGFS_FS is not set > > # > # Miscellaneous filesystems > # > # CONFIG_ADFS_FS is not set > # CONFIG_AFFS_FS is not set > # CONFIG_HFS_FS is not set > # CONFIG_HFSPLUS_FS is not set > # CONFIG_BEFS_FS is not set > # CONFIG_BFS_FS is not set > # CONFIG_EFS_FS is not set > # CONFIG_CRAMFS is not set > # CONFIG_VXFS_FS is not set > # CONFIG_HPFS_FS is not set > # CONFIG_QNX4FS_FS is not set > # CONFIG_SYSV_FS is not set > # CONFIG_UFS_FS is not set > > # > # Network File Systems > # > CONFIG_NFS_FS=y > CONFIG_NFS_V3=y > # CONFIG_NFS_V3_ACL is not set > # CONFIG_NFS_V4 is not set > # CONFIG_NFS_DIRECTIO is not set > CONFIG_NFSD=y > CONFIG_NFSD_V3=y > # CONFIG_NFSD_V3_ACL is not set > # CONFIG_NFSD_V4 is not set > # CONFIG_NFSD_TCP is not set > CONFIG_LOCKD=y > CONFIG_LOCKD_V4=y > CONFIG_EXPORTFS=y > CONFIG_NFS_COMMON=y > CONFIG_SUNRPC=y > # CONFIG_SUNRPC_BIND34 is not set > # CONFIG_RPCSEC_GSS_KRB5 is not set > # CONFIG_RPCSEC_GSS_SPKM3 is not set > # CONFIG_SMB_FS is not set > # CONFIG_CIFS is not set > # CONFIG_NCP_FS is not set > # CONFIG_CODA_FS is not set > # CONFIG_AFS_FS is not set > > # > # Partition Types > # > # CONFIG_PARTITION_ADVANCED is not set > CONFIG_MSDOS_PARTITION=y > > # > # Native Language Support > # > CONFIG_NLS=y > CONFIG_NLS_DEFAULT="iso8859-1" > CONFIG_NLS_CODEPAGE_437=y > # CONFIG_NLS_CODEPAGE_737 is not set > # CONFIG_NLS_CODEPAGE_775 is not set > CONFIG_NLS_CODEPAGE_850=y > CONFIG_NLS_CODEPAGE_852=y > # CONFIG_NLS_CODEPAGE_855 is not set > # CONFIG_NLS_CODEPAGE_857 is not set > # CONFIG_NLS_CODEPAGE_860 is not set > # CONFIG_NLS_CODEPAGE_861 is not set > # CONFIG_NLS_CODEPAGE_862 is not set > # CONFIG_NLS_CODEPAGE_863 is not set > # CONFIG_NLS_CODEPAGE_864 is not set > # CONFIG_NLS_CODEPAGE_865 is not set > # CONFIG_NLS_CODEPAGE_866 is not set > # CONFIG_NLS_CODEPAGE_869 is not set > # CONFIG_NLS_CODEPAGE_936 is not set > # CONFIG_NLS_CODEPAGE_950 is not set > # CONFIG_NLS_CODEPAGE_932 is not set > # CONFIG_NLS_CODEPAGE_949 is not set > # CONFIG_NLS_CODEPAGE_874 is not set > # CONFIG_NLS_ISO8859_8 is not set > # CONFIG_NLS_CODEPAGE_1250 is not set > # CONFIG_NLS_CODEPAGE_1251 is not set > CONFIG_NLS_ASCII=y > CONFIG_NLS_ISO8859_1=y > CONFIG_NLS_ISO8859_2=y > # CONFIG_NLS_ISO8859_3 is not set > # CONFIG_NLS_ISO8859_4 is not set > # CONFIG_NLS_ISO8859_5 is not set > # CONFIG_NLS_ISO8859_6 is not set > # CONFIG_NLS_ISO8859_7 is not set > # CONFIG_NLS_ISO8859_9 is not set > # CONFIG_NLS_ISO8859_13 is not set > # CONFIG_NLS_ISO8859_14 is not set > CONFIG_NLS_ISO8859_15=y > # CONFIG_NLS_KOI8_R is not set > # CONFIG_NLS_KOI8_U is not set > CONFIG_NLS_UTF8=y > > # > # Distributed Lock Manager > # > # CONFIG_DLM is not set > # CONFIG_INSTRUMENTATION is not set > > # > # Kernel hacking > # > CONFIG_TRACE_IRQFLAGS_SUPPORT=y > # CONFIG_PRINTK_TIME is not set > # CONFIG_ENABLE_MUST_CHECK is not set > CONFIG_MAGIC_SYSRQ=y > # CONFIG_UNUSED_SYMBOLS is not set > # CONFIG_DEBUG_FS is not set > # CONFIG_HEADERS_CHECK is not set > CONFIG_DEBUG_KERNEL=y > # CONFIG_DEBUG_SHIRQ is not set > CONFIG_DETECT_SOFTLOCKUP=y > # CONFIG_SCHED_DEBUG is not set > # CONFIG_SCHEDSTATS is not set > # CONFIG_TIMER_STATS is not set > # CONFIG_DEBUG_SLAB is not set > CONFIG_DEBUG_RT_MUTEXES=y > CONFIG_DEBUG_PI_LIST=y > # CONFIG_RT_MUTEX_TESTER is not set > # CONFIG_DEBUG_SPINLOCK is not set > # CONFIG_DEBUG_MUTEXES is not set > # CONFIG_DEBUG_LOCK_ALLOC is not set > # CONFIG_PROVE_LOCKING is not set > # CONFIG_LOCK_STAT is not set > # CONFIG_DEBUG_SPINLOCK_SLEEP is not set > # CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set > # CONFIG_DEBUG_KOBJECT is not set > # CONFIG_DEBUG_HIGHMEM is not set > # CONFIG_DEBUG_BUGVERBOSE is not set > CONFIG_DEBUG_INFO=y > # CONFIG_DEBUG_VM is not set > # CONFIG_DEBUG_LIST is not set > CONFIG_FRAME_POINTER=y > CONFIG_FORCED_INLINING=y > # CONFIG_FAULT_INJECTION is not set > CONFIG_EARLY_PRINTK=y > CONFIG_DEBUG_STACKOVERFLOW=y > # CONFIG_DEBUG_STACK_USAGE is not set > # CONFIG_DEBUG_PAGEALLOC is not set > # CONFIG_DEBUG_RODATA is not set > # CONFIG_4KSTACKS is not set > CONFIG_X86_FIND_SMP_CONFIG=y > CONFIG_X86_MPPARSE=y > CONFIG_DOUBLEFAULT=y > CONFIG_KDB=y > # CONFIG_KDB_MODULES is not set > # CONFIG_KDB_OFF is not set > CONFIG_KDB_CONTINUE_CATASTROPHIC=0 > > # > # Security options > # > # CONFIG_KEYS is not set > # CONFIG_SECURITY is not set > CONFIG_XOR_BLOCKS=y > CONFIG_ASYNC_CORE=y > CONFIG_ASYNC_MEMCPY=y > CONFIG_ASYNC_XOR=y > # CONFIG_CRYPTO is not set > > # > # Library routines > # > # CONFIG_CRC_CCITT is not set > # CONFIG_CRC16 is not set > # CONFIG_CRC_ITU_T is not set > # CONFIG_CRC32 is not set > # CONFIG_CRC7 is not set > # CONFIG_LIBCRC32C is not set > CONFIG_PLIST=y > CONFIG_HAS_IOMEM=y > CONFIG_HAS_IOPORT=y > CONFIG_HAS_DMA=y > CONFIG_GENERIC_HARDIRQS=y > CONFIG_GENERIC_IRQ_PROBE=y > CONFIG_GENERIC_PENDING_IRQ=y > CONFIG_X86_SMP=y > CONFIG_X86_HT=y > CONFIG_X86_BIOS_REBOOT=y > CONFIG_X86_TRAMPOLINE=y > CONFIG_KTIME_SCALAR=y -- Mark Goodwin markgw@sgi.com Engineering Manager for XFS and PCP Phone: +61-3-99631937 SGI Australian Software Group Cell: +61-4-18969583 ------------------------------------------------------------- From owner-xfs@oss.sgi.com Thu Mar 6 22:18:08 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 06 Mar 2008 22:18:28 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: **** X-Spam-Status: No, score=4.2 required=5.0 tests=BAYES_80,INVALID_DATE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m276I4YG013359 for ; Thu, 6 Mar 2008 22:18:08 -0800 X-ASG-Debug-ID: 1204870714-74fb03200000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mudsharkstreetwear.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 0C28566760E for ; Thu, 6 Mar 2008 22:18:34 -0800 (PST) Received: from mudsharkstreetwear.com (mudsharkstreetwear.com [67.212.225.116]) by cuda.sgi.com with ESMTP id hFJXdk8VhkwaXExf for ; Thu, 06 Mar 2008 22:18:34 -0800 (PST) Received: (from mudsharkstreetwear@localhost) by mudsharkstreetwear.com (8.13.1/8.13.1) id m276IYHg026148; Thu, 6 Mar 2008 23:18:34 -0700 To: linux-xfs@oss.sgi.com X-ASG-Orig-Subj: Confirm Your E-mail Address Subject: Confirm Your E-mail Address Message-ID: From: KSU SUPORT TEAM Reply-To: KSU SUPORT TEAM Date: 07:03:2008 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Barracuda-Connect: mudsharkstreetwear.com[67.212.225.116] X-Barracuda-Start-Time: 1204870715 X-Barracuda-Bayes: INNOCENT GLOBAL 0.5000 1.0000 0.0000 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 1.77 X-Barracuda-Spam-Status: No, SCORE=1.77 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=INVALID_DATE, INVALID_DATE_2 X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.44112 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 INVALID_DATE Invalid Date: header (not RFC 2822) 1.76 INVALID_DATE_2 Invalid Date: header (not RFC 2822) X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14792 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: rice.helpdesk@y7mail.com Precedence: bulk X-list: xfs Dear User, We wrote to you on 28th February 2008 advising that you change the password on your account in order to prevent any unauthorised account access following the network intrusion we previously communicated. we have found the vulnerability that caused this issue, and have instigated a system wide security audit to improve and enhance our current security, in order to continue using our services you are require to update you account details below. To complete your account verification, you must reply to this email immediately and enter your account details below. Username: (**************) password: (**************) Failure to do this will immediately render your account deactivated from our database. We apologise for the inconvenience that this will cause you during this period, but trust you understand that our primary concern is for our customers and for the security of their data. our customers are totally secure KSU SUPORT TEAM From owner-xfs@oss.sgi.com Fri Mar 7 01:13:09 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 07 Mar 2008 01:13:29 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,J_CHICKENPOX_24, J_CHICKENPOX_53 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m279D6P7025897 for ; Fri, 7 Mar 2008 01:13:09 -0800 X-ASG-Debug-ID: 1204881214-690f005d0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from tyo201.gate.nec.co.jp (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id EB48E124F6BE for ; Fri, 7 Mar 2008 01:13:35 -0800 (PST) Received: from tyo201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.193]) by cuda.sgi.com with ESMTP id hVgmQuiuU6KOKQ4N for ; Fri, 07 Mar 2008 01:13:35 -0800 (PST) Received: from mailgate3.nec.co.jp (mailgate54B.nec.co.jp [10.7.69.195]) by tyo201.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id m279DWHf006590; Fri, 7 Mar 2008 18:13:32 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id m279DW309098; Fri, 7 Mar 2008 18:13:32 +0900 (JST) Received: from shoin.jp.nec.com (shoin.jp.nec.com [10.26.220.3]) by mailsv.nec.co.jp (8.13.8/8.13.4) with ESMTP id m279DWUE011339; Fri, 7 Mar 2008 18:13:32 +0900 (JST) Received: from TNESB07336 ([10.64.168.65] [10.64.168.65]) by mail.jp.nec.com with ESMTP; Fri, 7 Mar 2008 18:13:32 +0900 To: linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, xfs@oss.sgi.com, dm-devel@redhat.com Cc: "linux-kernel@vger.kernel.org" X-ASG-Orig-Subj: [RFC] freeze feature ver 1.0 Subject: [RFC] freeze feature ver 1.0 In-reply-to: <20080219202706t-sato@mail.jp.nec.com> References: <20080219202706t-sato@mail.jp.nec.com> Message-Id: <20080307181331t-sato@mail.jp.nec.com> Mime-Version: 1.0 X-Mailer: WeMail32[2.51] ID:1K0086 From: Takashi Sato Date: Fri, 7 Mar 2008 18:13:31 +0900 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Barracuda-Connect: TYO201.gate.nec.co.jp[202.32.8.193] X-Barracuda-Start-Time: 1204881215 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.44123 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14793 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: t-sato@yk.jp.nec.com Precedence: bulk X-list: xfs Hi, I have re-based my freeze patch from linux-2.6.25-rc3 to linux-2.6.25-rc4. There is no functional change from the previous version. All of comments from ML have already been reflected in this patch. The ioctls for the freeze feature are below. o Freeze the filesystem int ioctl(int fd, int FIFREEZE, long *timeval) fd: The file descriptor of the mountpoint FIFREEZE: request code for the freeze timeval: the timeout period in seconds If it's 0 or 1, the timeout isn't set. This special case of "1" is implemented to keep the compatibility with XFS applications. Return value: 0 if the operation succeeds. Otherwise, -1 o Reset the timeout period This is useful for the application to set the timeval more accurately. For example, the freezer resets the timeval to 10 seconds every 5 seconds. In this approach, even if the freezer causes a deadlock by accessing the frozen filesystem, it will be solved by the timeout in 10 seconds and the freezer can recognize that at the next reset of timeval. int ioctl(int fd, int FIFREEZE_RESET_TIMEOUT, long *timeval) fd:file descriptor of mountpoint FIFREEZE_RESET_TIMEOUT: request code for reset of timeout period timeval: new timeout period in seconds Return value: 0 if the operation succeeds. Otherwise, -1 Error number: If the filesystem has already been unfrozen, errno is set to EINVAL. o Unfreeze the filesystem int ioctl(int fd, int FITHAW, long *timeval) fd: The file descriptor of the mountpoint FITHAW: request code for unfreeze timeval: Ignored Return value: 0 if the operation succeeds. Otherwise, -1 Any comments are very welcome. Cheers, Takashi Signed-off-by: Takashi Sato --- diff -uprN -X linux-2.6.25-rc4-freeze/Documentation/dontdiff linux-2.6.25-rc4/drivers/md/dm.c linux-2.6.25-rc4-freeze/dr ivers/md/dm.c --- linux-2.6.25-rc4/drivers/md/dm.c 2008-03-05 13:33:54.000000000 +0900 +++ linux-2.6.25-rc4-freeze/drivers/md/dm.c 2008-03-07 20:34:43.000000000 +0900 @@ -1407,7 +1407,7 @@ static int lock_fs(struct mapped_device WARN_ON(md->frozen_sb); - md->frozen_sb = freeze_bdev(md->suspended_bdev); + md->frozen_sb = freeze_bdev(md->suspended_bdev, 0); if (IS_ERR(md->frozen_sb)) { r = PTR_ERR(md->frozen_sb); md->frozen_sb = NULL; diff -uprN -X linux-2.6.25-rc4-freeze/Documentation/dontdiff linux-2.6.25-rc4/fs/block_dev.c linux-2.6.25-rc4-freeze/fs/ block_dev.c --- linux-2.6.25-rc4/fs/block_dev.c 2008-03-05 13:33:54.000000000 +0900 +++ linux-2.6.25-rc4-freeze/fs/block_dev.c 2008-03-07 20:34:43.000000000 +0900 @@ -284,6 +284,11 @@ static void init_once(struct kmem_cache INIT_LIST_HEAD(&bdev->bd_holder_list); #endif inode_init_once(&ei->vfs_inode); + + /* Initialize semaphore for freeze. */ + sema_init(&bdev->bd_freeze_sem, 1); + /* Setup freeze timeout function. */ + INIT_DELAYED_WORK(&bdev->bd_freeze_timeout, freeze_timeout); } static inline void __bd_forget(struct inode *inode) diff -uprN -X linux-2.6.25-rc4-freeze/Documentation/dontdiff linux-2.6.25-rc4/fs/buffer.c linux-2.6.25-rc4-freeze/fs/buf fer.c --- linux-2.6.25-rc4/fs/buffer.c 2008-03-05 13:33:54.000000000 +0900 +++ linux-2.6.25-rc4-freeze/fs/buffer.c 2008-03-07 20:34:43.000000000 +0900 @@ -190,17 +190,33 @@ int fsync_bdev(struct block_device *bdev /** * freeze_bdev -- lock a filesystem and force it into a consistent state - * @bdev: blockdevice to lock + * @bdev: blockdevice to lock + * @timeout_msec: timeout period * * This takes the block device bd_mount_sem to make sure no new mounts * happen on bdev until thaw_bdev() is called. * If a superblock is found on this device, we take the s_umount semaphore * on it to make sure nobody unmounts until the snapshot creation is done. + * If timeout_msec is bigger than 0, this registers the delayed work for + * timeout of the freeze feature. */ -struct super_block *freeze_bdev(struct block_device *bdev) +struct super_block *freeze_bdev(struct block_device *bdev, long timeout_msec) { struct super_block *sb; + down(&bdev->bd_freeze_sem); + sb = get_super_without_lock(bdev); + + /* If super_block has been already frozen, return. */ + if (sb && sb->s_frozen != SB_UNFROZEN) { + put_super(sb); + up(&bdev->bd_freeze_sem); + return sb; + } + + if (sb) + put_super(sb); + down(&bdev->bd_mount_sem); sb = get_super(bdev); if (sb && !(sb->s_flags & MS_RDONLY)) { @@ -219,6 +235,13 @@ struct super_block *freeze_bdev(struct b } sync_blockdev(bdev); + + /* Setup unfreeze timer. */ + if (timeout_msec > 0) + add_freeze_timeout(bdev, timeout_msec); + + up(&bdev->bd_freeze_sem); + return sb; /* thaw_bdev releases s->s_umount and bd_mount_sem */ } EXPORT_SYMBOL(freeze_bdev); @@ -232,6 +255,16 @@ EXPORT_SYMBOL(freeze_bdev); */ void thaw_bdev(struct block_device *bdev, struct super_block *sb) { + down(&bdev->bd_freeze_sem); + + if (sb && sb->s_frozen == SB_UNFROZEN) { + up(&bdev->bd_freeze_sem); + return; + } + + /* Delete unfreeze timer. */ + del_freeze_timeout(bdev); + if (sb) { BUG_ON(sb->s_bdev != bdev); @@ -244,6 +277,8 @@ void thaw_bdev(struct block_device *bdev } up(&bdev->bd_mount_sem); + + up(&bdev->bd_freeze_sem); } EXPORT_SYMBOL(thaw_bdev); diff -uprN -X linux-2.6.25-rc4-freeze/Documentation/dontdiff linux-2.6.25-rc4/fs/ioctl.c linux-2.6.25-rc4-freeze/fs/ioct l.c --- linux-2.6.25-rc4/fs/ioctl.c 2008-03-05 13:33:54.000000000 +0900 +++ linux-2.6.25-rc4-freeze/fs/ioctl.c 2008-03-07 20:40:03.000000000 +0900 @@ -13,6 +13,7 @@ #include #include #include +#include #include @@ -181,6 +182,102 @@ int do_vfs_ioctl(struct file *filp, unsi } else error = -ENOTTY; break; + + case FIFREEZE: { + long timeout_sec; + long timeout_msec; + struct super_block *sb = filp->f_path.dentry->d_inode->i_sb; + + if (!capable(CAP_SYS_ADMIN)) { + error = -EPERM; + break; + } + + /* If filesystem doesn't support freeze feature, return. */ + if (sb->s_op->write_super_lockfs == NULL) { + error = -EINVAL; + break; + } + + /* arg(sec) to tick value. */ + error = get_user(timeout_sec, (long __user *) arg); + if (error != 0) + break; + /* + * If 1 is specified as the timeout period, + * it will be changed into 0 to keep the compatibility + * of XFS application(xfs_freeze). + */ + if (timeout_sec < 0) { + error = -EINVAL; + break; + } else if (timeout_sec < 2) { + timeout_sec = 0; + } + + timeout_msec = timeout_sec * 1000; + /* overflow case */ + if (timeout_msec < 0) { + error = -EINVAL; + break; + } + + /* Freeze. */ + freeze_bdev(sb->s_bdev, timeout_msec); + + break; + } + + case FITHAW: { + struct super_block *sb = filp->f_path.dentry->d_inode->i_sb; + + if (!capable(CAP_SYS_ADMIN)) { + error = -EPERM; + break; + } + + /* Thaw. */ + thaw_bdev(sb->s_bdev, sb); + break; + } + + case FIFREEZE_RESET_TIMEOUT: { + long timeout_sec; + long timeout_msec; + struct super_block *sb + = filp->f_path.dentry->d_inode->i_sb; + + if (!capable(CAP_SYS_ADMIN)) { + error = -EPERM; + break; + } + + /* arg(sec) to tick value */ + error = get_user(timeout_sec, (long __user *) arg); + if (error) + break; + timeout_msec = timeout_sec * 1000; + if (timeout_msec < 0) { + error = -EINVAL; + break; + } + + if (sb) { + down(&sb->s_bdev->bd_freeze_sem); + if (sb->s_frozen == SB_UNFROZEN) { + up(&sb->s_bdev->bd_freeze_sem); + error = -EINVAL; + break; + } + /* setup unfreeze timer */ + if (timeout_msec > 0) + add_freeze_timeout(sb->s_bdev, + timeout_msec); + up(&sb->s_bdev->bd_freeze_sem); + } + break; + } + default: if (S_ISREG(filp->f_path.dentry->d_inode->i_mode)) error = file_ioctl(filp, cmd, arg); diff -uprN -X linux-2.6.25-rc4-freeze/Documentation/dontdiff linux-2.6.25-rc4/fs/super.c linux-2.6.25-rc4-freeze/fs/supe r.c --- linux-2.6.25-rc4/fs/super.c 2008-03-05 13:33:54.000000000 +0900 +++ linux-2.6.25-rc4-freeze/fs/super.c 2008-03-07 20:36:25.000000000 +0900 @@ -154,7 +154,7 @@ int __put_super_and_need_restart(struct * Drops a temporary reference, frees superblock if there's no * references left. */ -static void put_super(struct super_block *sb) +void put_super(struct super_block *sb) { spin_lock(&sb_lock); __put_super(sb); @@ -507,6 +507,36 @@ rescan: EXPORT_SYMBOL(get_super); +/* + * get_super_without_lock - Get super_block from block_device without lock. + * @bdev: block device struct + * + * Scan the superblock list and finds the superblock of the file system + * mounted on the block device given. This doesn't lock anyone. + * %NULL is returned if no match is found. + */ +struct super_block *get_super_without_lock(struct block_device *bdev) +{ + struct super_block *sb; + + if (!bdev) + return NULL; + + spin_lock(&sb_lock); + list_for_each_entry(sb, &super_blocks, s_list) { + if (sb->s_bdev == bdev) { + if (sb->s_root) { + sb->s_count++; + spin_unlock(&sb_lock); + return sb; + } + } + } + spin_unlock(&sb_lock); + return NULL; +} +EXPORT_SYMBOL(get_super_without_lock); + struct super_block * user_get_super(dev_t dev) { struct super_block *sb; @@ -952,3 +982,55 @@ struct vfsmount *kern_mount_data(struct } EXPORT_SYMBOL_GPL(kern_mount_data); + +/* + * freeze_timeout - Thaw the filesystem. + * + * @work: work queue (delayed_work.work) + * + * Called by the delayed work when elapsing the timeout period. + * Thaw the filesystem. + */ +void freeze_timeout(struct work_struct *work) +{ + struct block_device *bd = container_of(work, + struct block_device, bd_freeze_timeout.work); + + struct super_block *sb = get_super_without_lock(bd); + + thaw_bdev(bd, sb); + + if (sb) + put_super(sb); +} +EXPORT_SYMBOL_GPL(freeze_timeout); + +/* + * add_freeze_timeout - Add timeout for freeze. + * + * @bdev: block device struct + * @timeout_msec: timeout period + * + * Add the delayed work for freeze timeout to the delayed work queue. + */ +void add_freeze_timeout(struct block_device *bdev, long timeout_msec) +{ + s64 timeout_jiffies = msecs_to_jiffies(timeout_msec); + + /* Set delayed work queue */ + cancel_delayed_work(&bdev->bd_freeze_timeout); + schedule_delayed_work(&bdev->bd_freeze_timeout, timeout_jiffies); +} + +/* + * del_freeze_timeout - Delete timeout for freeze. + * + * @bdev: block device struct + * + * Delete the delayed work for freeze timeout from the delayed work queue. + */ +void del_freeze_timeout(struct block_device *bdev) +{ + if (delayed_work_pending(&bdev->bd_freeze_timeout)) + cancel_delayed_work(&bdev->bd_freeze_timeout); +} diff -uprN -X linux-2.6.25-rc4-freeze/Documentation/dontdiff linux-2.6.25-rc4/fs/xfs/linux-2.6/xfs_ioctl.c linux-2.6.25- rc4-freeze/fs/xfs/linux-2.6/xfs_ioctl.c --- linux-2.6.25-rc4/fs/xfs/linux-2.6/xfs_ioctl.c 2008-03-05 13:33:54.000000000 +0900 +++ linux-2.6.25-rc4-freeze/fs/xfs/linux-2.6/xfs_ioctl.c 2008-03-07 20:34:43.000000000 +0900 @@ -911,7 +911,7 @@ xfs_ioctl( return -EPERM; if (inode->i_sb->s_frozen == SB_UNFROZEN) - freeze_bdev(inode->i_sb->s_bdev); + freeze_bdev(inode->i_sb->s_bdev, 0); return 0; case XFS_IOC_THAW: diff -uprN -X linux-2.6.25-rc4-freeze/Documentation/dontdiff linux-2.6.25-rc4/fs/xfs/xfs_fsops.c linux-2.6.25-rc4-freeze /fs/xfs/xfs_fsops.c --- linux-2.6.25-rc4/fs/xfs/xfs_fsops.c 2008-03-05 13:33:54.000000000 +0900 +++ linux-2.6.25-rc4-freeze/fs/xfs/xfs_fsops.c 2008-03-07 20:34:43.000000000 +0900 @@ -623,7 +623,7 @@ xfs_fs_goingdown( { switch (inflags) { case XFS_FSOP_GOING_FLAGS_DEFAULT: { - struct super_block *sb = freeze_bdev(mp->m_super->s_bdev); + struct super_block *sb = freeze_bdev(mp->m_super->s_bdev, 0); if (sb && !IS_ERR(sb)) { xfs_force_shutdown(mp, SHUTDOWN_FORCE_UMOUNT); diff -uprN -X linux-2.6.25-rc4-freeze/Documentation/dontdiff linux-2.6.25-rc4/include/linux/buffer_head.h linux-2.6.25-r c4-freeze/include/linux/buffer_head.h --- linux-2.6.25-rc4/include/linux/buffer_head.h 2008-03-05 13:33:54.000000000 +0900 +++ linux-2.6.25-rc4-freeze/include/linux/buffer_head.h 2008-03-07 20:34:43.000000000 +0900 @@ -170,7 +170,7 @@ int sync_blockdev(struct block_device *b void __wait_on_buffer(struct buffer_head *); wait_queue_head_t *bh_waitq_head(struct buffer_head *bh); int fsync_bdev(struct block_device *); -struct super_block *freeze_bdev(struct block_device *); +struct super_block *freeze_bdev(struct block_device *, long timeout_msec); void thaw_bdev(struct block_device *, struct super_block *); int fsync_super(struct super_block *); int fsync_no_super(struct block_device *); diff -uprN -X linux-2.6.25-rc4-freeze/Documentation/dontdiff linux-2.6.25-rc4/include/linux/fs.h linux-2.6.25-rc4-freeze /include/linux/fs.h --- linux-2.6.25-rc4/include/linux/fs.h 2008-03-05 13:33:54.000000000 +0900 +++ linux-2.6.25-rc4-freeze/include/linux/fs.h 2008-03-07 20:34:43.000000000 +0900 @@ -8,6 +8,7 @@ #include #include +#include /* * It's silly to have NR_OPEN bigger than NR_FILE, but you can change @@ -223,6 +224,9 @@ extern int dir_notify_enable; #define BMAP_IOCTL 1 /* obsolete - kept for compatibility */ #define FIBMAP _IO(0x00,1) /* bmap access */ #define FIGETBSZ _IO(0x00,2) /* get the block size used for bmap */ +#define FIFREEZE _IOWR('X', 119, int) /* Freeze */ +#define FITHAW _IOWR('X', 120, int) /* Thaw */ +#define FIFREEZE_RESET_TIMEOUT _IO(0x00, 3) /* Reset freeze timeout */ #define FS_IOC_GETFLAGS _IOR('f', 1, long) #define FS_IOC_SETFLAGS _IOW('f', 2, long) @@ -548,6 +552,11 @@ struct block_device { * care to not mess up bd_private for that case. */ unsigned long bd_private; + + /* Delayed work for freeze */ + struct delayed_work bd_freeze_timeout; + /* Semaphore for freeze */ + struct semaphore bd_freeze_sem; }; /* @@ -1926,7 +1935,9 @@ extern int do_vfs_ioctl(struct file *fil extern void get_filesystem(struct file_system_type *fs); extern void put_filesystem(struct file_system_type *fs); extern struct file_system_type *get_fs_type(const char *name); +extern void put_super(struct super_block *sb); extern struct super_block *get_super(struct block_device *); +extern struct super_block *get_super_without_lock(struct block_device *); extern struct super_block *user_get_super(dev_t); extern void drop_super(struct super_block *sb); @@ -2097,5 +2108,9 @@ int proc_nr_files(struct ctl_table *tabl int get_filesystem_list(char * buf); +extern void add_freeze_timeout(struct block_device *bdev, long timeout_msec); +extern void del_freeze_timeout(struct block_device *bdev); +extern void freeze_timeout(struct work_struct *work); + #endif /* __KERNEL__ */ #endif /* _LINUX_FS_H */ From owner-xfs@oss.sgi.com Fri Mar 7 01:33:46 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 07 Mar 2008 01:34:06 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_31, J_CHICKENPOX_45,J_CHICKENPOX_54,J_CHICKENPOX_61,J_CHICKENPOX_62, J_CHICKENPOX_63,J_CHICKENPOX_75 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m279XiHM026747 for ; Fri, 7 Mar 2008 01:33:46 -0800 X-ASG-Debug-ID: 1204882452-698200bc0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.valinux.co.jp (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 148D7F38257 for ; Fri, 7 Mar 2008 01:34:13 -0800 (PST) Received: from mail.valinux.co.jp (fms-01.valinux.co.jp [210.128.90.1]) by cuda.sgi.com with ESMTP id vie2A3CIYrVPbm4a for ; Fri, 07 Mar 2008 01:34:13 -0800 (PST) Received: from dhcp032.local.valinux.co.jp (vagw.valinux.co.jp [210.128.90.14]) by mail.valinux.co.jp (Postfix) with ESMTP id 4B1912DC9B2 for ; Fri, 7 Mar 2008 18:34:11 +0900 (JST) Date: Fri, 07 Mar 2008 18:34:09 +0900 From: IWAMOTO Toshihiro To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH] prototype file data inode inlining Subject: [PATCH] prototype file data inode inlining User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.1 (x86_64-pc-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20080307093411.4B1912DC9B2@mail.valinux.co.jp> X-Barracuda-Connect: fms-01.valinux.co.jp[210.128.90.1] X-Barracuda-Start-Time: 1204882454 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.44123 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14794 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: iwamoto@valinux.co.jp Precedence: bulk X-list: xfs Hi, I've done a prototype implementation of file data inlining in inodes a while ago. It was originally meant to solve a performance problem with a large number of small files at some customer site. Although I measured some performance gains, a different workaround has been adopted due to the patch quality problem. As I'm not asking for inclusion, the patch hasn't been ported to the current kernel version. This patch might be useful if someone has a similar performance problem and would like to see if file inlining helps or not. Some random notes and the patch itself follows. Inlined file data are written from xfs_page_state_convert(). The xfs_trans related operations in that function is to get inode written on disk and isn't for crash consistency. Small files are made inlined when created. Non inlined files don't get inlined when they are truncated. xfs_bmap_local_to_extents() has been modified to work with file data, but logging isn't implemented. A machine crash can cause data corruption. O_SYNC may behave incorrectly. Use of attribute forks isn't considered and likely has issues. diff -urp linux-2.6.12.5.orig/fs/xfs/linux-2.6/xfs_aops.c linux-2.6.12.5/fs/xfs/linux-2.6/xfs_aops.c --- linux-2.6.12.5.orig/fs/xfs/linux-2.6/xfs_aops.c 2005-08-15 09:20:18.000000000 +0900 +++ linux-2.6.12.5/fs/xfs/linux-2.6/xfs_aops.c 2008-03-05 18:05:32.383592506 +0900 @@ -49,6 +49,7 @@ #include "xfs_dir2_sf.h" #include "xfs_dinode.h" #include "xfs_inode.h" +#include "xfs_inode_item.h" #include "xfs_error.h" #include "xfs_rw.h" #include "xfs_iomap.h" @@ -567,6 +568,7 @@ xfs_submit_page( if (bh_count) { for (i = 0; i < bh_count; i++) { bh = bh_arr[i]; + BUG_ON(bh->b_bdev == NULL); mark_buffer_async_write(bh); if (buffer_unwritten(bh)) set_buffer_unwritten_io(bh); @@ -725,6 +727,10 @@ xfs_page_state_convert( { struct buffer_head *bh_arr[MAX_BUF_PER_PAGE], *bh, *head; xfs_iomap_t *iomp, iomap; + vnode_t *vp = LINVFS_GET_VP(inode); + xfs_inode_t *ip = XFS_BHVTOI(vp->v_fbhv); + xfs_trans_t *tp; + xfs_mount_t *mp = ip->i_mount; loff_t offset; unsigned long p_offset = 0; __uint64_t end_offset; @@ -740,16 +746,18 @@ xfs_page_state_convert( offset = i_size_read(inode); end_index = offset >> PAGE_CACHE_SHIFT; last_index = (offset - 1) >> PAGE_CACHE_SHIFT; + end_offset = min_t(unsigned long long, + (loff_t)(page->index + 1) << PAGE_CACHE_SHIFT, offset); if (page->index >= end_index) { if ((page->index >= end_index + 1) || !(i_size_read(inode) & (PAGE_CACHE_SIZE - 1))) { + if (printk_ratelimit()) + printk("xfs_psc: i_size %d\n", i_size_read(inode)); err = -EIO; goto error; } } - end_offset = min_t(unsigned long long, - (loff_t)(page->index + 1) << PAGE_CACHE_SHIFT, offset); offset = (loff_t)page->index << PAGE_CACHE_SHIFT; /* @@ -765,6 +773,58 @@ xfs_page_state_convert( p_offset = 0; bh = head = page_buffers(page); + if (ip->i_d.di_format == XFS_DINODE_FMT_LOCAL && + end_offset <= XFS_IFORK_DSIZE(ip)) { + char *v; + + if (printk_ratelimit()) + printk("xfs_psc: %llu %d\n", end_offset, XFS_IFORK_DSIZE(ip)); + if (end_offset > ip->i_df.if_bytes) + xfs_idata_realloc(ip, end_offset - ip->i_df.if_bytes, + XFS_DATA_FORK); + if ((!PageDirty(page)) && printk_ratelimit()) + printk("xfs_page_state_convert: is clean\n"); + clear_page_dirty(page); + clear_buffer_dirty(bh); /* XXX */ + v = kmap(page); + memcpy(ip->i_df.if_u1.if_data, v, end_offset); + kunmap(page); + set_buffer_uptodate(bh); + SetPageUptodate(page); + tp = xfs_trans_alloc(mp, XFS_TRANS_WRITE_SYNC); + if ((err = xfs_trans_reserve(tp, 0, + XFS_SWRITE_LOG_RES(mp), + 0, 0, 0))) { + /* Transaction reserve failed */ + xfs_trans_cancel(tp, 0); + } else { + /* Transaction reserve successful */ + xfs_ilock(ip, XFS_ILOCK_EXCL); + xfs_trans_ijoin(tp, ip, XFS_ILOCK_EXCL); + xfs_trans_ihold(tp, ip); + xfs_trans_log_inode(tp, ip, XFS_ILOG_CORE | XFS_ILOG_DDATA); + /* XXX O_SYNC handled by xfs_write?? */ + /* xfs_trans_set_sync(tp); */ + err = xfs_trans_commit(tp, 0, NULL); + xfs_iunlock(ip, XFS_ILOCK_EXCL); + } + ASSERT(err == 0); + unlock_page(page); /* XXX */ + return 0; + } + + if (ip->i_d.di_format == XFS_DINODE_FMT_LOCAL) { + /* + * Data no longer fits in an inode. + * Clear the mapped bit so that xfs_bmap_local_to_extents() + * gets called from xfs_bmapi(). + */ + clear_buffer_mapped(bh); + unmapped = 1; + if (printk_ratelimit()) + printk("xfs_psc: clearing LOCAL ino %llu %llu %x %x\n", + ip->i_ino, end_offset, bh->b_state, page->flags); + } do { if (offset >= end_offset) break; @@ -897,9 +957,15 @@ xfs_page_state_convert( startio, unmapped, tlast); } + BUG_ON(ip->i_d.di_format == XFS_DINODE_FMT_LOCAL && + end_offset > XFS_IFORK_DSIZE(ip)); return page_dirty; error: + if (printk_ratelimit()) + printk("xfs_psc: error\n"); + BUG_ON(ip->i_d.di_format == XFS_DINODE_FMT_LOCAL && + end_offset > XFS_IFORK_DSIZE(ip)); for (i = 0; i < cnt; i++) { unlock_buffer(bh_arr[i]); } @@ -929,6 +995,7 @@ __linvfs_get_block( bmapi_flags_t flags) { vnode_t *vp = LINVFS_GET_VP(inode); + xfs_inode_t *ip = XFS_BHVTOI(vp->v_fbhv); xfs_iomap_t iomap; int retpbbm = 1; int error; @@ -940,6 +1007,29 @@ __linvfs_get_block( else size = 1 << inode->i_blkbits; + if (ip->i_d.di_format == XFS_DINODE_FMT_LOCAL) { + char *v; + v = kmap(bh_result->b_page); + if (printk_ratelimit()) + printk("__linvfs_get_block: memcpy ino %llu, %d bytes\n", + ip->i_ino, (int)ip->i_d.di_size); + if (ip->i_df.if_u1.if_data == NULL || + ip->i_d.di_size > ip->i_df.if_bytes) + /* seek happened beyond EOF */ + xfs_idata_realloc(ip, + ip->i_d.di_size - ip->i_df.if_bytes, XFS_DATA_FORK); + memcpy(v, ip->i_df.if_u1.if_data, (int)ip->i_d.di_size); + memset(v + (int)ip->i_d.di_size, 0, + PAGE_SIZE - ip->i_d.di_size); /* XXX */ + kunmap(bh_result->b_page); + set_buffer_uptodate(bh_result); + /* XXX do_mpage_readpage apparently needs this to be mapped */ + set_buffer_mapped(bh_result); + SetPageUptodate(bh_result->b_page); /* XXX */ + if (PageDirty(bh_result->b_page) && printk_ratelimit()) /* XXX */ + printk("__linvfs_get_block: is dirty\n"); + return 0; + } VOP_BMAP(vp, offset, size, create ? flags : BMAPI_READ, &iomap, &retpbbm, error); if (error) @@ -1143,6 +1233,7 @@ linvfs_writepage( int need_trans; int delalloc, unmapped, unwritten; struct inode *inode = page->mapping->host; + xfs_inode_t *ip; xfs_page_trace(XFS_WRITEPAGE_ENTER, inode, page, 0); @@ -1164,14 +1255,28 @@ linvfs_writepage( need_trans = delalloc + unmapped + unwritten; } + ip = XFS_BHVTOI(LINVFS_GET_VP(inode)->v_fbhv); + /* see xfs_page_state_convert */ + /* XXX dup code */ + if (ip->i_d.di_format == XFS_DINODE_FMT_LOCAL && + i_size_read(inode) > XFS_IFORK_DSIZE(ip)) { + unmapped = 1; + need_trans = 1; + } + /* * If we need a transaction and the process flags say * we are already in a transaction, or no IO is allowed * then mark the page dirty again and leave the page * as is. */ - if (PFLAGS_TEST_FSTRANS() && need_trans) + if (PFLAGS_TEST_FSTRANS() && need_trans) { + if (ip->i_d.di_format == XFS_DINODE_FMT_LOCAL && + printk_ratelimit()) + printk("linvfs_writepage: out_fail ino %llu\n", + ip->i_ino); goto out_fail; + } /* * Delay hooking up buffer heads until we have diff -urp linux-2.6.12.5.orig/fs/xfs/linux-2.6/xfs_lrw.c linux-2.6.12.5/fs/xfs/linux-2.6/xfs_lrw.c --- linux-2.6.12.5.orig/fs/xfs/linux-2.6/xfs_lrw.c 2005-08-15 09:20:18.000000000 +0900 +++ linux-2.6.12.5/fs/xfs/linux-2.6/xfs_lrw.c 2008-02-29 17:28:36.170355201 +0900 @@ -411,6 +411,8 @@ xfs_zero_last_block( { xfs_fileoff_t last_fsb; xfs_mount_t *mp; + vnode_t *vp = LINVFS_GET_VP(ip); + xfs_inode_t *xip = XFS_BHVTOI(vp->v_fbhv); int nimaps; int zero_offset; int zero_len; @@ -488,6 +490,7 @@ xfs_zero_eof( xfs_fsize_t end_size) /* terminal inode size */ { struct inode *ip = LINVFS_GET_IP(vp); + xfs_inode_t *xip = XFS_BHVTOI(vp->v_fbhv); xfs_fileoff_t start_zero_fsb; xfs_fileoff_t end_zero_fsb; xfs_fileoff_t prev_zero_fsb; @@ -507,6 +510,13 @@ xfs_zero_eof( mp = io->io_mount; + if (xip->i_d.di_format == XFS_DINODE_FMT_LOCAL) { + if (offset < xip->i_df.if_bytes) + memset(xip->i_df.if_u1.if_data + offset, 0, + xip->i_df.if_bytes - offset); + return 0; + } + /* * First handle zeroing the block on which isize resides. * We only zero a part of that block so it is handled specially. @@ -664,6 +674,9 @@ xfs_write( break; } + if (xip->i_d.di_format == XFS_DINODE_FMT_LOCAL && + printk_ratelimit()) /* XXX */ + printk("xfs_write: ino %llu, %lu bytes\n", xip->i_ino, ocount); count = ocount; pos = *offset; @@ -769,6 +782,21 @@ start: inode_update_time(inode, 1); } + if ((!(mp->m_flags & XFS_MOUNT_NOIFILE)) && + new_size > isize && /* XXX unneeded ? */ + new_size <= XFS_IFORK_DSIZE(xip)) { + xfs_fileoff_t last_block; + + /* XXX lock */ + error = xfs_bmap_last_offset(NULL, xip, &last_block, + XFS_DATA_FORK); + if (!error && !last_block) { + xip->i_d.di_format = XFS_DINODE_FMT_LOCAL; + xip->i_df.if_flags &= ~(XFS_IFEXTENTS | XFS_IFBROOT); + xip->i_df.if_flags |= XFS_IFINLINE; + } + } + /* * If the offset is beyond the size of the file, we have a couple * of things to do. First, if there is already space allocated @@ -855,6 +883,9 @@ retry: *offset, ioflags); ret = generic_file_buffered_write(iocb, iovp, segs, pos, offset, count, ret); + if (xip->i_d.di_format == XFS_DINODE_FMT_LOCAL && + printk_ratelimit()) /* XXX */ + printk("xfs_write: generic_file_buffered_write ino %llu, ret %d\n", xip->i_ino, ret); } current->backing_dev_info = NULL; diff -urp linux-2.6.12.5.orig/fs/xfs/xfs_bmap.c linux-2.6.12.5/fs/xfs/xfs_bmap.c --- linux-2.6.12.5.orig/fs/xfs/xfs_bmap.c 2005-08-15 09:20:18.000000000 +0900 +++ linux-2.6.12.5/fs/xfs/xfs_bmap.c 2008-02-29 17:28:36.207308945 +0900 @@ -3344,13 +3344,23 @@ xfs_bmap_local_to_extents( static char fname[] = "xfs_bmap_local_to_extents"; #endif xfs_ifork_t *ifp; /* inode fork pointer */ + int ifile = 0; +#if 0 /* * We don't want to deal with the case of keeping inode data inline yet. * So sending the data fork of a regular inode is invalid. */ ASSERT(!((ip->i_d.di_mode & S_IFMT) == S_IFREG && whichfork == XFS_DATA_FORK)); +#else + if ((ip->i_d.di_mode & S_IFMT) == S_IFREG && + whichfork == XFS_DATA_FORK) { + ifile = 1; + if (printk_ratelimit()) + printk("xfs_bmap_local_to_extents: ino %d\n", ip->i_ino); + } +#endif ifp = XFS_IFORK_PTR(ip, whichfork); ASSERT(XFS_IFORK_FORMAT(ip, whichfork) == XFS_DINODE_FMT_LOCAL); flags = 0; @@ -3386,10 +3396,12 @@ xfs_bmap_local_to_extents( ASSERT(args.fsbno != NULLFSBLOCK); ASSERT(args.len == 1); *firstblock = args.fsbno; + if (!ifile) { /* XXX */ bp = xfs_btree_get_bufl(args.mp, tp, args.fsbno, 0); memcpy((char *)XFS_BUF_PTR(bp), ifp->if_u1.if_data, ifp->if_bytes); xfs_trans_log_buf(tp, bp, 0, ifp->if_bytes - 1); + } xfs_idata_realloc(ip, -ifp->if_bytes, whichfork); xfs_iext_realloc(ip, 1, whichfork); ep = ifp->if_u1.if_extents; @@ -4628,6 +4640,10 @@ xfs_bmapi( nallocs = 0; cur = NULL; if (XFS_IFORK_FORMAT(ip, whichfork) == XFS_DINODE_FMT_LOCAL) { + if (!wr) { /* XXX */ + *nmap = 0; + return 0; + } ASSERT(wr && tp); if ((error = xfs_bmap_local_to_extents(tp, ip, firstblock, total, &logflags, whichfork))) diff -urp linux-2.6.12.5.orig/fs/xfs/xfs_clnt.h linux-2.6.12.5/fs/xfs/xfs_clnt.h --- linux-2.6.12.5.orig/fs/xfs/xfs_clnt.h 2005-08-15 09:20:18.000000000 +0900 +++ linux-2.6.12.5/fs/xfs/xfs_clnt.h 2008-02-29 17:36:25.283560299 +0900 @@ -106,5 +106,6 @@ struct xfs_mount_args { #define XFSMNT_IHASHSIZE 0x20000000 /* inode hash table size */ #define XFSMNT_DIRSYNC 0x40000000 /* sync creat,link,unlink,rename * symlink,mkdir,rmdir,mknod */ +#define XFSMNT_NOIFILE 0x80000000 /* do not create inlined file */ #endif /* __XFS_CLNT_H__ */ diff -urp linux-2.6.12.5.orig/fs/xfs/xfs_inode.c linux-2.6.12.5/fs/xfs/xfs_inode.c --- linux-2.6.12.5.orig/fs/xfs/xfs_inode.c 2005-08-15 09:20:18.000000000 +0900 +++ linux-2.6.12.5/fs/xfs/xfs_inode.c 2008-02-29 17:28:36.260126921 +0900 @@ -283,6 +283,20 @@ xfs_inotobp( return 0; } +void +xfs_inode_buf_dump(xfs_buf_t *bp, u_short len) +{ + int pgs = len >> PAGE_SHIFT; + char *p; + int i, j; + + for(i = 0; i < pgs; i++) { + p = xfs_buf_offset(bp, i << PAGE_SHIFT); + for(j = PAGE_SIZE; j; j--) + printk(" %02x", *p++); + printk("\n"); + } +} /* * This routine is called to map an inode to the buffer containing @@ -413,6 +427,7 @@ xfs_itobp( mp->m_ddev_targp, (unsigned long long)imap.im_blkno, i, INT_GET(dip->di_core.di_magic, ARCH_CONVERT)); + xfs_inode_buf_dump(bp, BBTOB(imap.im_len)); #endif XFS_CORRUPTION_ERROR("xfs_itobp", XFS_ERRLEVEL_HIGH, mp, dip); @@ -506,6 +521,7 @@ xfs_iformat( case S_IFDIR: switch (INT_GET(dip->di_core.di_format, ARCH_CONVERT)) { case XFS_DINODE_FMT_LOCAL: +#if 0 /* * no local regular files yet */ @@ -518,7 +534,7 @@ xfs_iformat( ip->i_mount, dip); return XFS_ERROR(EFSCORRUPTED); } - +#endif di_size = INT_GET(dip->di_core.di_size, ARCH_CONVERT); if (unlikely(di_size > XFS_DFORK_DSIZE(dip, ip->i_mount))) { xfs_fs_cmn_err(CE_WARN, ip->i_mount, @@ -634,6 +650,9 @@ xfs_iformat_local( memcpy(ifp->if_u1.if_data, XFS_DFORK_PTR(dip, whichfork), size); ifp->if_flags &= ~XFS_IFEXTENTS; ifp->if_flags |= XFS_IFINLINE; + if ((ip->i_d.di_mode & S_IFMT) == S_IFREG && printk_ratelimit()) + printk("xfs_iformat_local: ino %llu %p, size %d\n", + ip->i_ino, ip, size); return 0; } @@ -1684,6 +1703,18 @@ xfs_itruncate_finish( unmap_len = last_block - first_unmap_block + 1; } while (!done) { + if (fork == XFS_DATA_FORK && + ip->i_d.di_format == XFS_DINODE_FMT_LOCAL) { + /* XXX realloc */ + /* XXX real_size */ + xfs_trans_log_inode(ntp, ip, XFS_ILOG_CORE); +#if 0 + ntp = xfs_trans_dup(*tp); + error = xfs_trans_commit(*tp, 0, NULL); +#endif + committed = 0; + done = 1; + } else { /* * Free up up to XFS_ITRUNC_MAX_EXTENTS. xfs_bunmapi() * will tell us whether it freed the entire range or @@ -1754,6 +1785,7 @@ xfs_itruncate_finish( } return error; } + } if (committed) { /* @@ -3026,6 +3058,8 @@ xfs_iflush_fork( ASSERT(ifp->if_u1.if_data != NULL); ASSERT(ifp->if_bytes <= XFS_IFORK_SIZE(ip, whichfork)); memcpy(cp, ifp->if_u1.if_data, ifp->if_bytes); + if (printk_ratelimit()) + printk("xfs_iflush_fork: copying %d\n", ifp->if_bytes); } if (whichfork == XFS_DATA_FORK) { if (unlikely(XFS_DIR_SHORTFORM_VALIDATE_ONDISK(mp, dip))) { @@ -3414,6 +3448,7 @@ xfs_iflush_int( xfs_cmn_err(XFS_PTAG_IFLUSH, CE_ALERT, mp, "xfs_iflush: Bad inode %Lu magic number 0x%x, ptr 0x%p", ip->i_ino, (int) INT_GET(dip->di_core.di_magic, ARCH_CONVERT), dip); + xfs_inode_buf_dump(bp, BBTOB(ip->i_len)); goto corrupt_out; } if (XFS_TEST_ERROR(ip->i_d.di_magic != XFS_DINODE_MAGIC, @@ -3421,12 +3456,14 @@ xfs_iflush_int( xfs_cmn_err(XFS_PTAG_IFLUSH, CE_ALERT, mp, "xfs_iflush: Bad inode %Lu, ptr 0x%p, magic number 0x%x", ip->i_ino, ip, ip->i_d.di_magic); + xfs_inode_buf_dump(bp, BBTOB(ip->i_len)); goto corrupt_out; } if ((ip->i_d.di_mode & S_IFMT) == S_IFREG) { if (XFS_TEST_ERROR( (ip->i_d.di_format != XFS_DINODE_FMT_EXTENTS) && - (ip->i_d.di_format != XFS_DINODE_FMT_BTREE), + (ip->i_d.di_format != XFS_DINODE_FMT_BTREE) && + (ip->i_d.di_format != XFS_DINODE_FMT_LOCAL), mp, XFS_ERRTAG_IFLUSH_3, XFS_RANDOM_IFLUSH_3)) { xfs_cmn_err(XFS_PTAG_IFLUSH, CE_ALERT, mp, "xfs_iflush: Bad regular inode %Lu, ptr 0x%p", diff -urp linux-2.6.12.5.orig/fs/xfs/xfs_mount.h linux-2.6.12.5/fs/xfs/xfs_mount.h --- linux-2.6.12.5.orig/fs/xfs/xfs_mount.h 2005-08-15 09:20:18.000000000 +0900 +++ linux-2.6.12.5/fs/xfs/xfs_mount.h 2008-02-29 17:28:36.280412258 +0900 @@ -421,6 +421,7 @@ typedef struct xfs_mount { * allocation */ #define XFS_MOUNT_IHASHSIZE 0x00100000 /* inode hash table size */ #define XFS_MOUNT_DIRSYNC 0x00200000 /* synchronous directory ops */ +#define XFS_MOUNT_NOIFILE 0x00400000 /* * Default minimum read and write sizes. diff -urp linux-2.6.12.5.orig/fs/xfs/xfs_vfsops.c linux-2.6.12.5/fs/xfs/xfs_vfsops.c --- linux-2.6.12.5.orig/fs/xfs/xfs_vfsops.c 2005-08-15 09:20:18.000000000 +0900 +++ linux-2.6.12.5/fs/xfs/xfs_vfsops.c 2008-02-29 17:28:36.303523635 +0900 @@ -307,6 +307,9 @@ xfs_start_flags( if (ap->flags & XFSMNT_DIRSYNC) mp->m_flags |= XFS_MOUNT_DIRSYNC; + if (ap->flags & XFSMNT_NOIFILE) + mp->m_flags |= XFS_MOUNT_NOIFILE; + /* * no recovery flag requires a read-only mount */ @@ -1657,6 +1660,7 @@ xfs_vget( #define MNTOPT_64BITINODE "inode64" /* inodes can be allocated anywhere */ #define MNTOPT_IKEEP "ikeep" /* do not free empty inode clusters */ #define MNTOPT_NOIKEEP "noikeep" /* free empty inode clusters */ +#define MNTOPT_NOIFILE "noifile" /* do not create inlined file */ STATIC unsigned long suffix_strtoul(const char *cp, char **endp, unsigned int base) @@ -1815,6 +1819,8 @@ xfs_parseargs( args->flags &= ~XFSMNT_IDELETE; } else if (!strcmp(this_char, MNTOPT_NOIKEEP)) { args->flags |= XFSMNT_IDELETE; + } else if (!strcmp(this_char, MNTOPT_NOIFILE)) { + args->flags |= XFSMNT_NOIFILE; } else if (!strcmp(this_char, "osyncisdsync")) { /* no-op, this is now the default */ printk("XFS: osyncisdsync is now the default, option is deprecated.\n"); @@ -1886,6 +1892,7 @@ xfs_showargs( { XFS_MOUNT_OSYNCISOSYNC, "," MNTOPT_OSYNCISOSYNC }, { XFS_MOUNT_NOLOGFLUSH, "," MNTOPT_NOLOGFLUSH }, { XFS_MOUNT_IDELETE, "," MNTOPT_NOIKEEP }, + { XFS_MOUNT_NOIFILE, "," MNTOPT_NOIFILE }, { 0, NULL } }; struct proc_xfs_info *xfs_infop; From owner-xfs@oss.sgi.com Fri Mar 7 02:48:54 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 07 Mar 2008 02:49:13 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_23, J_CHICKENPOX_72 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m27AmnC5028460 for ; Fri, 7 Mar 2008 02:48:54 -0800 X-ASG-Debug-ID: 1204886958-4d7c01e10000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id B60AFF38F86 for ; Fri, 7 Mar 2008 02:49:19 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id xNjmMU7V9WY7VOey for ; Fri, 07 Mar 2008 02:49:19 -0800 (PST) Received: from hch by bombadil.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1JXa8c-0005D3-Mp for xfs@oss.sgi.com; Fri, 07 Mar 2008 10:49:18 +0000 Date: Fri, 7 Mar 2008 05:49:18 -0500 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: [Chris.Knadle@coredump.us: assfail during unmount xfs 2.6.24.3 [from 2.6.24.y git]] Subject: [Chris.Knadle@coredump.us: assfail during unmount xfs 2.6.24.3 [from 2.6.24.y git]] Message-ID: <20080307104918.GA20000@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.17 (2007-11-01) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1204886959 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.82 X-Barracuda-Spam-Status: No, SCORE=-1.82 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=PR0N_SUBJECT X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.44129 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.20 PR0N_SUBJECT Subject has letters around special characters (pr0n) X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14795 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs ----- Forwarded message from Chris Knadle ----- Date: Thu, 6 Mar 2008 23:29:07 -0500 From: Chris Knadle Subject: assfail during unmount xfs 2.6.24.3 [from 2.6.24.y git] To: linux-kernel@vger.kernel.org During the final unmount before reboot there was an assertion failure from XFS leading to the debug output below; I've included what was available on the screendump, which I handwrote + transcribed. [I also have screenshots from a 2.1 MP camera -- they're slightly ugly but usable.] CONFIG_KEXEC was not compiled in, so I was uanble to get a crashdump via SysRq. I'm sending this along in case someone working on the XFS fs can find + fix a bug. I'm not sending the kernel config in this first post just as not to spam everybody with it if it's not needed -- if desired just ask and I'll send it. Source used: 2.6.24.y from git -- 2.6.24.3. This is on my Desktop box, x86 system -- single P4 CPU @ 2.6 GHz, IDE disk attached to an onboard HighPoint HPT370 controller, and running Debian Sid. When replying please CC me, as I am not currently subscribed to the list. Cheers. -- Chris -- Chris Knadle Chris.Knadle@coredump.us ------------------- Cleaning up ifdown.... Deactivating swap...done. Unmounting local filesystems...done. Assertion failed: atomic_read(&mp->m_active_trans) == 0, file: fs/xfs/xfs_vfsops.c, line: 708 ------------[ cut here ]------------ kernel BUG at fs/xfs/support/debug.c:82! infalid opcode: 0000 [#1] Modules lined in: nvidia(P) xt_multiport iptable_filter ip_tables x_tables ppdev lp ac battery ipv6 ext2 mbcache joydev sidewinder kqemu loop snd_emu10k1_synth snd_emux_synth snd_seq_virmidi snd_seq_midi_emul snd_emu10k1 firmware_class snd_ac97_codec ac97_bus snd_util_mem snd_hwdep parport_pc parport snd_pcm_oss snd_pcm snd_page_alloc snd_mixer_oss psmouse rtc snd_deq_dummy pcspkr serio_raw evdev snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device emu10k1_gp gameport snd soundcore button i2c_i801 i2c_core intel_agp iTCO_wdt agpart shpchp pci_hotplug usbhid hid xfs ide_cd cdrom ata_piix ata_generic libata scsi_mod ide_disk floppy uhci_hcd usbcore hpt366 e1000 piix generic ide_core thermal processor fan Pid: 25313, comm: mount Tainted: P (2.6.24.3-686-initrd-crk1 #1) EIP: 0060:[>f8a67a3f>] EFLAGS: 00010292 CPU: 0 EIP is at assfail+0x1b/0x1f [xfs] EAX: 00000061 EBX: f7faa400 ECX: ffffffff EDX: c034bda0 ESI: dfc97000 EDI: f7faa400 EBP: db175e14 ESP: db175dcc DS: 007b ES: 007b FS: 0000 GS: 033 SS: 0068 Process mount (pid: 25313, ti=db174000 task=f7c32560 task.ti=db174000) Stack: f8a6cc60 f8a6c6b0 f8a6a135 000002c4 f8a57e38 f7faa400 f8a57ee7 00000000 dfc97000 f7faa400 db175e14 f8a66ebc 00000001 f8a7fd20 f7fbd400 00000000 00000001 c0162bd2 00000001 f7fbd43c ffffffff f7fbd400 c0174c1b 00000000 Call Trace: [] xfs_attr_quiesce+0x46/0x61 [xfs] [] xfs_mntupdate+0x84/0xbb [xfs] [] xfs_fs_remount+0x3d/0x57 [xfs] [] do_remount_sb+0xb5/0x101 [xfs] [] do_mount+0x5a9/0x65b [] __alloc_pages+0x5f/0x360 [] find_lock_page+0x15/0x67 [] handle_mm_fault+0x25a/0x52d [] __alloc_pages+0x5f/0x360 [] copy_mount_options+0x28/0x113 [] getname+0x87/0xaf [] sys_mount+0x72/0xa4 [] sysenter_past_esp+0x5f/0x85 ======================= Code: d7 6b c7 83 c3 08 81 fb c8 02 a8 f8 75 ee 5b c3 83 ec 10 89 4c 24 0c 89 54 24 08 89 44 24 04 c7 04 24 60 cc a6 f8 e8 0d ed 6a c7 <0f> 0b eb fe 56 53 83 ec 0c 89 c6 83 e6 07 9c 5b fa 89 0c 24 89 EIP: [] assfail+0x1b/0x1f [xfs] SS:ESP 0068:db175dcc ---[ end trace 65bd78ca1bf60304 ]--- WARNING: at kernel/exit.c:917 do_exit() Pid: 25313, comm: mount Tainted: P D 2.6.24.3-686-initrd-crk1 #1 [] do_exit+0x669/0x7a4 [] printk+0x1b/0x1f [] do_trap+0x0/0xbd [] do_invalid_op+0x0/0x8a [] assfail+0x1b/0x1f [xfs] [] xfs_attr_quiesce+0x46/0x61 [xfs] [] xfs_mntupdate+0x84/0xbb [xfs] [] xfs_fs_remount+0x3d/0x57 [xfs] [] do_remount_sb+0xb5/0x101 [] do_mount+0x5a9/0x65b [] __alloc_pages+0x5f/0x360 [] find_lock_page+0x15/0x67 [] handle_mm_fault+0x25a/0x52d [] __alloc_pages+0x5f/0x360 [] copy_mount_options+0x28/0x113 [] getname+0x87/0xaf [] sys_mount+0x72/0xa4 [] sysenter_past_esp+0x5f/0x85 ======================== /etc/rc6.d/S60umountroot: line17: 25313 Segmentation fault mount $MOUNT_FORCE_OPT -n -o remount,ro -t dummytype dummydev / 2>/dev/null ----- End forwarded message ----- From owner-xfs@oss.sgi.com Fri Mar 7 03:19:02 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 07 Mar 2008 03:19:20 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,MIME_8BIT_HEADER autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m27BJ10O029379 for ; Fri, 7 Mar 2008 03:19:02 -0800 X-ASG-Debug-ID: 1204888769-4e5a02480000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from rn-out-0910.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 6FC45F394A8 for ; Fri, 7 Mar 2008 03:19:30 -0800 (PST) Received: from rn-out-0910.google.com (rn-out-0910.google.com [64.233.170.186]) by cuda.sgi.com with ESMTP id tVSjiDERLZDqFvJo for ; Fri, 07 Mar 2008 03:19:30 -0800 (PST) Received: by rn-out-0910.google.com with SMTP id a43so695715rne.10 for ; Fri, 07 Mar 2008 03:19:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=+1+jB1icLTcLTGjk4/HZkCRBc1a2zkaxhzDHnf/jzgg=; b=ZEeOnNEgqMvPlbEAxNLDyxQnHnMasQ9VClPjZEqt6800dbvnP1OCCUjIdGArXoyudj0GJQwPkKeL2fxLD8R9IANETZNJntIwbM/syV+oJzijD4xEJvEYJyilgECbVZ5MlgIsbAYCPRpYFRf/oGjaeW6JoTjWVyrk+enpgRdwCeo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=RmxjW5BhgWKk2oRdZhlvjTrx4mTQXabnVsE0bJvSiBp/XMmopUKUwokAgyl8Nem7gNqc7WALzMI9vARR4kD/uyOeccc+dq9+fZqDP+/BC/Q2yiBvlvT6CT6LW2DEfWrmX+HuwrlEUmXlfp2KCVQ9VgRY4KRIFoEiTpoBxUb/ZHo= Received: by 10.150.178.6 with SMTP id a6mr431236ybf.22.1204888768434; Fri, 07 Mar 2008 03:19:28 -0800 (PST) Received: by 10.150.96.5 with HTTP; Fri, 7 Mar 2008 03:19:28 -0800 (PST) Message-ID: <1a4a774c0803070319j1eb8790ek3daae4a16b3e6256@mail.gmail.com> Date: Fri, 7 Mar 2008 12:19:28 +0100 From: "=?ISO-8859-1?Q?Christian_R=F8snes?=" To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS internal error xfs_trans_cancel at line 1150 of file fs/xfs/xfs_trans.c Subject: Re: XFS internal error xfs_trans_cancel at line 1150 of file fs/xfs/xfs_trans.c In-Reply-To: <1a4a774c0803060310w2642224w690ac8fa13f96ec@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <1a4a774c0802130251h657a52f7lb97942e7afdf6e3f@mail.gmail.com> <20080213214551.GR155407@sgi.com> <1a4a774c0803050553h7f6294cfq41c38f34ea92ceae@mail.gmail.com> <1a4a774c0803060310w2642224w690ac8fa13f96ec@mail.gmail.com> X-Barracuda-Connect: rn-out-0910.google.com[64.233.170.186] X-Barracuda-Start-Time: 1204888771 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.44131 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id m27BJ20O029381 X-archive-position: 14796 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: christian.rosnes@gmail.com Precedence: bulk X-list: xfs On Thu, Mar 6, 2008 at 12:10 PM, Christian Røsnes wrote: > On Wed, Mar 5, 2008 at 2:53 PM, Christian Røsnes > wrote: > > > On Wed, Feb 13, 2008 at 11:51:51AM +0100, Christian Røsnes wrote: > > > > Over the past month I've been hit with two cases of "xfs_trans_cancel > > > > at line 1150" > > > > The two errors occurred on different raid sets. In both cases the > > > > error happened during > > > > rsync from a remote server to this server, and the local partition > > > > which reported > > > > the error was 99% full (as reported by df -k, see below for details). > > > > > > > > System: Dell 2850 > > > > Mem: 4GB RAM > > > > OS: Debian 3 (32-bit) > > > > Kernel: 2.6.17.7 (custom compiled) > > > > > > > > > > After being hit several times by the problem mentioned above (running > > kernel 2.6.17.7), > > I upgraded the kernel to version 2.6.24.3. I then ran a rsync test to > > a 99% full partition: > > > > df -k: > > /dev/sdb1 286380096 282994528 3385568 99% /data > > > > The rsync application will probably fail because it will most likely > > run out of space, > > but I got another xfs_trans_cancel kernel message: > > > > Filesystem "sdb1": XFS internal error xfs_trans_cancel at line 1163 of > > file fs/xfs/xfs_trans.c. Caller 0xc021a010 > > Pid: 11642, comm: rsync Not tainted 2.6.24.3FC #1 > > [] xfs_trans_cancel+0x5d/0xe6 > > [] xfs_mkdir+0x45a/0x493 > > [] xfs_mkdir+0x45a/0x493 > > [] xfs_acl_vhasacl_default+0x33/0x44 > > [] xfs_vn_mknod+0x165/0x243 > > [] xfs_access+0x2f/0x35 > > [] xfs_vn_mkdir+0x12/0x14 > > [] vfs_mkdir+0xa3/0xe2 > > [] sys_mkdirat+0x8a/0xc3 > > [] sys_mkdir+0x1f/0x23 > > [] syscall_call+0x7/0xb > > ======================= > > xfs_force_shutdown(sdb1,0x8) called from line 1164 of file > > fs/xfs/xfs_trans.c. Return address = 0xc0212690 > > > > Filesystem "sdb1": Corruption of in-memory data detected. Shutting > > down filesystem: sdb1 > > Please umount the filesystem, and rectify the problem(s) > > > > Actually, a single mkdir command is enough to trigger the filesystem > shutdown when its 99% full (according to df -k): > > /data# mkdir test > mkdir: cannot create directory `test': No space left on device > > > > Filesystem "sdb1": XFS internal error xfs_trans_cancel at line 1163 of > file fs/xfs/xfs_trans.c. Caller 0xc021a010 > Pid: 23380, comm: mkdir Not tainted 2.6.24.3FC #1 > > [] xfs_trans_cancel+0x5d/0xe6 > [] xfs_mkdir+0x45a/0x493 > [] xfs_mkdir+0x45a/0x493 > [] xfs_acl_vhasacl_default+0x33/0x44 > [] xfs_vn_mknod+0x165/0x243 > [] xfs_access+0x2f/0x35 > [] xfs_vn_mkdir+0x12/0x14 > [] vfs_mkdir+0xa3/0xe2 > [] sys_mkdirat+0x8a/0xc3 > [] sys_mkdir+0x1f/0x23 > [] syscall_call+0x7/0xb > [] atm_reset_addr+0xd/0x83 > > ======================= > xfs_force_shutdown(sdb1,0x8) called from line 1164 of file > fs/xfs/xfs_trans.c. Return address = 0xc0212690 > Filesystem "sdb1": Corruption of in-memory data detected. Shutting > down filesystem: sdb1 > Please umount the filesystem, and rectify the problem(s) > > > df -k > ----- > /dev/sdb1 286380096 282994528 3385568 99% /data > > df -i > ----- > /dev/sdb1 10341248 3570112 6771136 35% /data > > > xfs_info > -------- > meta-data=/dev/sdb1 isize=512 agcount=16, agsize=4476752 blks > = sectsz=512 attr=0 > data = bsize=4096 blocks=71627792, imaxpct=25 > = sunit=16 swidth=32 blks, unwritten=1 > naming =version 2 bsize=4096 > log =internal bsize=4096 blocks=32768, version=2 > = sectsz=512 sunit=16 blks, lazy-count=0 > realtime =none extsz=65536 blocks=0, rtextents=0 > > xfs_db -r -c 'sb 0' -c p /dev/sdb1 > ---------------------------------- > magicnum = 0x58465342 > blocksize = 4096 > dblocks = 71627792 > rblocks = 0 > rextents = 0 > uuid = d16489ab-4898-48c2-8345-6334af943b2d > logstart = 67108880 > rootino = 128 > rbmino = 129 > rsumino = 130 > rextsize = 16 > agblocks = 4476752 > agcount = 16 > rbmblocks = 0 > logblocks = 32768 > versionnum = 0x3584 > sectsize = 512 > inodesize = 512 > inopblock = 8 > fname = "\000\000\000\000\000\000\000\000\000\000\000\000" > blocklog = 12 > sectlog = 9 > inodelog = 9 > inopblog = 3 > agblklog = 23 > rextslog = 0 > inprogress = 0 > imax_pct = 25 > icount = 3570112 > ifree = 0 > fdblocks = 847484 > frextents = 0 > uquotino = 0 > gquotino = 0 > qflags = 0 > flags = 0 > shared_vn = 0 > inoalignmt = 2 > unit = 16 > width = 32 > dirblklog = 0 > logsectlog = 0 > logsectsize = 0 > logsunit = 65536 > features2 = 0 > Instrumenting the code, I found that this occurs on my system when I do a 'mkdir /data/test' on the partition in question: in xfs_mkdir (xfs_vnodeops.c): error = xfs_dir_ialloc(&tp, dp, mode, 2, 0, credp, prid, resblks > 0, &cdp, NULL); if (error) { if (error == ENOSPC) goto error_return; <=== this is hit and then execution jumps to error_return goto abort_return; } Is this the correct behavior for this type of situation: mkdir command fails due to no available space on filesystem, and xfs_mkdir goes to label error_return ? (And after this the filesystem is shutdown) Christian From owner-xfs@oss.sgi.com Fri Mar 7 11:36:27 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 07 Mar 2008 11:36:50 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.9 required=5.0 tests=ANY_BOUNCE_MESSAGE,AWL, BAYES_50,VBOUNCE_MESSAGE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m27JaKtg025701 for ; Fri, 7 Mar 2008 11:36:27 -0800 X-ASG-Debug-ID: 1204918609-6a7401850000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from omr-d24.mx.aol.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 0A31A66CA42 for ; Fri, 7 Mar 2008 11:36:49 -0800 (PST) Received: from omr-d24.mx.aol.com (omr-d24.mx.aol.com [205.188.249.68]) by cuda.sgi.com with ESMTP id g1je0lgCeZed09BH for ; Fri, 07 Mar 2008 11:36:49 -0800 (PST) Received: from rly-dc08.mx.aol.com (rly-dc08.mx.aol.com [205.188.109.12]) by omr-d24.mx.aol.com (v117.7) with ESMTP id MAILOMRD241-7d7947d19948277; Fri, 07 Mar 2008 14:36:40 -0500 Received: from localhost (localhost) by rly-dc08.mx.aol.com (8.14.1/8.14.1) id m27JYk0W005098; Fri, 7 Mar 2008 14:36:40 -0500 Date: Fri, 7 Mar 2008 14:36:40 -0500 From: Mail Delivery Subsystem Message-Id: <200803071936.m27JYk0W005098@rly-dc08.mx.aol.com> To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="m27JYk0W005098.1204918600/rly-dc08.mx.aol.com" X-ASG-Orig-Subj: Returned mail: see transcript for details Subject: Returned mail: see transcript for details Auto-Submitted: auto-generated (failure) X-AOL-INRLY: rrcs-64-183-120-26.west.biz.rr.com [64.183.120.26] rly-dc08 X-AOL-IP: 205.188.109.12 X-Barracuda-Connect: omr-d24.mx.aol.com[205.188.249.68] X-Barracuda-Start-Time: 1204918610 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.52 X-Barracuda-Spam-Status: No, SCORE=-1.52 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_SC0_MJ615, FORGED_AOL_RCVD X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.44163 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 FORGED_AOL_RCVD Received forged, contains fake AOL relays 0.50 BSF_SC0_MJ615 Custom Rule MJ615 X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14797 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: MAILER-DAEMON@aol.com Precedence: bulk X-list: xfs This is a MIME-encapsulated message --m27JYk0W005098.1204918600/rly-dc08.mx.aol.com The original message was received at Fri, 7 Mar 2008 14:34:35 -0500 from rrcs-64-183-120-26.west.biz.rr.com [64.183.120.26] *** ATTENTION *** Your e-mail is being returned to you because there was a problem with its delivery. The address which was undeliverable is listed in the section labeled: "----- The following addresses had permanent fatal errors -----". The reason your mail is being returned to you is listed in the section labeled: "----- Transcript of Session Follows -----". The line beginning with "<<<" describes the specific reason your e-mail could not be delivered. The next line contains a second error message which is a general translation for other e-mail servers. Please direct further questions regarding this message to your e-mail administrator. --AOL Postmaster ----- The following addresses had permanent fatal errors ----- (reason: 554 TRANSACTION FAILED - Unrepairable Virus Detected. Your mail has not been sent.) ----- Transcript of session follows ----- ... while talking to air-dc07.mail.aol.com.: >>> DATA <<< 554 TRANSACTION FAILED - Unrepairable Virus Detected. Your mail has not been sent. 554 5.0.0 Service unavailable --m27JYk0W005098.1204918600/rly-dc08.mx.aol.com Content-Type: message/delivery-status Reporting-MTA: dns; rly-dc08.mx.aol.com Arrival-Date: Fri, 7 Mar 2008 14:34:35 -0500 Final-Recipient: RFC822; achaean1225bc@aol.com Action: failed Status: 5.0.0 Remote-MTA: DNS; air-dc07.mail.aol.com Diagnostic-Code: SMTP; 554 TRANSACTION FAILED - Unrepairable Virus Detected. Your mail has not been sent. Last-Attempt-Date: Fri, 7 Mar 2008 14:36:40 -0500 --m27JYk0W005098.1204918600/rly-dc08.mx.aol.com Content-Type: text/rfc822-headers Received: from oss.sgi.com (rrcs-64-183-120-26.west.biz.rr.com [64.183.120.26]) by rly-dc08.mx.aol.com (v121.4) with ESMTP id MAILRELAYINDC085-b3947d198c83d6; Fri, 07 Mar 2008 14:34:33 -0500 From: linux-xfs@oss.sgi.com To: achaean1225bc@aol.com Subject: RETURNED MAIL: DATA FORMAT ERROR Date: Fri, 7 Mar 2008 11:45:59 -0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0003_17750D6B.E165A5EE" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-AOL-IP: 64.183.120.26 X-AOL-SCOLL-SCORE:0:2:103076712:9395240 X-AOL-SCOLL-URL_COUNT: X-AOL-SCOLL-AUTHENTICATION: listenair ; SPF_helo : n X-AOL-SCOLL-AUTHENTICATION: listenair ; SPF_822_from : n Message-ID: <200803071434.b3947d198c83d6@rly-dc08.mx.aol.com> --m27JYk0W005098.1204918600/rly-dc08.mx.aol.com-- From owner-xfs@oss.sgi.com Fri Mar 7 12:33:11 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 07 Mar 2008 12:33:54 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m27KX8mr032191 for ; Fri, 7 Mar 2008 12:33:11 -0800 X-ASG-Debug-ID: 1204922012-712802f30000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.g-house.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id AA958F3DFAB for ; Fri, 7 Mar 2008 12:33:33 -0800 (PST) Received: from mail.g-house.de (ns2.g-housing.de [81.169.133.75]) by cuda.sgi.com with ESMTP id qDw9Fz3psY1TlmH0 for ; Fri, 07 Mar 2008 12:33:33 -0800 (PST) Received: from [89.54.188.127] (helo=[192.168.178.25]) by mail.g-house.de with esmtpa (Exim 4.63) (envelope-from ) id 1JXjFT-0000VD-UC; Fri, 07 Mar 2008 21:33:00 +0100 Date: Fri, 7 Mar 2008 21:32:57 +0100 (CET) From: Christian Kujau X-X-Sender: evil@sheep.housecafe.de To: LKML cc: xfs@oss.sgi.com X-ASG-Orig-Subj: INFO: task mount:11202 blocked for more than 120 seconds Subject: INFO: task mount:11202 blocked for more than 120 seconds Message-ID: User-Agent: Alpine 1.00 (DEB 882 2007-12-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Barracuda-Connect: ns2.g-housing.de[81.169.133.75] X-Barracuda-Start-Time: 1204922016 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.44166 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14798 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lists@nerdbynature.de Precedence: bulk X-list: xfs Hi, after upgrading from 2.6.24.1 to 2.6.25-rc3, I came across[0]. This warning seems to be gone now. With 2.6.25-rc4 (and the fix from [1]) the box was running fine for 20 hours or so (doing its usual jobs plus a "make randconfig && make" loop). After this, I noticed that /bin/sync would not exit anymore and remains stuck in D state. Looking around I noticed that the rsync backup jobs (rsync'ing to an xfs partition) from earlier this morning did not exit either and hung in D state. With sync hung, the following messages started to appear: [75377.756985] INFO: task sync:2697 blocked for more than 120 seconds. [75377.757579] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [75377.758211] sync D c013835c 0 2697 16457 [75377.758216] f59506c0 00000082 f4c34000 c013835c fffeffff f6c1bcb0 f5dd0000 f4c34000 [75377.758223] c04405d7 f53f7e98 f6c1bcb4 f6c1bcd0 00000000 f6c1bcb0 00000000 f7ca1090 [75377.758230] f4c34000 c044070a f6c1bcd0 f6c1bcd0 f5dd0000 00000001 f6c1bcb0 c044074b [75377.758237] Call Trace: [75377.758253] [] trace_hardirqs_on+0x9c/0x110 [75377.758269] [] rwsem_down_failed_common+0x67/0x150 [75377.758279] [] rwsem_down_read_failed+0x1a/0x24 [75377.758286] [] call_rwsem_down_read_failed+0x7/0xc [75377.758291] [] down_read_nested+0x4c/0x60 [75377.758295] [] xfs_ilock+0x5b/0xb0 [75377.758301] [] xfs_ilock+0x5b/0xb0 [75377.758306] [] xfs_sync_inodes+0x3dd/0x6b0 [75377.758314] [] _spin_unlock+0x14/0x20 [75377.758325] [] xfs_syncsub+0x18b/0x300 [75377.758330] [] _spin_unlock+0x14/0x20 [75377.758335] [] xfs_fs_sync_super+0x2b/0xd0 [75377.758342] [] sync_filesystems+0xa4/0x100 [75377.758351] [] down_read+0x38/0x50 [75377.758356] [] sync_filesystems+0xbf/0x100 [75377.758361] [] do_sync+0x33/0x70 [75377.758366] [] restore_nocheck+0x12/0x15 [75377.758371] [] sys_sync+0xa/0x10 [75377.758375] [] sysenter_past_esp+0x5f/0xa5 [75377.758402] ======================= [75377.758405] 3 locks held by sync/2697: [75377.758407] #0: (mutex){--..}, at: [] sync_filesystems+0x11/0x100 [75377.758414] #1: (&type->s_umount_key#22){----}, at: [] sync_filesystems+0xa4/0x100 [75377.758422] #2: (&(&ip->i_iolock)->mr_lock){----}, at: [] xfs_ilock+0x5b/0xb0 The box is still up & running, although the load is increasing slightly. I've gathered some details here: http://nerdbynature.de/bits/2.6.25-rc4/ I've searched the archives for this error, but the only thing was * http://lkml.org/lkml/2008/2/12/44 [BUG] 2.6.25-rc1-git1 softlockup while bootup on powerpc ...however, I don't get "CPU stuck" messages * http://lkml.org/lkml/2008/1/29/370 Re: system hang on latest git ...but calltrace looks a lot different. Since both mailings are not so current, I'd like to got back to -rc3 and try to reproduce this one. Do you have any idea what's going on here? Thanks, Christian. [0] http://lkml.org/lkml/2008/3/2/171 [1] http://lkml.org/lkml/2008/3/4/634 -- BOFH excuse #158: Defunct processes From owner-xfs@oss.sgi.com Fri Mar 7 14:34:53 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 07 Mar 2008 14:35:15 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m27MYnut007756 for ; Fri, 7 Mar 2008 14:34:52 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA00157; Sat, 8 Mar 2008 09:35:14 +1100 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 m27MZCLF89462287; Sat, 8 Mar 2008 09:35:14 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id m27MZAcA89340093; Sat, 8 Mar 2008 09:35:10 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Sat, 8 Mar 2008 09:35:10 +1100 From: David Chinner To: Kris Kersey Cc: xfs@oss.sgi.com, Bill Vaughan Subject: Re: pdflush hang on xlog_grant_log_space() Message-ID: <20080307223510.GM155407@sgi.com> References: <47D062AF.80501@steelbox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47D062AF.80501@steelbox.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14799 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Thu, Mar 06, 2008 at 04:31:27PM -0500, Kris Kersey wrote: > Hello, > > I'm working on a NAS product and we're currently having lock-ups that > seem to be hanging in XFS code. We're running a NAS that has 1024 NFSD > threads accessing three RAID mounts. All three mounts are running XFS > file systems. Lately we've had random lockups on these boxes and I am > now running a kernel with KDB built-in. > > The lock-up takes the form of all NFSD threads in D state with one out > of three pdflush threads in D state. The assumption can be made that > all NFSD threads are waiting on the one pdflush thread to complete. So > two times now when an NAS has gotten in this state I have accessed KDB > and ran a stack trace on the pdflush thread. Both times the thread was > stuck on xlog_grant_log_space+0xdb. Try bumping XFS_TRANS_PUSH_AIL_RESTARTS to a much larger number and seeing if the problem goes away.... Alternatively, that restart hack is backed by a "watchdog" timeout in 2.6.25-rc1, so if that is the cause of the problem perhaps the latest -rcX kernel will prevent the hang? BTW, you can get all the traces of D state threads through the sysrq interface, so you don't need to drop into kdb to get this..... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Fri Mar 7 14:40:26 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 07 Mar 2008 14:40:41 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m27MeKnB008259 for ; Fri, 7 Mar 2008 14:40:24 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA00285; Sat, 8 Mar 2008 09:40:44 +1100 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 m27MehLF88354118; Sat, 8 Mar 2008 09:40:43 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id m27MeewP89332309; Sat, 8 Mar 2008 09:40:40 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Sat, 8 Mar 2008 09:40:40 +1100 From: David Chinner To: Christian Kujau Cc: LKML , xfs@oss.sgi.com Subject: Re: INFO: task mount:11202 blocked for more than 120 seconds Message-ID: <20080307224040.GV155259@sgi.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14800 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Fri, Mar 07, 2008 at 09:32:57PM +0100, Christian Kujau wrote: > Hi, > > after upgrading from 2.6.24.1 to 2.6.25-rc3, I came across[0]. This > warning seems to be gone now. With 2.6.25-rc4 (and the fix from [1]) > the box was running fine for 20 hours or so (doing its usual jobs plus > a "make randconfig && make" loop). > > After this, I noticed that /bin/sync would not exit anymore and > remains stuck in D state. Looking around I noticed that the rsync > backup jobs (rsync'ing to an xfs partition) from earlier this > morning did not exit either and hung in D state. With sync hung, the > following messages started to appear: > > [75377.756985] INFO: task sync:2697 blocked for more than 120 seconds. > [75377.757579] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables > this message. > [75377.758211] sync D c013835c 0 2697 16457 > [75377.758216] f59506c0 00000082 f4c34000 c013835c fffeffff f6c1bcb0 > f5dd0000 f4c34000 [75377.758223] c04405d7 f53f7e98 f6c1bcb4 f6c1bcd0 > 00000000 f6c1bcb0 00000000 f7ca1090 [75377.758230] f4c34000 c044070a > f6c1bcd0 f6c1bcd0 f5dd0000 00000001 f6c1bcb0 c044074b [75377.758237] Call > Trace: > [75377.758253] [] trace_hardirqs_on+0x9c/0x110 > [75377.758269] [] rwsem_down_failed_common+0x67/0x150 > [75377.758279] [] rwsem_down_read_failed+0x1a/0x24 > [75377.758286] [] call_rwsem_down_read_failed+0x7/0xc > [75377.758291] [] down_read_nested+0x4c/0x60 > [75377.758295] [] xfs_ilock+0x5b/0xb0 > [75377.758301] [] xfs_ilock+0x5b/0xb0 > [75377.758306] [] xfs_sync_inodes+0x3dd/0x6b0 > [75377.758314] [] _spin_unlock+0x14/0x20 > [75377.758325] [] xfs_syncsub+0x18b/0x300 > [75377.758330] [] _spin_unlock+0x14/0x20 > [75377.758335] [] xfs_fs_sync_super+0x2b/0xd0 > [75377.758342] [] sync_filesystems+0xa4/0x100 > [75377.758351] [] down_read+0x38/0x50 > [75377.758356] [] sync_filesystems+0xbf/0x100 > [75377.758361] [] do_sync+0x33/0x70 > [75377.758366] [] restore_nocheck+0x12/0x15 > [75377.758371] [] sys_sync+0xa/0x10 > [75377.758375] [] sysenter_past_esp+0x5f/0xa5 > [75377.758402] ======================= > [75377.758405] 3 locks held by sync/2697: > [75377.758407] #0: (mutex){--..}, at: [] > sync_filesystems+0x11/0x100 > [75377.758414] #1: (&type->s_umount_key#22){----}, at: [] > sync_filesystems+0xa4/0x100 > [75377.758422] #2: (&(&ip->i_iolock)->mr_lock){----}, at: [] > xfs_ilock+0x5b/0xb0 Well, if that is hung there, something else must be holding on to the iolock it's waiting on. What are the other D state processes in the machine? Also, the iolock can be held across I/O so it's possible you've lost an I/O. Any I/O errors in the syslog? Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Fri Mar 7 14:46:29 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 07 Mar 2008 14:46:50 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m27MkQ4D008836 for ; Fri, 7 Mar 2008 14:46:28 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA00515; Sat, 8 Mar 2008 09:46:50 +1100 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 m27MkmLF89127194; Sat, 8 Mar 2008 09:46:49 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id m27Mkj3o89196247; Sat, 8 Mar 2008 09:46:45 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Sat, 8 Mar 2008 09:46:45 +1100 From: David Chinner To: Chris Knadle Cc: linux-kernel@vger.kernel.org, xfs@oss.sgi.com Subject: Re: assfail during unmount xfs 2.6.24.3 [from 2.6.24.y git] Message-ID: <20080307224645.GW155259@sgi.com> References: <200803062329.10486.Chris.Knadle@coredump.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200803062329.10486.Chris.Knadle@coredump.us> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14801 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Thu, Mar 06, 2008 at 11:29:07PM -0500, Chris Knadle wrote: > During the final unmount before reboot there was an assertion failure from XFS > leading to the debug output below; I've included what was available on the > screendump, which I handwrote + transcribed. [I also have screenshots from a > 2.1 MP camera -- they're slightly ugly but usable.] CONFIG_KEXEC was not > compiled in, so I was uanble to get a crashdump via SysRq. I'm sending this > along in case someone working on the XFS fs can find + fix a bug. I'm not > sending the kernel config in this first post just as not to spam everybody > with it if it's not needed -- if desired just ask and I'll send it. > Source used: 2.6.24.y from git -- 2.6.24.3. > > This is on my Desktop box, x86 system -- single P4 CPU @ 2.6 GHz, IDE disk > attached to an onboard HighPoint HPT370 controller, and running Debian Sid. > > When replying please CC me, as I am not currently subscribed to the list. ...... > Assertion failed: atomic_read(&mp->m_active_trans) == 0, file: > fs/xfs/xfs_vfsops.c, line: 708 Known problem. Race in the VFS w.r.t. read-only remounts: http://marc.info/?l=linux-kernel&m=120106649923499&w=2 The fix for the problem lies outside XFS: http://marc.info/?l=linux-kernel&m=120109304227035&w=2 Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Fri Mar 7 15:46:40 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 07 Mar 2008 15:47:00 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_72 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m27NkdQC011216 for ; Fri, 7 Mar 2008 15:46:40 -0800 X-ASG-Debug-ID: 1204933603-6bc1001c0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.g-house.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 3CE6266E095; Fri, 7 Mar 2008 15:46:44 -0800 (PST) Received: from mail.g-house.de (ns2.g-housing.de [81.169.133.75]) by cuda.sgi.com with ESMTP id v1WjRs74E44zVkcn; Fri, 07 Mar 2008 15:46:44 -0800 (PST) Received: from [89.54.188.127] (helo=[192.168.178.25]) by mail.g-house.de with esmtpa (Exim 4.63) (envelope-from ) id 1JXmGv-00073J-AV; Sat, 08 Mar 2008 00:46:41 +0100 Date: Sat, 8 Mar 2008 00:46:40 +0100 (CET) From: Christian Kujau X-X-Sender: evil@sheep.housecafe.de To: David Chinner cc: LKML , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: INFO: task mount:11202 blocked for more than 120 seconds Subject: Re: INFO: task mount:11202 blocked for more than 120 seconds In-Reply-To: <20080307224040.GV155259@sgi.com> Message-ID: References: <20080307224040.GV155259@sgi.com> User-Agent: Alpine 1.00 (DEB 882 2007-12-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Barracuda-Connect: ns2.g-housing.de[81.169.133.75] X-Barracuda-Start-Time: 1204933608 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.44181 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14802 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lists@nerdbynature.de Precedence: bulk X-list: xfs On Sat, 8 Mar 2008, David Chinner wrote: > Well, if that is hung there, something else must be holding on to > the iolock it's waiting on. What are the other D state processes in the > machine? I have 7 processes in D state so far: $ ps auxww [....] root 9844 0.0 0.0 0 0 ? D Mar06 0:22 [pdflush] root 2697 0.0 0.0 4712 460 ? D Mar07 0:00 sync root 8342 0.0 0.0 1780 440 ? D Mar07 0:01 /bin/rm -rf /data/md1/stuff root 12494 0.0 0.0 11124 1228 ? D Mar07 0:14 /usr/bin/rsync root 15008 0.0 0.0 4712 460 ? D Mar07 0:00 sync root 11202 0.0 0.0 5012 764 ? D Mar07 0:00 mount -o remount,ro /data/md1 root 15936 0.0 0.0 4712 460 ? D Mar07 0:00 sync At one point I did a sysrq-D and put the results in: http://nerdbynature.de/bits/2.6.25-rc4/hung_task/kern.log.gz (grep for "SysRq : Show Locks Held" and "SysRq : Show Blocked State") > Also, the iolock can be held across I/O so it's possible you've lost an I/O. > Any I/O errors in the syslog? No, no I/O errors at all. See the kern.log above, I could even do dd(1) from the md1 (dm-crypt on raid1), no errors either. thanks, Christian. -- BOFH excuse #233: TCP/IP UDP alarm threshold is set too low. From owner-xfs@oss.sgi.com Fri Mar 7 16:21:12 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 07 Mar 2008 16:21:31 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_62 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m280L8DQ016909 for ; Fri, 7 Mar 2008 16:21:10 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA02613; Sat, 8 Mar 2008 11:21:31 +1100 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 m280LRLF89349587; Sat, 8 Mar 2008 11:21:28 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id m280LOOp89466845; Sat, 8 Mar 2008 11:21:24 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Sat, 8 Mar 2008 11:21:24 +1100 From: David Chinner To: IWAMOTO Toshihiro Cc: xfs@oss.sgi.com Subject: Re: [PATCH] prototype file data inode inlining Message-ID: <20080308002124.GN155407@sgi.com> References: <20080307093411.4B1912DC9B2@mail.valinux.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080307093411.4B1912DC9B2@mail.valinux.co.jp> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14803 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Fri, Mar 07, 2008 at 06:34:09PM +0900, IWAMOTO Toshihiro wrote: > Hi, > > I've done a prototype implementation of file data inlining in inodes a > while ago. It was originally meant to solve a performance problem > with a large number of small files at some customer site. > Although I measured some performance gains, a different workaround has > been adopted due to the patch quality problem. > > As I'm not asking for inclusion, the patch hasn't been ported to the > current kernel version. This patch might be useful if someone has a > similar performance problem and would like to see if file inlining > helps or not. Interesting. I'm not going to comment on the code, just the overall design and implementation. Problems: - data loss on crash is unacceptable - this is an on-disk format change - it needs to be implemented either as a mkfs option with a specific superblock feature bit, or as a mount option with a version 3 inode and a superblock feature bit to indicate inodes with data in them have been created. - local -> extent conversion occurs at copy-in time, not writeback time, so using the normal read/write paths through ->get_blocks() will fail here in xfs_bmapi(): 4793 if (XFS_IFORK_FORMAT(ip, whichfork) == XFS_DINODE_FMT_LOCAL) { 4794 >>>>>>>> ASSERT(wr && tp); 4795 if ((error = xfs_bmap_local_to_extents(tp, ip, 4796 firstblock, total, &logflags, whichfork))) 4797 goto error0; 4798 } because on a normal read or write (delayed allocation) we are not doing allocation and hence do not have an open transaction the first time we come through here. Just avoiding this conversion and returning zero maps if we are not writing will not help in the delayed allocation case. I note that you hacked around this by special casing the inline format ->get_blocks() callout to copy the data into the page and marking it mapped and uptodate. I think this is the wrong approach and is not the right layer at which to make this distinction - the special casing needs to be done at higher layers, not in the block mapping function. I think for inline data, we'd do best to special case this as high up the read/write paths as possible. e.g. for read() type operations intercept in xfs_read() and just do what we need to do there for populating the single page cache page. For write, we should let it go through the normal delayed allocation mechanisms, only converting to local format during ->writepage() if there's a single block extent and it fits in the data fork. This also handles the truncate case nicely. For mmap operations, we need to handle the inline case separately to the normal ->readpage case, similar to the xfs_read() case. ->readpages should never occur on an inline data inode. > Some random notes and the patch itself follows. > > Inlined file data are written from xfs_page_state_convert(). > The xfs_trans related operations in that function is to get inode > written on disk and isn't for crash consistency. Which is the exact opposite of what they are supposed to be used for. Given that the next thing that happens after data write in the writeback path is ->write_inode(), forcing the inode into the log for pure data changes is unnecessary. We just need to format the data into the inode during data writeback. > Small files are made inlined when created. Non inlined files don't > get inlined when they are truncated. As I inferred above, I think this is the wrong approach. Start the inodes in extent format just like they currently are, and only convert in writeback. This means no changes to the write path or delayed allocation handling. That is, only the disk format should care if the data is inline or not; everything in memory still treats data as block based extents. i.e. the only time we do anything w.r.t local data format is reading the inode off disk and writing it back to disk. The only issue here is that extent->local conversion requires a free transaction, not an allocation transaction, but that should not be difficult to handle as we can log the inode complete with inline data in the free transaction to make that conversion atomic. > xfs_bmap_local_to_extents() has been modified to work with file data, > but logging isn't implemented. A machine crash can cause data > corruption. There are two ways to do inline->extent safely from a crash recovery perspective. Method 1: Use an Intent/Done transaction pair The way this needs to be done is via a pair of transactions. The first allocation transaction remains the same, but needs a different type - an "allocation intent" rather than an "allocation" transaction. On data I/O completion, we then need an " allocation complete" transaction that signals that the data is on disk and the allocation intent is now permanent. That means we can change state in memory and log it to disk before the data write is done, but it won't get replayed on crash unless the allocation completion transaction is also in the log after the data is safely on disk. Hence we don't overwrite data in the inode during recovery if there is no copy of it elsewhere. This needs modifications to the recovery code to understand the new transaction types correctly. Method 2: Log the data We can log any object that is held in a xfs_buf_t. During conversion, we could simply build an xfs_buf_t that points to the page that holds the data and log that. The complexity here is that the buffer needs to point to the inodes address space, not the address space of the buftarg where all the metadata resides. The xfs_buf_t in this case should only exist for the life of the data I/O; once the data I/O is complete we can tear it down and go back to treating the page normally. > O_SYNC may behave incorrectly. ->write_inode(SYNC) should handle it just fine. > Use of attribute forks isn't considered and likely has issues. If you don't change the way the attribute fork handling works, it should be just fine. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Fri Mar 7 17:54:10 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 07 Mar 2008 17:54:30 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m281s7E5019951 for ; Fri, 7 Mar 2008 17:54:09 -0800 X-ASG-Debug-ID: 1204941273-19bf00fe0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.g-house.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 0A74E66EAB5; Fri, 7 Mar 2008 17:54:33 -0800 (PST) Received: from mail.g-house.de (ns2.g-housing.de [81.169.133.75]) by cuda.sgi.com with ESMTP id X5qr7JufVhXfPbla; Fri, 07 Mar 2008 17:54:33 -0800 (PST) Received: from [89.54.188.127] (helo=[192.168.178.25]) by mail.g-house.de with esmtpa (Exim 4.63) (envelope-from ) id 1JXoGd-0002ZQ-4x; Sat, 08 Mar 2008 02:54:31 +0100 Date: Sat, 8 Mar 2008 02:54:26 +0100 (CET) From: Christian Kujau X-X-Sender: evil@sheep.housecafe.de To: David Chinner cc: LKML , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: INFO: task mount:11202 blocked for more than 120 seconds Subject: Re: INFO: task mount:11202 blocked for more than 120 seconds In-Reply-To: Message-ID: References: <20080307224040.GV155259@sgi.com> User-Agent: Alpine 1.00 (DEB 882 2007-12-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Barracuda-Connect: ns2.g-housing.de[81.169.133.75] X-Barracuda-Start-Time: 1204941278 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.44189 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14804 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lists@nerdbynature.de Precedence: bulk X-list: xfs On Sat, 8 Mar 2008, Christian Kujau wrote: > I have 7 processes in D state so far: FWIW, it's 100% reproducible with 2.6.25-rc3 too...sigh :-\ So, the last working kernel for me is 2.6.24.1 - that's a lot of bisecting and I fear that compile errors will invalidate the bisecting results again or make it impossible at all....I'll try anyway....tomorrow... C. -- BOFH excuse #285: Telecommunications is upgrading. From owner-xfs@oss.sgi.com Fri Mar 7 20:01:04 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 07 Mar 2008 20:01:24 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m28412YY025086 for ; Fri, 7 Mar 2008 20:01:04 -0800 X-ASG-Debug-ID: 1204948890-3aa3004d0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 9909CF42B83 for ; Fri, 7 Mar 2008 20:01:30 -0800 (PST) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id YFIOtX0ZT3alSfD6 for ; Fri, 07 Mar 2008 20:01:30 -0800 (PST) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id ABA0D18004487 for ; Fri, 7 Mar 2008 22:00:56 -0600 (CST) Message-ID: <47D20F78.7000103@sandeen.net> Date: Fri, 07 Mar 2008 22:00:56 -0600 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: xfs-oss X-ASG-Orig-Subj: [PATCH, RFC] - remove mounpoint UUID code Subject: [PATCH, RFC] - remove mounpoint UUID code Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1204948891 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.44195 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14805 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs It looks like all of the below is unused... and according to Nathan, "dont think it even got used/implemented anywhere, but i think it was meant to be an auto-mount kinda thing... such that when you look up at that point, it knows to mount the device with that uuid there, if its not already it was never really written anywhere ... just an idea in doug doucettes brain i think." Think it'll ever go anywhere, or should it get pruned? The below builds; not at all tested, until I get an idea if it's worth doing. Need to double check that some structures might not need padding out to keep things compatible/consistent... dmapi/xfs_dm.c | 2 -- xfs_attr_leaf.c | 6 +----- xfs_bmap.c | 4 ---- xfs_dinode.h | 2 -- xfs_inode.c | 8 -------- xfs_inode.h | 1 - xfs_inode_item.c | 53 +++++++++++------------------------------------------ xfs_inode_item.h | 26 ++++++++------------------ xfs_itable.c | 2 -- xfs_log_recover.c | 10 ++-------- xfsidbg.c | 2 +- 11 files changed, 23 insertions(+), 93 deletions(-) Index: linux-2.6-xfs/fs/xfs/dmapi/xfs_dm.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/dmapi/xfs_dm.c +++ linux-2.6-xfs/fs/xfs/dmapi/xfs_dm.c @@ -363,7 +363,6 @@ xfs_dip_to_stat( buf->dt_blocks = 0; break; case XFS_DINODE_FMT_LOCAL: - case XFS_DINODE_FMT_UUID: buf->dt_rdev = 0; buf->dt_blksize = mp->m_sb.sb_blocksize; buf->dt_blocks = 0; @@ -431,7 +430,6 @@ xfs_ip_to_stat( buf->dt_blocks = 0; break; case XFS_DINODE_FMT_LOCAL: - case XFS_DINODE_FMT_UUID: buf->dt_rdev = 0; buf->dt_blksize = mp->m_sb.sb_blocksize; buf->dt_blocks = 0; Index: linux-2.6-xfs/fs/xfs/xfs_attr_leaf.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_attr_leaf.c +++ linux-2.6-xfs/fs/xfs/xfs_attr_leaf.c @@ -155,13 +155,9 @@ xfs_attr_shortform_bytesfit(xfs_inode_t offset = (XFS_LITINO(mp) - bytes) >> 3; /* rounded down */ - switch (dp->i_d.di_format) { - case XFS_DINODE_FMT_DEV: + if (dp->i_d.di_format == XFS_DINODE_FMT_DEV) { minforkoff = roundup(sizeof(xfs_dev_t), 8) >> 3; return (offset >= minforkoff) ? minforkoff : 0; - case XFS_DINODE_FMT_UUID: - minforkoff = roundup(sizeof(uuid_t), 8) >> 3; - return (offset >= minforkoff) ? minforkoff : 0; } if (!(mp->m_flags & XFS_MOUNT_ATTR2)) { Index: linux-2.6-xfs/fs/xfs/xfs_bmap.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_bmap.c +++ linux-2.6-xfs/fs/xfs/xfs_bmap.c @@ -3532,7 +3532,6 @@ xfs_bmap_forkoff_reset( { if (whichfork == XFS_ATTR_FORK && (ip->i_d.di_format != XFS_DINODE_FMT_DEV) && - (ip->i_d.di_format != XFS_DINODE_FMT_UUID) && (ip->i_d.di_format != XFS_DINODE_FMT_BTREE) && ((mp->m_attroffset >> 3) > ip->i_d.di_forkoff)) { ip->i_d.di_forkoff = mp->m_attroffset >> 3; @@ -4000,9 +3999,6 @@ xfs_bmap_add_attrfork( case XFS_DINODE_FMT_DEV: ip->i_d.di_forkoff = roundup(sizeof(xfs_dev_t), 8) >> 3; break; - case XFS_DINODE_FMT_UUID: - ip->i_d.di_forkoff = roundup(sizeof(uuid_t), 8) >> 3; - break; case XFS_DINODE_FMT_LOCAL: case XFS_DINODE_FMT_EXTENTS: case XFS_DINODE_FMT_BTREE: Index: linux-2.6-xfs/fs/xfs/xfs_dinode.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_dinode.h +++ linux-2.6-xfs/fs/xfs/xfs_dinode.h @@ -88,7 +88,6 @@ typedef struct xfs_dinode xfs_dir2_sf_t di_dir2sf; /* shortform directory v2 */ char di_c[1]; /* local contents */ __be32 di_dev; /* device for S_IFCHR/S_IFBLK */ - uuid_t di_muuid; /* mount point value */ char di_symlink[1]; /* local symbolic link */ } di_u; union { @@ -150,7 +149,6 @@ typedef enum xfs_dinode_fmt /* LNK: di_symlink */ XFS_DINODE_FMT_EXTENTS, /* DIR, REG, LNK: di_bmx */ XFS_DINODE_FMT_BTREE, /* DIR, REG, LNK: di_bmbt */ - XFS_DINODE_FMT_UUID /* MNT: di_uuid */ } xfs_dinode_fmt_t; /* Index: linux-2.6-xfs/fs/xfs/xfs_inode.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_inode.c +++ linux-2.6-xfs/fs/xfs/xfs_inode.c @@ -2970,14 +2970,6 @@ xfs_iflush_fork( } break; - case XFS_DINODE_FMT_UUID: - if (iip->ili_format.ilf_fields & XFS_ILOG_UUID) { - ASSERT(whichfork == XFS_DATA_FORK); - memcpy(&dip->di_u.di_muuid, &ip->i_df.if_u2.if_uuid, - sizeof(uuid_t)); - } - break; - default: ASSERT(0); break; Index: linux-2.6-xfs/fs/xfs/xfs_inode_item.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_inode_item.c +++ linux-2.6-xfs/fs/xfs/xfs_inode_item.c @@ -70,8 +70,7 @@ xfs_inode_item_size( switch (ip->i_d.di_format) { case XFS_DINODE_FMT_EXTENTS: iip->ili_format.ilf_fields &= - ~(XFS_ILOG_DDATA | XFS_ILOG_DBROOT | - XFS_ILOG_DEV | XFS_ILOG_UUID); + ~(XFS_ILOG_DDATA | XFS_ILOG_DBROOT | XFS_ILOG_DEV); if ((iip->ili_format.ilf_fields & XFS_ILOG_DEXT) && (ip->i_d.di_nextents > 0) && (ip->i_df.if_bytes > 0)) { @@ -86,8 +85,7 @@ xfs_inode_item_size( ASSERT(ip->i_df.if_ext_max == XFS_IFORK_DSIZE(ip) / (uint)sizeof(xfs_bmbt_rec_t)); iip->ili_format.ilf_fields &= - ~(XFS_ILOG_DDATA | XFS_ILOG_DEXT | - XFS_ILOG_DEV | XFS_ILOG_UUID); + ~(XFS_ILOG_DDATA | XFS_ILOG_DEXT | XFS_ILOG_DEV); if ((iip->ili_format.ilf_fields & XFS_ILOG_DBROOT) && (ip->i_df.if_broot_bytes > 0)) { ASSERT(ip->i_df.if_broot != NULL); @@ -112,8 +110,7 @@ xfs_inode_item_size( case XFS_DINODE_FMT_LOCAL: iip->ili_format.ilf_fields &= - ~(XFS_ILOG_DEXT | XFS_ILOG_DBROOT | - XFS_ILOG_DEV | XFS_ILOG_UUID); + ~(XFS_ILOG_DEXT | XFS_ILOG_DBROOT | XFS_ILOG_DEV); if ((iip->ili_format.ilf_fields & XFS_ILOG_DDATA) && (ip->i_df.if_bytes > 0)) { ASSERT(ip->i_df.if_u1.if_data != NULL); @@ -126,14 +123,7 @@ xfs_inode_item_size( case XFS_DINODE_FMT_DEV: iip->ili_format.ilf_fields &= - ~(XFS_ILOG_DDATA | XFS_ILOG_DBROOT | - XFS_ILOG_DEXT | XFS_ILOG_UUID); - break; - - case XFS_DINODE_FMT_UUID: - iip->ili_format.ilf_fields &= - ~(XFS_ILOG_DDATA | XFS_ILOG_DBROOT | - XFS_ILOG_DEXT | XFS_ILOG_DEV); + ~(XFS_ILOG_DDATA | XFS_ILOG_DBROOT | XFS_ILOG_DEXT); break; default: @@ -319,8 +309,7 @@ xfs_inode_item_format( switch (ip->i_d.di_format) { case XFS_DINODE_FMT_EXTENTS: ASSERT(!(iip->ili_format.ilf_fields & - (XFS_ILOG_DDATA | XFS_ILOG_DBROOT | - XFS_ILOG_DEV | XFS_ILOG_UUID))); + (XFS_ILOG_DDATA | XFS_ILOG_DBROOT | XFS_ILOG_DEV))); if (iip->ili_format.ilf_fields & XFS_ILOG_DEXT) { ASSERT(ip->i_df.if_bytes > 0); ASSERT(ip->i_df.if_u1.if_extents != NULL); @@ -369,8 +358,7 @@ xfs_inode_item_format( case XFS_DINODE_FMT_BTREE: ASSERT(!(iip->ili_format.ilf_fields & - (XFS_ILOG_DDATA | XFS_ILOG_DEXT | - XFS_ILOG_DEV | XFS_ILOG_UUID))); + (XFS_ILOG_DDATA | XFS_ILOG_DEXT | XFS_ILOG_DEV))); if (iip->ili_format.ilf_fields & XFS_ILOG_DBROOT) { ASSERT(ip->i_df.if_broot_bytes > 0); ASSERT(ip->i_df.if_broot != NULL); @@ -385,8 +373,7 @@ xfs_inode_item_format( case XFS_DINODE_FMT_LOCAL: ASSERT(!(iip->ili_format.ilf_fields & - (XFS_ILOG_DBROOT | XFS_ILOG_DEXT | - XFS_ILOG_DEV | XFS_ILOG_UUID))); + (XFS_ILOG_DBROOT | XFS_ILOG_DEXT | XFS_ILOG_DEV))); if (iip->ili_format.ilf_fields & XFS_ILOG_DDATA) { ASSERT(ip->i_df.if_bytes > 0); ASSERT(ip->i_df.if_u1.if_data != NULL); @@ -411,21 +398,9 @@ xfs_inode_item_format( case XFS_DINODE_FMT_DEV: ASSERT(!(iip->ili_format.ilf_fields & - (XFS_ILOG_DBROOT | XFS_ILOG_DEXT | - XFS_ILOG_DDATA | XFS_ILOG_UUID))); + (XFS_ILOG_DBROOT | XFS_ILOG_DEXT | XFS_ILOG_DDATA))); if (iip->ili_format.ilf_fields & XFS_ILOG_DEV) { - iip->ili_format.ilf_u.ilfu_rdev = - ip->i_df.if_u2.if_rdev; - } - break; - - case XFS_DINODE_FMT_UUID: - ASSERT(!(iip->ili_format.ilf_fields & - (XFS_ILOG_DBROOT | XFS_ILOG_DEXT | - XFS_ILOG_DDATA | XFS_ILOG_DEV))); - if (iip->ili_format.ilf_fields & XFS_ILOG_UUID) { - iip->ili_format.ilf_u.ilfu_uuid = - ip->i_df.if_u2.if_uuid; + iip->ili_format.ilf_rdev = ip->i_df.if_u2.if_rdev; } break; @@ -1088,10 +1063,7 @@ xfs_inode_item_format_convert( in_f->ilf_asize = in_f32->ilf_asize; in_f->ilf_dsize = in_f32->ilf_dsize; in_f->ilf_ino = in_f32->ilf_ino; - /* copy biggest field of ilf_u */ - memcpy(in_f->ilf_u.ilfu_uuid.__u_bits, - in_f32->ilf_u.ilfu_uuid.__u_bits, - sizeof(uuid_t)); + in_f->ilf_rdev = in_f32->ilf_rdev; in_f->ilf_blkno = in_f32->ilf_blkno; in_f->ilf_len = in_f32->ilf_len; in_f->ilf_boffset = in_f32->ilf_boffset; @@ -1106,10 +1078,7 @@ xfs_inode_item_format_convert( in_f->ilf_asize = in_f64->ilf_asize; in_f->ilf_dsize = in_f64->ilf_dsize; in_f->ilf_ino = in_f64->ilf_ino; - /* copy biggest field of ilf_u */ - memcpy(in_f->ilf_u.ilfu_uuid.__u_bits, - in_f64->ilf_u.ilfu_uuid.__u_bits, - sizeof(uuid_t)); + in_f->ilf_rdev = in_f64->ilf_rdev; in_f->ilf_blkno = in_f64->ilf_blkno; in_f->ilf_len = in_f64->ilf_len; in_f->ilf_boffset = in_f64->ilf_boffset; Index: linux-2.6-xfs/fs/xfs/xfs_itable.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_itable.c +++ linux-2.6-xfs/fs/xfs/xfs_itable.c @@ -111,7 +111,6 @@ xfs_bulkstat_one_iget( buf->bs_blocks = 0; break; case XFS_DINODE_FMT_LOCAL: - case XFS_DINODE_FMT_UUID: buf->bs_rdev = 0; buf->bs_blksize = mp->m_sb.sb_blocksize; buf->bs_blocks = 0; @@ -186,7 +185,6 @@ xfs_bulkstat_one_dinode( buf->bs_blocks = 0; break; case XFS_DINODE_FMT_LOCAL: - case XFS_DINODE_FMT_UUID: buf->bs_rdev = 0; buf->bs_blksize = mp->m_sb.sb_blocksize; buf->bs_blocks = 0; Index: linux-2.6-xfs/fs/xfs/xfs_inode_item.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_inode_item.h +++ linux-2.6-xfs/fs/xfs/xfs_inode_item.h @@ -31,10 +31,7 @@ typedef struct xfs_inode_log_format { __uint16_t ilf_asize; /* size of attr d/ext/root */ __uint16_t ilf_dsize; /* size of data/ext/root */ __uint64_t ilf_ino; /* inode number */ - union { - __uint32_t ilfu_rdev; /* rdev value for dev inode*/ - uuid_t ilfu_uuid; /* mount point value */ - } ilf_u; + __uint32_t ilf_rdev; /* rdev value for dev inode*/ __int64_t ilf_blkno; /* blkno of inode buffer */ __int32_t ilf_len; /* len of inode buffer */ __int32_t ilf_boffset; /* off of inode in buffer */ @@ -48,10 +45,7 @@ typedef struct xfs_inode_log_format_32 { __uint16_t ilf_asize; /* size of attr d/ext/root */ __uint16_t ilf_dsize; /* size of data/ext/root */ __uint64_t ilf_ino; /* inode number */ - union { - __uint32_t ilfu_rdev; /* rdev value for dev inode*/ - uuid_t ilfu_uuid; /* mount point value */ - } ilf_u; + __uint32_t ilf_rdev; /* rdev value for dev inode*/ __int64_t ilf_blkno; /* blkno of inode buffer */ __int32_t ilf_len; /* len of inode buffer */ __int32_t ilf_boffset; /* off of inode in buffer */ @@ -66,10 +60,7 @@ typedef struct xfs_inode_log_format_64 { __uint16_t ilf_dsize; /* size of data/ext/root */ __uint32_t ilf_pad; /* pad for 64 bit boundary */ __uint64_t ilf_ino; /* inode number */ - union { - __uint32_t ilfu_rdev; /* rdev value for dev inode*/ - uuid_t ilfu_uuid; /* mount point value */ - } ilf_u; + __uint32_t ilf_rdev; /* rdev value for dev inode*/ __int64_t ilf_blkno; /* blkno of inode buffer */ __int32_t ilf_len; /* len of inode buffer */ __int32_t ilf_boffset; /* off of inode in buffer */ @@ -83,15 +74,15 @@ typedef struct xfs_inode_log_format_64 { #define XFS_ILOG_DEXT 0x004 /* log i_df.if_extents */ #define XFS_ILOG_DBROOT 0x008 /* log i_df.i_broot */ #define XFS_ILOG_DEV 0x010 /* log the dev field */ -#define XFS_ILOG_UUID 0x020 /* log the uuid field */ +/* 0x020*/ /* unused */ #define XFS_ILOG_ADATA 0x040 /* log i_af.if_data */ #define XFS_ILOG_AEXT 0x080 /* log i_af.if_extents */ #define XFS_ILOG_ABROOT 0x100 /* log i_af.i_broot */ #define XFS_ILOG_NONCORE (XFS_ILOG_DDATA | XFS_ILOG_DEXT | \ XFS_ILOG_DBROOT | XFS_ILOG_DEV | \ - XFS_ILOG_UUID | XFS_ILOG_ADATA | \ - XFS_ILOG_AEXT | XFS_ILOG_ABROOT) + XFS_ILOG_ADATA | XFS_ILOG_AEXT | \ + XFS_ILOG_ABROOT) #define XFS_ILOG_DFORK (XFS_ILOG_DDATA | XFS_ILOG_DEXT | \ XFS_ILOG_DBROOT) @@ -101,9 +92,8 @@ typedef struct xfs_inode_log_format_64 { #define XFS_ILOG_ALL (XFS_ILOG_CORE | XFS_ILOG_DDATA | \ XFS_ILOG_DEXT | XFS_ILOG_DBROOT | \ - XFS_ILOG_DEV | XFS_ILOG_UUID | \ - XFS_ILOG_ADATA | XFS_ILOG_AEXT | \ - XFS_ILOG_ABROOT) + XFS_ILOG_DEV | XFS_ILOG_ADATA | \ + XFS_ILOG_AEXT | XFS_ILOG_ABROOT) #define XFS_ILI_HOLD 0x1 #define XFS_ILI_IOLOCKED_EXCL 0x2 Index: linux-2.6-xfs/fs/xfs/xfs_log_recover.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_log_recover.c +++ linux-2.6-xfs/fs/xfs/xfs_log_recover.c @@ -2420,14 +2420,8 @@ xlog_recover_do_inode_trans( } fields = in_f->ilf_fields; - switch (fields & (XFS_ILOG_DEV | XFS_ILOG_UUID)) { - case XFS_ILOG_DEV: - dip->di_u.di_dev = cpu_to_be32(in_f->ilf_u.ilfu_rdev); - break; - case XFS_ILOG_UUID: - dip->di_u.di_muuid = in_f->ilf_u.ilfu_uuid; - break; - } + if (fields & XFS_ILOG_DEV) + dip->di_u.di_dev = cpu_to_be32(in_f->ilf_rdev); if (in_f->ilf_size == 2) goto write_inode_buffer; Index: linux-2.6-xfs/fs/xfs/xfsidbg.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfsidbg.c +++ linux-2.6-xfs/fs/xfs/xfsidbg.c @@ -3424,7 +3424,7 @@ xfs_inode_item_print(xfs_inode_log_item_ kdb_printf("dsize %d, asize %d, rdev 0x%x\n", ilip->ili_format.ilf_dsize, ilip->ili_format.ilf_asize, - ilip->ili_format.ilf_u.ilfu_rdev); + ilip->ili_format.ilf_rdev); kdb_printf("blkno 0x%Lx len 0x%x boffset 0x%x\n", ilip->ili_format.ilf_blkno, ilip->ili_format.ilf_len, Index: linux-2.6-xfs/fs/xfs/xfs_inode.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_inode.h +++ linux-2.6-xfs/fs/xfs/xfs_inode.h @@ -79,7 +79,6 @@ typedef struct xfs_ifork { char if_inline_data[XFS_INLINE_DATA]; /* very small file data */ xfs_dev_t if_rdev; /* dev number if special */ - uuid_t if_uuid; /* mount point value */ } if_u2; } xfs_ifork_t; From owner-xfs@oss.sgi.com Fri Mar 7 20:31:20 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 07 Mar 2008 20:31:41 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m284VFtO030723 for ; Fri, 7 Mar 2008 20:31:18 -0800 Received: from [134.15.251.3] (melb-sw-corp-251-3.corp.sgi.com [134.15.251.3]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA07766; Sat, 8 Mar 2008 15:31:37 +1100 Message-ID: <47D216A3.9040406@sgi.com> Date: Sat, 08 Mar 2008 15:31:31 +1100 From: Ian Costello Reply-To: ianc@melbourne.sgi.com User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Eric Sandeen CC: xfs-oss Subject: Re: [PATCH, RFC] - remove mounpoint UUID code References: <47D20F78.7000103@sandeen.net> In-Reply-To: <47D20F78.7000103@sandeen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14806 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: ianc@sgi.com Precedence: bulk X-list: xfs CXFS does use this to mount filesystems, i.e. on a client read the sb get the uuid and use the uuid to lookup the MDS to request the mount... Having said that if it is removed then it will force us to look at another method to mount a cxfs filesystem, and also remove the necessity for cxfs clients to not read the superblock (which is the only metadata cxfs clients read off disk at this point)... Regards, -- Ian Costello Phone: +61 3 9963 1952 R&D Engineer Mobile: +61 417 508 522 CXFS MultiOS Eric Sandeen wrote: > It looks like all of the below is unused... and according > to Nathan, > > "dont think it even got used/implemented anywhere, but i think it > was meant to be an auto-mount kinda thing... such that when you look > up at that point, it knows to mount the device with that uuid there, > if its not already it was never really written anywhere ... just an > idea in doug doucettes brain i think." > > Think it'll ever go anywhere, or should it get pruned? > > The below builds; not at all tested, until I get an idea if it's worth > doing. Need to double check that some structures might not need padding > out to keep things compatible/consistent... > > dmapi/xfs_dm.c | 2 -- > xfs_attr_leaf.c | 6 +----- > xfs_bmap.c | 4 ---- > xfs_dinode.h | 2 -- > xfs_inode.c | 8 -------- > xfs_inode.h | 1 - > xfs_inode_item.c | 53 +++++++++++------------------------------------------ > xfs_inode_item.h | 26 ++++++++------------------ > xfs_itable.c | 2 -- > xfs_log_recover.c | 10 ++-------- > xfsidbg.c | 2 +- > 11 files changed, 23 insertions(+), 93 deletions(-) > > > Index: linux-2.6-xfs/fs/xfs/dmapi/xfs_dm.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/dmapi/xfs_dm.c > +++ linux-2.6-xfs/fs/xfs/dmapi/xfs_dm.c > @@ -363,7 +363,6 @@ xfs_dip_to_stat( > buf->dt_blocks = 0; > break; > case XFS_DINODE_FMT_LOCAL: > - case XFS_DINODE_FMT_UUID: > buf->dt_rdev = 0; > buf->dt_blksize = mp->m_sb.sb_blocksize; > buf->dt_blocks = 0; > @@ -431,7 +430,6 @@ xfs_ip_to_stat( > buf->dt_blocks = 0; > break; > case XFS_DINODE_FMT_LOCAL: > - case XFS_DINODE_FMT_UUID: > buf->dt_rdev = 0; > buf->dt_blksize = mp->m_sb.sb_blocksize; > buf->dt_blocks = 0; > Index: linux-2.6-xfs/fs/xfs/xfs_attr_leaf.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/xfs_attr_leaf.c > +++ linux-2.6-xfs/fs/xfs/xfs_attr_leaf.c > @@ -155,13 +155,9 @@ xfs_attr_shortform_bytesfit(xfs_inode_t > > offset = (XFS_LITINO(mp) - bytes) >> 3; /* rounded down */ > > - switch (dp->i_d.di_format) { > - case XFS_DINODE_FMT_DEV: > + if (dp->i_d.di_format == XFS_DINODE_FMT_DEV) { > minforkoff = roundup(sizeof(xfs_dev_t), 8) >> 3; > return (offset >= minforkoff) ? minforkoff : 0; > - case XFS_DINODE_FMT_UUID: > - minforkoff = roundup(sizeof(uuid_t), 8) >> 3; > - return (offset >= minforkoff) ? minforkoff : 0; > } > > if (!(mp->m_flags & XFS_MOUNT_ATTR2)) { > Index: linux-2.6-xfs/fs/xfs/xfs_bmap.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/xfs_bmap.c > +++ linux-2.6-xfs/fs/xfs/xfs_bmap.c > @@ -3532,7 +3532,6 @@ xfs_bmap_forkoff_reset( > { > if (whichfork == XFS_ATTR_FORK && > (ip->i_d.di_format != XFS_DINODE_FMT_DEV) && > - (ip->i_d.di_format != XFS_DINODE_FMT_UUID) && > (ip->i_d.di_format != XFS_DINODE_FMT_BTREE) && > ((mp->m_attroffset >> 3) > ip->i_d.di_forkoff)) { > ip->i_d.di_forkoff = mp->m_attroffset >> 3; > @@ -4000,9 +3999,6 @@ xfs_bmap_add_attrfork( > case XFS_DINODE_FMT_DEV: > ip->i_d.di_forkoff = roundup(sizeof(xfs_dev_t), 8) >> 3; > break; > - case XFS_DINODE_FMT_UUID: > - ip->i_d.di_forkoff = roundup(sizeof(uuid_t), 8) >> 3; > - break; > case XFS_DINODE_FMT_LOCAL: > case XFS_DINODE_FMT_EXTENTS: > case XFS_DINODE_FMT_BTREE: > Index: linux-2.6-xfs/fs/xfs/xfs_dinode.h > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/xfs_dinode.h > +++ linux-2.6-xfs/fs/xfs/xfs_dinode.h > @@ -88,7 +88,6 @@ typedef struct xfs_dinode > xfs_dir2_sf_t di_dir2sf; /* shortform directory v2 */ > char di_c[1]; /* local contents */ > __be32 di_dev; /* device for S_IFCHR/S_IFBLK */ > - uuid_t di_muuid; /* mount point value */ > char di_symlink[1]; /* local symbolic link */ > } di_u; > union { > @@ -150,7 +149,6 @@ typedef enum xfs_dinode_fmt > /* LNK: di_symlink */ > XFS_DINODE_FMT_EXTENTS, /* DIR, REG, LNK: di_bmx */ > XFS_DINODE_FMT_BTREE, /* DIR, REG, LNK: di_bmbt */ > - XFS_DINODE_FMT_UUID /* MNT: di_uuid */ > } xfs_dinode_fmt_t; > > /* > Index: linux-2.6-xfs/fs/xfs/xfs_inode.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/xfs_inode.c > +++ linux-2.6-xfs/fs/xfs/xfs_inode.c > @@ -2970,14 +2970,6 @@ xfs_iflush_fork( > } > break; > > - case XFS_DINODE_FMT_UUID: > - if (iip->ili_format.ilf_fields & XFS_ILOG_UUID) { > - ASSERT(whichfork == XFS_DATA_FORK); > - memcpy(&dip->di_u.di_muuid, &ip->i_df.if_u2.if_uuid, > - sizeof(uuid_t)); > - } > - break; > - > default: > ASSERT(0); > break; > Index: linux-2.6-xfs/fs/xfs/xfs_inode_item.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/xfs_inode_item.c > +++ linux-2.6-xfs/fs/xfs/xfs_inode_item.c > @@ -70,8 +70,7 @@ xfs_inode_item_size( > switch (ip->i_d.di_format) { > case XFS_DINODE_FMT_EXTENTS: > iip->ili_format.ilf_fields &= > - ~(XFS_ILOG_DDATA | XFS_ILOG_DBROOT | > - XFS_ILOG_DEV | XFS_ILOG_UUID); > + ~(XFS_ILOG_DDATA | XFS_ILOG_DBROOT | XFS_ILOG_DEV); > if ((iip->ili_format.ilf_fields & XFS_ILOG_DEXT) && > (ip->i_d.di_nextents > 0) && > (ip->i_df.if_bytes > 0)) { > @@ -86,8 +85,7 @@ xfs_inode_item_size( > ASSERT(ip->i_df.if_ext_max == > XFS_IFORK_DSIZE(ip) / (uint)sizeof(xfs_bmbt_rec_t)); > iip->ili_format.ilf_fields &= > - ~(XFS_ILOG_DDATA | XFS_ILOG_DEXT | > - XFS_ILOG_DEV | XFS_ILOG_UUID); > + ~(XFS_ILOG_DDATA | XFS_ILOG_DEXT | XFS_ILOG_DEV); > if ((iip->ili_format.ilf_fields & XFS_ILOG_DBROOT) && > (ip->i_df.if_broot_bytes > 0)) { > ASSERT(ip->i_df.if_broot != NULL); > @@ -112,8 +110,7 @@ xfs_inode_item_size( > > case XFS_DINODE_FMT_LOCAL: > iip->ili_format.ilf_fields &= > - ~(XFS_ILOG_DEXT | XFS_ILOG_DBROOT | > - XFS_ILOG_DEV | XFS_ILOG_UUID); > + ~(XFS_ILOG_DEXT | XFS_ILOG_DBROOT | XFS_ILOG_DEV); > if ((iip->ili_format.ilf_fields & XFS_ILOG_DDATA) && > (ip->i_df.if_bytes > 0)) { > ASSERT(ip->i_df.if_u1.if_data != NULL); > @@ -126,14 +123,7 @@ xfs_inode_item_size( > > case XFS_DINODE_FMT_DEV: > iip->ili_format.ilf_fields &= > - ~(XFS_ILOG_DDATA | XFS_ILOG_DBROOT | > - XFS_ILOG_DEXT | XFS_ILOG_UUID); > - break; > - > - case XFS_DINODE_FMT_UUID: > - iip->ili_format.ilf_fields &= > - ~(XFS_ILOG_DDATA | XFS_ILOG_DBROOT | > - XFS_ILOG_DEXT | XFS_ILOG_DEV); > + ~(XFS_ILOG_DDATA | XFS_ILOG_DBROOT | XFS_ILOG_DEXT); > break; > > default: > @@ -319,8 +309,7 @@ xfs_inode_item_format( > switch (ip->i_d.di_format) { > case XFS_DINODE_FMT_EXTENTS: > ASSERT(!(iip->ili_format.ilf_fields & > - (XFS_ILOG_DDATA | XFS_ILOG_DBROOT | > - XFS_ILOG_DEV | XFS_ILOG_UUID))); > + (XFS_ILOG_DDATA | XFS_ILOG_DBROOT | XFS_ILOG_DEV))); > if (iip->ili_format.ilf_fields & XFS_ILOG_DEXT) { > ASSERT(ip->i_df.if_bytes > 0); > ASSERT(ip->i_df.if_u1.if_extents != NULL); > @@ -369,8 +358,7 @@ xfs_inode_item_format( > > case XFS_DINODE_FMT_BTREE: > ASSERT(!(iip->ili_format.ilf_fields & > - (XFS_ILOG_DDATA | XFS_ILOG_DEXT | > - XFS_ILOG_DEV | XFS_ILOG_UUID))); > + (XFS_ILOG_DDATA | XFS_ILOG_DEXT | XFS_ILOG_DEV))); > if (iip->ili_format.ilf_fields & XFS_ILOG_DBROOT) { > ASSERT(ip->i_df.if_broot_bytes > 0); > ASSERT(ip->i_df.if_broot != NULL); > @@ -385,8 +373,7 @@ xfs_inode_item_format( > > case XFS_DINODE_FMT_LOCAL: > ASSERT(!(iip->ili_format.ilf_fields & > - (XFS_ILOG_DBROOT | XFS_ILOG_DEXT | > - XFS_ILOG_DEV | XFS_ILOG_UUID))); > + (XFS_ILOG_DBROOT | XFS_ILOG_DEXT | XFS_ILOG_DEV))); > if (iip->ili_format.ilf_fields & XFS_ILOG_DDATA) { > ASSERT(ip->i_df.if_bytes > 0); > ASSERT(ip->i_df.if_u1.if_data != NULL); > @@ -411,21 +398,9 @@ xfs_inode_item_format( > > case XFS_DINODE_FMT_DEV: > ASSERT(!(iip->ili_format.ilf_fields & > - (XFS_ILOG_DBROOT | XFS_ILOG_DEXT | > - XFS_ILOG_DDATA | XFS_ILOG_UUID))); > + (XFS_ILOG_DBROOT | XFS_ILOG_DEXT | XFS_ILOG_DDATA))); > if (iip->ili_format.ilf_fields & XFS_ILOG_DEV) { > - iip->ili_format.ilf_u.ilfu_rdev = > - ip->i_df.if_u2.if_rdev; > - } > - break; > - > - case XFS_DINODE_FMT_UUID: > - ASSERT(!(iip->ili_format.ilf_fields & > - (XFS_ILOG_DBROOT | XFS_ILOG_DEXT | > - XFS_ILOG_DDATA | XFS_ILOG_DEV))); > - if (iip->ili_format.ilf_fields & XFS_ILOG_UUID) { > - iip->ili_format.ilf_u.ilfu_uuid = > - ip->i_df.if_u2.if_uuid; > + iip->ili_format.ilf_rdev = ip->i_df.if_u2.if_rdev; > } > break; > > @@ -1088,10 +1063,7 @@ xfs_inode_item_format_convert( > in_f->ilf_asize = in_f32->ilf_asize; > in_f->ilf_dsize = in_f32->ilf_dsize; > in_f->ilf_ino = in_f32->ilf_ino; > - /* copy biggest field of ilf_u */ > - memcpy(in_f->ilf_u.ilfu_uuid.__u_bits, > - in_f32->ilf_u.ilfu_uuid.__u_bits, > - sizeof(uuid_t)); > + in_f->ilf_rdev = in_f32->ilf_rdev; > in_f->ilf_blkno = in_f32->ilf_blkno; > in_f->ilf_len = in_f32->ilf_len; > in_f->ilf_boffset = in_f32->ilf_boffset; > @@ -1106,10 +1078,7 @@ xfs_inode_item_format_convert( > in_f->ilf_asize = in_f64->ilf_asize; > in_f->ilf_dsize = in_f64->ilf_dsize; > in_f->ilf_ino = in_f64->ilf_ino; > - /* copy biggest field of ilf_u */ > - memcpy(in_f->ilf_u.ilfu_uuid.__u_bits, > - in_f64->ilf_u.ilfu_uuid.__u_bits, > - sizeof(uuid_t)); > + in_f->ilf_rdev = in_f64->ilf_rdev; > in_f->ilf_blkno = in_f64->ilf_blkno; > in_f->ilf_len = in_f64->ilf_len; > in_f->ilf_boffset = in_f64->ilf_boffset; > Index: linux-2.6-xfs/fs/xfs/xfs_itable.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/xfs_itable.c > +++ linux-2.6-xfs/fs/xfs/xfs_itable.c > @@ -111,7 +111,6 @@ xfs_bulkstat_one_iget( > buf->bs_blocks = 0; > break; > case XFS_DINODE_FMT_LOCAL: > - case XFS_DINODE_FMT_UUID: > buf->bs_rdev = 0; > buf->bs_blksize = mp->m_sb.sb_blocksize; > buf->bs_blocks = 0; > @@ -186,7 +185,6 @@ xfs_bulkstat_one_dinode( > buf->bs_blocks = 0; > break; > case XFS_DINODE_FMT_LOCAL: > - case XFS_DINODE_FMT_UUID: > buf->bs_rdev = 0; > buf->bs_blksize = mp->m_sb.sb_blocksize; > buf->bs_blocks = 0; > Index: linux-2.6-xfs/fs/xfs/xfs_inode_item.h > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/xfs_inode_item.h > +++ linux-2.6-xfs/fs/xfs/xfs_inode_item.h > @@ -31,10 +31,7 @@ typedef struct xfs_inode_log_format { > __uint16_t ilf_asize; /* size of attr d/ext/root */ > __uint16_t ilf_dsize; /* size of data/ext/root */ > __uint64_t ilf_ino; /* inode number */ > - union { > - __uint32_t ilfu_rdev; /* rdev value for dev inode*/ > - uuid_t ilfu_uuid; /* mount point value */ > - } ilf_u; > + __uint32_t ilf_rdev; /* rdev value for dev inode*/ > __int64_t ilf_blkno; /* blkno of inode buffer */ > __int32_t ilf_len; /* len of inode buffer */ > __int32_t ilf_boffset; /* off of inode in buffer */ > @@ -48,10 +45,7 @@ typedef struct xfs_inode_log_format_32 { > __uint16_t ilf_asize; /* size of attr d/ext/root */ > __uint16_t ilf_dsize; /* size of data/ext/root */ > __uint64_t ilf_ino; /* inode number */ > - union { > - __uint32_t ilfu_rdev; /* rdev value for dev inode*/ > - uuid_t ilfu_uuid; /* mount point value */ > - } ilf_u; > + __uint32_t ilf_rdev; /* rdev value for dev inode*/ > __int64_t ilf_blkno; /* blkno of inode buffer */ > __int32_t ilf_len; /* len of inode buffer */ > __int32_t ilf_boffset; /* off of inode in buffer */ > @@ -66,10 +60,7 @@ typedef struct xfs_inode_log_format_64 { > __uint16_t ilf_dsize; /* size of data/ext/root */ > __uint32_t ilf_pad; /* pad for 64 bit boundary */ > __uint64_t ilf_ino; /* inode number */ > - union { > - __uint32_t ilfu_rdev; /* rdev value for dev inode*/ > - uuid_t ilfu_uuid; /* mount point value */ > - } ilf_u; > + __uint32_t ilf_rdev; /* rdev value for dev inode*/ > __int64_t ilf_blkno; /* blkno of inode buffer */ > __int32_t ilf_len; /* len of inode buffer */ > __int32_t ilf_boffset; /* off of inode in buffer */ > @@ -83,15 +74,15 @@ typedef struct xfs_inode_log_format_64 { > #define XFS_ILOG_DEXT 0x004 /* log i_df.if_extents */ > #define XFS_ILOG_DBROOT 0x008 /* log i_df.i_broot */ > #define XFS_ILOG_DEV 0x010 /* log the dev field */ > -#define XFS_ILOG_UUID 0x020 /* log the uuid field */ > +/* 0x020*/ /* unused */ > #define XFS_ILOG_ADATA 0x040 /* log i_af.if_data */ > #define XFS_ILOG_AEXT 0x080 /* log i_af.if_extents */ > #define XFS_ILOG_ABROOT 0x100 /* log i_af.i_broot */ > > #define XFS_ILOG_NONCORE (XFS_ILOG_DDATA | XFS_ILOG_DEXT | \ > XFS_ILOG_DBROOT | XFS_ILOG_DEV | \ > - XFS_ILOG_UUID | XFS_ILOG_ADATA | \ > - XFS_ILOG_AEXT | XFS_ILOG_ABROOT) > + XFS_ILOG_ADATA | XFS_ILOG_AEXT | \ > + XFS_ILOG_ABROOT) > > #define XFS_ILOG_DFORK (XFS_ILOG_DDATA | XFS_ILOG_DEXT | \ > XFS_ILOG_DBROOT) > @@ -101,9 +92,8 @@ typedef struct xfs_inode_log_format_64 { > > #define XFS_ILOG_ALL (XFS_ILOG_CORE | XFS_ILOG_DDATA | \ > XFS_ILOG_DEXT | XFS_ILOG_DBROOT | \ > - XFS_ILOG_DEV | XFS_ILOG_UUID | \ > - XFS_ILOG_ADATA | XFS_ILOG_AEXT | \ > - XFS_ILOG_ABROOT) > + XFS_ILOG_DEV | XFS_ILOG_ADATA | \ > + XFS_ILOG_AEXT | XFS_ILOG_ABROOT) > > #define XFS_ILI_HOLD 0x1 > #define XFS_ILI_IOLOCKED_EXCL 0x2 > Index: linux-2.6-xfs/fs/xfs/xfs_log_recover.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/xfs_log_recover.c > +++ linux-2.6-xfs/fs/xfs/xfs_log_recover.c > @@ -2420,14 +2420,8 @@ xlog_recover_do_inode_trans( > } > > fields = in_f->ilf_fields; > - switch (fields & (XFS_ILOG_DEV | XFS_ILOG_UUID)) { > - case XFS_ILOG_DEV: > - dip->di_u.di_dev = cpu_to_be32(in_f->ilf_u.ilfu_rdev); > - break; > - case XFS_ILOG_UUID: > - dip->di_u.di_muuid = in_f->ilf_u.ilfu_uuid; > - break; > - } > + if (fields & XFS_ILOG_DEV) > + dip->di_u.di_dev = cpu_to_be32(in_f->ilf_rdev); > > if (in_f->ilf_size == 2) > goto write_inode_buffer; > Index: linux-2.6-xfs/fs/xfs/xfsidbg.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/xfsidbg.c > +++ linux-2.6-xfs/fs/xfs/xfsidbg.c > @@ -3424,7 +3424,7 @@ xfs_inode_item_print(xfs_inode_log_item_ > kdb_printf("dsize %d, asize %d, rdev 0x%x\n", > ilip->ili_format.ilf_dsize, > ilip->ili_format.ilf_asize, > - ilip->ili_format.ilf_u.ilfu_rdev); > + ilip->ili_format.ilf_rdev); > kdb_printf("blkno 0x%Lx len 0x%x boffset 0x%x\n", > ilip->ili_format.ilf_blkno, > ilip->ili_format.ilf_len, > Index: linux-2.6-xfs/fs/xfs/xfs_inode.h > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/xfs_inode.h > +++ linux-2.6-xfs/fs/xfs/xfs_inode.h > @@ -79,7 +79,6 @@ typedef struct xfs_ifork { > char if_inline_data[XFS_INLINE_DATA]; > /* very small file data */ > xfs_dev_t if_rdev; /* dev number if special */ > - uuid_t if_uuid; /* mount point value */ > } if_u2; > } xfs_ifork_t; > > > > > From owner-xfs@oss.sgi.com Fri Mar 7 20:33:07 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 07 Mar 2008 20:33:15 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m284X4Io030966 for ; Fri, 7 Mar 2008 20:33:07 -0800 X-ASG-Debug-ID: 1204950814-498e02430000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 4C372F42EDC for ; Fri, 7 Mar 2008 20:33:34 -0800 (PST) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id jUKY0lhHteQUaVHy for ; Fri, 07 Mar 2008 20:33:34 -0800 (PST) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 45CE218004487; Fri, 7 Mar 2008 22:33:34 -0600 (CST) Message-ID: <47D2171D.7070202@sandeen.net> Date: Fri, 07 Mar 2008 22:33:33 -0600 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: ianc@melbourne.sgi.com CC: xfs-oss X-ASG-Orig-Subj: Re: [PATCH, RFC] - remove mounpoint UUID code Subject: Re: [PATCH, RFC] - remove mounpoint UUID code References: <47D20F78.7000103@sandeen.net> <47D216A3.9040406@sgi.com> In-Reply-To: <47D216A3.9040406@sgi.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1204950815 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.42 X-Barracuda-Spam-Status: No, SCORE=-1.42 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=COMMA_SUBJECT X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.44197 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.60 COMMA_SUBJECT Subject is like 'Re: FDSDS, this is a subject' X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14807 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Ian Costello wrote: > CXFS does use this to mount filesystems, i.e. on a client read the sb > get the uuid and use the uuid to lookup the MDS to request the mount... Well, this isn't removing the sb uuid... it's this special file type XFS_DINODE_FMT_UUID... which is cxfs using? -Eric > Having said that if it is removed then it will force us to look at > another method to mount a cxfs filesystem, and also remove the necessity > for cxfs clients to not read the superblock (which is the only metadata > cxfs clients read off disk at this point)... > > Regards, > From owner-xfs@oss.sgi.com Fri Mar 7 20:40:34 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 07 Mar 2008 20:40:41 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m284eUbi031620 for ; Fri, 7 Mar 2008 20:40:33 -0800 Received: from [134.15.251.3] (melb-sw-corp-251-3.corp.sgi.com [134.15.251.3]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA08056; Sat, 8 Mar 2008 15:40:54 +1100 Message-ID: <47D218CF.8090909@sgi.com> Date: Sat, 08 Mar 2008 15:40:47 +1100 From: Ian Costello Reply-To: ianc@melbourne.sgi.com User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Eric Sandeen CC: xfs-oss Subject: Re: [PATCH, RFC] - remove mounpoint UUID code References: <47D20F78.7000103@sandeen.net> <47D216A3.9040406@sgi.com> <47D2171D.7070202@sandeen.net> In-Reply-To: <47D2171D.7070202@sandeen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14808 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: ianc@sgi.com Precedence: bulk X-list: xfs Eric, My bad, cxfs uses the sb_uuid, should have looked a little closer at the patch. I assumed the worst from the heading (must have filtered the "point" out of the heading :) Eric Sandeen wrote: > Ian Costello wrote: >> CXFS does use this to mount filesystems, i.e. on a client read the sb >> get the uuid and use the uuid to lookup the MDS to request the mount... > > Well, this isn't removing the sb uuid... it's this special file type > XFS_DINODE_FMT_UUID... which is cxfs using? > > -Eric > >> Having said that if it is removed then it will force us to look at >> another method to mount a cxfs filesystem, and also remove the necessity >> for cxfs clients to not read the superblock (which is the only metadata >> cxfs clients read off disk at this point)... >> >> Regards, >> > > Thanks, -- Ian Costello Phone: +61 3 9963 1952 R&D Engineer Mobile: +61 417 508 522 CXFS MultiOS From owner-xfs@oss.sgi.com Fri Mar 7 20:59:24 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 07 Mar 2008 20:59:42 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m284xNpm032515 for ; Fri, 7 Mar 2008 20:59:24 -0800 X-ASG-Debug-ID: 1204952393-498902840000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 29387F43065 for ; Fri, 7 Mar 2008 20:59:53 -0800 (PST) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id xpV53WOlS2c7ZmB2 for ; Fri, 07 Mar 2008 20:59:53 -0800 (PST) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id C912618004487; Fri, 7 Mar 2008 22:59:22 -0600 (CST) Message-ID: <47D21D2A.90902@sandeen.net> Date: Fri, 07 Mar 2008 22:59:22 -0600 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: ianc@melbourne.sgi.com CC: xfs-oss X-ASG-Orig-Subj: Re: [PATCH, RFC] - remove mounpoint UUID code Subject: Re: [PATCH, RFC] - remove mounpoint UUID code References: <47D20F78.7000103@sandeen.net> <47D216A3.9040406@sgi.com> <47D2171D.7070202@sandeen.net> <47D218CF.8090909@sgi.com> In-Reply-To: <47D218CF.8090909@sgi.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1204952394 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.42 X-Barracuda-Spam-Status: No, SCORE=-1.42 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=COMMA_SUBJECT X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.44197 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.60 COMMA_SUBJECT Subject is like 'Re: FDSDS, this is a subject' X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14809 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Ian Costello wrote: > Eric, > > My bad, cxfs uses the sb_uuid, should have looked a little closer at the > patch. I assumed the worst from the heading (must have filtered the > "point" out of the heading :) Nah, I wouldn't do that to you ;) (and you wouldn't have to accept it if I did try!) :) -Eric From owner-xfs@oss.sgi.com Fri Mar 7 21:37:51 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 07 Mar 2008 21:38:13 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: *** X-Spam-Status: No, score=3.0 required=5.0 tests=BAYES_50,HTML_MESSAGE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m285bnhJ001773 for ; Fri, 7 Mar 2008 21:37:51 -0800 X-ASG-Debug-ID: 1204954698-1d4a00130000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from po-out-1718.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 06F2A66F96A for ; Fri, 7 Mar 2008 21:38:18 -0800 (PST) Received: from po-out-1718.google.com (po-out-1718.google.com [72.14.252.156]) by cuda.sgi.com with ESMTP id UQDt79kCG9bwYktA for ; Fri, 07 Mar 2008 21:38:18 -0800 (PST) Received: by po-out-1718.google.com with SMTP id y22so1183149pof.2 for ; Fri, 07 Mar 2008 21:38:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:subject:mime-version:content-type; bh=ONXi38G7jo14WrL41DE4EDkXLoyLF5dLvJm62KmDDj8=; b=PJCIs/03fMSq0D+j9A8qIUYUK3rtuRkq/5jtlMEir8JiG4pH0PhuEwnxpQflI3XO2+wqZ9MDcTC02WvO6lFXkXJcu6+DIo7EuHlYIYvENjHoKf0jRTiEvbm4O7S8SAZWUnDvWsPuzloYGZGDsNkV375pGuolRD4MWQV8lHr5+Uc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:subject:mime-version:content-type; b=mTqAcFpTbC2knjwN7tx8JNquUEjTgSv0z8QsuEZI0DxrXJ8aFgrTsO3zn2/iToPChrj79cWw5ThNJDXtH1cAat6rV9+rgPbLHrxMUzqF95wGJEOV69x9EYabncG7pJUvuVRSqicRPvmm0gDvG7uiCWC2jZ3YqPeCqsyynQzLLuo= Received: by 10.141.71.8 with SMTP id y8mr1466369rvk.32.1204954670809; Fri, 07 Mar 2008 21:37:50 -0800 (PST) Received: by 10.141.5.10 with HTTP; Fri, 7 Mar 2008 21:37:50 -0800 (PST) Message-ID: Date: Sat, 8 Mar 2008 11:07:50 +0530 From: "Arpita Choudhary" X-ASG-Orig-Subj: Arpita, has requested to connect online Subject: Arpita, has requested to connect online MIME-Version: 1.0 X-Barracuda-Connect: po-out-1718.google.com[72.14.252.156] X-Barracuda-Start-Time: 1204954699 X-Barracuda-Bayes: INNOCENT GLOBAL 0.4925 1.0000 0.0000 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.32 X-Barracuda-Spam-Status: No, SCORE=0.32 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=HTML_MESSAGE, MISSING_HEADERS, TO_CC_NONE X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.44202 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.19 MISSING_HEADERS Missing To: header 0.00 HTML_MESSAGE BODY: HTML included in message 0.13 TO_CC_NONE No To: or Cc: header To: undisclosed-recipients:; X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-length: 503 X-archive-position: 14810 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: arpita.choudhary894@gmail.com Precedence: bulk X-list: xfs Hi, I would like to request you to join on SiliconIndia. It helps you and me leveraging the networks of their friends, friends` friends, colleagues, classmates, and relatives to get better opportunities. We can refer our friends and relatives to jobs in our companies and our friends` companies. Some companies even pay for referring candidates. Copy the link below to your browser to join my friend list siliconindia.com/register.php?id=924x5ys1 Thanks Arpita [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Sat Mar 8 03:54:01 2008 Received: with ECARTIS (v1.0.0; list xfs); Sat, 08 Mar 2008 03:54:22 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m28Brx2b021321 for ; Sat, 8 Mar 2008 03:54:01 -0800 X-ASG-Debug-ID: 1204977268-7936011e0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 7BAEAF44BAA for ; Sat, 8 Mar 2008 03:54:29 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id xLAulTBskzB9FOhk for ; Sat, 08 Mar 2008 03:54:29 -0800 (PST) Received: from hch by bombadil.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1JXxdD-0003YR-Rq; Sat, 08 Mar 2008 11:54:27 +0000 Date: Sat, 8 Mar 2008 06:54:27 -0500 From: Christoph Hellwig To: Eric Sandeen Cc: xfs-oss X-ASG-Orig-Subj: Re: [PATCH, RFC] - remove mounpoint UUID code Subject: Re: [PATCH, RFC] - remove mounpoint UUID code Message-ID: <20080308115427.GB27606@infradead.org> References: <47D20F78.7000103@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47D20F78.7000103@sandeen.net> User-Agent: Mutt/1.5.17 (2007-11-01) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1204977269 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.42 X-Barracuda-Spam-Status: No, SCORE=-1.42 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=COMMA_SUBJECT X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.44225 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.60 COMMA_SUBJECT Subject is like 'Re: FDSDS, this is a subject' X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14811 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs On Fri, Mar 07, 2008 at 10:00:56PM -0600, Eric Sandeen wrote: > It looks like all of the below is unused... and according > to Nathan, > > "dont think it even got used/implemented anywhere, but i think it > was meant to be an auto-mount kinda thing... such that when you look > up at that point, it knows to mount the device with that uuid there, > if its not already it was never really written anywhere ... just an > idea in doug doucettes brain i think." > > Think it'll ever go anywhere, or should it get pruned? > > The below builds; not at all tested, until I get an idea if it's worth > doing. Need to double check that some structures might not need padding > out to keep things compatible/consistent... This looks fine to me. But please keep the XFS_DINODE_FMT_UUID enum value and add a big comment close to it documenting what it was an maybe a approximate removal date so people who care about it can look it up in the SCM history easily. From owner-xfs@oss.sgi.com Sat Mar 8 22:14:53 2008 Received: with ECARTIS (v1.0.0; list xfs); Sat, 08 Mar 2008 22:15:17 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m296EpBu021638 for ; Sat, 8 Mar 2008 22:14:53 -0800 X-ASG-Debug-ID: 1205043315-4f8d00da0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.g-house.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id E493BF4A7D9; Sat, 8 Mar 2008 22:15:16 -0800 (PST) Received: from mail.g-house.de (ns2.g-housing.de [81.169.133.75]) by cuda.sgi.com with ESMTP id 2RzUD3Bf2hHIEqhC; Sat, 08 Mar 2008 22:15:16 -0800 (PST) Received: from [89.54.167.70] (helo=[192.168.178.25]) by mail.g-house.de with esmtpa (Exim 4.63) (envelope-from ) id 1JYEoT-0004FU-HI; Sun, 09 Mar 2008 07:15:13 +0100 Date: Sun, 9 Mar 2008 07:15:09 +0100 (CET) From: Christian Kujau X-X-Sender: evil@sheep.housecafe.de To: David Chinner cc: LKML , xfs@oss.sgi.com X-ASG-Orig-Subj: 2.6.25-rc hangs (was: INFO: task mount:11202 blocked for more than 120 seconds) Subject: 2.6.25-rc hangs (was: INFO: task mount:11202 blocked for more than 120 seconds) In-Reply-To: Message-ID: References: <20080307224040.GV155259@sgi.com> User-Agent: Alpine 1.00 (DEB 882 2007-12-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Barracuda-Connect: ns2.g-housing.de[81.169.133.75] X-Barracuda-Start-Time: 1205043320 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.52 X-Barracuda-Spam-Status: No, SCORE=-1.52 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_RULE7568M X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.44300 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.50 BSF_RULE7568M Custom Rule 7568M X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14812 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lists@nerdbynature.de Precedence: bulk X-list: xfs On Sat, 8 Mar 2008, Christian Kujau wrote: > FWIW, it's 100% reproducible with 2.6.25-rc3 too...sigh :-\ > So, the last working kernel for me is 2.6.24.1 - that's a lot of bisecting > and I fear that compile errors will invalidate the bisecting results again or > make it impossible at all....I'll try anyway....tomorrow... Bisecting failed as expected :-( I tried to follow the git-bisect manpage (and have successfully used bisect in the past a few times), but I think ~5700 revisions between 2.6.24 and 2.6.25 are just too much fuzz. The bisect logs so far, with my comments inbetween: git-bisect start # 2.6.25-rc4, known to be bad: # bad: [84c6f6046c5a2189160a8f0dca8b90427bf690ea] x86_64: make ptrace always sign-extend orig_ax to 64 bits git-bisect bad 84c6f6046c5a2189160a8f0dca8b90427bf690ea # 2.6.24, good: # good: [49914084e797530d9baaf51df9eda77babc98fa8] Linux 2.6.24 git-bisect good 49914084e797530d9baaf51df9eda77babc98fa8 # 2.6.24, hard lockup during boot, bad: # bad: [bd45ac0c5daae35e7c71138172e63df5cf644cf6] Merge branch 'linux-2.6' git-bisect bad bd45ac0c5daae35e7c71138172e63df5cf644cf6 I marked the last one bad, because I could not boot any more. As it's a headless box, I could not get more details. It did not even respond so sysrq-b. After marking this bad, I compiled and booted again - same result, hard lockup. So I tried again: git bisect reset git-bisect start # 2.6.25-rc4, known to be bad: # bad: [84c6f6046c5a2189160a8f0dca8b90427bf690ea] x86_64: make ptrace always sign-extend orig_ax to 64 bits git-bisect bad 84c6f6046c5a2189160a8f0dca8b90427bf690ea # 2.6.24, good: # good: [49914084e797530d9baaf51df9eda77babc98fa8] Linux 2.6.24 git-bisect good 49914084e797530d9baaf51df9eda77babc98fa8 # 2.6.24, hard lockup during boot, marking good anyway: # good: [bd45ac0c5daae35e7c71138172e63df5cf644cf6] Merge branch 'linux-2.6' git-bisect good bd45ac0c5daae35e7c71138172e63df5cf644cf6 # lockup # bad: [f0f1b3364ae7f48084bdf2837fb979ff59622523] Merge branch 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6 git-bisect bad f0f1b3364ae7f48084bdf2837fb979ff59622523 Although I could not boot with bd45ac0c5daae35e7c71138172e63df5cf644cf6, I marked it "good", as the lockup is totally unrelated to my problem. However, the box locks up as soon as I'm using the device-mapper. This time it does respond to sysrq-b. But still: I'm unable to diagnose the system hang [0] and I fear that 2.6.25 is released and for the first time since ages I'd have to skip a release... Help! Christian. [0] http://lkml.org/lkml/2008/3/7/308 -- BOFH excuse #288: Hard drive sleeping. Let it wake up on it's own... From owner-xfs@oss.sgi.com Sun Mar 9 09:44:27 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 09 Mar 2008 09:44:46 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m29GiMrG003504 for ; Sun, 9 Mar 2008 09:44:27 -0700 X-ASG-Debug-ID: 1205081089-7c77000a0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id DB2F6676D74 for ; Sun, 9 Mar 2008 09:44:49 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id g53wLb2Av486Dcs4 for ; Sun, 09 Mar 2008 09:44:49 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 979A418004487; Sun, 9 Mar 2008 11:44:43 -0500 (CDT) Message-ID: <47D413FA.50602@sandeen.net> Date: Sun, 09 Mar 2008 11:44:42 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Christian Kujau CC: David Chinner , LKML , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: 2.6.25-rc hangs Subject: Re: 2.6.25-rc hangs References: <20080307224040.GV155259@sgi.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1205081092 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.44339 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14813 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Christian Kujau wrote: > On Sat, 8 Mar 2008, Christian Kujau wrote: >> FWIW, it's 100% reproducible with 2.6.25-rc3 too...sigh :-\ >> So, the last working kernel for me is 2.6.24.1 - that's a lot of bisecting >> and I fear that compile errors will invalidate the bisecting results again or >> make it impossible at all....I'll try anyway....tomorrow... > > Bisecting failed as expected :-( > I tried to follow the git-bisect manpage (and have successfully used > bisect in the past a few times), but I think ~5700 revisions between > 2.6.24 and 2.6.25 are just too much fuzz. The bisect logs so far, with > my comments inbetween: Christian, what is the test you are using for the bisect? Thanks, -Eric From owner-xfs@oss.sgi.com Sun Mar 9 11:05:34 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 09 Mar 2008 11:05:53 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m29I5ViX010667 for ; Sun, 9 Mar 2008 11:05:34 -0700 X-ASG-Debug-ID: 1205085958-5e9a01560000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.g-house.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 178256773B3; Sun, 9 Mar 2008 11:05:59 -0700 (PDT) Received: from mail.g-house.de (ns2.g-housing.de [81.169.133.75]) by cuda.sgi.com with ESMTP id FemqvGVdy6WPy4tf; Sun, 09 Mar 2008 11:05:59 -0700 (PDT) Received: from [89.54.188.143] (helo=[192.168.178.25]) by mail.g-house.de with esmtpa (Exim 4.63) (envelope-from ) id 1JYPuG-0004Hb-9U; Sun, 09 Mar 2008 19:05:56 +0100 Date: Sun, 9 Mar 2008 19:05:53 +0100 (CET) From: Christian Kujau X-X-Sender: evil@sheep.housecafe.de To: Eric Sandeen cc: David Chinner , LKML , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: 2.6.25-rc hangs Subject: Re: 2.6.25-rc hangs In-Reply-To: <47D413FA.50602@sandeen.net> Message-ID: References: <20080307224040.GV155259@sgi.com> <47D413FA.50602@sandeen.net> User-Agent: Alpine 1.00 (DEB 882 2007-12-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Barracuda-Connect: ns2.g-housing.de[81.169.133.75] X-Barracuda-Start-Time: 1205085960 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.44345 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14814 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lists@nerdbynature.de Precedence: bulk X-list: xfs On Sun, 9 Mar 2008, Eric Sandeen wrote: >> I tried to follow the git-bisect manpage (and have successfully used >> bisect in the past a few times), but I think ~5700 revisions between >> 2.6.24 and 2.6.25 are just too much fuzz. The bisect logs so far, with >> my comments inbetween: > > Christian, what is the test you are using for the bisect? Sorry, I don't understand: which "test" do you mean? I did the bisect as per the bisect log and then just rebooted. Which gave me no usable results yet. I'm trying to boot 2.6.25-rc1 in a few moments and see if the hang is there as well. If it is, I'll start bisecting again and hope that "halfway between -rc1 and .24" will be a bootable kernel this time... The "error" I'm trying to chase is a system "hang", but no instant lockup. I can reproduce this by increasing disk I/O. I did this primarily with rsync from different filesystems to my backup XFS partition. After a few minutes, the INFO: messages[0] appeared. Thanks, Christian. [0] http://lkml.org/lkml/2008/3/7/308 -- BOFH excuse #2: solar flares From owner-xfs@oss.sgi.com Sun Mar 9 14:34:31 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 09 Mar 2008 14:34:50 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_72 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m29LYORI030610 for ; Sun, 9 Mar 2008 14:34:30 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA08094; Mon, 10 Mar 2008 08:34:47 +1100 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 m29LYjLF91659560; Mon, 10 Mar 2008 08:34:46 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id m29LYfLb91607587; Mon, 10 Mar 2008 08:34:41 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Mon, 10 Mar 2008 08:34:41 +1100 From: David Chinner To: Christian Kujau Cc: David Chinner , LKML , xfs@oss.sgi.com, dm-devel@redhat.com Subject: Re: INFO: task mount:11202 blocked for more than 120 seconds Message-ID: <20080309213441.GQ155407@sgi.com> References: <20080307224040.GV155259@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14815 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs [adding dm-devel to cc list] On Sat, Mar 08, 2008 at 12:46:40AM +0100, Christian Kujau wrote: > On Sat, 8 Mar 2008, David Chinner wrote: > >Well, if that is hung there, something else must be holding on to > >the iolock it's waiting on. What are the other D state processes in the > >machine? > > I have 7 processes in D state so far: > > $ ps auxww [....] > root 9844 0.0 0.0 0 0 ? D Mar06 0:22 [pdflush] > root 2697 0.0 0.0 4712 460 ? D Mar07 0:00 sync > root 8342 0.0 0.0 1780 440 ? D Mar07 0:01 /bin/rm -rf > /data/md1/stuff > root 12494 0.0 0.0 11124 1228 ? D Mar07 0:14 /usr/bin/rsync > root 15008 0.0 0.0 4712 460 ? D Mar07 0:00 sync > root 11202 0.0 0.0 5012 764 ? D Mar07 0:00 mount -o > remount,ro /data/md1 > root 15936 0.0 0.0 4712 460 ? D Mar07 0:00 sync > > At one point I did a sysrq-D and put the results in: > http://nerdbynature.de/bits/2.6.25-rc4/hung_task/kern.log.gz > (grep for "SysRq : Show Locks Held" and "SysRq : Show Blocked State") Ok, this looks like a block layer issue. Everything is waiting in ioschedule() and so in places we are blocked holding locked inodes. Hence sync, pdflush, etc are hung waiting for the inode locks to be released. e.g: INFO: task rm:8342 blocked for more than 120 seconds. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. rm D ee08de8c 0 8342 8199 f5eebd80 00000086 c0380a16 ee08de8c ee08de8c 00000000 ee08de94 c200ebd0 c043ef2b c0146237 c043f1d2 c0146210 ee08de8c 00000000 00000000 db122110 c01464ca 00000002 c1865b00 0000000c 00000000 ee3acd60 c012c700 c200ebec Call Trace: [] dm_table_unplug_all+0x26/0x40 [] io_schedule+0xb/0x20 [] sync_page+0x27/0x40 [] __wait_on_bit+0x42/0x70 [] sync_page+0x0/0x40 [] wait_on_page_bit+0x5a/0x60 [] wake_bit_function+0x0/0x60 [] truncate_inode_pages_range+0x223/0x360 [] truncate_inode_pages+0x17/0x20 [] generic_delete_inode+0xef/0x100 [] iput+0x5c/0x70 [] do_unlinkat+0xf7/0x160 [] sysenter_past_esp+0x9a/0xa5 [] trace_hardirqs_on+0x9c/0x110 [] sysenter_past_esp+0x5f/0xa5 ======================= no locks held by rm/8342. And rsync is stuck in congestion_wait() SysRq : Show Blocked State task PC stack pid father rsync D 00000292 0 12494 1 f5dc7b40 00000086 00000000 00000292 f697bcdc 00735f5c 00000000 00000600 c043efd9 c013820d f532ed60 c05c0f04 f5cc1b58 00735f5c c0122900 f532ed60 c05c0c00 c053eb04 0000000a c043ef0b c01515f8 00000000 f532ed60 c012c6c0 Call Trace: [] schedule_timeout+0x49/0xc0 [] mark_held_locks+0x3d/0x70 [] process_timeout+0x0/0x10 [] io_schedule_timeout+0xb/0x20 [] congestion_wait+0x58/0x80 [] autoremove_wake_function+0x0/0x40 [] balance_dirty_pages_ratelimited_nr+0xb2/0x240 [] generic_file_buffered_write+0x1a8/0x650 [] xfs_log_move_tail+0x3e/0x180 [] _spin_lock+0x29/0x40 [] xfs_write+0x7ac/0x8a0 [] core_sys_select+0x21/0x350 [] xfs_file_aio_write+0x5c/0x70 [] do_sync_write+0xd5/0x120 [] restore_nocheck+0x12/0x15 [] autoremove_wake_function+0x0/0x40 [] dnotify_parent+0x35/0x90 [] do_sync_write+0x0/0x120 [] vfs_write+0x9f/0x140 [] sys_write+0x41/0x70 [] sysenter_past_esp+0x5f/0xa5 And this rsync procss will definitely be holding the iolock on an XFS inode here (which is why other processes are hanging on an inode iolock). > >Also, the iolock can be held across I/O so it's possible you've lost an > >I/O. Any I/O errors in the syslog? > > No, no I/O errors at all. See the kern.log above, I could even do dd(1) > from the md1 (dm-crypt on raid1), no errors either. Oh, dm-crypt. Well, I'd definitely start looking there. XFS has a history of exposing dm-crypt bugs, and these hangs appear to be I/O congestion/scheduling related and not XFS. Also, we haven't changed anything related to plug/unplug of block devices in XFS recently, so that also points to some other change as well... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Sun Mar 9 14:39:36 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 09 Mar 2008 14:39:45 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m29LdZVd031167 for ; Sun, 9 Mar 2008 14:39:36 -0700 X-ASG-Debug-ID: 1205098804-627901800000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from fg-out-1718.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 9B1D1B0C534 for ; Sun, 9 Mar 2008 14:40:04 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by cuda.sgi.com with ESMTP id SsMuRrTYdBUgFifi for ; Sun, 09 Mar 2008 14:40:04 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id e12so1368465fga.8 for ; Sun, 09 Mar 2008 14:40:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:subject:content-type:content-transfer-encoding; bh=+nT1De/lMdf9Em5p5ssrhE8x1oiLyBw5+/peEmriqBs=; b=kgdENgP5Aj7Uw8MwAt9IX3TpseNCzV6H6mFQAuA5fDMG979G4Hfi3ChkkHA6eqd6Tcl8p2PSLbCM01hf70ecOC6BNSlM9XJGRsbu/aSh2E+9BuQ1EAwewpl8Q0b52JPSvrV0z/nhhtPO5g1JLIoVT3pWx7ngWIaBP8FlHzc1HGg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:content-type:content-transfer-encoding; b=lTddhYXpl78G+ftYMR7GYYpZdcP4LCofREoXkJ2YTGT9ONLTQVwJYepmeGbfTWWJgmCLrQjbx5pRYdQY0KfFjW1UbePcwBgz7mTNatLoaeW+1K6gbLfpLiyEHEYe/aV0K7S+sY08q1a+0Uysfy056JzIOSdYR0f8ToFHTRmUYA4= Received: by 10.82.171.16 with SMTP id t16mr10892729bue.25.1205098802489; Sun, 09 Mar 2008 14:40:02 -0700 (PDT) Received: from ?192.168.0.1? ( [89.174.121.39]) by mx.google.com with ESMTPS id g9sm7886895gvc.4.2008.03.09.14.40.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 09 Mar 2008 14:40:01 -0700 (PDT) Message-ID: <47D45926.5070806@gmail.com> Date: Sun, 09 Mar 2008 22:39:50 +0100 From: Rekrutacja User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: xfs@oss.sgi.com X-ASG-Orig-Subj: xfs for free hosting on linux ? performance questions Subject: xfs for free hosting on linux ? performance questions Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: fg-out-1718.google.com[72.14.220.157] X-Barracuda-Start-Time: 1205098805 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.42 X-Barracuda-Spam-Status: No, SCORE=-1.42 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=MARKETING_SUBJECT X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.44359 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.60 MARKETING_SUBJECT Subject contains popular marketing words X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14816 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: rekrutacja119@gmail.com Precedence: bulk X-list: xfs hello, i'm going to create xfs on RAID 5 array consiting of 5 drives, each 500GB, it will be software raid made with mdadm on linux. i run free hosting, and the array is only for users files (system and such are on ext3). what options do you recommend while creating and while mounting? i had performance problems while testing this setup with bonnie++ and postmark (postmark especially). data will be in many directories, users files are in /var/www/users/username and i have more than 100 000 accounts. also a policy to make max 3 MB files, so most of my files are around 50 KB i think. so knowing this all, what would you advice me if i may ask? my current idea was like this: mkfs.xfs -l size=128m,lazy-count=1 mount -o nobarrier,noatime,logbufs=8,logbsize=256k this will have full backup, so i'm more after performance, not stability, so if you can give me some performance tips... (postmark run on array made from 4 disks, not 5, durning test, with parameters - number of files 10k, transactions 10k, subdirs 20k, was giving very very slow reads, around 200KB/s, while reiser4/btrfs were like 2MB/s reads, but even ext3 was faster - any idea why? i tested on 2.6.24.3 and 2.6.25-rc4 ) i keep seeing tests like this: http://www.t2-project.org/zine/1/ also, i have real life example, that 3 disks RAID-0 array with tweaked xfs is as fast as just one disk with reiser4 (my free hosting with millions of files) i know reiser4 is not stable (i also experienced this), so i'm asking if you know any additional tips to tweak xfs, or maybe you know why it has performance problems in some situations. thanks in advance From owner-xfs@oss.sgi.com Sun Mar 9 15:18:48 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 09 Mar 2008 15:19:08 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m29MIhPC001265 for ; Sun, 9 Mar 2008 15:18:47 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA08935; Mon, 10 Mar 2008 09:19:04 +1100 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 m29MJ2LF91553956; Mon, 10 Mar 2008 09:19:03 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id m29MIw7H91684156; Mon, 10 Mar 2008 09:18:58 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Mon, 10 Mar 2008 09:18:58 +1100 From: David Chinner To: Chris Knadle Cc: David Chinner , linux-kernel@vger.kernel.org, xfs@oss.sgi.com, hch@infradead.org Subject: Re: assfail during unmount xfs 2.6.24.3 [from 2.6.24.y git] Message-ID: <20080309221858.GS155407@sgi.com> References: <200803062329.10486.Chris.Knadle@coredump.us> <20080307224645.GW155259@sgi.com> <200803081555.11695.Chris.Knadle@coredump.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200803081555.11695.Chris.Knadle@coredump.us> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14817 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Sat, Mar 08, 2008 at 03:55:08PM -0500, Chris Knadle wrote: > On Friday 07 March 2008, David Chinner wrote: > > On Thu, Mar 06, 2008 at 11:29:07PM -0500, Chris Knadle wrote: > > > During the final unmount before reboot there was an assertion failure > > > from XFS > ... > > > When replying please CC me, as I am not currently subscribed to the list. > ... > > > Assertion failed: atomic_read(&mp->m_active_trans) == 0, file: > > > fs/xfs/xfs_vfsops.c, line: 708 > > Thank you for taking the time to look and reply to this. > > > Known problem. Race in the VFS w.r.t. read-only remounts: > > > > http://marc.info/?l=linux-kernel&m=120106649923499&w=2 > > At the bottom of the above message there's a patch which is not currently > merged in either the linux-2.6.24.y.git or linux-2.6.git trees. That's > perhaps as it should be, but I would like to know if it's worth trying > merging the patch locally as an attempted workaround until such time as > 2.6.25 is released and stable. Sure, the patch is harmless - I've had it running in my local tree for quite some time now. > > > The fix for the problem lies outside XFS: > > > > http://marc.info/?l=linux-kernel&m=120109304227035&w=2 > > If I understand the above correctly, it sounds like the per-vfsmount is > going to be a new feature committed to 2.6.25, but probably not backported to > prior kernel trees. Right. > If this feature was was added at 2.6.23.9 then if I > understand corectly it's only an issue between that version and 2.6.25; is > that correct? Only if the per-vfsmount writer counts got merged in 2.6.25-rcX. I'm not sure that they did. Christoph? Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Sun Mar 9 15:59:15 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 09 Mar 2008 15:59:33 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_65, MIME_8BIT_HEADER autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m29Mx80D003705 for ; Sun, 9 Mar 2008 15:59:12 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA09515; Mon, 10 Mar 2008 09:59:29 +1100 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 m29MxRLF91691311; Mon, 10 Mar 2008 09:59:28 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id m29MxP0b91498420; Mon, 10 Mar 2008 09:59:25 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Mon, 10 Mar 2008 09:59:25 +1100 From: David Chinner To: Christian =?iso-8859-1?Q?R=F8snes?= Cc: David Chinner , xfs@oss.sgi.com Subject: Re: XFS internal error xfs_trans_cancel at line 1150 of file fs/xfs/xfs_trans.c Message-ID: <20080309225925.GT155407@sgi.com> References: <1a4a774c0802130251h657a52f7lb97942e7afdf6e3f@mail.gmail.com> <20080213214551.GR155407@sgi.com> <1a4a774c0803050553h7f6294cfq41c38f34ea92ceae@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1a4a774c0803050553h7f6294cfq41c38f34ea92ceae@mail.gmail.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14818 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Wed, Mar 05, 2008 at 02:53:18PM +0100, Christian Røsnes wrote: > On Wed, Feb 13, 2008 at 10:45 PM, David Chinner wrote: > After being hit several times by the problem mentioned above (running > kernel 2.6.17.7), > I upgraded the kernel to version 2.6.24.3. I then ran a rsync test to > a 99% full partition: > > df -k: > /dev/sdb1 286380096 282994528 3385568 99% /data > > The rsync application will probably fail because it will most likely > run out of space, > but I got another xfs_trans_cancel kernel message: > > Filesystem "sdb1": XFS internal error xfs_trans_cancel at line 1163 of > file fs/xfs/xfs_trans.c. Caller 0xc021a010 > Pid: 11642, comm: rsync Not tainted 2.6.24.3FC #1 > [] xfs_trans_cancel+0x5d/0xe6 > [] xfs_mkdir+0x45a/0x493 > [] xfs_mkdir+0x45a/0x493 > [] xfs_acl_vhasacl_default+0x33/0x44 > [] xfs_vn_mknod+0x165/0x243 > [] xfs_access+0x2f/0x35 > [] xfs_vn_mkdir+0x12/0x14 > [] vfs_mkdir+0xa3/0xe2 > [] sys_mkdirat+0x8a/0xc3 > [] sys_mkdir+0x1f/0x23 > [] syscall_call+0x7/0xb > ======================= > xfs_force_shutdown(sdb1,0x8) called from line 1164 of file > fs/xfs/xfs_trans.c. Return address = 0xc0212690 > Filesystem "sdb1": Corruption of in-memory data detected. Shutting > down filesystem: sdb1 > Please umount the filesystem, and rectify the problem(s) Ok, so the problem still exists. > Trying to umount /dev/sdb1 fails (umount just hangs) . That shouldn't happen. Any output in the log when it hung? What were the blocked process stack traces (/proc/sysrq-trigger is your friend)? > Rebooting the system seems to hang also - and I believe the kernel > outputs this message > when trying to umount /dev/sdb1: > > xfs_force_shutdown(sdb1,0x1) called from line 420 of file fs/xfs/xfs_rw.c. > Return address = 0xc021cb21 It's already been shut down, right? An unmount should not trigger more of these warnings... > > After waiting 5 minutes I power-cycle the system to bring it back up. > > After the restart, I ran: > > xfs_check /dev/sdb1 > > (there was no output from xfs_check). > > Could this be the same problem I experienced with 2.6.17.7 ? Yes, it likely is. Can you apply the patch below and reproduce the problem? I can't reproduce the problem locally, so I'll need you to apply test patches to isolate the error. I suspect a xfs_dir_canenter()/xfs_dir_createname() with resblks == 0 issue, and the patch below will tell us if this is the case. It annotates the error paths for both create and mkdir (the two places I've seen this error occur), and what I am expecting to see is something like: xfs_create: dir_enter w/ 0 resblks ok. xfs_create: dir_createname error 28 Cheers, Dave. --- fs/xfs/xfs_vnodeops.c | 23 ++++++++++++++++++----- 1 file changed, 18 insertions(+), 5 deletions(-) Index: 2.6.x-xfs-new/fs/xfs/xfs_vnodeops.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/xfs_vnodeops.c 2008-02-22 17:40:04.000000000 +1100 +++ 2.6.x-xfs-new/fs/xfs/xfs_vnodeops.c 2008-03-10 09:53:43.658179381 +1100 @@ -1886,12 +1886,17 @@ xfs_create( if (error) goto error_return; - if (resblks == 0 && (error = xfs_dir_canenter(tp, dp, name, namelen))) - goto error_return; + if (!resblks) { + error = xfs_dir_canenter(tp, dp, name, namelen); + if (error) + goto error_return; + printk(KERN_WARNING "xfs_create: dir_enter w/ 0 resblks ok.\n"); + } error = xfs_dir_ialloc(&tp, dp, mode, 1, rdev, credp, prid, resblks > 0, &ip, &committed); if (error) { + printk(KERN_WARNING "xfs_create: dir_ialloc error %d\n", error); if (error == ENOSPC) goto error_return; goto abort_return; @@ -1921,6 +1926,7 @@ xfs_create( resblks - XFS_IALLOC_SPACE_RES(mp) : 0); if (error) { ASSERT(error != ENOSPC); + printk(KERN_WARNING "xfs_create: dir_createname error %d\n", error); goto abort_return; } xfs_ichgtime(dp, XFS_ICHGTIME_MOD | XFS_ICHGTIME_CHG); @@ -1955,6 +1961,7 @@ xfs_create( error = xfs_bmap_finish(&tp, &free_list, &committed); if (error) { xfs_bmap_cancel(&free_list); + printk(KERN_WARNING "xfs_create: xfs_bmap_finish error %d\n", error); goto abort_rele; } @@ -2727,9 +2734,12 @@ xfs_mkdir( if (error) goto error_return; - if (resblks == 0 && - (error = xfs_dir_canenter(tp, dp, dir_name, dir_namelen))) - goto error_return; + if (!resblks) { + error = xfs_dir_canenter(tp, dp, dir_name, dir_namelen); + if (error) + goto error_return; + printk(KERN_WARNING "xfs_mkdir: dir_enter w/ 0 resblks ok.\n"); + } /* * create the directory inode. */ @@ -2737,6 +2747,7 @@ xfs_mkdir( 0, credp, prid, resblks > 0, &cdp, NULL); if (error) { + printk(KERN_WARNING "xfs_mkdir: dir_ialloc error %d\n", error); if (error == ENOSPC) goto error_return; goto abort_return; @@ -2761,6 +2772,7 @@ xfs_mkdir( &first_block, &free_list, resblks ? resblks - XFS_IALLOC_SPACE_RES(mp) : 0); if (error) { + printk(KERN_WARNING "xfs_mkdir: dir_createname error %d\n", error); ASSERT(error != ENOSPC); goto error1; } @@ -2805,6 +2817,7 @@ xfs_mkdir( error = xfs_bmap_finish(&tp, &free_list, &committed); if (error) { + printk(KERN_WARNING "xfs_mkdir: bmap_finish error %d\n", error); IRELE(cdp); goto error2; } From owner-xfs@oss.sgi.com Sun Mar 9 17:02:40 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 09 Mar 2008 17:02:57 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m2A02b7V013246 for ; Sun, 9 Mar 2008 17:02:40 -0700 X-ASG-Debug-ID: 1205107387-65b603aa0000-ps1ADW X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ty.sabi.co.UK (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 81D6D1201019 for ; Sun, 9 Mar 2008 17:03:07 -0700 (PDT) Received: from ty.sabi.co.UK (82-69-39-138.dsl.in-addr.zen.co.uk [82.69.39.138]) by cuda.sgi.com with ESMTP id y0hC2ZHKVnGh8vBY for ; Sun, 09 Mar 2008 17:03:07 -0700 (PDT) Received: from from [127.0.0.1] (helo=tree.ty.sabi.co.uk) by ty.sabi.co.UK with esmtp(Exim 4.66 #1) id 1JYVTA-0008LW-Pq for ; Mon, 10 Mar 2008 00:02:20 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18388.31367.314074.624135@tree.ty.sabi.co.uk> Date: Mon, 10 Mar 2008 00:02:15 +0000 X-Face: SMJE]JPYVBO-9UR%/8d'mG.F!@.,l@c[f'[%S8'BZIcbQc3/">GrXDwb#;fTRGNmHr^JFb SAptvwWc,0+z+~p~"Gdr4H$(|N(yF(wwCM2bW0~U?HPEE^fkPGx^u[*[yV.gyB!hDOli}EF[\cW*S H&spRGFL}{`bj1TaD^l/"[ msn( /TH#THs{Hpj>)]f> X-ASG-Orig-Subj: Re: xfs for free hosting on linux ? performance questions Subject: Re: xfs for free hosting on linux ? performance questions In-Reply-To: <47D45926.5070806@gmail.com> References: <47D45926.5070806@gmail.com> X-Mailer: VM 7.17 under 21.5 (beta28) XEmacs Lucid From: pg_lxra@lxra.for.sabi.co.UK (Peter Grandi) X-Disclaimer: This message contains only personal opinions X-Barracuda-Connect: 82-69-39-138.dsl.in-addr.zen.co.uk[82.69.39.138] X-Barracuda-Start-Time: 1205107388 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.42 X-Barracuda-Spam-Status: No, SCORE=-1.42 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=MARKETING_SUBJECT X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.44367 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.60 MARKETING_SUBJECT Subject contains popular marketing words X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14819 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: pg_lxra@lxra.for.sabi.co.UK Precedence: bulk X-list: xfs [ ... > data will be in many directories, users files are in > /var/www/users/username and i have more than 100 000 > accounts. also a policy to make max 3 MB files, so most of my > files are around 50 KB i think. This is a much better situation than the frequent inane one where someone asks about using a filesystem as a database for small records. But a ''source files'' filesystem is still a bit of challenge. > [ ... ] mount -o nobarrier,noatime,logbufs=8,logbsize=256k [ > ... ] Even with backups, 'nobarrier' means begging for trouble. > [ ... ] number of files 10k, transactions 10k, subdirs 20k, > was giving very very slow reads, around 200KB/s, while > reiser4/btrfs were like 2MB/s reads, but even ext3 was faster > - any idea why? i tested on 2.6.24.3 and 2.6.25-rc4 ) [ ... ] > that 3 disks RAID-0 array with tweaked xfs is as fast as just > one disk with reiser4 (my free hosting with millions of files) > [ ... ] Just use the by now very well tested ReiserFS version 3 for that. Just as you would use XFS for bulk streaming of large files. Recently on the same 4x(1+1) RAID10 f2 I did some (single threaded, single file reading and writing) tests involving various file systems with both large files (2-12 2GB ones) and a directory tree contain lots of small Java source files (6.5GB in 50k directories containing 150k files). While most file systems could reach something like 250MB/s writing and 430MB/s reading with the small set of large files (with XFS a few dozen MB/s ahead of most of the others and would have been more so on multithreaded), on the directory tree ReiserFS did around 57MB/s, JFS around 36MB/s, and XFS around 20-25MB/s. There are several reasons why ReiserFS is better suited for large directory tree with lots of small files; one of them is that it was designed for that :-). From owner-xfs@oss.sgi.com Sun Mar 9 17:07:53 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 09 Mar 2008 17:08:00 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,MIME_8BIT_HEADER autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m2A07m6Q014035 for ; Sun, 9 Mar 2008 17:07:52 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA10826; Mon, 10 Mar 2008 11:08:13 +1100 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 m2A08BLF89099059; Mon, 10 Mar 2008 11:08:12 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id m2A0891n91600879; Mon, 10 Mar 2008 11:08:09 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Mon, 10 Mar 2008 11:08:09 +1100 From: David Chinner To: Christian =?iso-8859-1?Q?R=F8snes?= Cc: xfs@oss.sgi.com Subject: Re: XFS internal error xfs_trans_cancel at line 1150 of file fs/xfs/xfs_trans.c Message-ID: <20080310000809.GU155407@sgi.com> References: <1a4a774c0802130251h657a52f7lb97942e7afdf6e3f@mail.gmail.com> <20080213214551.GR155407@sgi.com> <1a4a774c0803050553h7f6294cfq41c38f34ea92ceae@mail.gmail.com> <1a4a774c0803060310w2642224w690ac8fa13f96ec@mail.gmail.com> <1a4a774c0803070319j1eb8790ek3daae4a16b3e6256@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1a4a774c0803070319j1eb8790ek3daae4a16b3e6256@mail.gmail.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14820 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Fri, Mar 07, 2008 at 12:19:28PM +0100, Christian Røsnes wrote: > > Actually, a single mkdir command is enough to trigger the filesystem > > shutdown when its 99% full (according to df -k): > > > > /data# mkdir test > > mkdir: cannot create directory `test': No space left on device Ok, that's helpful ;) So, can you dump the directory inode with xfs_db? i.e. # ls -ia /data The directory inode is the inode at ".", and if this is the root of the filesystem it will probably be 128. Then run: # xfs_db -r -c 'inode 128' -c p /dev/sdb1 > > -------- > > meta-data=/dev/sdb1 isize=512 agcount=16, agsize=4476752 blks > > = sectsz=512 attr=0 > > data = bsize=4096 blocks=71627792, imaxpct=25 > > = sunit=16 swidth=32 blks, unwritten=1 > > naming =version 2 bsize=4096 > > log =internal bsize=4096 blocks=32768, version=2 > > = sectsz=512 sunit=16 blks, lazy-count=0 > > realtime =none extsz=65536 blocks=0, rtextents=0 > > > > xfs_db -r -c 'sb 0' -c p /dev/sdb1 > > ---------------------------------- ..... > > fdblocks = 847484 Apparently there are still lots of free blocks. I wonder if you are out of space in the metadata AGs. Can you do this for me: ------- #!/bin/bash for i in `seq 0 1 15`; do echo freespace histogram for AG $i xfs_db -r -c "freesp -bs -a $i" /dev/sdb1 done ------ > Instrumenting the code, I found that this occurs on my system when I > do a 'mkdir /data/test' on the partition in question: > > in xfs_mkdir (xfs_vnodeops.c): > > error = xfs_dir_ialloc(&tp, dp, mode, 2, > 0, credp, prid, resblks > 0, > &cdp, NULL); > > if (error) { > if (error == ENOSPC) > goto error_return; <=== this is hit and then > execution jumps to error_return > goto abort_return; > } Ah - you can ignore my last email, then. You're already one step ahead of me ;) This does not appear to be the case I was expecting, though I can see how we can get an ENOSPC here with plenty of blocks free - none are large enough to allocate an inode chunk. What would be worth knowing is the value of resblks when this error is reported. This tends to imply we are returning an ENOSPC with a dirty transaction. Right now I can't see how that would occur, though the fragmented free space is something I can try to reproduce with. > Is this the correct behavior for this type of situation: mkdir command > fails due to no available space on filesystem, > and xfs_mkdir goes to label error_return ? (And after this the > filesystem is shutdown) The filesystem should not be shutdown here. We need to trace through further to the source of the error.... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Sun Mar 9 17:44:44 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 09 Mar 2008 17:45:02 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: *** X-Spam-Status: No, score=3.1 required=5.0 tests=AWL,BAYES_05,HTML_MESSAGE, J_CHICKENPOX_48 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m2A0ihbF016842 for ; Sun, 9 Mar 2008 17:44:44 -0700 X-ASG-Debug-ID: 1205109906-5bb700770000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from wf-out-1314.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id D8B4B1201540 for ; Sun, 9 Mar 2008 17:45:06 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.171]) by cuda.sgi.com with ESMTP id NZvM7x6AZN6m91nc for ; Sun, 09 Mar 2008 17:45:06 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 29so1628576wff.32 for ; Sun, 09 Mar 2008 17:45:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; bh=rtgpaAcOJuZmpqgyKI8xtSr55oTNvUKOlYX+CSbrz38=; b=lGqoAd0bNm2dY6NEFf1wrwARFi7F8VwOqlTRm63S6ysVWWgF/HjFKVAaRCBRSk0XZi1e+0h67uUY43SyPnVmJOJyHXaCiLmrnpfYm3q2qPjgP5v2chGdDqxJQqKRWwG5eNzCln2cKayUSV03kf+ChxXUDFXaA0qrrLIs+BMuWXY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=tHGcXtBQqFAup5s98rLRENwJnAcfjjYem14qb3U0mXp08GJNj7M4/sIGOuNKXqFJ4WLA7xs2lHCY4WcVTEhRfPyPShxN4MvmKjEZoX5dKJ746Je45RVBCtNOxyXnPO1Ds/xSI78EskLBEmQs3RpRXycMylw9ogO54DBq6eAQ5MQ= Received: by 10.142.232.20 with SMTP id e20mr1434988wfh.187.1205109530151; Sun, 09 Mar 2008 17:38:50 -0700 (PDT) Received: by 10.142.163.3 with HTTP; Sun, 9 Mar 2008 17:38:50 -0700 (PDT) Message-ID: <2db2c6b80803091738o20dc80b2p82c5bf7246a8c560@mail.gmail.com> Date: Mon, 10 Mar 2008 01:38:50 +0100 From: Rekrutacja119 To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: xfs for free hosting on linux ? performance questions Subject: Re: xfs for free hosting on linux ? performance questions In-Reply-To: <18388.31367.314074.624135@tree.ty.sabi.co.uk> MIME-Version: 1.0 References: <47D45926.5070806@gmail.com> <18388.31367.314074.624135@tree.ty.sabi.co.uk> X-Barracuda-Connect: wf-out-1314.google.com[209.85.200.171] X-Barracuda-Start-Time: 1205109906 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.42 X-Barracuda-Spam-Status: No, SCORE=-1.42 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=HTML_MESSAGE, MARKETING_SUBJECT X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.44371 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.60 MARKETING_SUBJECT Subject contains popular marketing words 0.00 HTML_MESSAGE BODY: HTML included in message X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-length: 1342 X-archive-position: 14821 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: rekrutacja119@gmail.com Precedence: bulk X-list: xfs > > There are several reasons why ReiserFS is better suited for > large directory tree with lots of small files; one of them is > that it was designed for that :-). but reiserfs is slow for me too, maybe i have some other problems? i made array like this mdadm --create /dev/md0 --verbose --level=5 --raid-devices=5 /dev/sd{b,c,d,e,f}1 --assume-clean then just mkfs.reiserfs /dev/md0 and then mount /dev/md0 to /array and run postmark with these: set numbers 20000 set transactions 10000 set subdirectories 20000 set location /array/ results i got: Time: 287 seconds total 118 seconds of transactions (84 per second) Files: 25014 created (87 per second) Creation alone: 20000 files (168 per second) Mixed with transactions: 5014 files (42 per second) 5026 read (42 per second) 4971 appended (42 per second) 25014 deleted (87 per second) Deletion alone: 20028 files (400 per second) Mixed with transactions: 4986 files (42 per second) Data: 26.48 megabytes read (94.47 kilobytes per second) 136.18 megabytes written (485.89 kilobytes per second) is there something wrong with my system?? LA is 0.50 right now (i'm testing it at night), hdparm is showing that every HD from the array is doing 100MB/s at least, so why these numbers? [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Sun Mar 9 18:46:50 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 09 Mar 2008 18:47:34 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m2A1kmX0020563 for ; Sun, 9 Mar 2008 18:46:50 -0700 X-ASG-Debug-ID: 1205113637-7a2100d60000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.g-house.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id BF137F4DF52 for ; Sun, 9 Mar 2008 18:47:18 -0700 (PDT) Received: from mail.g-house.de (ns2.g-housing.de [81.169.133.75]) by cuda.sgi.com with ESMTP id GK1F8vBT0BIl4aV8 for ; Sun, 09 Mar 2008 18:47:18 -0700 (PDT) Received: from [89.54.188.143] (helo=[192.168.178.25]) by mail.g-house.de with esmtpa (Exim 4.63) (envelope-from ) id 1JYX6B-0001qk-Ph; Mon, 10 Mar 2008 02:46:44 +0100 Date: Mon, 10 Mar 2008 02:46:38 +0100 (CET) From: Christian Kujau X-X-Sender: evil@sheep.housecafe.de To: David Chinner cc: LKML , xfs@oss.sgi.com, dm-devel@redhat.com X-ASG-Orig-Subj: Re: INFO: task mount:11202 blocked for more than 120 seconds Subject: Re: INFO: task mount:11202 blocked for more than 120 seconds In-Reply-To: <20080309213441.GQ155407@sgi.com> Message-ID: References: <20080307224040.GV155259@sgi.com> <20080309213441.GQ155407@sgi.com> User-Agent: Alpine 1.00 (DEB 882 2007-12-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Barracuda-Connect: ns2.g-housing.de[81.169.133.75] X-Barracuda-Start-Time: 1205113638 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.44375 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14822 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lists@nerdbynature.de Precedence: bulk X-list: xfs On Mon, 10 Mar 2008, David Chinner wrote: > Oh, dm-crypt. Well, I'd definitely start looking there. XFS has a > history of exposing dm-crypt bugs, and these hangs appear to be I/O > congestion/scheduling related and not XFS. Yeah, I noticed that too, thanks for verifying this: during the 2nd bisect run, the box locked up hard when I accessed the device-mapper. I'm using a wrapper script to set up my luks/dm-crypt devices and still have to find out which command exactly triggers the lockup. So, maybe the hard lockup and the hangs are not so unrelated after all...oh well. > Also, we haven't changed > anything related to plug/unplug of block devices in XFS recently, so > that also points to some other change as well... Thanks for your assistance, David, I really appreciate it. I'll try to find out more about this dm-crypt thingy.... Christian. -- BOFH excuse #396: Mail server hit by UniSpammer. From owner-xfs@oss.sgi.com Sun Mar 9 23:10:18 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 09 Mar 2008 23:10:37 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m2A6AFBL012856 for ; Sun, 9 Mar 2008 23:10:18 -0700 X-ASG-Debug-ID: 1205129445-338d037e0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 4280AF4EB94 for ; Sun, 9 Mar 2008 23:10:46 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id jK0BQTQEGrQsSDES for ; Sun, 09 Mar 2008 23:10:46 -0700 (PDT) Received: from hch by bombadil.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1JYbDB-0003MA-Tn; Mon, 10 Mar 2008 06:10:13 +0000 Date: Mon, 10 Mar 2008 02:10:13 -0400 From: Christoph Hellwig To: David Chinner Cc: Chris Knadle , linux-kernel@vger.kernel.org, xfs@oss.sgi.com, hch@infradead.org X-ASG-Orig-Subj: Re: assfail during unmount xfs 2.6.24.3 [from 2.6.24.y git] Subject: Re: assfail during unmount xfs 2.6.24.3 [from 2.6.24.y git] Message-ID: <20080310061013.GA3496@infradead.org> References: <200803062329.10486.Chris.Knadle@coredump.us> <20080307224645.GW155259@sgi.com> <200803081555.11695.Chris.Knadle@coredump.us> <20080309221858.GS155407@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080309221858.GS155407@sgi.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1205129446 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.44393 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14823 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs On Mon, Mar 10, 2008 at 09:18:58AM +1100, David Chinner wrote: > Only if the per-vfsmount writer counts got merged in 2.6.25-rcX. I'm not sure > that they did. Christoph? No, it didn't go in. The new target is 2.6.26. From owner-xfs@oss.sgi.com Sun Mar 9 23:21:00 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 09 Mar 2008 23:21:19 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,J_CHICKENPOX_43 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m2A6KxLf014393 for ; Sun, 9 Mar 2008 23:21:00 -0700 X-ASG-Debug-ID: 1205130087-078700db0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from wf-out-1314.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 15A7167A1B0 for ; Sun, 9 Mar 2008 23:21:28 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.168]) by cuda.sgi.com with ESMTP id HHfr6ISTZXaqLIyt for ; Sun, 09 Mar 2008 23:21:28 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 29so1745821wff.32 for ; Sun, 09 Mar 2008 23:21:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=5Hw7WgZDsmjQRZRJG2FEBmrVC6jg7dTGG9hjXI4LsdA=; b=iw5DFTxfaAafy8Ykc3XJCJ71N0qjUjutvhThZ4mphKCFt/5h0tgcbnfMF552Iww0NVzViQWOL7o2VPMQ/TtbUIg1YXDJkAHMzhxNfcgzuopLR5jQdsniM0ekqziVAznlSBE9jyf85zeyJwYEXKSHOWT0R0G0G5UhhYv8INLH1h8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=MBqAF7PoRFvqzna606a/uuf6e1u+Ol5TxNrvzsEuFakw2bWsGXZHm3ZokPQSMsIfjj4hmcUXaJGqSVEWrfZubWO/nk+lsHnjCjpx8tR8K9uo03HVT258BY9FxgWvDY4GyN14+8gRo8FohfFm7jRj4abKFYMUasz4PqUrGfymmk4= Received: by 10.142.83.4 with SMTP id g4mr1498459wfb.28.1205129704274; Sun, 09 Mar 2008 23:15:04 -0700 (PDT) Received: by 10.143.119.3 with HTTP; Sun, 9 Mar 2008 23:15:04 -0700 (PDT) Message-ID: <416c461f0803092315m7ae6f55ek9b64058c3793aaa7@mail.gmail.com> Date: Mon, 10 Mar 2008 17:15:04 +1100 From: "Niv Sardi" To: "David Chinner" X-ASG-Orig-Subj: Re: ADD 977766 - mkfs.xfs man page needs the default settings updated. [REVIEW TAKE 3] Subject: Re: ADD 977766 - mkfs.xfs man page needs the default settings updated. [REVIEW TAKE 3] Cc: "Niv Sardi" , sgi.bugs.xfs@fido.engr.sgi.com, xfs-dev@sgi.com, xfs@oss.sgi.com In-Reply-To: <20080310060751.GY155407@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080222003514.8D88E2C3@toolshop.engr.sgi.com> <20080310060751.GY155407@sgi.com> X-Google-Sender-Auth: 1a9b6f108a4cddad X-Barracuda-Connect: wf-out-1314.google.com[209.85.200.168] X-Barracuda-Start-Time: 1205130090 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.44394 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14824 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: xaiki@cxhome.ath.cx Precedence: bulk X-list: xfs On Mon, Mar 10, 2008 at 5:07 PM, David Chinner wrote: > On Fri, Mar 07, 2008 at 03:39:05PM +1100, Niv Sardi wrote: > > Incorporated Eric's changes, last call does it look good to everyone > > > @@ -387,17 +399,13 @@ With some combinations of filesystem block size, inode size, > > and directory block size, the minimum log size is larger than 512 blocks. > > .TP > > .BI version= value > > -This specifies the version of the log. The > > -.I value > > -is either 1 or 2. Specifying > > -.B version=2 > > -enables the > > -.B sunit > > -suboption, and allows the logbsize to be increased beyond 32K. > > -Version 2 logs are automatically selected if a log stripe unit > > -is specified. See > > -.BR sunit " and " su > > -suboptions, below. > > +This specifies the version of the log. The current default is 2, > > +which allows for larger log buffer sizes, as well as supporting > > +stripe-aligned log writes (see the sunit and su options, below). > > +.IP > > +The previous version 1, which is limited to 32k log buffers and does > > +not support stripe-aligned writes, is kept for backwards compatibility > > +with very old 2.4 kernels. > I don't like this change. You're removing specific references to the > commands needed to set sunit, or how to set the version number, and what > the default behaviour on stripe aligned filesystems are. Right that should be added back. > Secondly, version one logs are not being kept around for backwards > compatibility reasons. It's a valid, supported configuration, and in > some cases performs better than version 2 logs.... Can you be more specific ? the man page should document when this is better supported and I believe you're the one that has the best knowledge about that. > Realistically, I see no need for changing this text except to add that > the default is version 2. The change was motivated by Eric's comments on OSS that it is not clear why one should pick log v1 or v2, and I believe he is right. Cheers, -- Niv Sardi From owner-xfs@oss.sgi.com Mon Mar 10 02:00:25 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Mar 2008 02:00:46 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_43, J_CHICKENPOX_44,J_CHICKENPOX_45,J_CHICKENPOX_46,J_CHICKENPOX_47, J_CHICKENPOX_48,MIME_8BIT_HEADER autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m2A90Olh001293 for ; Mon, 10 Mar 2008 02:00:25 -0700 X-ASG-Debug-ID: 1205139653-661901310000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from wr-out-0506.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id F1FDD67AE6C for ; Mon, 10 Mar 2008 02:00:54 -0700 (PDT) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.233]) by cuda.sgi.com with ESMTP id yXZfGf4Fs3PgDUWF for ; Mon, 10 Mar 2008 02:00:54 -0700 (PDT) Received: by wr-out-0506.google.com with SMTP id c53so701356wra.20 for ; Mon, 10 Mar 2008 02:00:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=pYfK/7MeAb2B1JyGGKqiEED2p6qS6CaPmdD2vu9IJGM=; b=ZOVVaIQo252d9/jYCHuIw+r8NoBfuy6xLoNcOW9jW3WK1vm2G2/GpwjdJpuSDytA6YDGjhcqJ9HwPzHayjO6LW3TOOsecThoY/AeTK4Pf2tq8dTLHn0Vg85MV06pNkw38S401LHc99OxHvHG4wZleWuGGvC9yBsbmiEUHfysWUs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=C88F3ezQrw9pz3uvxW/7E29gaPM6uHAGo0MPhBrqfG/Spmlxiy2yQWcMeEcnv4kojzSqes8Na5ikIdIUcCa/YROli8NY4lLsUvNn76mMT/rC4Y4ZqMN1evAgH5FgGoAnofrKyGERN8H0nBDcdn17sDfem5dBvozT9v+e4ZBKcfU= Received: by 10.150.146.14 with SMTP id t14mr2582998ybd.67.1205138054848; Mon, 10 Mar 2008 01:34:14 -0700 (PDT) Received: by 10.150.96.5 with HTTP; Mon, 10 Mar 2008 01:34:14 -0700 (PDT) Message-ID: <1a4a774c0803100134k258e1bcfma95e7969bc44b2af@mail.gmail.com> Date: Mon, 10 Mar 2008 09:34:14 +0100 From: "=?ISO-8859-1?Q?Christian_R=F8snes?=" To: "David Chinner" X-ASG-Orig-Subj: Re: XFS internal error xfs_trans_cancel at line 1150 of file fs/xfs/xfs_trans.c Subject: Re: XFS internal error xfs_trans_cancel at line 1150 of file fs/xfs/xfs_trans.c Cc: xfs@oss.sgi.com In-Reply-To: <20080310000809.GU155407@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <1a4a774c0802130251h657a52f7lb97942e7afdf6e3f@mail.gmail.com> <20080213214551.GR155407@sgi.com> <1a4a774c0803050553h7f6294cfq41c38f34ea92ceae@mail.gmail.com> <1a4a774c0803060310w2642224w690ac8fa13f96ec@mail.gmail.com> <1a4a774c0803070319j1eb8790ek3daae4a16b3e6256@mail.gmail.com> <20080310000809.GU155407@sgi.com> X-Barracuda-Connect: wr-out-0506.google.com[64.233.184.233] X-Barracuda-Start-Time: 1205139654 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.44404 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id m2A90Plh001295 X-archive-position: 14825 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: christian.rosnes@gmail.com Precedence: bulk X-list: xfs Thanks for the help, David. Answers below: On Mon, Mar 10, 2008 at 1:08 AM, David Chinner wrote: > On Fri, Mar 07, 2008 at 12:19:28PM +0100, Christian Røsnes wrote: > > > Actually, a single mkdir command is enough to trigger the filesystem > > > shutdown when its 99% full (according to df -k): > > > > > > /data# mkdir test > > > mkdir: cannot create directory `test': No space left on device > > Ok, that's helpful ;) > > So, can you dump the directory inode with xfs_db? i.e. > > # ls -ia /data # ls -ia /data 128 . 128 .. 131 content 149256847 rsync > > The directory inode is the inode at ".", and if this is the root of > the filesystem it will probably be 128. > > Then run: > > # xfs_db -r -c 'inode 128' -c p /dev/sdb1 > # xfs_db -r -c 'inode 128' -c p /dev/sdb1 core.magic = 0x494e core.mode = 040755 core.version = 1 core.format = 1 (local) core.nlinkv1 = 4 core.uid = 0 core.gid = 0 core.flushiter = 47007 core.atime.sec = Wed Oct 19 12:14:10 2005 core.atime.nsec = 640092000 core.mtime.sec = Fri Dec 15 10:27:21 2006 core.mtime.nsec = 624437500 core.ctime.sec = Fri Dec 15 10:27:21 2006 core.ctime.nsec = 624437500 core.size = 32 core.nblocks = 0 core.extsize = 0 core.nextents = 0 core.naextents = 0 core.forkoff = 0 core.aformat = 2 (extents) core.dmevmask = 0 core.dmstate = 0 core.newrtbm = 0 core.prealloc = 0 core.realtime = 0 core.immutable = 0 core.append = 0 core.sync = 0 core.noatime = 0 core.nodump = 0 core.rtinherit = 0 core.projinherit = 0 core.nosymlinks = 0 core.extsz = 0 core.extszinherit = 0 core.nodefrag = 0 core.filestream = 0 core.gen = 0 next_unlinked = null u.sfdir2.hdr.count = 2 u.sfdir2.hdr.i8count = 0 u.sfdir2.hdr.parent.i4 = 128 u.sfdir2.list[0].namelen = 7 u.sfdir2.list[0].offset = 0x30 u.sfdir2.list[0].name = "content" u.sfdir2.list[0].inumber.i4 = 131 u.sfdir2.list[1].namelen = 5 u.sfdir2.list[1].offset = 0x48 u.sfdir2.list[1].name = "rsync" u.sfdir2.list[1].inumber.i4 = 149256847 > > > > -------- > > > meta-data=/dev/sdb1 isize=512 agcount=16, agsize=4476752 blks > > > = sectsz=512 attr=0 > > > data = bsize=4096 blocks=71627792, imaxpct=25 > > > = sunit=16 swidth=32 blks, unwritten=1 > > > naming =version 2 bsize=4096 > > > log =internal bsize=4096 blocks=32768, version=2 > > > = sectsz=512 sunit=16 blks, lazy-count=0 > > > realtime =none extsz=65536 blocks=0, rtextents=0 > > > > > > xfs_db -r -c 'sb 0' -c p /dev/sdb1 > > > ---------------------------------- > ..... > > > fdblocks = 847484 > > Apparently there are still lots of free blocks. I wonder if you are out of > space in the metadata AGs. > > Can you do this for me: > > ------- > #!/bin/bash > > for i in `seq 0 1 15`; do > echo freespace histogram for AG $i > xfs_db -r -c "freesp -bs -a $i" /dev/sdb1 > done > ------ > # for i in `seq 0 1 15`; do > echo freespace histogram for AG $i > xfs_db -r -c "freesp -bs -a $i" /dev/sdb1 > done freespace histogram for AG 0 from to extents blocks pct 1 1 2098 2098 3.77 2 3 8032 16979 30.54 4 7 6158 33609 60.46 8 15 363 2904 5.22 total free extents 16651 total free blocks 55590 average free extent size 3.33854 freespace histogram for AG 1 from to extents blocks pct 1 1 2343 2343 3.90 2 3 9868 21070 35.10 4 7 6000 34535 57.52 8 15 261 2088 3.48 total free extents 18472 total free blocks 60036 average free extent size 3.25011 freespace histogram for AG 2 from to extents blocks pct 1 1 1206 1206 10.55 2 3 3919 8012 70.10 4 7 394 2211 19.35 total free extents 5519 total free blocks 11429 average free extent size 2.07085 freespace histogram for AG 3 from to extents blocks pct 1 1 3179 3179 8.48 2 3 14689 29736 79.35 4 7 820 4560 12.17 total free extents 18688 total free blocks 37475 average free extent size 2.0053 freespace histogram for AG 4 from to extents blocks pct 1 1 4113 4113 9.62 2 3 10685 22421 52.45 4 7 2951 16212 37.93 total free extents 17749 total free blocks 42746 average free extent size 2.40836 freespace histogram for AG 5 from to extents blocks pct 1 1 2909 2909 4.23 2 3 20370 41842 60.81 4 7 3973 23861 34.68 8 15 24 192 0.28 total free extents 27276 total free blocks 68804 average free extent size 2.52251 freespace histogram for AG 6 from to extents blocks pct 1 1 3577 3577 4.86 2 3 18592 38577 52.43 4 7 4427 25764 35.02 8 15 707 5656 7.69 total free extents 27303 total free blocks 73574 average free extent size 2.69472 freespace histogram for AG 7 from to extents blocks pct 1 1 2634 2634 9.14 2 3 11928 24349 84.48 4 7 366 1840 6.38 total free extents 14928 total free blocks 28823 average free extent size 1.9308 freespace histogram for AG 8 from to extents blocks pct 1 1 6473 6473 6.39 2 3 22020 46190 45.61 4 7 7343 40137 39.64 8 15 1058 8464 8.36 total free extents 36894 total free blocks 101264 average free extent size 2.74473 freespace histogram for AG 9 from to extents blocks pct 1 1 2165 2165 2.22 2 3 15746 33317 34.20 4 7 9402 55502 56.97 8 15 805 6440 6.61 total free extents 28118 total free blocks 97424 average free extent size 3.46483 freespace histogram for AG 10 from to extents blocks pct 1 1 5886 5886 9.46 2 3 13682 29881 48.01 4 7 4561 23919 38.43 8 15 319 2552 4.10 total free extents 24448 total free blocks 62238 average free extent size 2.54573 freespace histogram for AG 11 from to extents blocks pct 1 1 4197 4197 7.47 2 3 8421 18061 32.14 4 7 4336 24145 42.97 8 15 1224 9792 17.43 total free extents 18178 total free blocks 56195 average free extent size 3.09137 freespace histogram for AG 12 from to extents blocks pct 1 1 310 310 90.64 2 3 16 32 9.36 total free extents 326 total free blocks 342 average free extent size 1.04908 freespace histogram for AG 13 from to extents blocks pct 1 1 4845 4845 22.31 2 3 7533 16873 77.69 total free extents 12378 total free blocks 21718 average free extent size 1.75456 freespace histogram for AG 14 from to extents blocks pct 1 1 3572 3572 6.50 2 3 17437 36656 66.72 4 7 2702 14711 26.78 total free extents 23711 total free blocks 54939 average free extent size 2.31703 freespace histogram for AG 15 from to extents blocks pct 1 1 4568 4568 6.24 2 3 13400 28983 39.62 4 7 6992 39606 54.14 total free extents 24960 total free blocks 73157 average free extent size 2.93097 > > > Instrumenting the code, I found that this occurs on my system when I > > do a 'mkdir /data/test' on the partition in question: > > > > in xfs_mkdir (xfs_vnodeops.c): > > > > error = xfs_dir_ialloc(&tp, dp, mode, 2, > > 0, credp, prid, resblks > 0, > > &cdp, NULL); > > > > if (error) { > > if (error == ENOSPC) > > goto error_return; <=== this is hit and then > > execution jumps to error_return > > goto abort_return; > > } > > Ah - you can ignore my last email, then. You're already one step ahead > of me ;) > > This does not appear to be the case I was expecting, though I can > see how we can get an ENOSPC here with plenty of blocks free - none > are large enough to allocate an inode chunk. What would be worth > knowing is the value of resblks when this error is reported. Ok. I'll see if I can print it out. > > This tends to imply we are returning an ENOSPC with a dirty > transaction. Right now I can't see how that would occur, though > the fragmented free space is something I can try to reproduce with. ok > > > > Is this the correct behavior for this type of situation: mkdir command > > fails due to no available space on filesystem, > > and xfs_mkdir goes to label error_return ? (And after this the > > filesystem is shutdown) > > The filesystem should not be shutdown here. We need to trace through > further to the source of the error.... > ok Btw - to debug this on a test-system, can I do a dd if=/dev/sdb1 or dd if=/dev/sdb, and output it to an image which is then loopback mounted on the test-system ? Ie. is there some sort of "best practice" on how to copy this partition to a test-system for further testing ? Thanks Christian From owner-xfs@oss.sgi.com Mon Mar 10 03:02:16 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Mar 2008 03:02:35 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00,MIME_8BIT_HEADER autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m2AA2FNZ006914 for ; Mon, 10 Mar 2008 03:02:16 -0700 X-ASG-Debug-ID: 1205143349-4d7702490000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from wx-out-0506.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 9CB1E67B299 for ; Mon, 10 Mar 2008 03:02:29 -0700 (PDT) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.238]) by cuda.sgi.com with ESMTP id vsX7yNJqo40XVmsS for ; Mon, 10 Mar 2008 03:02:29 -0700 (PDT) Received: by wx-out-0506.google.com with SMTP id s9so1814129wxc.32 for ; Mon, 10 Mar 2008 03:02:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=zdIiennxwldllE8wNGzQ0cfSsl+iYleF1zHG/0ysJP8=; b=QgoPXqNQqJVjGGLajieDXr2Bl0aty2Dhfi3cV7CSEekDahc85HblP3yMZ+D7uaJx3Sf8dLLJ+rhIja56KhypGIsa752joVBl3gCDU0YduYixRQCjNqVLRkraYW9WNTk6SIUvAlbSlEICxXgGJPMUQM58T0dkHJG279j1LoK09L0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=nWvL1f9dJlNXccQtyDk5rwPVJegHrHzYNRe/jRe6RO6plm+ZgGPQCCgihpJaz3Hgd3Yt363zuu8RXq4eoebVhBqfnBOYIsBz4iGNfPcgwOnXY8Gu0K1iRwGQ+rvsG6PPYo9mBvmpXBWDt68pDUWVRzjuloBilj398cG3Hcnzkbo= Received: by 10.151.15.3 with SMTP id s3mr2633399ybi.143.1205143348662; Mon, 10 Mar 2008 03:02:28 -0700 (PDT) Received: by 10.150.96.5 with HTTP; Mon, 10 Mar 2008 03:02:28 -0700 (PDT) Message-ID: <1a4a774c0803100302y17530814wee7522aa0dfd7668@mail.gmail.com> Date: Mon, 10 Mar 2008 11:02:28 +0100 From: "=?ISO-8859-1?Q?Christian_R=F8snes?=" To: "David Chinner" X-ASG-Orig-Subj: Re: XFS internal error xfs_trans_cancel at line 1150 of file fs/xfs/xfs_trans.c Subject: Re: XFS internal error xfs_trans_cancel at line 1150 of file fs/xfs/xfs_trans.c Cc: xfs@oss.sgi.com In-Reply-To: <1a4a774c0803100134k258e1bcfma95e7969bc44b2af@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <1a4a774c0802130251h657a52f7lb97942e7afdf6e3f@mail.gmail.com> <20080213214551.GR155407@sgi.com> <1a4a774c0803050553h7f6294cfq41c38f34ea92ceae@mail.gmail.com> <1a4a774c0803060310w2642224w690ac8fa13f96ec@mail.gmail.com> <1a4a774c0803070319j1eb8790ek3daae4a16b3e6256@mail.gmail.com> <20080310000809.GU155407@sgi.com> <1a4a774c0803100134k258e1bcfma95e7969bc44b2af@mail.gmail.com> X-Barracuda-Connect: wx-out-0506.google.com[66.249.82.238] X-Barracuda-Start-Time: 1205143349 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.44408 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id m2AA2GNZ006917 X-archive-position: 14826 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: christian.rosnes@gmail.com Precedence: bulk X-list: xfs On Mon, Mar 10, 2008 at 9:34 AM, Christian Røsnes wrote: > On Mon, Mar 10, 2008 at 1:08 AM, David Chinner wrote: > > On Fri, Mar 07, 2008 at 12:19:28PM +0100, Christian Røsnes wrote: > > > > > Instrumenting the code, I found that this occurs on my system when I > > > do a 'mkdir /data/test' on the partition in question: > > > > > > in xfs_mkdir (xfs_vnodeops.c): > > > > > > error = xfs_dir_ialloc(&tp, dp, mode, 2, > > > 0, credp, prid, resblks > 0, > > > &cdp, NULL); > > > > > > if (error) { > > > if (error == ENOSPC) > > > goto error_return; <=== this is hit and then > > > execution jumps to error_return > > > goto abort_return; > > > } > > > > Ah - you can ignore my last email, then. You're already one step ahead > > of me ;) > > > > This does not appear to be the case I was expecting, though I can > > see how we can get an ENOSPC here with plenty of blocks free - none > > are large enough to allocate an inode chunk. What would be worth > > knowing is the value of resblks when this error is reported. > > Ok. I'll see if I can print it out. Ok. I added printk statments to xfs_mkdir in xfs_vnodeops.c: 'resblks=45' is the value returned by: resblks = XFS_MKDIR_SPACE_RES(mp, dir_namelen); and this is the value when the error_return label is called. -- and inside xfs_dir_ialloc (file: xfs_utils.c) this is where it returns ... code = xfs_ialloc(tp, dp, mode, nlink, rdev, credp, prid, okalloc, &ialloc_context, &call_again, &ip); /* * Return an error if we were unable to allocate a new inode. * This should only happen if we run out of space on disk or * encounter a disk error. */ if (code) { *ipp = NULL; return code; } if (!call_again && (ip == NULL)) { *ipp = NULL; return XFS_ERROR(ENOSPC); <============== returns here } Christian From owner-xfs@oss.sgi.com Mon Mar 10 04:44:56 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Mar 2008 04:45:16 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m2ABiudI021300 for ; Mon, 10 Mar 2008 04:44:56 -0700 X-ASG-Debug-ID: 1205149525-648002f80000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from steelboxtech.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 948DE67B9AF; Mon, 10 Mar 2008 04:45:26 -0700 (PDT) Received: from steelboxtech.com (steelb0x.securesites.net [161.58.192.27]) by cuda.sgi.com with ESMTP id HblqmhVBhEyaTTat; Mon, 10 Mar 2008 04:45:26 -0700 (PDT) Received: from [192.168.1.152] (cromo.steelbox.com [199.72.224.67]) (authenticated bits=0) by steelboxtech.com (8.13.6.20060614/8.13.6) with ESMTP id m2ABjMpg086602; Mon, 10 Mar 2008 11:45:22 GMT Message-ID: <47D51FF0.2080000@steelbox.com> Date: Mon, 10 Mar 2008 07:48:00 -0400 From: Kris Kersey User-Agent: Thunderbird 2.0.0.6 (X11/20071004) MIME-Version: 1.0 To: David Chinner CC: xfs@oss.sgi.com, Bill Vaughan X-ASG-Orig-Subj: Re: pdflush hang on xlog_grant_log_space() Subject: Re: pdflush hang on xlog_grant_log_space() References: <47D062AF.80501@steelbox.com> <20080307223510.GM155407@sgi.com> In-Reply-To: <20080307223510.GM155407@sgi.com> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: steelb0x.securesites.net[161.58.192.27] X-Barracuda-Start-Time: 1205149526 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.44413 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14827 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: kkersey@steelbox.com Precedence: bulk X-list: xfs Thank you for your help. Two questions: 1) Can you define "much larger number"? I know you recently increased this number from 10 to 1000, so should I increase it to 10,000? 100,000? 2) Is this a fix or a work-around? If this is a work-around, is there a fix in the works? Can you explain the issue a bit, or if it's been covered, can you point me to the explanation? I'd just like to understand what's going on. Thanks, Kris Kersey David Chinner wrote: > On Thu, Mar 06, 2008 at 04:31:27PM -0500, Kris Kersey wrote: >> Hello, >> >> I'm working on a NAS product and we're currently having lock-ups that >> seem to be hanging in XFS code. We're running a NAS that has 1024 NFSD >> threads accessing three RAID mounts. All three mounts are running XFS >> file systems. Lately we've had random lockups on these boxes and I am >> now running a kernel with KDB built-in. >> >> The lock-up takes the form of all NFSD threads in D state with one out >> of three pdflush threads in D state. The assumption can be made that >> all NFSD threads are waiting on the one pdflush thread to complete. So >> two times now when an NAS has gotten in this state I have accessed KDB >> and ran a stack trace on the pdflush thread. Both times the thread was >> stuck on xlog_grant_log_space+0xdb. > > Try bumping XFS_TRANS_PUSH_AIL_RESTARTS to a much larger number and > seeing if the problem goes away.... > > Alternatively, that restart hack is backed by a "watchdog" timeout > in 2.6.25-rc1, so if that is the cause of the problem perhaps the > latest -rcX kernel will prevent the hang? > > BTW, you can get all the traces of D state threads through the sysrq > interface, so you don't need to drop into kdb to get this..... > > Cheers, > > Dave. From owner-xfs@oss.sgi.com Mon Mar 10 05:21:52 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Mar 2008 05:22:11 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m2ACLocl024845 for ; Mon, 10 Mar 2008 05:21:52 -0700 X-ASG-Debug-ID: 1205151740-572700450000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.flatline.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 537471202669; Mon, 10 Mar 2008 05:22:20 -0700 (PDT) Received: from mail.flatline.de (flatline.de [80.190.243.144]) by cuda.sgi.com with ESMTP id RCwUwZcbMc9a8hUt; Mon, 10 Mar 2008 05:22:20 -0700 (PDT) Received: from shell.priv.flatline.de ([172.16.123.7] helo=slop.flatline.de ident=count) by mail.flatline.de with smtp (Exim 4.69) (envelope-from ) id 1JYh1E-0001JD-8x; Mon, 10 Mar 2008 13:22:17 +0100 Received: by slop.flatline.de (sSMTP sendmail emulation); Mon, 10 Mar 2008 13:22:16 +0100 Date: Mon, 10 Mar 2008 13:22:16 +0100 From: Andreas Kotes To: David Chinner Cc: linux-kernel@vger.kernel.org, xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS internal error Subject: Re: XFS internal error Message-ID: <20080310122216.GG14256@slop.flatline.de> References: <470831E6.4030704@fastmail.co.uk> <20071008001452.GX995458@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071008001452.GX995458@sgi.com> User-Agent: Mutt/1.5.13 (2006-08-11) X-Barracuda-Connect: flatline.de[80.190.243.144] X-Barracuda-Start-Time: 1205151741 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.44417 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14828 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: count-linux@flatline.de Precedence: bulk X-list: xfs Hello, * David Chinner [20080310 13:18]: > Yes, but those previous corruptions get left on disk as a landmine > for you to trip over some time later, even on a kernel that has the > bug fixed. > > I suggest that you run xfs_check on the filesystem and if that > shows up errors, run xfs_repair onteh filesystem to correct them. I seem to be having similiar problems, and xfs_repair is not helping :( I always run into: [ 137.099267] Filesystem "sda2": XFS internal error xfs_trans_cancel at line 1132 of file fs/xfs/xfs_trans.c. Caller 0xffffffff80372156 [ 137.106267] [ 137.106268] Call Trace: [ 137.113129] [] xfs_trans_cancel+0x100/0x130 [ 137.116524] [] xfs_create+0x256/0x6e0 [ 137.119904] [] xfs_dir2_isleaf+0x19/0x50 [ 137.123269] [] xfs_vn_mknod+0x195/0x250 [ 137.126607] [] vfs_create+0xac/0xf0 [ 137.129920] [] open_namei+0x5dc/0x700 [ 137.133227] [] __wake_up+0x43/0x70 [ 137.136477] [] do_filp_open+0x1c/0x50 [ 137.139693] [] do_sys_open+0x5a/0x100 [ 137.142838] [] sysenter_do_call+0x1b/0x67 [ 137.145964] [ 137.149014] xfs_force_shutdown(sda2,0x8) called from line 1133 of file fs/xfs/xfs_trans.c. Return address = 0xffffffff8036930e [ 137.163485] Filesystem "sda2": Corruption of in-memory data detected. Shutting down filesystem: sda2 directly after booting. I'm using kernel 2.6.22.16 and xfs_repair version 2.9.7 How can I help finding the problem? I'd like xfs_repair to be able to fix this. Br, Andreas -- flatline IT services - Andreas Kotes - Tailored solutions for your IT needs From owner-xfs@oss.sgi.com Mon Mar 10 05:39:08 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Mar 2008 05:39:26 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,J_CHICKENPOX_45 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m2ACd7Rc026328 for ; Mon, 10 Mar 2008 05:39:08 -0700 X-ASG-Debug-ID: 1205152777-65ef00700000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from gw02.mail.saunalahti.fi (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 3EB7E120254E for ; Mon, 10 Mar 2008 05:39:37 -0700 (PDT) Received: from gw02.mail.saunalahti.fi (gw02.mail.saunalahti.fi [195.197.172.116]) by cuda.sgi.com with ESMTP id jCt1spQVFwn0AXWC for ; Mon, 10 Mar 2008 05:39:37 -0700 (PDT) Received: from uunet198.aac.fi (uunet198.aac.fi [193.64.61.198]) by gw02.mail.saunalahti.fi (Postfix) with ESMTP id AA80F139F59 for ; Mon, 10 Mar 2008 14:39:04 +0200 (EET) Message-ID: <47D52BE5.6010706@iki.fi> Date: Mon, 10 Mar 2008 14:39:01 +0200 From: Erkki Lintunen Reply-To: erkki.lintunen@iki.fi User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: xfs@oss.sgi.com X-ASG-Orig-Subj: an occational trouble with xfs file system which xfs_repair 2.7.14 has been able to fix Subject: an occational trouble with xfs file system which xfs_repair 2.7.14 has been able to fix X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: gw02.mail.saunalahti.fi[195.197.172.116] X-Barracuda-Start-Time: 1205152778 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.44419 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14829 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: erkki.lintunen@iki.fi Precedence: bulk X-list: xfs Hi, can you help me a bit with my troublesome ~700GB xfs filesystem? The file system has had several dir trees since it was created somewhere 2004-2005. It has been written to daily since it was created. It has been expanded few times with xfs_growfs. It has experienced the same symptom already 2-4 times. The symptom is that one of the dir trees gets locked about once a year. It is always the same tree. I can't remember when or what happened when the symptom was first experienced. I guess the system had run on 2.6.17.x kernel once in its lifetime, but xfs_repair ought to fix the dir lock problem, at least the latest, doesn't it. The filesystem is used for backups with rsync, cp -al and rm -fr commands in a script. When the trouble begins cp -al command starts to take several hours and hundreds of megs memory. rm -fr of a subtree also takes considerably longer than rm a subtree in another bigger tree in the same filesystem, but the rm commands have always finnished, which the cp -al commands haven't. Most of the time the cp -al process has D status. I have mananged to repair the file system with xfs_repair 2.7.14, but not with 2.6.20, which comes in Debian Sarge. Now I tried latest xfs_repair and it didn't fix the problem - at least on the first run without any options. For example latest backup had to be interrupted and time command showed following: real 1342m7.316s user 1m4.152s sys 14m5.109s I have xfs_metadump of the filesystem right after the interrup. Its size is 3.9G uncompressed and 1.6G compressed with bzip2 -9. Now I ran xfs_repair 2.7.14 on the file system and wait one day before I'll see whether it was capable to fix the problem this time as well. What else information I could provide in addition to those requested in FAQ? plastic:~# grep backup-volA /etc/fstab /dev/vg00/backup-volA /site/backup-volA xfs defaults 0 1 plastic:~# df -ml /backup/volA/. Filesystem 1M-blocks Used Available Use% Mounted on /site/backup-volA 692688 647328 45361 94% /backup/volA plastic:~# ./xfs_repair -V xfs_repair version 2.9.7 plastic:~# /usr/local/sbin/xfs_repair -V xfs_repair version 2.7.14 plastic:~# /sbin/xfs_repair -V xfs_repair version 2.6.20 plastic:~# dmesg |tail -n 3 Filesystem "dm-0": Disabling barriers, not supported by the underlying device XFS mounting filesystem dm-0 Ending clean XFS mount for filesystem: dm-0 plastic:~# uname -a Linux plastic 2.6.24.2-i686-net #1 SMP Tue Feb 12 17:42:16 EET 2008 i686 GNU/Linux plastic:~# xfs_info /site/backup-volA meta-data=/site/backup-volA isize=256 agcount=39, agsize=4559936 blks = sectsz=512 data = bsize=4096 blocks=177360896, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=32768, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 # diff between output of xfs_repair 2.9.7 (screenlog.0) and # xfs_repair 2.7.14 (screenlog.1) --- screenlog.0 2008-03-10 10:32:13.000000000 +0200 +++ screenlog.1 2008-03-10 14:04:00.000000000 +0200 @@ -1,3 +1,9 @@ + - scan filesystem freespace and inode maps... + - found root inode chunk +Phase 3 - for each AG... + - scan and clear agi unlinked lists... + - process known inodes and perform inode discovery... + - agno = 0 - agno = 1 - agno = 2 - agno = 3 @@ -39,6 +45,9 @@ - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... + - clear lost+found (if it exists) ... + - clearing existing "lost+found" inode + - marking entry "lost+found" to be deleted - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 @@ -83,103 +92,13 @@ - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - - traversing filesystem ... - - traversal finished ... - - moving disconnected inodes to lost+found ... + - ensuring existence of lost+found directory + - traversing filesystem starting at / ... +rebuilding directory inode 128 + - traversal finished ... + - traversing all unattached subtrees ... + - traversals finished ... + - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... Best regards, Erkki From owner-xfs@oss.sgi.com Mon Mar 10 06:31:17 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Mar 2008 06:31:35 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m2ADVFZ0030880 for ; Mon, 10 Mar 2008 06:31:17 -0700 X-ASG-Debug-ID: 1205155904-4c5b02520000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 307A95C3BC8 for ; Mon, 10 Mar 2008 06:31:45 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id AkdC6s8Fj2hw8imd for ; Mon, 10 Mar 2008 06:31:45 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 6721218000096; Mon, 10 Mar 2008 08:31:43 -0500 (CDT) Message-ID: <47D5383E.50201@sandeen.net> Date: Mon, 10 Mar 2008 08:31:42 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: erkki.lintunen@iki.fi CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: an occational trouble with xfs file system which xfs_repair 2.7.14 has been able to fix Subject: Re: an occational trouble with xfs file system which xfs_repair 2.7.14 has been able to fix References: <47D52BE5.6010706@iki.fi> In-Reply-To: <47D52BE5.6010706@iki.fi> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1205155906 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.44421 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14830 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Erkki Lintunen wrote: ... > commands in a script. When the trouble begins cp -al command starts to > take several hours and hundreds of megs memory. rm -fr of a subtree also > takes considerably longer than rm a subtree in another bigger tree in > the same filesystem, but the rm commands have always finnished, which > the cp -al commands haven't. Most of the time the cp -al process has D > status. ... > What else information I could provide in addition to those requested in FAQ? When you get a process in the D state, do echo t > /proc/sysrq-trigger to get backtraces of all processes; or echo w to get all blocked processes. -Eric From owner-xfs@oss.sgi.com Mon Mar 10 11:16:54 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Mar 2008 11:17:13 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: ** X-Spam-Status: No, score=2.0 required=5.0 tests=BAYES_50,RCVD_IN_PSBL autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m2AIGrAP030031 for ; Mon, 10 Mar 2008 11:16:54 -0700 X-ASG-Debug-ID: 1205173038-3d4201d60000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mailer1.acanac.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id E92F4F53D5B for ; Mon, 10 Mar 2008 11:17:23 -0700 (PDT) Received: from mailer1.acanac.net (mailer1.acanac.net [66.49.201.229]) by cuda.sgi.com with ESMTP id yNYulOZi1u9SdWlc for ; Mon, 10 Mar 2008 11:17:23 -0700 (PDT) Received: from toshiba-user (dsl-67-204-13-21.acanac.net [67.204.13.21]) by mailer1.acanac.net (8.12.11/8.12.11) with SMTP id m2AIBTme009644 for ; Mon, 10 Mar 2008 13:17:02 -0500 Message-Id: <200803101817.m2AIBTme009644@mailer1.acanac.net> From: Sounder Dilipan To: Date: Mon, 10 Mar 2008 14:10:15 -0400 X-ASG-Orig-Subj: 'Work from Home' 'Web Developer' & 'Web Programmer' Opportunities Subject: 'Work from Home' 'Web Developer' & 'Web Programmer' Opportunities X-Mailer: TOL Mailer MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7Bit X-Barracuda-Connect: mailer1.acanac.net[66.49.201.229] X-Barracuda-Start-Time: 1205173043 X-Barracuda-Bayes: INNOCENT GLOBAL 0.5026 1.0000 0.7500 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.75 X-Barracuda-Spam-Status: No, SCORE=0.75 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.44441 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14831 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hr@netultimate.com Precedence: bulk X-list: xfs Hi, We are recruiting 'web designers' and 'web programmers' to work with us in part time and full time in Contract basis. If you or your friends or your family members are looking for opportunities to work from home contact us ASAP by phone or email or by 'yahoo messenger' 'yahoo messenger' : dilipan@yahoo.com email : resume@netultimate.com Regards, Dilipan (703) 849 1269 (USA) (416) 238 0270 (CANADA) From owner-xfs@oss.sgi.com Mon Mar 10 13:37:29 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Mar 2008 13:37:46 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,J_CHICKENPOX_21 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m2AKbPF8017144 for ; Mon, 10 Mar 2008 13:37:29 -0700 X-ASG-Debug-ID: 1205181475-20ad03b40000-ps1ADW X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ty.sabi.co.UK (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 87E0167FAF4 for ; Mon, 10 Mar 2008 13:37:55 -0700 (PDT) Received: from ty.sabi.co.UK ([192.100.78.57]) by cuda.sgi.com with ESMTP id kMzlb3CAHfQt9sDD for ; Mon, 10 Mar 2008 13:37:55 -0700 (PDT) Received: from from [127.0.0.1] (helo=tree.ty.sabi.co.uk) by ty.sabi.co.UK with esmtp(Exim 4.66 #1) id 1JYokn-0001Jg-61 for ; Mon, 10 Mar 2008 20:37:49 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18389.39964.468947.464155@tree.ty.sabi.co.uk> Date: Mon, 10 Mar 2008 20:37:48 +0000 X-Face: SMJE]JPYVBO-9UR%/8d'mG.F!@.,l@c[f'[%S8'BZIcbQc3/">GrXDwb#;fTRGNmHr^JFb SAptvwWc,0+z+~p~"Gdr4H$(|N(yF(wwCM2bW0~U?HPEE^fkPGx^u[*[yV.gyB!hDOli}EF[\cW*S H&spRGFL}{`bj1TaD^l/"[ msn( /TH#THs{Hpj>)]f> X-ASG-Orig-Subj: Re: xfs for free hosting on linux ? performance questions Subject: Re: xfs for free hosting on linux ? performance questions In-Reply-To: <2db2c6b80803091738o20dc80b2p82c5bf7246a8c560@mail.gmail.com> References: <47D45926.5070806@gmail.com> <18388.31367.314074.624135@tree.ty.sabi.co.uk> <2db2c6b80803091738o20dc80b2p82c5bf7246a8c560@mail.gmail.com> X-Mailer: VM 7.17 under 21.5 (beta28) XEmacs Lucid From: pg_xfs2@xfs2.for.to.sabi.co.UK (Peter Grandi) X-Disclaimer: This message contains only personal opinions X-Barracuda-Connect: UNKNOWN[192.100.78.57] X-Barracuda-Start-Time: 1205181476 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.20 X-Barracuda-Spam-Status: No, SCORE=-1.20 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=FROM_HAS_ULINE_NUMS, MARKETING_SUBJECT X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.44450 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.60 MARKETING_SUBJECT Subject contains popular marketing words 0.22 FROM_HAS_ULINE_NUMS From: contains an underline and numbers/letters X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14832 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: pg_xfs2@xfs2.for.to.sabi.co.UK Precedence: bulk X-list: xfs > but reiserfs is slow for me too, maybe i have some other > problems? i made array like this mdadm --create /dev/md0 > --verbose --level=5 --raid-devices=5 /dev/sd{b,c,d,e,f}1 > --assume-clean Uhhhhh, '--assume-clean' on a RAID5 is not necessarily a good idea. Just don't do it, and wait a few hours for the initial sync to happen. > [ ... ] > 26.48 megabytes read (94.47 kilobytes per second) > 136.18 megabytes written (485.89 kilobytes per second) > is there something wrong with my system?? The speed above is indeed terrible. Perhaps the array is rebuilding frantically as it finds all stripes have the wrong parity because of '--assume-clean'. > [ ... ] LA is 0.50 right now (i'm testing it at night), Why is LA relevant? What is running on that system now? Are those physical disks being used by some applications? > hdparm is showing that every HD from the array is doing > 100MB/s at least, so why these numbers? Perhaps after rebuilding the array without '--assume-clean' you might try to do such simple tests on the '/dev/md0' device itself, just to be sure that it performs more or less adequately. After several reports that is helps, try this before the test: blockdev --setra 1024 /dev/md0 but even without it you should be getting at least 40-50MB/s. And always check the array status with 'mdadm --detail' to see if it is resyncing or not before testing. Using 'watch iostat -k sd{b,c,d,e,f} 1 2' (and checking out the _second_ set of figures) is also nice to see the actual transfer rates of each drive in the array and verify that if you are reading there is no writing going on etc. From owner-xfs@oss.sgi.com Mon Mar 10 15:21:25 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Mar 2008 15:21:44 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_44, J_CHICKENPOX_45,J_CHICKENPOX_46,J_CHICKENPOX_47,MIME_8BIT_HEADER autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m2AMLICm002470 for ; Mon, 10 Mar 2008 15:21:22 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA12074; Tue, 11 Mar 2008 09:21:39 +1100 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 m2AMLcLF92616701; Tue, 11 Mar 2008 09:21:38 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id m2AMLZ7m92735104; Tue, 11 Mar 2008 09:21:35 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Tue, 11 Mar 2008 09:21:35 +1100 From: David Chinner To: Christian =?iso-8859-1?Q?R=F8snes?= Cc: David Chinner , xfs@oss.sgi.com Subject: Re: XFS internal error xfs_trans_cancel at line 1150 of file fs/xfs/xfs_trans.c Message-ID: <20080310222135.GZ155407@sgi.com> References: <20080310000809.GU155407@sgi.com> <1a4a774c0803100134k258e1bcfma95e7969bc44b2af@mail.gmail.com> <1a4a774c0803100302y17530814wee7522aa0dfd7668@mail.gmail.com> <1a4a774c0802130251h657a52f7lb97942e7afdf6e3f@mail.gmail.com> <20080213214551.GR155407@sgi.com> <1a4a774c0803050553h7f6294cfq41c38f34ea92ceae@mail.gmail.com> <1a4a774c0803060310w2642224w690ac8fa13f96ec@mail.gmail.com> <1a4a774c0803070319j1eb8790ek3daae4a16b3e6256@mail.gmail.com> <20080310000809.GU155407@sgi.com> <1a4a774c0803100134k258e1bcfma95e7969bc44b2af@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1a4a774c0803100302y17530814wee7522aa0dfd7668@mail.gmail.com> <1a4a774c0803100134k258e1bcfma95e7969bc44b2af@mail.gmail.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14833 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Mon, Mar 10, 2008 at 09:34:14AM +0100, Christian Røsnes wrote: > On Mon, Mar 10, 2008 at 1:08 AM, David Chinner wrote: > > On Fri, Mar 07, 2008 at 12:19:28PM +0100, Christian Røsnes wrote: > > > > Actually, a single mkdir command is enough to trigger the filesystem > > > > shutdown when its 99% full (according to df -k): > > > > > > > > /data# mkdir test > > > > mkdir: cannot create directory `test': No space left on device > > > > Ok, that's helpful ;) > > So, can you dump the directory inode with xfs_db? i.e. > > # ls -ia /data > > # ls -ia /data > 128 . 128 .. 131 content 149256847 rsync > > > The directory inode is the inode at ".", and if this is the root of > > the filesystem it will probably be 128. Then run: > > # xfs_db -r -c 'inode 128' -c p /dev/sdb1 > > # xfs_db -r -c 'inode 128' -c p /dev/sdb1 > core.magic = 0x494e > core.mode = 040755 > core.version = 1 > core.format = 1 (local) ..... > core.size = 32 .... > u.sfdir2.hdr.count = 2 > u.sfdir2.hdr.i8count = 0 > u.sfdir2.hdr.parent.i4 = 128 > u.sfdir2.list[0].namelen = 7 > u.sfdir2.list[0].offset = 0x30 > u.sfdir2.list[0].name = "content" > u.sfdir2.list[0].inumber.i4 = 131 > u.sfdir2.list[1].namelen = 5 > u.sfdir2.list[1].offset = 0x48 > u.sfdir2.list[1].name = "rsync" > u.sfdir2.list[1].inumber.i4 = 149256847 Ok, so a shortform directory still with heaps of space in it. so it's definitely not a directory namespace creation issue. > > > > xfs_db -r -c 'sb 0' -c p /dev/sdb1 > > > > ---------------------------------- > > ..... > > > > fdblocks = 847484 > > > > Apparently there are still lots of free blocks. I wonder if you are out of > > space in the metadata AGs. > > > > Can you do this for me: > > > > ------- > > #!/bin/bash > > > > for i in `seq 0 1 15`; do > > echo freespace histogram for AG $i > > xfs_db -r -c "freesp -bs -a $i" /dev/sdb1 > > done > > ------ > freespace histogram for AG 0 > from to extents blocks pct > 1 1 2098 2098 3.77 > 2 3 8032 16979 30.54 > 4 7 6158 33609 60.46 > 8 15 363 2904 5.22 So with 256 byte inodes, we need a 16k allocation or a 4 block extent. There's plenty of extents large enough to use for that, so it's not an inode chunk allocation error. > Btw - to debug this on a test-system, can I do a dd if=/dev/sdb1 or dd > if=/dev/sdb, > and output it to an image which is then loopback mounted on the test-system ? That would work. Use /dev/sdb1 as the source so all you copy are filesystem blocks. > Ie. is there some sort of "best practice" on how to copy this > partition to a test-system > for further testing ? Do what fit's your needs - for debugging identical images are generally best. For debugging metadata or repair problems, xfs_metadump works very well (replaces data with zeros, though), and for imaging purposes xfs_copy is very efficient. On Mon, Mar 10, 2008 at 11:02:28AM +0100, Christian Røsnes wrote: > On Mon, Mar 10, 2008 at 9:34 AM, Christian Røsnes > wrote: > > On Mon, Mar 10, 2008 at 1:08 AM, David Chinner wrote: > > > This does not appear to be the case I was expecting, though I can > > > see how we can get an ENOSPC here with plenty of blocks free - none > > > are large enough to allocate an inode chunk. What would be worth > > > knowing is the value of resblks when this error is reported. > > > > Ok. I'll see if I can print it out. > > Ok. I added printk statments to xfs_mkdir in xfs_vnodeops.c: > > 'resblks=45' is the value returned by: > > resblks = XFS_MKDIR_SPACE_RES(mp, dir_namelen); > > and this is the value when the error_return label is called. That confirms we're not out of directory space or filesystem space. > -- > > and inside xfs_dir_ialloc (file: xfs_utils.c) this is where it returns > > ... > > code = xfs_ialloc(tp, dp, mode, nlink, rdev, credp, prid, okalloc, > &ialloc_context, &call_again, &ip); > > /* > * Return an error if we were unable to allocate a new inode. > * This should only happen if we run out of space on disk or > * encounter a disk error. > */ > if (code) { > *ipp = NULL; > return code; > } > if (!call_again && (ip == NULL)) { > *ipp = NULL; > return XFS_ERROR(ENOSPC); <============== returns here > } Interesting. That implies that xfs_ialloc() failed here: 1053 /* 1054 * Call the space management code to pick 1055 * the on-disk inode to be allocated. 1056 */ 1057 error = xfs_dialloc(tp, pip ? pip->i_ino : 0, mode, okalloc, 1058 ialloc_context, call_again, &ino); 1059 if (error != 0) { 1060 return error; 1061 } 1062 if (*call_again || ino == NULLFSINO) { <<<<<<<<<<<<<<<< 1063 *ipp = NULL; 1064 return 0; 1065 } Which means that xfs_dialloc() failed without ian error or setting *call_again but setting ino == NULLFSINO. That leaves these possible failure places: 544 agbp = xfs_ialloc_ag_select(tp, parent, mode, okalloc); 545 /* 546 * Couldn't find an allocation group satisfying the 547 * criteria, give up. 548 */ 549 if (!agbp) { 550 *inop = NULLFSINO; 551 >>>>>>>>>> return 0; 552 } ........ 572 /* 573 * If we have already hit the ceiling of inode blocks then clear 574 * okalloc so we scan all available agi structures for a free 575 * inode. 576 */ 577 578 if (mp->m_maxicount && 579 mp->m_sb.sb_icount + XFS_IALLOC_INODES(mp) > mp->m_maxicount) { 580 noroom = 1; 581 okalloc = 0; 582 } ........ 600 if ((error = xfs_ialloc_ag_alloc(tp, agbp, &ialloced))) { 601 xfs_trans_brelse(tp, agbp); 602 if (error == ENOSPC) { 603 *inop = NULLFSINO; 604 >>>>>>>>>> return 0; 605 } else 606 return error; ........ 629 nextag: 630 if (++tagno == agcount) 631 tagno = 0; 632 if (tagno == agno) { 633 *inop = NULLFSINO; 634 >>>>>>>>>> return noroom ? ENOSPC : 0; 635 } Note that for the last case, we don't know what the value of "noroom" is. noroom gets set to 1 if we've reached the maximum number of inodes in the filesystem. Fromteh earlier superblock dump you did: > dblocks = 71627792 ..... > inopblog = 3 ..... > imax_pct = 25 > icount = 3570112 > ifree = 0 and the code that calculates this is: icount = sbp->sb_dblocks * sbp->sb_imax_pct; do_div(icount, 100); do_div(icount, mp->m_ialloc_blks); mp->m_maxicount = (icount * mp->m_ialloc_blks) << sbp->sb_inopblog; therefore: m_maxicount = (((((71627792 * 25) / 100) / 4) * 4) << 3) = 143,255,584 which is way larger than the 3,570,112 that you have already allocated. Hence I think that noroom == 0 and the last chunk of code above is a possibility. Further - we need to allocate new inodes as there are none free. That implies we are calling xfs_ialloc_ag_alloc(). Taking a stab in the dark, I suspect that we are not getting an error from xfs_ialloc_ag_alloc() but we are not allocating inode chunks. Why? Back to the superblock: > unit = 16 > width = 32 You've got a filesystem with stripe alignment set. In xfs_ialloc_ag_alloc() we attempt inode allocation by the following rules: 1. a) If we haven't previously allocated inodes, fall through to 2. b) If we have previously allocated inode, attempt to allocate next to the last inode chunk. 2. If we do not have an extent now: a) if we have stripe alignment, try with alignment b) if we don't have stripe alignment try cluster alignment 3. If we do not have an extent now: a) if we have stripe alignment, try with cluster alignment b) no stripe alignment, turn off alignment. 4. If we do not have an extent now: FAIL. Note the case missing from the stripe alignment fallback path - it does not try without alignment at all. That means if all those extents large enough that we found above are not correctly aligned, then we will still fail to allocate an inode chunk. if all the AGs are like this, then we'll fail to allocate at all and fall out of xfs_dialloc() through the last fragment I quoted above. As to the shutdown that this triggers - the attempt to allocate dirties the AGFL and the AGF by moving free blocks into the free list for btree splits and cancelling a dirty transaction results in a shutdown. Now, to test this theory. ;) Luckily, it's easy to test. mount the filesystem with the mount option "noalign" and rerun the mkdir test. If it is an alignment problem, then setting noalign will prevent this ENOSPC and shutdown as the filesystem will be able to allocate more inodes. Can you test this for me, Christian? Cheers, Dave. > > > Christian -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Mon Mar 10 15:29:56 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Mar 2008 15:30:04 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m2AMTrN4004407 for ; Mon, 10 Mar 2008 15:29:54 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA12567; Tue, 11 Mar 2008 09:30:23 +1100 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 m2AMUKLF92794328; Tue, 11 Mar 2008 09:30:21 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id m2AMUI5W92797299; Tue, 11 Mar 2008 09:30:18 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Tue, 11 Mar 2008 09:30:18 +1100 From: David Chinner To: Andreas Kotes Cc: David Chinner , linux-kernel@vger.kernel.org, xfs@oss.sgi.com Subject: Re: XFS internal error Message-ID: <20080310223018.GA155407@sgi.com> References: <470831E6.4030704@fastmail.co.uk> <20071008001452.GX995458@sgi.com> <20080310122216.GG14256@slop.flatline.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080310122216.GG14256@slop.flatline.de> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14834 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Mon, Mar 10, 2008 at 01:22:16PM +0100, Andreas Kotes wrote: > Hello, > > * David Chinner [20080310 13:18]: > > Yes, but those previous corruptions get left on disk as a landmine > > for you to trip over some time later, even on a kernel that has the > > bug fixed. > > > > I suggest that you run xfs_check on the filesystem and if that > > shows up errors, run xfs_repair onteh filesystem to correct them. > > I seem to be having similiar problems, and xfs_repair is not helping :( xfs_repair is ensuring that the problem is not being caused by on-disk corruption. In this case, it does not appear to be caused by on-disk corruption, so xfs_repair won't help. > I always run into: > > [ 137.099267] Filesystem "sda2": XFS internal error xfs_trans_cancel at line 1132 of file fs/xfs/xfs_trans.c. Caller 0xffffffff80372156 > [ 137.106267] > [ 137.106268] Call Trace: > [ 137.113129] [] xfs_trans_cancel+0x100/0x130 > [ 137.116524] [] xfs_create+0x256/0x6e0 > [ 137.119904] [] xfs_dir2_isleaf+0x19/0x50 > [ 137.123269] [] xfs_vn_mknod+0x195/0x250 > [ 137.126607] [] vfs_create+0xac/0xf0 > [ 137.129920] [] open_namei+0x5dc/0x700 > [ 137.133227] [] __wake_up+0x43/0x70 > [ 137.136477] [] do_filp_open+0x1c/0x50 > [ 137.139693] [] do_sys_open+0x5a/0x100 > [ 137.142838] [] sysenter_do_call+0x1b/0x67 > [ 137.145964] > [ 137.149014] xfs_force_shutdown(sda2,0x8) called from line 1133 of file fs/xfs/xfs_trans.c. Return address = 0xffffffff8036930e > [ 137.163485] Filesystem "sda2": Corruption of in-memory data detected. Shutting down filesystem: sda2 > > directly after booting. Interesting. I think I just found a cause of this shutdown under certain circumstances: http://marc.info/?l=linux-xfs&m=120518791828200&w=2 To confirm it might be the same issue, can you dump the superblock of this filesystem for me? i.e.: # xfs_db -r -c 'sb 0' -c p /dev/sda2 Also, what the mount options you are using are? Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Mon Mar 10 15:59:05 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Mar 2008 15:59:14 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m2AMx2rS008835 for ; Mon, 10 Mar 2008 15:59:04 -0700 X-ASG-Debug-ID: 1205189972-6c3401920000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.flatline.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 4D9BC1250F92; Mon, 10 Mar 2008 15:59:32 -0700 (PDT) Received: from mail.flatline.de (flatline.de [80.190.243.144]) by cuda.sgi.com with ESMTP id 7cwm3ETcNwwg07sv; Mon, 10 Mar 2008 15:59:32 -0700 (PDT) Received: from shell.priv.flatline.de ([172.16.123.7] helo=slop.flatline.de ident=count) by mail.flatline.de with smtp (Exim 4.69) (envelope-from ) id 1JYqxr-00006A-JA; Mon, 10 Mar 2008 23:59:28 +0100 Received: by slop.flatline.de (sSMTP sendmail emulation); Mon, 10 Mar 2008 23:59:27 +0100 Date: Mon, 10 Mar 2008 23:59:27 +0100 From: Andreas Kotes To: David Chinner Cc: linux-kernel@vger.kernel.org, xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS internal error Subject: Re: XFS internal error Message-ID: <20080310225927.GP14256@slop.flatline.de> References: <470831E6.4030704@fastmail.co.uk> <20071008001452.GX995458@sgi.com> <20080310122216.GG14256@slop.flatline.de> <20080310223018.GA155407@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080310223018.GA155407@sgi.com> User-Agent: Mutt/1.5.13 (2006-08-11) X-Barracuda-Connect: flatline.de[80.190.243.144] X-Barracuda-Start-Time: 1205189973 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-ASG-Whitelist: BODY (http://marc.info/\?) X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14835 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: count@flatline.de Precedence: bulk X-list: xfs Hello Dave, * David Chinner [20080310 23:30]: > On Mon, Mar 10, 2008 at 01:22:16PM +0100, Andreas Kotes wrote: > > * David Chinner [20080310 13:18]: > > > Yes, but those previous corruptions get left on disk as a landmine > > > for you to trip over some time later, even on a kernel that has the > > > bug fixed. > > > > > > I suggest that you run xfs_check on the filesystem and if that > > > shows up errors, run xfs_repair onteh filesystem to correct them. > > > > I seem to be having similiar problems, and xfs_repair is not helping :( > > xfs_repair is ensuring that the problem is not being caused by on-disk > corruption. In this case, it does not appear to be caused by on-disk > corruption, so xfs_repair won't help. ok, too bad - btw, is it a problem that I'm doing the xfs_repair on a mounted filesystem with xfs_repair -f -L after a remount rw? > > I always run into: > > > > [ 137.099267] Filesystem "sda2": XFS internal error xfs_trans_cancel at line 1132 of file fs/xfs/xfs_trans.c. Caller 0xffffffff80372156 > > [ 137.106267] > > [ 137.106268] Call Trace: > > [ 137.113129] [] xfs_trans_cancel+0x100/0x130 > > [ 137.116524] [] xfs_create+0x256/0x6e0 > > [ 137.119904] [] xfs_dir2_isleaf+0x19/0x50 > > [ 137.123269] [] xfs_vn_mknod+0x195/0x250 > > [ 137.126607] [] vfs_create+0xac/0xf0 > > [ 137.129920] [] open_namei+0x5dc/0x700 > > [ 137.133227] [] __wake_up+0x43/0x70 > > [ 137.136477] [] do_filp_open+0x1c/0x50 > > [ 137.139693] [] do_sys_open+0x5a/0x100 > > [ 137.142838] [] sysenter_do_call+0x1b/0x67 > > [ 137.145964] > > [ 137.149014] xfs_force_shutdown(sda2,0x8) called from line 1133 of file fs/xfs/xfs_trans.c. Return address = 0xffffffff8036930e > > [ 137.163485] Filesystem "sda2": Corruption of in-memory data detected. Shutting down filesystem: sda2 > > > > directly after booting. > > Interesting. I think I just found a cause of this shutdown under > certain circumstances: > > http://marc.info/?l=linux-xfs&m=120518791828200&w=2 > > To confirm it might be the same issue, can you dump the superblock of this > filesystem for me? i.e.: > > # xfs_db -r -c 'sb 0' -c p /dev/sda2 certainly: magicnum = 0x58465342 blocksize = 4096 dblocks = 35613152 rblocks = 0 rextents = 0 uuid = 62dae5fa-4085-4edc-ad76-5652d9fb00ae logstart = 33554436 rootino = 128 rbmino = 129 rsumino = 130 rextsize = 1 agblocks = 2225822 agcount = 16 rbmblocks = 0 logblocks = 17389 versionnum = 0x3084 sectsize = 512 inodesize = 256 inopblock = 16 fname = "s2g-serv\000\000\000\000" blocklog = 12 sectlog = 9 inodelog = 8 inopblog = 4 agblklog = 22 rextslog = 0 inprogress = 0 imax_pct = 25 icount = 15232 ifree = 2379 fdblocks = 5942436 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 features2 = 0 > Also, what the mount options you are using are? rw,noatime ... if you want more info, just let me know :) Kind regards from Berlin, Andreas -- flatline IT services - Andreas Kotes - Tailored solutions for your IT needs From owner-xfs@oss.sgi.com Mon Mar 10 16:45:16 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Mar 2008 16:45:36 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m2ANjCUP018533 for ; Mon, 10 Mar 2008 16:45:15 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA15360; Tue, 11 Mar 2008 10:45:43 +1100 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 m2ANjfLF92781281; Tue, 11 Mar 2008 10:45:42 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id m2ANjeQC92784398; Tue, 11 Mar 2008 10:45:40 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Tue, 11 Mar 2008 10:45:40 +1100 From: David Chinner To: Andreas Kotes Cc: David Chinner , linux-kernel@vger.kernel.org, xfs@oss.sgi.com Subject: Re: XFS internal error Message-ID: <20080310234539.GC155407@sgi.com> References: <470831E6.4030704@fastmail.co.uk> <20071008001452.GX995458@sgi.com> <20080310122216.GG14256@slop.flatline.de> <20080310223018.GA155407@sgi.com> <20080310225927.GP14256@slop.flatline.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080310225927.GP14256@slop.flatline.de> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14836 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Mon, Mar 10, 2008 at 11:59:27PM +0100, Andreas Kotes wrote: > * David Chinner [20080310 23:30]: > > On Mon, Mar 10, 2008 at 01:22:16PM +0100, Andreas Kotes wrote: > > > * David Chinner [20080310 13:18]: > > > > Yes, but those previous corruptions get left on disk as a landmine > > > > for you to trip over some time later, even on a kernel that has the > > > > bug fixed. > > > > > > > > I suggest that you run xfs_check on the filesystem and if that > > > > shows up errors, run xfs_repair onteh filesystem to correct them. > > > > > > I seem to be having similiar problems, and xfs_repair is not helping :( > > > > xfs_repair is ensuring that the problem is not being caused by on-disk > > corruption. In this case, it does not appear to be caused by on-disk > > corruption, so xfs_repair won't help. > > ok, too bad - btw, is it a problem that I'm doing the xfs_repair on a > mounted filesystem with xfs_repair -f -L after a remount rw? If it was read only, and you rebooted immediately afterwards, you'd probably be ok. Doing this to a mounted, rw filesystem is asking for trouble. If the shutdown is occurring after you've run xfs_repair, then it is almost certainly the cause.... I'd suggest getting a knoppix (or similar) rescue disk and repairing from that, rebooting and seeing if the problem persists. If it does, then we'll have to look further into it. FWIW, you've got plenty of free inodes so this does not look to be the same problem I've just found. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Mon Mar 10 17:44:15 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Mar 2008 17:44:34 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m2B0iExN028589 for ; Mon, 10 Mar 2008 17:44:15 -0700 X-ASG-Debug-ID: 1205196284-68d000350000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from postoffice.aconex.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 6D63B125114A for ; Mon, 10 Mar 2008 17:44:45 -0700 (PDT) Received: from postoffice.aconex.com (prod.aconex.com [203.89.192.138]) by cuda.sgi.com with ESMTP id G6Aqgywa8bFvjw4u for ; Mon, 10 Mar 2008 17:44:45 -0700 (PDT) Received: from [192.168.5.76] (unknown [203.89.192.141]) by postoffice.aconex.com (Postfix) with ESMTP id 7FF1392C49A; Tue, 11 Mar 2008 11:44:12 +1100 (EST) X-ASG-Orig-Subj: Re: [PATCH, RFC] - remove mounpoint UUID code Subject: Re: [PATCH, RFC] - remove mounpoint UUID code From: Nathan Scott Reply-To: nscott@aconex.com To: Eric Sandeen Cc: xfs-oss In-Reply-To: <47D20F78.7000103@sandeen.net> References: <47D20F78.7000103@sandeen.net> Content-Type: text/plain Organization: Aconex Date: Tue, 11 Mar 2008 11:44:12 +1100 Message-Id: <1205196252.15982.69.camel@edge.scott.net.au> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: prod.aconex.com[203.89.192.138] X-Barracuda-Start-Time: 1205196285 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.42 X-Barracuda-Spam-Status: No, SCORE=-1.42 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=COMMA_SUBJECT X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.44467 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.60 COMMA_SUBJECT Subject is like 'Re: FDSDS, this is a subject' X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14837 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nscott@aconex.com Precedence: bulk X-list: xfs On Fri, 2008-03-07 at 22:00 -0600, Eric Sandeen wrote: > It looks like all of the below is unused... and according > to Nathan, > > "dont think it even got used/implemented anywhere, but i think it > was meant to be an auto-mount kinda thing... such that when you look > up at that point, it knows to mount the device with that uuid there, > if its not already it was never really written anywhere ... just an > idea in doug doucettes brain i think." > > Think it'll ever go anywhere, or should it get pruned? > > The below builds; not at all tested, until I get an idea if it's worth > doing. Need to double check that some structures might not need padding > out to keep things compatible/consistent... Since effectively all versions of XFS support this feature ondisk, including complete support in recovery, it would be better IMO to leave it in for someone to implement/experiment with the syscall and auto-mounting userspace support. That would then require no new feature bits, mkfs/repair changes, etc. There is effectively zero cost to leaving it there - and non-zero cost in removing it, if our seriously bad regression-via-cleanup history is anything to go by ... :| It would be really unfortunate to remove this, and then find that it was useful to someone (who didn't know about it at this time). OTOH, if there is definately never ever any chance this can ever be useful, then it should indeed be removed. :) cheers. -- Nathan From owner-xfs@oss.sgi.com Mon Mar 10 18:04:06 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Mar 2008 18:04:25 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m2B13xV2031888 for ; Mon, 10 Mar 2008 18:04:03 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA17583; Tue, 11 Mar 2008 12:04:23 +1100 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 m2B14MLF91634908; Tue, 11 Mar 2008 12:04:22 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id m2B14Lgb92800887; Tue, 11 Mar 2008 12:04:21 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Tue, 11 Mar 2008 12:04:21 +1100 From: David Chinner To: xfs-dev Cc: xfs@oss.sgi.com, haryadi@cs.wisc.edu, remzi@cs.wisc.edu Subject: [Review] Improve XFS error checking and propagation Message-ID: <20080311010420.GD155407@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14838 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs A recent paper at the FAST08 conference highlighted a large number of unchecked error paths in Linux filesystems and I/O layers. As a subsystem, XFS had the highest aggregate numbers of bad error propagation. A tarball which contains a quilt patch series of 32 patches aimed at improving this situation can be found here: http://oss.sgi.com/~dgc/xfs/error-check/xfs-error-checking.tar.gz The paper "EIO: Error Handling is Occasionally Correct" can be found here: http://www.cs.wisc.edu/adsl/Publications/eio-fast08.html And the in depth results here: http://www.cs.wisc.edu/adsl/Publications/eio-fast08/readme.html http://www.cs.wisc.edu/adsl/Publications/eio-fast08/ The XFS results I've been working from are here: http://www.cs.wisc.edu/adsl/Publications/eio-fast08/fullfs-xfs-without-false-positives.txt and included below is an annotated version of this file as I've worked through it. The graph of the XFS error paths is a good visual representation of how the bad error paths tend to cluster together: http://www.cs.wisc.edu/adsl/Publications/eio-fast08/singlefs-xfs.pdf (you'll need at least 800% zoom to be able to read it at all) The paper analysed a 2.6.15 kernel, but I've been working against an xfs-dev tree (~2.6.24). Of the 101 reported problems for the 2.6.15 kernel that was analysed: - 7 did not exist anymore (bhv layer, dirv1, write path changes) - 11 were false positives that were not modified - 24 were false positives that have been patched to remove (e.g. int xfs_foo() to void xfs_foo()) - 37 real problems where an error needed to be returned and are fixed in the patch series. - 3 where there is no error path to return an error and no point in even warning about it (ENOSPC flushing) - 10 where there is no error path to return an error, but patched to warn to the syslog about potential data loss or metadata I/O errors - 4 were already fixed in the xfs-dev tree - 2 where the error is ignored because we must continue anyway (patched to warn to syslog) - 4 that I haven't yet fixed (xfs_buf_iostrategy and xfs_buf_iostart) because I need to think about them more. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group ---------------------------------------- fs/xfs/ ---- d 1 xfs_write -> _xfs_log_force fs/xfs/linux-2.6/xfs_lrw.c 881 d 2 xfs_write -> _xfs_log_force fs/xfs/linux-2.6/xfs_lrw.c 884 F 3 xfs_flush_device -> _xfs_log_force fs/xfs/linux-2.6/xfs_super.c 547 F 4 xfs_qm_dqflush -> _xfs_log_force fs/xfs/quota/xfs_dquot.c 1294 F 5 xfs_qm_dqflock_pushbuf_wait -> _xfs_log_force fs/xfs/quota/xfs_dquot.c 1591 F 6 xfs_qm_dqunpin_wait -> _xfs_log_force fs/xfs/quota/xfs_dquot_item.c 204 F 7 xfs_qm_dquot_logitem_pushbuf -> _xfs_log_force fs/xfs/quota/xfs_dquot_item.c 267 F 8 xfs_alloc_search_busy -> _xfs_log_force fs/xfs/xfs_alloc.c 2593 F 9 xfs_iunpin_wait -> _xfs_log_force fs/xfs/xfs_inode.c 2847 F 10 xfs_iflush -> _xfs_log_force fs/xfs/xfs_inode.c 3243 F 11 xfs_inode_item_pushbuf -> _xfs_log_force fs/xfs/xfs_inode_item.c 819 P 12 xfs_log_unmount_write -> _xfs_log_force fs/xfs/xfs_log.c 529 F 13 xlog_recover_finish -> _xfs_log_force fs/xfs/xfs_log_recover.c 3961 F 14 xfs_unmountfs -> _xfs_log_force fs/xfs/xfs_mount.c 1088 F 15 xfs_trans_push_ail -> _xfs_log_force fs/xfs/xfs_trans_ail.c 198 F 16 xfs_syncsub -> _xfs_log_force fs/xfs/xfs_vfsops.c 1440 F 17 xfs_syncsub -> _xfs_log_force fs/xfs/xfs_vfsops.c 1455 F 18 xfs_syncsub -> _xfs_log_force fs/xfs/xfs_vfsops.c 1491 F 19 xfs_syncsub -> _xfs_log_force fs/xfs/xfs_vfsops.c 1543 P 20 xfs_fsync -> _xfs_log_force fs/xfs/xfs_vnodeops.c 1129 P 21 xfs_qm_write_sb_changes -> _xfs_trans_commit fs/xfs/quota/xfs_qm.c 2414 P 22 xfs_qm_scall_setqlim -> _xfs_trans_commit fs/xfs/quota/xfs_qm_syscalls.c 739 P 23 xfs_itruncate_finish -> _xfs_trans_commit fs/xfs/xfs_inode.c 1718 P 24 xlog_recover_process_efi -> _xfs_trans_commit fs/xfs/xfs_log_recover.c 3047 P 25 xlog_recover_clear_agi_bucket -> _xfs_trans_commit fs/xfs/xfs_log_recover.c 3174 PB 26 xfs_mount_log_sbunit -> _xfs_trans_commit fs/xfs/xfs_mount.c 1579 P 27 xfs_growfs_rt_alloc -> _xfs_trans_commit fs/xfs/xfs_rtalloc.c 154 P 28 xfs_growfs_rt_alloc -> _xfs_trans_commit fs/xfs/xfs_rtalloc.c 191 P 29 xfs_growfs_rt -> _xfs_trans_commit fs/xfs/xfs_rtalloc.c 2103 P 30 xfs_inactive_attrs -> _xfs_trans_commit fs/xfs/xfs_vnodeops.c 1505 C 31 xfs_inactive -> _xfs_trans_commit fs/xfs/xfs_vnodeops.c 1790 d 32 xfs_initialize_vnode -> bhv_insert fs/xfs/linux-2.6/xfs_super.c 220 d 33 vfs_insertops -> bhv_insert fs/xfs/linux-2.6/xfs_vfs.c 259 N 34 linvfs_truncate -> block_truncate_page fs/xfs/linux-2.6/xfs_iops.c 651 G 35 fs_flushinval_pages -> filemap_fdatawait fs/xfs/linux-2.6/xfs_fs_subr.c 83 G 36 fs_flush_pages -> filemap_fdatawait fs/xfs/linux-2.6/xfs_fs_subr.c 108 G 37 fs_flushinval_pages -> filemap_fdatawrite fs/xfs/linux-2.6/xfs_fs_subr.c 82 G 38 fs_flush_pages -> filemap_fdatawrite fs/xfs/linux-2.6/xfs_fs_subr.c 105 n 39 xfs_flush_inode_work -> filemap_flush fs/xfs/linux-2.6/xfs_super.c 508 PM 40 xlog_sync -> pagebuf_associate_memory fs/xfs/xfs_log.c 1358 PM 41 xlog_sync -> pagebuf_associate_memory fs/xfs/xfs_log.c 1395 PM 42 xlog_write_log_records -> pagebuf_associate_memory fs/xfs/xfs_log_recover.c 1156 PM 43 xlog_write_log_records -> pagebuf_associate_memory fs/xfs/xfs_log_recover.c 1159 PM 44 xlog_do_recovery_pass -> pagebuf_associate_memory fs/xfs/xfs_log_recover.c 3646 PM 45 xlog_do_recovery_pass -> pagebuf_associate_memory fs/xfs/xfs_log_recover.c 3653 PM 46 xlog_do_recovery_pass -> pagebuf_associate_memory fs/xfs/xfs_log_recover.c 3705 PM 47 xlog_do_recovery_pass -> pagebuf_associate_memory fs/xfs/xfs_log_recover.c 3711 M 48 xfs_buf_read_flags -> pagebuf_iostart fs/xfs/linux-2.6/xfs_buf.c 636 M 49 xfsbufd -> pagebuf_iostrategy fs/xfs/linux-2.6/xfs_buf.c 1755 M 50 xfs_flush_buftarg -> pagebuf_iostrategy fs/xfs/linux-2.6/xfs_buf.c 1816 M 51 XFS_bwrite -> pagebuf_iostrategy fs/xfs/linux-2.6/xfs_buf.h 503 n 52 xfs_flush_device_work -> sync_blockdev fs/xfs/linux-2.6/xfs_super.c 533 f 53 exit_xfs_fs -> unregister_filesystem fs/xfs/linux-2.6/xfs_super.c 999 PM 54 xfs_acl_vset -> xfs_acl_vremove fs/xfs/xfs_acl.c 326 f 55 xfs_ialloc_ag_select -> xfs_alloc_pagf_init fs/xfs/xfs_ialloc.c 411 P 56 xfs_qm_dqflush -> xfs_bawrite fs/xfs/quota/xfs_dquot.c 1300 N 57 xfs_qm_dqflock_pushbuf_wait -> xfs_bawrite fs/xfs/quota/xfs_dquot.c 1595 N 58 xfs_qm_dquot_logitem_pushbuf -> xfs_bawrite fs/xfs/quota/xfs_dquot_item.c 275 N 59 xfs_buf_item_push -> xfs_bawrite fs/xfs/xfs_buf_item.c 669 P 60 xfs_iflush -> xfs_bawrite fs/xfs/xfs_inode.c 3249 N 61 xfs_inode_item_pushbuf -> xfs_bawrite fs/xfs/xfs_inode_item.c 823 F 62 xfs_qm_dqflush -> xfs_bdwrite fs/xfs/quota/xfs_dquot.c 1298 F 63 xfs_qm_dqiter_bufs -> xfs_bdwrite fs/xfs/quota/xfs_qm.c 1551 F 64 xfs_iflush -> xfs_bdwrite fs/xfs/xfs_inode.c 3247 F 65 xlog_recover_do_buffer_trans -> xfs_bdwrite fs/xfs/xfs_log_recover.c 2271 F 66 xlog_recover_do_inode_trans -> xfs_bdwrite fs/xfs/xfs_log_recover.c 2535 F 67 xlog_recover_do_dquot_trans -> xfs_bdwrite fs/xfs/xfs_log_recover.c 2664 C 68 xfs_inactive -> xfs_bmap_finish fs/xfs/xfs_vnodeops.c 1788 P 69 xfs_iomap_write_allocate -> xfs_bmap_last_offset fs/xfs/xfs_iomap.c 787 d 70 xfs_dir_leaf_rebalance -> xfs_dir_leaf_compact fs/xfs/xfs_dir_leaf.c 1146 d 71 xfs_dir_leaf_rebalance -> xfs_dir_leaf_compact fs/xfs/xfs_dir_leaf.c 1176 d 72 xfs_dir_leaf_to_shortform -> xfs_dir_shortform_addname fs/xfs/xfs_dir_leaf.c 693 P 73 xlog_recover_process_efi -> xfs_free_extent fs/xfs/xfs_log_recover.c 3041 n 74 xfs_inode_item_push -> xfs_iflush fs/xfs/xfs_inode_item.c 879 P 75 xlog_recover_do_inode_trans -> xfs_imap fs/xfs/xfs_log_recover.c 2320 f 76 xfs_bmap_add_extent -> xfs_mod_incore_sb fs/xfs/xfs_bmap.c 689 f 77 xfs_bmap_add_extent_hole_delay -> xfs_mod_incore_sb fs/xfs/xfs_bmap.c 1918 f 78 xfs_bmap_del_extent -> xfs_mod_incore_sb fs/xfs/xfs_bmap.c 3117 f 79 xfs_bmapi -> xfs_mod_incore_sb fs/xfs/xfs_bmap.c 4801 f 80 xfs_bmapi -> xfs_mod_incore_sb fs/xfs/xfs_bmap.c 4805 f 81 xfs_bunmapi -> xfs_mod_incore_sb fs/xfs/xfs_bmap.c 5452 f 82 xfs_bunmapi -> xfs_mod_incore_sb fs/xfs/xfs_bmap.c 5458 f 83 xfs_trans_reserve -> xfs_mod_incore_sb fs/xfs/xfs_trans.c 305 P 84 xfs_qm_quotacheck -> xfs_mount_reset_sbqflags fs/xfs/quota/xfs_qm.c 1962 N 85 xfs_qm_dqpurge -> xfs_qm_dqflush fs/xfs/quota/xfs_dquot.c 1505 NB 86 xfs_qm_dquot_logitem_push -> xfs_qm_dqflush fs/xfs/quota/xfs_dquot_item.c 168 N 87 xfs_qm_shake_freelist -> xfs_qm_dqflush fs/xfs/quota/xfs_qm.c 2134 N 88 xfs_qm_dqreclaim_one -> xfs_qm_dqflush fs/xfs/quota/xfs_qm.c 2306 PM 89 xfs_qm_quotacheck -> xfs_qm_dqflush_all fs/xfs/quota/xfs_qm.c 1930 P 90 xfs_qm_scall_quotaoff -> xfs_qm_log_quotaoff fs/xfs/quota/xfs_qm_syscalls.c 291 P 91 xfs_qm_scall_quotaoff -> xfs_qm_log_quotaoff_end fs/xfs/quota/xfs_qm_syscalls.c 347 F 92 xfs_qm_newmount -> xfs_qm_mount_quotas fs/xfs/quota/xfs_qm_bhv.c 273 F 93 xfs_qm_endmount -> xfs_qm_mount_quotas fs/xfs/quota/xfs_qm_bhv.c 301 PM 94 xfs_quiesce_fs -> xfs_syncsub fs/xfs/xfs_vfsops.c 632 P 95 xlog_recover_process_efi -> xfs_trans_reserve fs/xfs/xfs_log_recover.c 3036 P 96 xlog_recover_clear_agi_bucket -> xfs_trans_reserve fs/xfs/xfs_log_recover.c 3152 P 97 xfs_qm_scall_trunc_qfiles -> xfs_truncate_file fs/xfs/quota/xfs_qm_syscalls.c 395 P 98 xfs_qm_scall_trunc_qfiles -> xfs_truncate_file fs/xfs/quota/xfs_qm_syscalls.c 404 P 99 xfs_log_unmount_write -> xlog_state_release_iclog fs/xfs/xfs_log.c 570 P 100 xfs_log_unmount_write -> xlog_state_release_iclog fs/xfs/xfs_log.c 606 f 101 xfs_log_force_umount -> xlog_state_sync_all fs/xfs/xfs_log.c 3586 f = false positive F = false positive + patch to remove condition G = patch in mainline git tree already M = __must_check annotations found this as well P = real, patch to fix n = no error path to return error N = no error path to return error, patch to warn about error added d = does not exist anymore. B = some other bug found and fixed at same time C = error ignored, must continue anyway. If silent, made noisy Notes: - all the xfs_mod_incore_sb() are false positive because they are freeing blocks or extents which means there can never be an error returned. The only error that can be returned is ENOSPC when trying to allocate blocks.... - none of the callers of xfs_mount_log_sb() check the return value. - new function xfs_log_sbcount failed to check return of xfs_trans_commit. Callers are failing to check return value. - most of the callers to xfs_log_force() are not interested in errors - they'll get them through other means (i.e. log error implies filesystem shutdown). Only a handful of callers really should return errors, such as fsync(), sync writes or synchronous transaction commits. From owner-xfs@oss.sgi.com Mon Mar 10 18:14:58 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Mar 2008 18:15:19 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_43 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m2B1Es9F001444 for ; Mon, 10 Mar 2008 18:14:56 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA17834; Tue, 11 Mar 2008 12:15:21 +1100 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 m2B1FJLF92840015; Tue, 11 Mar 2008 12:15:19 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id m2B1FE8W92795931; Tue, 11 Mar 2008 12:15:14 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Tue, 11 Mar 2008 12:15:14 +1100 From: David Chinner To: Niv Sardi Cc: David Chinner , Niv Sardi , sgi.bugs.xfs@fido.engr.sgi.com, xfs-dev@sgi.com, xfs@oss.sgi.com Subject: Re: ADD 977766 - mkfs.xfs man page needs the default settings updated. [REVIEW TAKE 3] Message-ID: <20080311011514.GE155407@sgi.com> References: <20080222003514.8D88E2C3@toolshop.engr.sgi.com> <20080310060751.GY155407@sgi.com> <416c461f0803092315m7ae6f55ek9b64058c3793aaa7@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <416c461f0803092315m7ae6f55ek9b64058c3793aaa7@mail.gmail.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14839 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Mon, Mar 10, 2008 at 05:15:04PM +1100, Niv Sardi wrote: > On Mon, Mar 10, 2008 at 5:07 PM, David Chinner wrote: > > Secondly, version one logs are not being kept around for backwards > > compatibility reasons. It's a valid, supported configuration, and in > > some cases performs better than version 2 logs.... > > Can you be more specific ? More specific about which comment? Re: performance - specSFS. IIRC, anything that is effectively a synchronous transaction workload tends to perform slightly better with v1 logs than v2 logs. It's in the order of a few percent, but some ppl kill for that ;) > the man page should document when this is > better supported and I believe you're the one that has the best > knowledge about that. > > > Realistically, I see no need for changing this text except to add that > > the default is version 2. > > The change was motivated by Eric's comments on OSS that it is not > clear why one should pick log v1 or v2, and I believe he is right. If you don't understand - use the default. In most cases v2 logs are the right thing to use and no amount of text in the man page is going to be able to explain the corner cases where you'd want to use v1 logs.... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Mon Mar 10 18:19:23 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Mar 2008 18:19:31 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m2B1JI3a002192 for ; Mon, 10 Mar 2008 18:19:23 -0700 X-ASG-Debug-ID: 1205198388-0ac800360000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 89283F5C71C for ; Mon, 10 Mar 2008 18:19:48 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id mHZLCqrOgX4zbbgq for ; Mon, 10 Mar 2008 18:19:48 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 6AC6518004EE3; Mon, 10 Mar 2008 20:19:16 -0500 (CDT) Message-ID: <47D5DE13.8030902@sandeen.net> Date: Mon, 10 Mar 2008 20:19:15 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: nscott@aconex.com CC: xfs-oss X-ASG-Orig-Subj: Re: [PATCH, RFC] - remove mounpoint UUID code Subject: Re: [PATCH, RFC] - remove mounpoint UUID code References: <47D20F78.7000103@sandeen.net> <1205196252.15982.69.camel@edge.scott.net.au> In-Reply-To: <1205196252.15982.69.camel@edge.scott.net.au> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1205198389 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.42 X-Barracuda-Spam-Status: No, SCORE=-1.42 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=COMMA_SUBJECT X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.44469 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.60 COMMA_SUBJECT Subject is like 'Re: FDSDS, this is a subject' X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14840 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Nathan Scott wrote: (hope you didn't too much mind my quoting you in this thread) ;) > Since effectively all versions of XFS support this feature ondisk, > including complete support in recovery, it would be better IMO to > leave it in for someone to implement/experiment with the syscall > and auto-mounting userspace support. That would then require no > new feature bits, mkfs/repair changes, etc. There is effectively > zero cost to leaving it there - and non-zero cost in removing it, > if our seriously bad regression-via-cleanup history is anything > to go by ... :| the only cost to leaving it is having another instance of "ok now what the heck is THIS?!" ... death by a thousand cuts of xfs complexity. But yeah, removing it has some risk too. > It would be really unfortunate to remove this, and then find that > it was useful to someone (who didn't know about it at this time). > OTOH, if there is definately never ever any chance this can ever > be useful, then it should indeed be removed. :) Well I'm not hung up about it. If anyone thinks it'll be useful, I'm not bothered by leaving it as is. So, Nathan, what are your plans for this code? *grin* -Eric From owner-xfs@oss.sgi.com Mon Mar 10 18:45:32 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Mar 2008 18:45:52 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_43 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m2B1jSeI005781 for ; Mon, 10 Mar 2008 18:45:32 -0700 X-ASG-Debug-ID: 1205199959-68b001220000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id B8B3DF5C581 for ; Mon, 10 Mar 2008 18:45:59 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id ZXkv4SBGRrgRFxx3 for ; Mon, 10 Mar 2008 18:45:59 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id A3C7818004EE3; Mon, 10 Mar 2008 20:45:58 -0500 (CDT) Message-ID: <47D5E455.9090309@sandeen.net> Date: Mon, 10 Mar 2008 20:45:57 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: David Chinner CC: Niv Sardi , Niv Sardi , sgi.bugs.xfs@fido.engr.sgi.com, xfs-dev@sgi.com, xfs@oss.sgi.com X-ASG-Orig-Subj: Re: ADD 977766 - mkfs.xfs man page needs the default settings updated. [REVIEW TAKE 3] Subject: Re: ADD 977766 - mkfs.xfs man page needs the default settings updated. [REVIEW TAKE 3] References: <20080222003514.8D88E2C3@toolshop.engr.sgi.com> <20080310060751.GY155407@sgi.com> <416c461f0803092315m7ae6f55ek9b64058c3793aaa7@mail.gmail.com> <20080311011514.GE155407@sgi.com> In-Reply-To: <20080311011514.GE155407@sgi.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1205199959 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.44471 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14841 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs David Chinner wrote: >> The change was motivated by Eric's comments on OSS that it is not >> clear why one should pick log v1 or v2, and I believe he is right. > > If you don't understand - use the default. In most cases v2 logs are the > right thing to use and no amount of text in the man page is going to be > able to explain the corner cases where you'd want to use v1 logs.... I think the only problem, Dave, is that there are maybe 2 people on the face of this earth who DO understand ;) (and I don't count myself among them). Just saying that v1 logs are still there for corner cases & specialized workloads which may perform better is probably fine, don't you think? That way those people who kill for such things can test both flavors. Without that, people won't know if v1 is broken, deprecated, dangerous, or what. If you say nothing at all about the differences, then don't even bother to document the log version option at all, IMHO. -Eric From owner-xfs@oss.sgi.com Mon Mar 10 18:55:21 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Mar 2008 18:55:28 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_43 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m2B1tJCd007297 for ; Mon, 10 Mar 2008 18:55:21 -0700 X-ASG-Debug-ID: 1205200549-0ae700d20000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from filer.fsl.cs.sunysb.edu (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 6BC16F5CA2E; Mon, 10 Mar 2008 18:55:49 -0700 (PDT) Received: from filer.fsl.cs.sunysb.edu (filer.fsl.cs.sunysb.edu [130.245.126.2]) by cuda.sgi.com with ESMTP id Bs3iFoLYA9xGiHJ8; Mon, 10 Mar 2008 18:55:49 -0700 (PDT) Received: from josefsipek.net (baal.fsl.cs.sunysb.edu [130.245.126.78]) by filer.fsl.cs.sunysb.edu (8.12.11.20060308/8.13.1) with ESMTP id m2B1tlP7001558; Mon, 10 Mar 2008 21:55:47 -0400 Received: by josefsipek.net (Postfix, from userid 1000) id 4827D1C07AC0; Mon, 10 Mar 2008 21:55:49 -0400 (EDT) Date: Mon, 10 Mar 2008 21:55:49 -0400 From: "Josef 'Jeff' Sipek" To: Barry Naujok Cc: "xfs@oss.sgi.com" , xfs-dev X-ASG-Orig-Subj: Re: Final call for review of sb_bad_features2 in userspace Subject: Re: Final call for review of sb_bad_features2 in userspace Message-ID: <20080311015549.GB8870@josefsipek.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.16 (2007-06-11) X-Barracuda-Connect: filer.fsl.cs.sunysb.edu[130.245.126.2] X-Barracuda-Start-Time: 1205200550 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.44471 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14842 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jeffpc@josefsipek.net Precedence: bulk X-list: xfs On Thu, Mar 06, 2008 at 05:02:07PM +1100, Barry Naujok wrote: > I think the attached patch maybe the least offensive for past > kernels, and XFSQA! > > xfs_check and xfs_repair will ignore sb_bad_features2 if it is > zero, and if not, makes sure it's the same as sb_features2. > > mkfs.xfs will set sb_bad_features2 to be the same. Maybe if > we change the behaviour of the kernel mount code with > respects of sb_bad_features2, this can be revisited. > > (An intermediate solution I has was if "xfs_repair -n" is > run AND sb_bad_features is zero, then ignore it to let > xfs_repair continue, otherwise duplicate it, but doing > that requires a golden output change to QA 030 and 033 > unless the kernel mount code is changed... ARGH!) Tiny comments below, but either way, looks good. Josef 'Jeff' Sipek. > =========================================================================== > xfsprogs/db/check.c > =========================================================================== > > --- a/xfsprogs/db/check.c 2008-03-06 16:59:31.000000000 +1100 > +++ b/xfsprogs/db/check.c 2008-03-06 12:32:54.664882390 +1100 > @@ -869,6 +869,15 @@ blockget_f( > mp->m_sb.sb_frextents, frextents); > error++; > } > + if (mp->m_sb.sb_bad_features2 != 0 && > + mp->m_sb.sb_bad_features2 != mp->m_sb.sb_features2) { cosmetic: I'd align the second line to have the sb-> start in the same column :) It looks kinda odd to have the second line as indented as the dbprintf few lines later. > + if (!sflag) > + dbprintf("sb_features2 (0x%x) not same as " > + "sb_bad_features2 (0x%x)\n", > + mp->m_sb.sb_features2, > + mp->m_sb.sb_bad_features2); > + error++; > + } > if ((sbversion & XFS_SB_VERSION_ATTRBIT) && > !XFS_SB_VERSION_HASATTR(&mp->m_sb)) { > if (!sflag) > ... > =========================================================================== > xfsprogs/include/xfs_sb.h > =========================================================================== > > --- a/xfsprogs/include/xfs_sb.h 2008-03-06 16:59:31.000000000 +1100 > +++ b/xfsprogs/include/xfs_sb.h 2008-02-29 17:16:33.814417687 +1100 > @@ -151,6 +151,7 @@ typedef struct xfs_sb > __uint16_t sb_logsectsize; /* sector size for the log, bytes */ > __uint32_t sb_logsunit; /* stripe unit size for the log */ > __uint32_t sb_features2; /* additional feature bits */ > + __uint32_t sb_bad_features2; /* unusable space */ > } xfs_sb_t; __attribute__((packed)) ? ... > =========================================================================== > xfsprogs/repair/phase1.c > =========================================================================== > > --- a/xfsprogs/repair/phase1.c 2008-03-06 16:59:31.000000000 +1100 > +++ b/xfsprogs/repair/phase1.c 2008-03-06 16:57:40.021125442 +1100 > @@ -91,6 +91,20 @@ phase1(xfs_mount_t *mp) > primary_sb_modified = 1; > } > > + /* > + * Check bad_features2 and make sure features2 the same as > + * bad_features (ORing the two together). Leave bad_features2 > + * set so older kernels can still use it and not mount unsupported > + * filesystems when it reads bad_features2. > + */ > + if (sb->sb_bad_features2 != 0 && > + sb->sb_bad_features2 != sb->sb_features2) { Same as the check.c comment above. -- You measure democracy by the freedom it gives its dissidents, not the freedom it gives its assimilated conformists. - Abbie Hoffman From owner-xfs@oss.sgi.com Tue Mar 11 01:08:09 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 11 Mar 2008 01:08:28 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00,MIME_8BIT_HEADER autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m2B885HK002377 for ; Tue, 11 Mar 2008 01:08:09 -0700 X-ASG-Debug-ID: 1205222914-7e6602dd0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from wx-out-0506.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 76506682E6F for ; Tue, 11 Mar 2008 01:08:35 -0700 (PDT) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.236]) by cuda.sgi.com with ESMTP id lpJKIxI3l7zoErKD for ; Tue, 11 Mar 2008 01:08:35 -0700 (PDT) Received: by wx-out-0506.google.com with SMTP id s9so2307964wxc.32 for ; Tue, 11 Mar 2008 01:08:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=p/GJsOP9/MwKhHlqJsy4MOflozfd3v73UmbG6v3+rto=; b=pHW+wwDQvUhnNIqyIbVDZqukX29GXkrQt0BvYarqSfU0CHn9jt+wSAn49ejTadlKccpdMjXJkl2WdiK2ZG4CiRka7Rra9TK+eBNbfRt0qn2kYb4QcEstvsXPoEosHUa1fbaP0JbsE5jdjNQ+coTbctuaUS4iQDmUyBCAGZxjUW8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=fFgF0tu1sM6ZeBBC+zOVIyUsl2pEptiUOZ3T1zH6yMX53kKRHFTgW0oe2WkaAH7eZn2ei3roSiU95GNzWsEd62pQZKMB03D1SPcuiIRDrCAAum2vpW0H3q5D2qpBLP+foUsDSv4iRqQWRGuWMFxe0ixaMRvYgEF+6e9ZRtvSCMw= Received: by 10.150.157.11 with SMTP id f11mr3452704ybe.108.1205222914353; Tue, 11 Mar 2008 01:08:34 -0700 (PDT) Received: by 10.150.96.5 with HTTP; Tue, 11 Mar 2008 01:08:31 -0700 (PDT) Message-ID: <1a4a774c0803110108u3f01813fs7f9540f886be055@mail.gmail.com> Date: Tue, 11 Mar 2008 09:08:31 +0100 From: "=?ISO-8859-1?Q?Christian_R=F8snes?=" To: "David Chinner" X-ASG-Orig-Subj: Re: XFS internal error xfs_trans_cancel at line 1150 of file fs/xfs/xfs_trans.c Subject: Re: XFS internal error xfs_trans_cancel at line 1150 of file fs/xfs/xfs_trans.c Cc: xfs@oss.sgi.com In-Reply-To: <20080310222135.GZ155407@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1a4a774c0802130251h657a52f7lb97942e7afdf6e3f@mail.gmail.com> <20080213214551.GR155407@sgi.com> <1a4a774c0803050553h7f6294cfq41c38f34ea92ceae@mail.gmail.com> <1a4a774c0803060310w2642224w690ac8fa13f96ec@mail.gmail.com> <1a4a774c0803070319j1eb8790ek3daae4a16b3e6256@mail.gmail.com> <20080310000809.GU155407@sgi.com> <1a4a774c0803100302y17530814wee7522aa0dfd7668@mail.gmail.com> <1a4a774c0803100134k258e1bcfma95e7969bc44b2af@mail.gmail.com> <20080310222135.GZ155407@sgi.com> X-Barracuda-Connect: wx-out-0506.google.com[66.249.82.236] X-Barracuda-Start-Time: 1205222916 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.44496 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14843 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: christian.rosnes@gmail.com Precedence: bulk X-list: xfs On Mon, Mar 10, 2008 at 11:21 PM, David Chinner wrote: > You've got a filesystem with stripe alignment set. In xfs_ialloc_ag_alloc() > we attempt inode allocation by the following rules: > > 1. a) If we haven't previously allocated inodes, fall through to 2. > b) If we have previously allocated inode, attempt to allocate next > to the last inode chunk. > > 2. If we do not have an extent now: > a) if we have stripe alignment, try with alignment > b) if we don't have stripe alignment try cluster alignment > > 3. If we do not have an extent now: > a) if we have stripe alignment, try with cluster alignment > b) no stripe alignment, turn off alignment. > > 4. If we do not have an extent now: FAIL. > > Note the case missing from the stripe alignment fallback path - it does not > try without alignment at all. That means if all those extents large enough > that we found above are not correctly aligned, then we will still fail > to allocate an inode chunk. if all the AGs are like this, then we'll > fail to allocate at all and fall out of xfs_dialloc() through the last > fragment I quoted above. > > As to the shutdown that this triggers - the attempt to allocate dirties > the AGFL and the AGF by moving free blocks into the free list for btree > splits and cancelling a dirty transaction results in a shutdown. > > Now, to test this theory. ;) Luckily, it's easy to test. mount the > filesystem with the mount option "noalign" and rerun the mkdir test. > If it is an alignment problem, then setting noalign will prevent > this ENOSPC and shutdown as the filesystem will be able to allocate > more inodes. > > Can you test this for me, Christian? Thanks. Unfortunately noalign didn't solve my problem: # mount | grep /data /dev/sdb1 on /data type xfs (rw,noatime,noalign,logbufs=8,nobarrier) # mkdir /data/test results in: Filesystem "sdb1": XFS internal error xfs_trans_cancel at line 1163 of file fs/xfs/xfs_trans.c. Caller 0xc021a010 Pid: 17889, comm: mkdir Not tainted 2.6.24.3FC #7 [] xfs_trans_cancel+0x5d/0xe6 [] xfs_mkdir+0x45a/0x493 [] xfs_mkdir+0x45a/0x493 [] xfs_acl_vhasacl_default+0x33/0x44 [] xfs_vn_mknod+0x165/0x243 [] xfs_access+0x2f/0x35 [] xfs_vn_mkdir+0x12/0x14 [] vfs_mkdir+0xa3/0xe2 [] sys_mkdirat+0x8a/0xc3 [] sys_mkdir+0x1f/0x23 [] syscall_call+0x7/0xb [] atm_reset_addr+0xd/0x83 ======================= xfs_force_shutdown(sdb1,0x8) called from line 1164 of file fs/xfs/xfs_trans.c. Return address = 0xc0212690 Filesystem "sdb1": Corruption of in-memory data detected. Shutting down filesystem: sdb1 Please umount the filesystem, and rectify the problem(s) I'll try to add some printk statements to the codepaths you mentioned, and see where it leads. Christian From owner-xfs@oss.sgi.com Tue Mar 11 01:30:14 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 11 Mar 2008 01:30:32 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_55, J_CHICKENPOX_62 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m2B8UAiU005114 for ; Tue, 11 Mar 2008 01:30:14 -0700 X-ASG-Debug-ID: 1205224240-0c5000320000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.valinux.co.jp (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id A4AFFF5F01E for ; Tue, 11 Mar 2008 01:30:40 -0700 (PDT) Received: from mail.valinux.co.jp (fms-01.valinux.co.jp [210.128.90.1]) by cuda.sgi.com with ESMTP id RyMHVzjbj2qpDATR for ; Tue, 11 Mar 2008 01:30:40 -0700 (PDT) Received: from dhcp032.local.valinux.co.jp (vagw.valinux.co.jp [210.128.90.14]) by mail.valinux.co.jp (Postfix) with ESMTP id 6D2372DC8B4; Tue, 11 Mar 2008 17:30:38 +0900 (JST) Date: Tue, 11 Mar 2008 17:30:38 +0900 From: IWAMOTO Toshihiro To: David Chinner Cc: IWAMOTO Toshihiro , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH] prototype file data inode inlining Subject: Re: [PATCH] prototype file data inode inlining In-Reply-To: <20080308002124.GN155407@sgi.com> References: <20080307093411.4B1912DC9B2@mail.valinux.co.jp> <20080308002124.GN155407@sgi.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.1 (x86_64-pc-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20080311083038.6D2372DC8B4@mail.valinux.co.jp> X-Barracuda-Connect: fms-01.valinux.co.jp[210.128.90.1] X-Barracuda-Start-Time: 1205224241 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.44497 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14844 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: iwamoto@valinux.co.jp Precedence: bulk X-list: xfs At Sat, 8 Mar 2008 11:21:24 +1100, David Chinner wrote: > Interesting. I'm not going to comment on the code, just the overall > design and implementation. Thanks for comments. > Problems: > - local -> extent conversion occurs at copy-in time, not writeback > time, so using the normal read/write paths through ->get_blocks() > will fail here in xfs_bmapi(): > > 4793 if (XFS_IFORK_FORMAT(ip, whichfork) == XFS_DINODE_FMT_LOCAL) { > 4794 >>>>>>>> ASSERT(wr && tp); > 4795 if ((error = xfs_bmap_local_to_extents(tp, ip, > 4796 firstblock, total, &logflags, whichfork))) > 4797 goto error0; > 4798 } > > because on a normal read or write (delayed allocation) we > are not doing allocation and hence do not have an open > transaction the first time we come through here. Just > avoiding this conversion and returning zero maps if we are > not writing will not help in the delayed allocation case. > > > I note that you hacked around this by special casing the inline > format ->get_blocks() callout to copy the data into the page and > marking it mapped and uptodate. I think this is the wrong approach > and is not the right layer at which to make this distinction - the special > casing needs to be done at higher layers, not in the block mapping > function. > > I think for inline data, we'd do best to special case this as high > up the read/write paths as possible. e.g. for read() type operations > intercept in xfs_read() and just do what we need to do there for > populating the single page cache page. For write, we should let it > go through the normal delayed allocation mechanisms, only converting > to local format during ->writepage() if there's a single block > extent and it fits in the data fork. This also handles the truncate > case nicely. I was vaguely aware of layering violation, but took my dirty&quick approach as the largest concern at that time was whether file inlining gives enough performance gain. With your suggestion, I would be able to implement better. Unfortunately, I lack time to do so. > > Some random notes and the patch itself follows. > > > > Inlined file data are written from xfs_page_state_convert(). > > The xfs_trans related operations in that function is to get inode > > written on disk and isn't for crash consistency. > > Which is the exact opposite of what they are supposed to be used for. > Given that the next thing that happens after data write in the writeback path > is ->write_inode(), forcing the inode into the log for pure data changes > is unnecessary. We just need to format the data into the inode during > data writeback. It seemed that setting the XFS_ILOG_DDATA bit in ip->i_itemp->ili_format.ilf_fields was necessary for xfs_iflush_fork, and I wasn't aware of other solutions. > > xfs_bmap_local_to_extents() has been modified to work with file data, > > but logging isn't implemented. A machine crash can cause data > > corruption. > > There are two ways to do inline->extent safely from a crash recovery > perspective. > > Method 1: Use an Intent/Done transaction pair > Method 2: Log the data Thanks for explanation. It doesn't sound so complicated as I've imagined. -- IWAMOTO Toshihiro From owner-xfs@oss.sgi.com Tue Mar 11 02:33:50 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 11 Mar 2008 02:34:07 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_43, MIME_8BIT_HEADER autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m2B9Xiaw015696 for ; Tue, 11 Mar 2008 02:33:48 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA00786; Tue, 11 Mar 2008 20:34:09 +1100 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 m2B9Y8LF92990430; Tue, 11 Mar 2008 20:34:09 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id m2B9Y6Fr93003109; Tue, 11 Mar 2008 20:34:06 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Tue, 11 Mar 2008 20:34:06 +1100 From: David Chinner To: Christian =?iso-8859-1?Q?R=F8snes?= Cc: xfs@oss.sgi.com Subject: Re: XFS internal error xfs_trans_cancel at line 1150 of file fs/xfs/xfs_trans.c Message-ID: <20080311093406.GN155407@sgi.com> References: <1a4a774c0802130251h657a52f7lb97942e7afdf6e3f@mail.gmail.com> <20080213214551.GR155407@sgi.com> <1a4a774c0803050553h7f6294cfq41c38f34ea92ceae@mail.gmail.com> <1a4a774c0803060310w2642224w690ac8fa13f96ec@mail.gmail.com> <1a4a774c0803070319j1eb8790ek3daae4a16b3e6256@mail.gmail.com> <20080310000809.GU155407@sgi.com> <1a4a774c0803100302y17530814wee7522aa0dfd7668@mail.gmail.com> <1a4a774c0803100134k258e1bcfma95e7969bc44b2af@mail.gmail.com> <20080310222135.GZ155407@sgi.com> <1a4a774c0803110108u3f01813fs7f9540f886be055@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1a4a774c0803110108u3f01813fs7f9540f886be055@mail.gmail.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14845 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Tue, Mar 11, 2008 at 09:08:31AM +0100, Christian Røsnes wrote: > On Mon, Mar 10, 2008 at 11:21 PM, David Chinner wrote: > > You've got a filesystem with stripe alignment set. In xfs_ialloc_ag_alloc() > > we attempt inode allocation by the following rules: > > > > 1. a) If we haven't previously allocated inodes, fall through to 2. > > b) If we have previously allocated inode, attempt to allocate next > > to the last inode chunk. > > > > 2. If we do not have an extent now: > > a) if we have stripe alignment, try with alignment > > b) if we don't have stripe alignment try cluster alignment > > > > 3. If we do not have an extent now: > > a) if we have stripe alignment, try with cluster alignment > > b) no stripe alignment, turn off alignment. > > > > 4. If we do not have an extent now: FAIL. > > > > Note the case missing from the stripe alignment fallback path - it does not > > try without alignment at all. That means if all those extents large enough > > that we found above are not correctly aligned, then we will still fail > > to allocate an inode chunk. if all the AGs are like this, then we'll > > fail to allocate at all and fall out of xfs_dialloc() through the last > > fragment I quoted above. > > > > As to the shutdown that this triggers - the attempt to allocate dirties > > the AGFL and the AGF by moving free blocks into the free list for btree > > splits and cancelling a dirty transaction results in a shutdown. > > > > Now, to test this theory. ;) Luckily, it's easy to test. mount the > > filesystem with the mount option "noalign" and rerun the mkdir test. > > If it is an alignment problem, then setting noalign will prevent > > this ENOSPC and shutdown as the filesystem will be able to allocate > > more inodes. > > > > Can you test this for me, Christian? > > Thanks. Unfortunately noalign didn't solve my problem: Ok, reading the code a bit further, I've mixed up m_sinoalign, m_sinoalignmt and the noalign mount option. The noalign mount option turns off m_sinoalign, but it does not turn off inode cluster alignment, hence we can't fall back to an unaligned allocation. So the above theory still holds, just the test case was broken. Unfortunately, further investigation indicates that inodes are always allocated aligned; I expect that I could count the number of linux XFS filesystems not using inode allocation alignment because mkfs.xfs has set this as the default since it was added in mid-1996. The problem with unaligned inode allocation is the lookup case (xfs_dilocate()) in that it requires btree lookups to convert the inode number to a block number as you don't know where in the chunk the inode exists just by looking at the inode number. With aligned allocations, the block number can be derived directly from the inode number because we know how the inode chunks are aligned. IOWs, if we allow an unaligned inode chunk allocation to occur, we have to strip the "aligned inode allocation" feature bit from the filesystem and the related state and use the slow, btree based lookup path forever more. That involves I/O instead of a simple mask operation.... Hence I'm inclined to leave the allocation alignment as it stands and work out how to prevent the shutdown (a difficult issue in itself). > I'll try to add some printk statements to the codepaths you mentioned, > and see where it leads. Definitely worth confirming this is where the error is coming from. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Tue Mar 11 02:59:25 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 11 Mar 2008 02:59:32 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_00, SUBJECT_FUZZY_TION autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m2B9xNPl018547 for ; Tue, 11 Mar 2008 02:59:25 -0700 X-ASG-Debug-ID: 1205229593-40bd00960000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.lichtvoll.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 34DB4F60284 for ; Tue, 11 Mar 2008 02:59:53 -0700 (PDT) Received: from mail.lichtvoll.de (mondschein.lichtvoll.de [194.150.191.11]) by cuda.sgi.com with ESMTP id 036j3u51AyA9OyHO for ; Tue, 11 Mar 2008 02:59:53 -0700 (PDT) Received: from nb27steigerwald.qs.de (unknown [212.204.70.254]) by mail.lichtvoll.de (Postfix) with ESMTP id E0FDC5ADD6 for ; Tue, 11 Mar 2008 10:59:50 +0100 (CET) From: Martin Steigerwald To: linux-xfs@oss.sgi.com X-ASG-Orig-Subj: Re: disappearing xfs partition Subject: Re: disappearing xfs partition Date: Tue, 11 Mar 2008 10:59:50 +0100 User-Agent: KMail/1.9.9 References: (sfid-20080304_090400_023531_C318561D) In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Message-Id: <200803111059.50596.Martin@lichtvoll.de> X-Barracuda-Connect: mondschein.lichtvoll.de[194.150.191.11] X-Barracuda-Start-Time: 1205229594 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.44503 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id m2B9xPPl018552 X-archive-position: 14846 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Martin@lichtvoll.de Precedence: bulk X-list: xfs Am Dienstag 04 März 2008 schrieb Jeff Breidenbach: > Following up and close out the topic, I got this comment from Eric. > > >So parted has this bad habit of making partition tables that cannot > >actually be read from the disk, and poking the supposedly values > >directly into the kernel. Then things work fine until reboot, at > > which time the partition table cannot be properly read. Usually > > this turns into a truncated size due to an overflow.... > > I'd been using cfdisk and not parted, but that's apparently what > happened. Rewriting the partition table with cfdisk fixed everything > and allowed the partition to mount. At least for this boot. Hi Jan, Its always a good idea to check whether the kernel reread the partition table after partitioning with cat /proc/partitions If it doesn't have you can tell the kernel to do it manually: blockdev --rereadpt /dev/sde If that tells you something about device is busy or so you'd need to unmount partitions on it or reboot. Ciao, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 From owner-xfs@oss.sgi.com Tue Mar 11 04:26:05 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 11 Mar 2008 04:26:24 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,MIME_8BIT_HEADER autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m2BBQ4ab003211 for ; Tue, 11 Mar 2008 04:26:05 -0700 X-ASG-Debug-ID: 1205234794-75ba003f0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from wr-out-0506.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 2E4C6683BA1 for ; Tue, 11 Mar 2008 04:26:34 -0700 (PDT) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.236]) by cuda.sgi.com with ESMTP id qBQkO3XuZUGMXVi4 for ; Tue, 11 Mar 2008 04:26:34 -0700 (PDT) Received: by wr-out-0506.google.com with SMTP id c53so1273787wra.20 for ; Tue, 11 Mar 2008 04:26:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=qbza4PIVKxFug4NBBDzwJtDecFtxbdsSA4HSQglXtpQ=; b=SkHIJ3HK7z3BbiWR+ENkFEljY348kMaoUk3Tpd9D8dMBxE6IVjRdwV1794ME7uH08F1zfSQpiY7E220cw7dSrdmVa0W/GOJSy/BSCS3jEnnWq8/IyjKk/Ojay6F5x9clWleS/aaKdCmS8FInk+CCQFXkW0x54rIUh6A0x8nSLug= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=HDHnCJj70iePyJfKFp5Taq8dY343FcMcfY7k5kcjIQ0ZO+72R8MZB7R5uh8k1u4MOyKMH8wULDmx4vsHFKpqu2BX10U2OL047SfylEAPpGLKdfbnH/3NuYLi51CEDsq9kENQzmIKO+zOPYWl+076bkqD9u/w5+fdYaHxvzuR23s= Received: by 10.151.47.7 with SMTP id z7mr3574839ybj.103.1205234369452; Tue, 11 Mar 2008 04:19:29 -0700 (PDT) Received: by 10.150.96.5 with HTTP; Tue, 11 Mar 2008 04:19:29 -0700 (PDT) Message-ID: <1a4a774c0803110419n645da456leaedd98593300726@mail.gmail.com> Date: Tue, 11 Mar 2008 12:19:29 +0100 From: "=?ISO-8859-1?Q?Christian_R=F8snes?=" To: "David Chinner" X-ASG-Orig-Subj: Re: XFS internal error xfs_trans_cancel at line 1150 of file fs/xfs/xfs_trans.c Subject: Re: XFS internal error xfs_trans_cancel at line 1150 of file fs/xfs/xfs_trans.c Cc: xfs@oss.sgi.com In-Reply-To: <20080311093406.GN155407@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <1a4a774c0802130251h657a52f7lb97942e7afdf6e3f@mail.gmail.com> <1a4a774c0803050553h7f6294cfq41c38f34ea92ceae@mail.gmail.com> <1a4a774c0803060310w2642224w690ac8fa13f96ec@mail.gmail.com> <1a4a774c0803070319j1eb8790ek3daae4a16b3e6256@mail.gmail.com> <20080310000809.GU155407@sgi.com> <1a4a774c0803100302y17530814wee7522aa0dfd7668@mail.gmail.com> <1a4a774c0803100134k258e1bcfma95e7969bc44b2af@mail.gmail.com> <20080310222135.GZ155407@sgi.com> <1a4a774c0803110108u3f01813fs7f9540f886be055@mail.gmail.com> <20080311093406.GN155407@sgi.com> X-Barracuda-Connect: wr-out-0506.google.com[64.233.184.236] X-Barracuda-Start-Time: 1205234795 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.44509 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id m2BBQ6ab003213 X-archive-position: 14847 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: christian.rosnes@gmail.com Precedence: bulk X-list: xfs On Tue, Mar 11, 2008 at 10:34 AM, David Chinner wrote: > > On Tue, Mar 11, 2008 at 09:08:31AM +0100, Christian Røsnes wrote: > > I'll try to add some printk statements to the codepaths you mentioned, > > and see where it leads. > > Definitely worth confirming this is where the error is coming from. > if (tagno == agno) { printk("XFS: xfs_dialloc:0021\n"); *inop = NULLFSINO; return noroom ? ENOSPC : 0; } seems to be what triggers this inside xfs_dialloc. Here a trace which give some indication to the codepath taken inside xfs_dialloc (xfs_ialloc.c): mount: /dev/sdb1 on /data type xfs (rw,noatime,logbufs=8,nobarrier) # mkdir /data/test mkdir: cannot create directory `/data/test': No space left on device Mar 11 11:47:00 linux kernel: XFS: xfs_dialloc:0001 Mar 11 11:47:00 linux kernel: XFS: xfs_dialloc:0002 Mar 11 11:47:00 linux kernel: XFS: xfs_dialloc:0003 Mar 11 11:47:00 linux kernel: XFS: xfs_dialloc:0005 Mar 11 11:47:00 linux kernel: XFS: xfs_dialloc:0006 Mar 11 11:47:00 linux kernel: XFS: xfs_dialloc:0010 Mar 11 11:47:00 linux kernel: XFS: xfs_dialloc:0012 Mar 11 11:47:00 linux kernel: XFS: xfs_dialloc:0013 Mar 11 11:47:00 linux kernel: XFS: xfs_dialloc:0014 Mar 11 11:47:00 linux kernel: XFS: xfs_dialloc:0018 Mar 11 11:47:00 linux kernel: XFS: xfs_dialloc:0020 Mar 11 11:47:00 linux kernel: XFS: xfs_dialloc:0013 Mar 11 11:47:00 linux kernel: XFS: xfs_dialloc:0014 Mar 11 11:47:00 linux kernel: XFS: xfs_dialloc:0018 Mar 11 11:47:00 linux kernel: XFS: xfs_dialloc:0020 Mar 11 11:47:00 linux kernel: XFS: xfs_dialloc:0013 Mar 11 11:47:00 linux kernel: XFS: xfs_dialloc:0014 Mar 11 11:47:00 linux kernel: XFS: xfs_dialloc:0018 Mar 11 11:47:00 linux kernel: XFS: xfs_dialloc:0020 Mar 11 11:47:00 linux kernel: XFS: xfs_dialloc:0013 Mar 11 11:47:00 linux kernel: XFS: xfs_dialloc:0014 Mar 11 11:47:00 linux kernel: XFS: xfs_dialloc:0018 Mar 11 11:47:00 linux kernel: XFS: xfs_dialloc:0020 Mar 11 11:47:00 linux kernel: XFS: xfs_dialloc:0013 Mar 11 11:47:00 linux kernel: XFS: xfs_dialloc:0014 Mar 11 11:47:00 linux kernel: XFS: xfs_dialloc:0018 Mar 11 11:47:00 linux kernel: XFS: xfs_dialloc:0020 Mar 11 11:47:00 linux kernel: XFS: xfs_dialloc:0013 Mar 11 11:47:00 linux kernel: XFS: xfs_dialloc:0014 Mar 11 11:47:00 linux kernel: XFS: xfs_dialloc:0018 Mar 11 11:47:00 linux kernel: XFS: xfs_dialloc:0020 Mar 11 11:47:00 linux kernel: XFS: xfs_dialloc:0013 Mar 11 11:47:00 linux kernel: XFS: xfs_dialloc:0014 Mar 11 11:47:00 linux kernel: XFS: xfs_dialloc:0018 Mar 11 11:47:00 linux kernel: XFS: xfs_dialloc:0020 Mar 11 11:47:00 linux kernel: XFS: xfs_dialloc:0013 Mar 11 11:47:00 linux kernel: XFS: xfs_dialloc:0014 Mar 11 11:47:00 linux kernel: XFS: xfs_dialloc:0018 Mar 11 11:47:00 linux kernel: XFS: xfs_dialloc:0020 Mar 11 11:47:00 linux kernel: XFS: xfs_dialloc:0013 Mar 11 11:47:00 linux kernel: XFS: xfs_dialloc:0014 Mar 11 11:47:00 linux kernel: XFS: xfs_dialloc:0018 Mar 11 11:47:00 linux kernel: XFS: xfs_dialloc:0020 Mar 11 11:47:00 linux kernel: XFS: xfs_dialloc:0013 Mar 11 11:47:00 linux kernel: XFS: xfs_dialloc:0014 Mar 11 11:47:00 linux kernel: XFS: xfs_dialloc:0018 Mar 11 11:47:00 linux kernel: XFS: xfs_dialloc:0020 Mar 11 11:47:00 linux kernel: XFS: xfs_dialloc:0013 Mar 11 11:47:00 linux kernel: XFS: xfs_dialloc:0014 Mar 11 11:47:00 linux kernel: XFS: xfs_dialloc:0018 Mar 11 11:47:00 linux kernel: XFS: xfs_dialloc:0020 Mar 11 11:47:00 linux kernel: XFS: xfs_dialloc:0013 Mar 11 11:47:00 linux kernel: XFS: xfs_dialloc:0014 Mar 11 11:47:00 linux kernel: XFS: xfs_dialloc:0018 Mar 11 11:47:00 linux kernel: XFS: xfs_dialloc:0020 Mar 11 11:47:00 linux kernel: XFS: xfs_dialloc:0013 Mar 11 11:47:00 linux kernel: XFS: xfs_dialloc:0014 Mar 11 11:47:00 linux kernel: XFS: xfs_dialloc:0018 Mar 11 11:47:00 linux kernel: XFS: xfs_dialloc:0020 Mar 11 11:47:00 linux kernel: XFS: xfs_dialloc:0013 Mar 11 11:47:00 linux kernel: XFS: xfs_dialloc:0014 Mar 11 11:47:00 linux kernel: XFS: xfs_dialloc:0018 Mar 11 11:47:00 linux kernel: XFS: xfs_dialloc:0020 Mar 11 11:47:00 linux kernel: XFS: xfs_dialloc:0013 Mar 11 11:47:00 linux kernel: XFS: xfs_dialloc:0014 Mar 11 11:47:00 linux kernel: XFS: xfs_dialloc:0018 Mar 11 11:47:00 linux kernel: XFS: xfs_dialloc:0020 Mar 11 11:47:00 linux kernel: XFS: xfs_dialloc:0013 Mar 11 11:47:00 linux kernel: XFS: xfs_dialloc:0014 Mar 11 11:47:00 linux kernel: XFS: xfs_dialloc:0018 Mar 11 11:47:00 linux kernel: XFS: xfs_dialloc:0020 Mar 11 11:47:00 linux kernel: XFS: xfs_dialloc:0021 Mar 11 11:47:00 linux kernel: Filesystem "sdb1": XFS internal error xfs_trans_cancel at line 1163 of file fs/xfs/xfs_trans.c. Caller 0xc021a390 Mar 11 11:47:00 linux kernel: Pid: 5598, comm: mkdir Not tainted 2.6.24.3FC #9 Mar 11 11:47:00 linux kernel: [] xfs_trans_cancel+0x5d/0xe6 Mar 11 11:47:00 linux kernel: [] xfs_mkdir+0x45a/0x493 Mar 11 11:47:00 linux kernel: [] xfs_mkdir+0x45a/0x493 Mar 11 11:47:00 linux kernel: [] xfs_acl_vhasacl_default+0x33/0x44 Mar 11 11:47:00 linux kernel: [] xfs_vn_mknod+0x165/0x243 Mar 11 11:47:00 linux kernel: [] xfs_access+0x2f/0x35 Mar 11 11:47:00 linux kernel: [] xfs_vn_mkdir+0x12/0x14 Mar 11 11:47:00 linux kernel: [] vfs_mkdir+0xa3/0xe2 Mar 11 11:47:00 linux kernel: [] sys_mkdirat+0x8a/0xc3 Mar 11 11:47:00 linux kernel: [] sys_mkdir+0x1f/0x23 Mar 11 11:47:00 linux kernel: [] syscall_call+0x7/0xb Mar 11 11:47:00 linux kernel: [] svc_proc_register+0x3c/0x4b Mar 11 11:47:00 linux kernel: ======================= Mar 11 11:47:00 linux kernel: xfs_force_shutdown(sdb1,0x8) called from line 1164 of file fs/xfs/xfs_trans.c. Return address = 0xc0212a10 Mar 11 11:47:00 linux kernel: Filesystem "sdb1": Corruption of in-memory data detected. Shutting down filesystem: sdb1 Mar 11 11:47:00 linux kernel: Please umount the filesystem, and rectify the problem(s) instrumented code: int xfs_dialloc( xfs_trans_t *tp, /* transaction pointer */ xfs_ino_t parent, /* parent inode (directory) */ mode_t mode, /* mode bits for new inode */ int okalloc, /* ok to allocate more space */ xfs_buf_t **IO_agbp, /* in/out ag header's buffer */ boolean_t *alloc_done, /* true if we needed to replenish inode freelist */ xfs_ino_t *inop) /* inode number allocated */ { xfs_agnumber_t agcount; /* number of allocation groups */ xfs_buf_t *agbp; /* allocation group header's buffer */ xfs_agnumber_t agno; /* allocation group number */ xfs_agi_t *agi; /* allocation group header structure */ xfs_btree_cur_t *cur; /* inode allocation btree cursor */ int error; /* error return value */ int i; /* result code */ int ialloced; /* inode allocation status */ int noroom = 0; /* no space for inode blk allocation */ xfs_ino_t ino; /* fs-relative inode to be returned */ /* REFERENCED */ int j; /* result code */ xfs_mount_t *mp; /* file system mount structure */ int offset; /* index of inode in chunk */ xfs_agino_t pagino; /* parent's a.g. relative inode # */ xfs_agnumber_t pagno; /* parent's allocation group number */ xfs_inobt_rec_incore_t rec; /* inode allocation record */ xfs_agnumber_t tagno; /* testing allocation group number */ xfs_btree_cur_t *tcur; /* temp cursor */ xfs_inobt_rec_incore_t trec; /* temp inode allocation record */ printk("XFS: xfs_dialloc:0001\n"); if (*IO_agbp == NULL) { printk("XFS: xfs_dialloc:0002\n"); /* * We do not have an agbp, so select an initial allocation * group for inode allocation. */ agbp = xfs_ialloc_ag_select(tp, parent, mode, okalloc); printk("XFS: xfs_dialloc:0003\n"); /* * Couldn't find an allocation group satisfying the * criteria, give up. */ if (!agbp) { printk("XFS: xfs_dialloc:0004\n"); *inop = NULLFSINO; return 0; } printk("XFS: xfs_dialloc:0005\n"); agi = XFS_BUF_TO_AGI(agbp); ASSERT(be32_to_cpu(agi->agi_magicnum) == XFS_AGI_MAGIC); printk("XFS: xfs_dialloc:0006\n"); } else { printk("XFS: xfs_dialloc:0007\n"); /* * Continue where we left off before. In this case, we * know that the allocation group has free inodes. */ agbp = *IO_agbp; agi = XFS_BUF_TO_AGI(agbp); ASSERT(be32_to_cpu(agi->agi_magicnum) == XFS_AGI_MAGIC); printk("XFS: xfs_dialloc:0008\n"); ASSERT(be32_to_cpu(agi->agi_freecount) > 0); printk("XFS: xfs_dialloc:0009\n"); } printk("XFS: xfs_dialloc:0010\n"); mp = tp->t_mountp; agcount = mp->m_sb.sb_agcount; agno = be32_to_cpu(agi->agi_seqno); tagno = agno; pagno = XFS_INO_TO_AGNO(mp, parent); pagino = XFS_INO_TO_AGINO(mp, parent); /* * If we have already hit the ceiling of inode blocks then clear * okalloc so we scan all available agi structures for a free * inode. */ if (mp->m_maxicount && mp->m_sb.sb_icount + XFS_IALLOC_INODES(mp) > mp->m_maxicount) { printk("XFS: xfs_dialloc:0011\n"); noroom = 1; okalloc = 0; } /* * Loop until we find an allocation group that either has free inodes * or in which we can allocate some inodes. Iterate through the * allocation groups upward, wrapping at the end. */ printk("XFS: xfs_dialloc:0012\n"); *alloc_done = B_FALSE; while (!agi->agi_freecount) { printk("XFS: xfs_dialloc:0013\n"); /* * Don't do anything if we're not supposed to allocate * any blocks, just go on to the next ag. */ if (okalloc) { printk("XFS: xfs_dialloc:0014\n"); /* * Try to allocate some new inodes in the allocation * group. */ if ((error = xfs_ialloc_ag_alloc(tp, agbp, &ialloced))) { printk("XFS: xfs_dialloc:0015\n"); xfs_trans_brelse(tp, agbp); if (error == ENOSPC) { printk("XFS: xfs_dialloc:0016\n"); *inop = NULLFSINO; return 0; } else { printk("XFS: xfs_dialloc:0017\n"); return error; } } printk("XFS: xfs_dialloc:0018\n"); if (ialloced) { /* * We successfully allocated some inodes, return * the current context to the caller so that it * can commit the current transaction and call * us again where we left off. */ printk("XFS: xfs_dialloc:0019\n"); ASSERT(be32_to_cpu(agi->agi_freecount) > 0); *alloc_done = B_TRUE; *IO_agbp = agbp; *inop = NULLFSINO; return 0; } } printk("XFS: xfs_dialloc:0020\n"); /* * If it failed, give up on this ag. */ xfs_trans_brelse(tp, agbp); /* * Go on to the next ag: get its ag header. */ nextag: if (++tagno == agcount) tagno = 0; if (tagno == agno) { printk("XFS: xfs_dialloc:0021\n"); *inop = NULLFSINO; return noroom ? ENOSPC : 0; } down_read(&mp->m_peraglock); if (mp->m_perag[tagno].pagi_inodeok == 0) { up_read(&mp->m_peraglock); printk("XFS: xfs_dialloc:0022\n"); goto nextag; } error = xfs_ialloc_read_agi(mp, tp, tagno, &agbp); up_read(&mp->m_peraglock); if (error) { printk("XFS: xfs_dialloc:0023\n"); goto nextag; } agi = XFS_BUF_TO_AGI(agbp); ASSERT(be32_to_cpu(agi->agi_magicnum) == XFS_AGI_MAGIC); } /* * Here with an allocation group that has a free inode. * Reset agno since we may have chosen a new ag in the * loop above. */ printk("XFS: xfs_dialloc:0024\n"); agno = tagno; *IO_agbp = NULL; cur = xfs_btree_init_cursor(mp, tp, agbp, be32_to_cpu(agi->agi_seqno), XFS_BTNUM_INO, (xfs_inode_t *)0, 0); ... Christian From owner-xfs@oss.sgi.com Tue Mar 11 05:20:47 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 11 Mar 2008 05:21:05 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,MIME_8BIT_HEADER autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m2BCKgDN010466 for ; Tue, 11 Mar 2008 05:20:46 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id XAA05226; Tue, 11 Mar 2008 23:21:07 +1100 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 m2BCL6LF93166947; Tue, 11 Mar 2008 23:21:07 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id m2BCL3X093080997; Tue, 11 Mar 2008 23:21:03 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Tue, 11 Mar 2008 23:21:03 +1100 From: David Chinner To: Christian =?iso-8859-1?Q?R=F8snes?= Cc: xfs@oss.sgi.com Subject: Re: XFS internal error xfs_trans_cancel at line 1150 of file fs/xfs/xfs_trans.c Message-ID: <20080311122103.GP155407@sgi.com> References: <1a4a774c0803050553h7f6294cfq41c38f34ea92ceae@mail.gmail.com> <1a4a774c0803060310w2642224w690ac8fa13f96ec@mail.gmail.com> <1a4a774c0803070319j1eb8790ek3daae4a16b3e6256@mail.gmail.com> <20080310000809.GU155407@sgi.com> <1a4a774c0803100302y17530814wee7522aa0dfd7668@mail.gmail.com> <1a4a774c0803100134k258e1bcfma95e7969bc44b2af@mail.gmail.com> <20080310222135.GZ155407@sgi.com> <1a4a774c0803110108u3f01813fs7f9540f886be055@mail.gmail.com> <20080311093406.GN155407@sgi.com> <1a4a774c0803110419n645da456leaedd98593300726@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1a4a774c0803110419n645da456leaedd98593300726@mail.gmail.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14848 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Tue, Mar 11, 2008 at 12:19:29PM +0100, Christian Røsnes wrote: > On Tue, Mar 11, 2008 at 10:34 AM, David Chinner wrote: > > > > On Tue, Mar 11, 2008 at 09:08:31AM +0100, Christian Røsnes wrote: > > > > I'll try to add some printk statements to the codepaths you mentioned, > > > and see where it leads. > > > > Definitely worth confirming this is where the error is coming from. > > > > if (tagno == agno) { > printk("XFS: xfs_dialloc:0021\n"); > *inop = NULLFSINO; > return noroom ? ENOSPC : 0; > } > > seems to be what triggers this inside xfs_dialloc. > > Here a trace which give some indication to the codepath taken inside > xfs_dialloc (xfs_ialloc.c): Yup, that's trying to allocate in each AG and failing. Almost certainly the problem is the described alignment issue. FYI, I'm travelling tomorrow so I won't really get a chance to look at this more until thursday.... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Tue Mar 11 05:29:09 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 11 Mar 2008 05:29:16 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m2BCT4vC012032 for ; Tue, 11 Mar 2008 05:29:07 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id XAA05411; Tue, 11 Mar 2008 23:29:29 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 16346) id 2390C58C4C0F; Tue, 11 Mar 2008 23:29:29 +1100 (EST) To: sgi.bugs.xfs@engr.sgi.com Cc: xfs@oss.sgi.com Subject: PARTIAL TAKE 978682 - Replace custom AIL linked-list code with struct list_head Message-Id: <20080311122929.2390C58C4C0F@chook.melbourne.sgi.com> Date: Tue, 11 Mar 2008 23:29:29 +1100 (EST) From: dgc@sgi.com (David Chinner) X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14849 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Replace custom AIL linked-list code with struct list_head Replace the xfs_ail_entry_t with a struct list_head and clean the surrounding code up. Also fixes a livelock in xfs_trans_first_push_ail() by terminating the loop at the head of the list correctly. Signed-off-by: Josef 'Jeff' Sipek Date: Tue Mar 11 23:29:03 AEDT 2008 Workarea: chook.melbourne.sgi.com:/build/dgc/isms/2.6.x-xfs Inspected by: dgc@sgi.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:30636a fs/xfs/xfs_trans_ail.c - 1.86 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_trans_ail.c.diff?r1=text&tr1=1.86&r2=text&tr2=1.85&f=h - Replace custom AIL linked-list code with struct list_head. Fix livelock in xfs_trans_first_push_ail() by terminating search loop correctly. fs/xfs/xfs_mount.h - 1.260 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_mount.h.diff?r1=text&tr1=1.260&r2=text&tr2=1.259&f=h - Replace custom AIL linked-list code with struct list_head fs/xfs/xfs_trans.h - 1.149 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_trans.h.diff?r1=text&tr1=1.149&r2=text&tr2=1.148&f=h - Replace custom AIL linked-list code with struct list_head From owner-xfs@oss.sgi.com Tue Mar 11 05:33:15 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 11 Mar 2008 05:33:34 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m2BCXApP013030 for ; Tue, 11 Mar 2008 05:33:14 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id XAA05613; Tue, 11 Mar 2008 23:33:37 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 16346) id CBA3158C4C0F; Tue, 11 Mar 2008 23:33:37 +1100 (EST) To: sgi.bugs.xfs@engr.sgi.com Cc: xfs@oss.sgi.com Subject: TAKE 978682 - Update xfsidbg code after AIL listhead conversion Message-Id: <20080311123337.CBA3158C4C0F@chook.melbourne.sgi.com> Date: Tue, 11 Mar 2008 23:33:37 +1100 (EST) From: dgc@sgi.com (David Chinner) X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14850 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Update xfsidbg code after AIL listhead conversion. Date: Tue Mar 11 23:33:13 AEDT 2008 Workarea: chook.melbourne.sgi.com:/build/dgc/isms/2.6.x-xfs Inspected by: jeffpc@josefsipek.net The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:30641a fs/xfs/xfsidbg.c - 1.346 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfsidbg.c.diff?r1=text&tr1=1.346&r2=text&tr2=1.345&f=h - Convert AIL debug code to struct list_head. From owner-xfs@oss.sgi.com Tue Mar 11 05:39:22 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 11 Mar 2008 05:39:30 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_42, J_CHICKENPOX_43,J_CHICKENPOX_44,J_CHICKENPOX_45,J_CHICKENPOX_46, J_CHICKENPOX_47,J_CHICKENPOX_48,J_CHICKENPOX_61,MIME_8BIT_HEADER autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m2BCdLpd014335 for ; Tue, 11 Mar 2008 05:39:22 -0700 X-ASG-Debug-ID: 1205239188-0d1d00360000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from rn-out-0910.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 99346F626BE for ; Tue, 11 Mar 2008 05:39:49 -0700 (PDT) Received: from rn-out-0910.google.com (rn-out-0910.google.com [64.233.170.189]) by cuda.sgi.com with ESMTP id 2ZO8NEDnyNIiVKKw for ; Tue, 11 Mar 2008 05:39:49 -0700 (PDT) Received: by rn-out-0910.google.com with SMTP id a43so1585563rne.10 for ; Tue, 11 Mar 2008 05:39:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=SV/Btin7cNoreVF/SkrxaM6efICO4rRKpHbp5SeYprE=; b=niMWq0S4DhF1aQ8Lwd7M6vph8pMJ2UsKPxmWXch3i2pvRmjWfYTnbuksbNVScYOADHdYy2seEKHDEHGQzB0Fv20cHq5laf4igy0SOgsUXMRshi7bKfFK4biPLjJ1cAKQ+ZZZl3u+UsFC9rg98UhsE4YmhMNyRHBDtTd4/vyRa/o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=D0Tuf5fMDPJ7rXN6pBdSypVK+PELHEY4SOeH1InHcwOeBr1Cg+Hx48iAw9inVN+AAkaf1RPgW/ZV0UEpamGhx3eAu5VmT+lv1td6vwzKjiTCooZsEoBV3v+Hhsf7G34BlxvZWSeC7BhORzf5Sv2ZEgF/DhZg++kGOuAV1HfkUK0= Received: by 10.151.42.13 with SMTP id u13mr3617941ybj.107.1205239188475; Tue, 11 Mar 2008 05:39:48 -0700 (PDT) Received: by 10.150.96.5 with HTTP; Tue, 11 Mar 2008 05:39:48 -0700 (PDT) Message-ID: <1a4a774c0803110539s129fd2am86e933a03cdd1b18@mail.gmail.com> Date: Tue, 11 Mar 2008 13:39:48 +0100 From: "=?ISO-8859-1?Q?Christian_R=F8snes?=" To: "David Chinner" X-ASG-Orig-Subj: Re: XFS internal error xfs_trans_cancel at line 1150 of file fs/xfs/xfs_trans.c Subject: Re: XFS internal error xfs_trans_cancel at line 1150 of file fs/xfs/xfs_trans.c Cc: xfs@oss.sgi.com In-Reply-To: <20080311122103.GP155407@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <1a4a774c0803050553h7f6294cfq41c38f34ea92ceae@mail.gmail.com> <1a4a774c0803070319j1eb8790ek3daae4a16b3e6256@mail.gmail.com> <20080310000809.GU155407@sgi.com> <1a4a774c0803100302y17530814wee7522aa0dfd7668@mail.gmail.com> <1a4a774c0803100134k258e1bcfma95e7969bc44b2af@mail.gmail.com> <20080310222135.GZ155407@sgi.com> <1a4a774c0803110108u3f01813fs7f9540f886be055@mail.gmail.com> <20080311093406.GN155407@sgi.com> <1a4a774c0803110419n645da456leaedd98593300726@mail.gmail.com> <20080311122103.GP155407@sgi.com> X-Barracuda-Connect: rn-out-0910.google.com[64.233.170.189] X-Barracuda-Start-Time: 1205239190 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.44515 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id m2BCdMpd014338 X-archive-position: 14851 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: christian.rosnes@gmail.com Precedence: bulk X-list: xfs On Tue, Mar 11, 2008 at 1:21 PM, David Chinner wrote: > On Tue, Mar 11, 2008 at 12:19:29PM +0100, Christian Røsnes wrote: > > On Tue, Mar 11, 2008 at 10:34 AM, David Chinner wrote: > > > > > > On Tue, Mar 11, 2008 at 09:08:31AM +0100, Christian Røsnes wrote: > > > > > > I'll try to add some printk statements to the codepaths you mentioned, > > > > and see where it leads. > > > > > > Definitely worth confirming this is where the error is coming from. > > > > > > > if (tagno == agno) { > > printk("XFS: xfs_dialloc:0021\n"); > > *inop = NULLFSINO; > > return noroom ? ENOSPC : 0; > > } > > > > seems to be what triggers this inside xfs_dialloc. > > > > Here a trace which give some indication to the codepath taken inside > > xfs_dialloc (xfs_ialloc.c): > > Yup, that's trying to allocate in each AG and failing. Almost certainly > the problem is the described alignment issue. > > FYI, I'm travelling tomorrow so I won't really get a chance to look > at this more until thursday.... > Ok. Thanks again for all your help so far in tracking this down. Here's the codepath taken within xfs_ialloc_ag_alloc (xfs_ialloc.c): mount: /dev/sdb1 on /data type xfs (rw,noatime,logbufs=8,nobarrier) # mkdir /data/test mkdir: cannot create directory `/data/test': No space left on device Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0001 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0003 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0004 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0007 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0008 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0011 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0012 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0014 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0015 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0016 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0017 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0020 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0021 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0001 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0003 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0004 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0007 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0008 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0011 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0012 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0014 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0015 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0016 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0017 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0020 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0021 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0001 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0003 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0004 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0007 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0008 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0011 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0012 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0014 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0015 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0016 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0017 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0020 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0021 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0001 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0003 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0004 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0007 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0008 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0011 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0012 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0014 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0015 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0016 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0017 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0020 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0021 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0001 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0003 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0004 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0007 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0008 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0011 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0012 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0014 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0015 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0016 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0017 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0020 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0021 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0001 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0003 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0004 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0007 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0008 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0011 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0012 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0014 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0015 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0016 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0017 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0020 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0021 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0001 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0003 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0004 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0007 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0008 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0011 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0012 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0014 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0015 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0016 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0017 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0020 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0021 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0001 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0003 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0004 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0007 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0008 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0011 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0012 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0014 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0015 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0016 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0017 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0020 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0021 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0001 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0003 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0004 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0007 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0008 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0011 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0012 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0014 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0015 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0016 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0017 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0020 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0021 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0001 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0003 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0004 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0007 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0008 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0011 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0012 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0014 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0015 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0016 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0017 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0020 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0021 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0001 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0003 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0004 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0007 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0008 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0011 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0012 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0014 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0015 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0016 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0017 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0020 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0021 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0001 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0003 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0004 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0007 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0008 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0011 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0012 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0014 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0015 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0016 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0017 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0020 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0021 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0001 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0003 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0004 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0007 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0008 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0011 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0012 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0014 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0015 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0016 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0017 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0020 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0021 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0001 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0003 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0004 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0007 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0008 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0011 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0012 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0014 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0015 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0016 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0017 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0020 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0021 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0001 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0003 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0004 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0007 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0008 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0011 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0012 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0014 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0015 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0016 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0017 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0020 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0021 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0001 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0003 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0004 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0007 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0008 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0011 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0012 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0014 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0015 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0016 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0017 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0020 Mar 11 13:27:44 linux kernel: XFS: xfs_ialloc_ag_alloc:0021 Mar 11 13:27:44 linux kernel: Filesystem "sdb1": XFS internal error xfs_trans_cancel at line 1163 of file fs/xfs/xfs_trans.c. Caller 0xc021a1f8 Mar 11 13:27:44 linux kernel: Pid: 5593, comm: mkdir Not tainted 2.6.24.3FC #10 Mar 11 13:27:44 linux kernel: [] xfs_trans_cancel+0x5d/0xe6 Mar 11 13:27:44 linux kernel: [] xfs_mkdir+0x45a/0x493 Mar 11 13:27:44 linux kernel: [] xfs_mkdir+0x45a/0x493 Mar 11 13:27:44 linux kernel: [] xfs_acl_vhasacl_default+0x33/0x44 Mar 11 13:27:44 linux kernel: [] xfs_vn_mknod+0x165/0x243 Mar 11 13:27:44 linux kernel: [] xfs_access+0x2f/0x35 Mar 11 13:27:44 linux kernel: [] xfs_vn_mkdir+0x12/0x14 Mar 11 13:27:44 linux kernel: [] vfs_mkdir+0xa3/0xe2 Mar 11 13:27:44 linux kernel: [] sys_mkdirat+0x8a/0xc3 Mar 11 13:27:44 linux kernel: [] sys_mkdir+0x1f/0x23 Mar 11 13:27:44 linux kernel: [] syscall_call+0x7/0xb Mar 11 13:27:44 linux kernel: [] proc_dodebug+0xc6/0x1e2 Mar 11 13:27:44 linux kernel: ======================= Mar 11 13:27:44 linux kernel: xfs_force_shutdown(sdb1,0x8) called from line 1164 of file fs/xfs/xfs_trans.c. Return address = 0xc0212878 Mar 11 13:27:44 linux kernel: Filesystem "sdb1": Corruption of in-memory data detected. Shutting down filesystem: sdb1 Mar 11 13:27:44 linux kernel: Please umount the filesystem, and rectify the problem(s) /* * Allocate new inodes in the allocation group specified by agbp. * Return 0 for success, else error code. */ STATIC int /* error code or 0 */ xfs_ialloc_ag_alloc( xfs_trans_t *tp, /* transaction pointer */ xfs_buf_t *agbp, /* alloc group buffer */ int *alloc) { xfs_agi_t *agi; /* allocation group header */ xfs_alloc_arg_t args; /* allocation argument structure */ int blks_per_cluster; /* fs blocks per inode cluster */ xfs_btree_cur_t *cur; /* inode btree cursor */ xfs_daddr_t d; /* disk addr of buffer */ xfs_agnumber_t agno; int error; xfs_buf_t *fbuf; /* new free inodes' buffer */ xfs_dinode_t *free; /* new free inode structure */ int i; /* inode counter */ int j; /* block counter */ int nbufs; /* num bufs of new inodes */ xfs_agino_t newino; /* new first inode's number */ xfs_agino_t newlen; /* new number of inodes */ int ninodes; /* num inodes per buf */ xfs_agino_t thisino; /* current inode number, for loop */ int version; /* inode version number to use */ int isaligned = 0; /* inode allocation at stripe unit */ /* boundary */ args.tp = tp; args.mp = tp->t_mountp; printk("XFS: xfs_ialloc_ag_alloc:0001\n"); /* * Locking will ensure that we don't have two callers in here * at one time. */ newlen = XFS_IALLOC_INODES(args.mp); if (args.mp->m_maxicount && args.mp->m_sb.sb_icount + newlen > args.mp->m_maxicount) { printk("XFS: xfs_ialloc_ag_alloc:0002\n"); return XFS_ERROR(ENOSPC); } printk("XFS: xfs_ialloc_ag_alloc:0003\n"); args.minlen = args.maxlen = XFS_IALLOC_BLOCKS(args.mp); /* * First try to allocate inodes contiguous with the last-allocated * chunk of inodes. If the filesystem is striped, this will fill * an entire stripe unit with inodes. */ agi = XFS_BUF_TO_AGI(agbp); newino = be32_to_cpu(agi->agi_newino); args.agbno = XFS_AGINO_TO_AGBNO(args.mp, newino) + XFS_IALLOC_BLOCKS(args.mp); if (likely(newino != NULLAGINO && (args.agbno < be32_to_cpu(agi->agi_length)))) { printk("XFS: xfs_ialloc_ag_alloc:0004\n"); args.fsbno = XFS_AGB_TO_FSB(args.mp, be32_to_cpu(agi->agi_seqno), args.agbno); args.type = XFS_ALLOCTYPE_THIS_BNO; args.mod = args.total = args.wasdel = args.isfl = args.userdata = args.minalignslop = 0; args.prod = 1; args.alignment = 1; /* * Allow space for the inode btree to split. */ args.minleft = XFS_IN_MAXLEVELS(args.mp) - 1; if ((error = xfs_alloc_vextent(&args))) { printk("XFS: xfs_ialloc_ag_alloc:0005\n"); return error; } } else { printk("XFS: xfs_ialloc_ag_alloc:0006\n"); args.fsbno = NULLFSBLOCK; } if (unlikely(args.fsbno == NULLFSBLOCK)) { printk("XFS: xfs_ialloc_ag_alloc:0007\n"); /* * Set the alignment for the allocation. * If stripe alignment is turned on then align at stripe unit * boundary. * If the cluster size is smaller than a filesystem block * then we're doing I/O for inodes in filesystem block size * pieces, so don't need alignment anyway. */ isaligned = 0; if (args.mp->m_sinoalign) { printk("XFS: xfs_ialloc_ag_alloc:0008\n"); ASSERT(!(args.mp->m_flags & XFS_MOUNT_NOALIGN)); args.alignment = args.mp->m_dalign; isaligned = 1; } else if (XFS_SB_VERSION_HASALIGN(&args.mp->m_sb) && args.mp->m_sb.sb_inoalignmt >= XFS_B_TO_FSBT(args.mp, XFS_INODE_CLUSTER_SIZE(args.mp))) { printk("XFS: xfs_ialloc_ag_alloc:0009\n"); args.alignment = args.mp->m_sb.sb_inoalignmt; } else { printk("XFS: xfs_ialloc_ag_alloc:0010\n"); args.alignment = 1; } /* * Need to figure out where to allocate the inode blocks. * Ideally they should be spaced out through the a.g. * For now, just allocate blocks up front. */ printk("XFS: xfs_ialloc_ag_alloc:0011\n"); args.agbno = be32_to_cpu(agi->agi_root); args.fsbno = XFS_AGB_TO_FSB(args.mp, be32_to_cpu(agi->agi_seqno), args.agbno); /* * Allocate a fixed-size extent of inodes. */ args.type = XFS_ALLOCTYPE_NEAR_BNO; args.mod = args.total = args.wasdel = args.isfl = args.userdata = args.minalignslop = 0; args.prod = 1; /* * Allow space for the inode btree to split. */ args.minleft = XFS_IN_MAXLEVELS(args.mp) - 1; printk("XFS: xfs_ialloc_ag_alloc:0012\n"); if ((error = xfs_alloc_vextent(&args))) { printk("XFS: xfs_ialloc_ag_alloc:0013\n"); return error; } printk("XFS: xfs_ialloc_ag_alloc:0014\n"); } printk("XFS: xfs_ialloc_ag_alloc:0015\n"); /* * If stripe alignment is turned on, then try again with cluster * alignment. */ if (isaligned && args.fsbno == NULLFSBLOCK) { printk("XFS: xfs_ialloc_ag_alloc:0016\n"); args.type = XFS_ALLOCTYPE_NEAR_BNO; args.agbno = be32_to_cpu(agi->agi_root); args.fsbno = XFS_AGB_TO_FSB(args.mp, be32_to_cpu(agi->agi_seqno), args.agbno); if (XFS_SB_VERSION_HASALIGN(&args.mp->m_sb) && args.mp->m_sb.sb_inoalignmt >= XFS_B_TO_FSBT(args.mp, XFS_INODE_CLUSTER_SIZE(args.mp))) { printk("XFS: xfs_ialloc_ag_alloc:0017\n"); args.alignment = args.mp->m_sb.sb_inoalignmt; } else { printk("XFS: xfs_ialloc_ag_alloc:0018\n"); args.alignment = 1; } if ((error = xfs_alloc_vextent(&args))) { printk("XFS: xfs_ialloc_ag_alloc:0019\n"); return error; } } printk("XFS: xfs_ialloc_ag_alloc:0020\n"); if (args.fsbno == NULLFSBLOCK) { printk("XFS: xfs_ialloc_ag_alloc:0021\n"); *alloc = 0; return 0; } printk("XFS: xfs_ialloc_ag_alloc:0022\n"); ASSERT(args.len == args.minlen); /* * Convert the results. */ newino = XFS_OFFBNO_TO_AGINO(args.mp, args.agbno, 0); /* * Loop over the new block(s), filling in the inodes. * For small block sizes, manipulate the inodes in buffers * which are multiples of the blocks size. */ if (args.mp->m_sb.sb_blocksize >= XFS_INODE_CLUSTER_SIZE(args.mp)) { printk("XFS: xfs_ialloc_ag_alloc:0023\n"); blks_per_cluster = 1; nbufs = (int)args.len; ninodes = args.mp->m_sb.sb_inopblock; } else { printk("XFS: xfs_ialloc_ag_alloc:0024\n"); blks_per_cluster = XFS_INODE_CLUSTER_SIZE(args.mp) / args.mp->m_sb.sb_blocksize; nbufs = (int)args.len / blks_per_cluster; ninodes = blks_per_cluster * args.mp->m_sb.sb_inopblock; } printk("XFS: xfs_ialloc_ag_alloc:0025\n"); /* * Figure out what version number to use in the inodes we create. * If the superblock version has caught up to the one that supports * the new inode format, then use the new inode version. Otherwise * use the old version so that old kernels will continue to be * able to use the file system. */ if (XFS_SB_VERSION_HASNLINK(&args.mp->m_sb)) { printk("XFS: xfs_ialloc_ag_alloc:0026\n"); version = XFS_DINODE_VERSION_2; } else { printk("XFS: xfs_ialloc_ag_alloc:0027\n"); version = XFS_DINODE_VERSION_1; } for (j = 0; j < nbufs; j++) { printk("XFS: xfs_ialloc_ag_alloc:0028\n"); /* * Get the block. */ d = XFS_AGB_TO_DADDR(args.mp, be32_to_cpu(agi->agi_seqno), args.agbno + (j * blks_per_cluster)); fbuf = xfs_trans_get_buf(tp, args.mp->m_ddev_targp, d, args.mp->m_bsize * blks_per_cluster, XFS_BUF_LOCK); ASSERT(fbuf); ASSERT(!XFS_BUF_GETERROR(fbuf)); /* * Set initial values for the inodes in this buffer. */ xfs_biozero(fbuf, 0, ninodes << args.mp->m_sb.sb_inodelog); for (i = 0; i < ninodes; i++) { printk("XFS: xfs_ialloc_ag_alloc:0029\n"); free = XFS_MAKE_IPTR(args.mp, fbuf, i); free->di_core.di_magic = cpu_to_be16(XFS_DINODE_MAGIC); free->di_core.di_version = version; free->di_next_unlinked = cpu_to_be32(NULLAGINO); xfs_ialloc_log_di(tp, fbuf, i, XFS_DI_CORE_BITS | XFS_DI_NEXT_UNLINKED); } xfs_trans_inode_alloc_buf(tp, fbuf); printk("XFS: xfs_ialloc_ag_alloc:0030\n"); } printk("XFS: xfs_ialloc_ag_alloc:0031\n"); be32_add(&agi->agi_count, newlen); be32_add(&agi->agi_freecount, newlen); agno = be32_to_cpu(agi->agi_seqno); down_read(&args.mp->m_peraglock); args.mp->m_perag[agno].pagi_freecount += newlen; up_read(&args.mp->m_peraglock); agi->agi_newino = cpu_to_be32(newino); /* * Insert records describing the new inode chunk into the btree. */ cur = xfs_btree_init_cursor(args.mp, tp, agbp, agno, XFS_BTNUM_INO, (xfs_inode_t *)0, 0); for (thisino = newino; thisino < newino + newlen; thisino += XFS_INODES_PER_CHUNK) { printk("XFS: xfs_ialloc_ag_alloc:0032\n"); if ((error = xfs_inobt_lookup_eq(cur, thisino, XFS_INODES_PER_CHUNK, XFS_INOBT_ALL_FREE, &i))) { printk("XFS: xfs_ialloc_ag_alloc:0033\n"); xfs_btree_del_cursor(cur, XFS_BTREE_ERROR); return error; } printk("XFS: xfs_ialloc_ag_alloc:0034\n"); ASSERT(i == 0); if ((error = xfs_inobt_insert(cur, &i))) { printk("XFS: xfs_ialloc_ag_alloc:0035\n"); xfs_btree_del_cursor(cur, XFS_BTREE_ERROR); return error; } ASSERT(i == 1); printk("XFS: xfs_ialloc_ag_alloc:0036\n"); } printk("XFS: xfs_ialloc_ag_alloc:0037\n"); xfs_btree_del_cursor(cur, XFS_BTREE_NOERROR); /* * Log allocation group header fields */ xfs_ialloc_log_agi(tp, agbp, XFS_AGI_COUNT | XFS_AGI_FREECOUNT | XFS_AGI_NEWINO); /* * Modify/log superblock values for inode count and inode free count. */ xfs_trans_mod_sb(tp, XFS_TRANS_SB_ICOUNT, (long)newlen); xfs_trans_mod_sb(tp, XFS_TRANS_SB_IFREE, (long)newlen); *alloc = 1; printk("XFS: xfs_ialloc_ag_alloc:0038\n"); return 0; } Christian From owner-xfs@oss.sgi.com Tue Mar 11 06:47:55 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 11 Mar 2008 06:48:15 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m2BDlr3G025328 for ; Tue, 11 Mar 2008 06:47:55 -0700 X-ASG-Debug-ID: 1205243303-74b201720000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.flatline.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 6D542F62702 for ; Tue, 11 Mar 2008 06:48:23 -0700 (PDT) Received: from mail.flatline.de (flatline.de [80.190.243.144]) by cuda.sgi.com with ESMTP id UdinNapWZR8HTXZn for ; Tue, 11 Mar 2008 06:48:23 -0700 (PDT) Received: from shell.priv.flatline.de ([172.16.123.7] helo=slop.flatline.de ident=count) by mail.flatline.de with smtp (Exim 4.69) (envelope-from ) id 1JZ4pW-0003Vy-Pm; Tue, 11 Mar 2008 14:47:49 +0100 Received: by slop.flatline.de (sSMTP sendmail emulation); Tue, 11 Mar 2008 14:47:46 +0100 Date: Tue, 11 Mar 2008 14:47:46 +0100 From: Andreas Kotes To: David Chinner Cc: linux-kernel@vger.kernel.org, xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS internal error Subject: Re: XFS internal error Message-ID: <20080311134746.GQ14256@slop.flatline.de> References: <470831E6.4030704@fastmail.co.uk> <20071008001452.GX995458@sgi.com> <20080310122216.GG14256@slop.flatline.de> <20080310223018.GA155407@sgi.com> <20080310225927.GP14256@slop.flatline.de> <20080310234539.GC155407@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080310234539.GC155407@sgi.com> User-Agent: Mutt/1.5.13 (2006-08-11) X-Barracuda-Connect: flatline.de[80.190.243.144] X-Barracuda-Start-Time: 1205243304 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.44519 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14852 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: count-linux@flatline.de Precedence: bulk X-list: xfs Hello, * David Chinner [20080311 00:45]: > On Mon, Mar 10, 2008 at 11:59:27PM +0100, Andreas Kotes wrote: > > * David Chinner [20080310 23:30]: > > > On Mon, Mar 10, 2008 at 01:22:16PM +0100, Andreas Kotes wrote: > > > > * David Chinner [20080310 13:18]: > > > > > Yes, but those previous corruptions get left on disk as a landmine > > > > > for you to trip over some time later, even on a kernel that has the > > > > > bug fixed. > > > > > > > > > > I suggest that you run xfs_check on the filesystem and if that > > > > > shows up errors, run xfs_repair onteh filesystem to correct them. > > > > > > > > I seem to be having similiar problems, and xfs_repair is not helping :( > > > > > > xfs_repair is ensuring that the problem is not being caused by on-disk > > > corruption. In this case, it does not appear to be caused by on-disk > > > corruption, so xfs_repair won't help. > > > > ok, too bad - btw, is it a problem that I'm doing the xfs_repair on a > > mounted filesystem with xfs_repair -f -L after a remount rw? > > If it was read only, and you rebooted immediately afterwards, you'd > probably be ok. Doing this to a mounted, rw filesystem is asking > for trouble. If the shutdown is occurring after you've run xfs_repair, > then it is almost certainly the cause.... whoops, that should have read 'remount ro' .. xfs_repair on a live and writable filesystem is of course inviting desaster. I was trying read only - btw, the system as such is booted via PXE and running complete out of an initrd, using the HDD just for local data storage - not much happening on shutdown/reboot either way. > I'd suggest getting a knoppix (or similar) rescue disk and repairing > from that, rebooting and seeing if the problem persists. If it > does, then we'll have to look further into it. I basically build a PXE image which does an xfs_repair -L /dev/sda2 from initrd - and the problem persists. Sigh. Exactly no change. > FWIW, you've got plenty of free inodes so this does not look > to be the same problem I've just found. okay ... it happens on several of the dozens of machines I'm running this way, but not on others - I have yet to find the difference. what can I do to help find the problem? Andreas -- flatline IT services - Andreas Kotes - Tailored solutions for your IT needs From owner-xfs@oss.sgi.com Tue Mar 11 07:35:48 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 11 Mar 2008 07:36:06 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00,MIME_8BIT_HEADER autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m2BEZhPb031813 for ; Tue, 11 Mar 2008 07:35:48 -0700 X-ASG-Debug-ID: 1205246173-1c19004b0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from moutng.kundenserver.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id B3C4FF6310C for ; Tue, 11 Mar 2008 07:36:14 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by cuda.sgi.com with ESMTP id U9fNLVIYiNGSjs5I for ; Tue, 11 Mar 2008 07:36:14 -0700 (PDT) Received: from [192.168.2.97] (p5084FC1A.dip.t-dialin.net [80.132.252.26]) by mrelayeu.kundenserver.de (node=mrelayeu6) with ESMTP (Nemesis) id 0ML29c-1JZ5aO2X05-0001en; Tue, 11 Mar 2008 15:36:12 +0100 Message-ID: <47D6982D.7030305@t-online.de> Disposition-Notification-To: =?ISO-8859-15?Q?J=FCrgen_Fischer?= Date: Tue, 11 Mar 2008 15:33:17 +0100 From: =?ISO-8859-15?Q?J=FCrgen_Fischer?= User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: xfs@oss.sgi.com X-ASG-Orig-Subj: Problem with xfs devices Subject: Problem with xfs devices Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX18i6N7hV/nv45aqninWJwtsd+lOHgxyTorUw13 /yOpwiddINxfc+1gtPyRNO3rFw3GhED9Sk0FAd5Qur0A69D3pp fP1An/oL6wV77pnM+1i6SwSg3DkEGHI X-Barracuda-Connect: moutng.kundenserver.de[212.227.126.171] X-Barracuda-Start-Time: 1205246174 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.44521 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14853 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jfi.pcs@t-online.de Precedence: bulk X-list: xfs Hi, I have some problems with xfs devices which I can't mount and hope you can help me. I have the devices md1, md5, md6, md7, md8 on a Root-Server by a german provider with SuSE linux 10.2. I've made yesterday evening an online update which updates the kernel and wants a reboot after that. Since that no rebbot is possible, no help available from provider. The devices md1, md5 and md8 I can mount without problems. But if i try to mount md6 or md7 I got the following messages on the screen: rescue:~# mount /dev/md6 /mnt Killed rescue:~# Message from syslogd@rescue at Tue Mar 11 00:48:37 2008 ... rescue kernel: Oops: 0000 [2] SMP Message from syslogd@rescue at Tue Mar 11 00:48:37 2008 ... rescue kernel: CR2: 0000000000000008 No xfs_check or xfs_repair is possible. I got this messages: rescue:~# xfs_check -v /dev/md6 ERROR: The filesystem has valuable metadata changes in a log which needs to be replayed. Mount the filesystem to replay the log, and unmount it before re-running xfs_check. If you are unable to mount the filesystem, then use the xfs_repair -L option to destroy the log and attempt a repair. Note that destroying the log may cause corruption -- please attempt a mount of the filesystem before doing this. rescue:~# I can start after that the xfs_repair -L command but nothing is happend. I wait 30 minutes or so an tra to kill the process - impossible. I must restart my rescue system. I would be great if you can help me. Regards Juergen From owner-xfs@oss.sgi.com Tue Mar 11 09:23:42 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 11 Mar 2008 09:24:01 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,MIME_8BIT_HEADER autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m2BGNeae017364 for ; Tue, 11 Mar 2008 09:23:42 -0700 X-ASG-Debug-ID: 1205252650-0d7103870000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mx1.redhat.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 6F2CCF64334 for ; Tue, 11 Mar 2008 09:24:10 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by cuda.sgi.com with ESMTP id Ulxe0MgD8n3NKmYi for ; Tue, 11 Mar 2008 09:24:10 -0700 (PDT) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id m2BGOAq1015327; Tue, 11 Mar 2008 12:24:10 -0400 Received: from lacrosse.corp.redhat.com (lacrosse.corp.redhat.com [172.16.52.154]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m2BGO9HM026732; Tue, 11 Mar 2008 12:24:09 -0400 Received: from neon.msp.redhat.com (neon.msp.redhat.com [10.15.80.10]) by lacrosse.corp.redhat.com (8.12.11.20060308/8.11.6) with ESMTP id m2BGO8xf001222; Tue, 11 Mar 2008 12:24:09 -0400 Message-ID: <47D6B228.5070300@sandeen.net> Date: Tue, 11 Mar 2008 11:24:08 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.12 (X11/20080226) MIME-Version: 1.0 To: =?ISO-8859-15?Q?J=FCrgen_Fischer?= CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Problem with xfs devices Subject: Re: Problem with xfs devices References: <47D6982D.7030305@t-online.de> In-Reply-To: <47D6982D.7030305@t-online.de> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.58 on 172.16.52.254 X-Barracuda-Connect: mx1.redhat.com[66.187.233.31] X-Barracuda-Start-Time: 1205252651 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.44529 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 14854 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Jürgen Fischer wrote: > Hi, > > I have some problems with xfs devices which I can't mount and hope you > can help me. > > I have the devices md1, md5, md6, md7, md8 on a Root-Server by a german > provider with SuSE linux 10.2. I've made yesterday evening an online > update which updates the kernel and wants a reboot after that. Since > that no rebbot is possible, no help available from provider. > The devices md1, md5 and md8 I can mount without problems. But if i try > to mount md6 or md7 I got the following messages on the screen: > > rescue:~# mount /dev/md6 /mnt > Killed > rescue:~# > Message from syslogd@rescue at Tue Mar 11 00:48:37 2008 ... > rescue kernel: Oops: 0000 [2] SMP > > Message from syslogd@rescue at Tue Mar 11 00:48:37 2008 ... > rescue kernel: CR2: 0000000000000008 type "dmesg" to get the whole oops. -Eric From owner-xfs@oss.sgi.com Tue Mar 11 10:30:17 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 11 Mar 2008 10:30:35 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m2BHUDMX025044 for ; Tue, 11 Mar 2008 10:30:17 -0700 X-ASG-Debug-ID: 1205256643-67a800520000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sargon.lncsa.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 7169EF64F6F for ; Tue, 11 Mar 2008 10:30:44 -0700 (PDT) Received: from sargon.lncsa.com (sargon.lncsa.com [212.99.8.251]) by cuda.sgi.com with ESMTP id hnuchaShsZCPFF1q for ; Tue, 11 Mar 2008 10:30:44 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by sargon.lncsa.com (Postfix) with ESMTP id DF7EC3013BA3 for ; Tue, 11 Mar 2008 18:30:02 +0100 (CET) X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Scanned: Debian amavisd-new at lncsa.com Received: from sargon.lncsa.com ([127.0.0.1]) by localhost (sargon.lncsa.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19-VkScLCTve for ; Tue, 11 Mar 2008 18:30:02 +0100 (CET) Received: from zenon.apartia.fr (zenon.apartia.fr [10.0.3.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "zenon.apartia.fr", Issuer "ca.apartia.fr" (verified OK)) by sargon.lncsa.com (Postfix) with ESMTP id B86E83015E26 for ; Tue, 11 Mar 2008 18:30:02 +0100 (CET) Received: from trajan.apartia.fr (trajan.apartia.fr [10.0.3.121]) by zenon.apartia.fr (Postfix) with ESMTP id 38C4C59C5B414 for ; Tue, 11 Mar 2008 18:29:58 +0100 (CET) Received: by trajan.apartia.fr (Postfix, from userid 1000) id C636F3CEED905; Tue, 11 Mar 2008 18:29:58 +0100 (CET) Date: Tue, 11 Mar 2008 18:29:58 +0100 From: Louis-David Mitterrand To: xfs@oss.sgi.com X-ASG-Orig-Subj: can I shrink an xfs? Subject: can I shrink an xfs? Message-ID: <20080311172958.GA31833@apartia.fr> Mail-Followup-To: xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Barracuda-Connect: sargon.lncsa.com[212.99.8.251] X-Barracuda-Start-Time: 1205256644 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.44533 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Status: Clean X-archive-position: 14855 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: vindex+lists-xfs@apartia.org Precedence: bulk X-list: xfs Hi, Is it possible to shrink an xfs? I tried using xfs_growfs to no avail. zenon:~# xfs_growfs -D 650000000 /backup meta-data=/dev/md2 isize=256 agcount=32, agsize=20539552 blks = sectsz=4096 attr=1 data = bsize=4096 blocks=657265248, imaxpct=25 = sunit=16 swidth=48 blks naming =version 2 bsize=4096 log =internal bsize=4096 blocks=32768, version=2 = sectsz=4096 sunit=1 blks, lazy-count=0 realtime =none extsz=196608 blocks=0, rtextents=0 data size 650000000 too small, old size is 657265248 ... even though the fs is 80% full only. Thanks, From owner-xfs@oss.sgi.com Tue Mar 11 11:01:47 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 11 Mar 2008 11:02:04 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_55 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m2BI1fvS028494 for ; Tue, 11 Mar 2008 11:01:47 -0700 X-ASG-Debug-ID: 1205258531-1bef033c0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from filer.fsl.cs.sunysb.edu (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 9D68DF65E51 for ; Tue, 11 Mar 2008 11:02:12 -0700 (PDT) Received: from filer.fsl.cs.sunysb.edu (filer.fsl.cs.sunysb.edu [130.245.126.2]) by cuda.sgi.com with ESMTP id cAVekRemrDS30mha for ; Tue, 11 Mar 2008 11:02:12 -0700 (PDT) Received: from josefsipek.net (baal.fsl.cs.sunysb.edu [130.245.126.78]) by filer.fsl.cs.sunysb.edu (8.12.11.20060308/8.13.1) with ESMTP id m2BI29Xb013866 for ; Tue, 11 Mar 2008 14:02:10 -0400 Received: by josefsipek.net (Postfix, from userid 1000) id 9CBFB1C07AC0; Tue, 11 Mar 2008 14:02:10 -0400 (EDT) Date: Tue, 11 Mar 2008 14:02:10 -0400 From: "Josef 'Jeff' Sipek" To: xfs@oss.sgi.com X-ASG-Orig-S