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 partition