From owner-linux-xfs@oss.sgi.com Sat Apr 1 21:37:22 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 01 Apr 2006 21:37:29 -0800 (PST) Received: from uproxy.gmail.com (uproxy.gmail.com [66.249.92.200]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k325bLgC014943 for ; Sat, 1 Apr 2006 21:37:22 -0800 Received: by uproxy.gmail.com with SMTP id u2so621941uge for ; Sun, 02 Apr 2006 22:32:46 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=WI0sQvjO2xD51X/+okK8AaTg0KBXKs+uGOjQg6pIXrdryRmxs4A0UVoK+hcEDJxgTxIaidA7M0z6dnOLKCS4LXEIfERdYK4o0/cYSkwbvX7cJ3D786FEHjWvxyVCCHw7tD3C39rqU0ozQaBnQoAR1d1frNXkrFNHQZGb2MbWXAI= Received: by 10.78.20.13 with SMTP id 13mr41814hut; Sun, 02 Apr 2006 20:55:10 -0700 (PDT) Received: by 10.78.40.1 with HTTP; Sun, 2 Apr 2006 20:55:10 -0700 (PDT) Message-ID: <6b22a6b40604022055s27c9400bjabafbdd593fd3119@mail.gmail.com> Date: Mon, 3 Apr 2006 13:55:10 +1000 From: "Gerard Neil" To: linux-xfs@oss.sgi.com Subject: xfsdump and chattr +d : undocumented but really useful behaviour MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id k325bMgC014946 X-archive-position: 7573 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: xyzzy@devferret.org Precedence: bulk X-list: linux-xfs Status: O Content-Length: 785 Lines: 20 I've been running a gentoo linux server (currently 2.6.15) using xfs and xfsdump for a couple of years now. I've just discovered that if the the no-dump (d) attribute is set on a directory (using chattr +d), then any new directories/files created in that directory automatically acquire the attribute too. This is *really* useful when used in conjunction with xfsdump -e, because it means I can easily exclude entire subtrees from dumps. If this is really how the no-dump attribute is supposed to behave on xfs, then I suggest documenting this in the xfsdump man page. The current "excluding individual files" section is confusing with respect to chattr +d, and certainly doesn't mention this useful behaviour. I can't find it documented anywhere else, either... Regards, Gerard From owner-linux-xfs@oss.sgi.com Sun Apr 2 07:37:25 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 02 Apr 2006 07:37:33 -0700 (PDT) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k32EbOgC002074 for ; Sun, 2 Apr 2006 07:37:24 -0700 Received: from internal-mail-relay1.corp.sgi.com (internal-mail-relay1.corp.sgi.com [198.149.32.52]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id k33EWmnx018878 for ; Mon, 3 Apr 2006 09:32:48 -0500 Received: from [128.162.233.24] (fsgi275.americas.sgi.com [128.162.233.24]) by internal-mail-relay1.corp.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id k33EcOpG5131407; Mon, 3 Apr 2006 07:38:24 -0700 (PDT) Message-ID: <4431320D.2040500@sgi.com> Date: Mon, 03 Apr 2006 09:32:45 -0500 From: Bill Kendall User-Agent: Debian Thunderbird 1.0.7 (X11/20051017) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gerard Neil CC: linux-xfs@oss.sgi.com Subject: Re: xfsdump and chattr +d : undocumented but really useful behaviour References: <6b22a6b40604022055s27c9400bjabafbdd593fd3119@mail.gmail.com> In-Reply-To: <6b22a6b40604022055s27c9400bjabafbdd593fd3119@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7574 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: wkendall@sgi.com Precedence: bulk X-list: linux-xfs Status: O Content-Length: 1003 Lines: 30 Hi Gerard, This is a popular question lately. The man page was updated a couple months back, around version 2.2.34 or so. Regards, Bill On 04/02/06 22:55, Gerard Neil wrote: > I've been running a gentoo linux server (currently 2.6.15) using xfs > and xfsdump for a couple of years now. > > I've just discovered that if the the no-dump (d) attribute is set on a > directory (using chattr +d), then any new directories/files created in > that directory automatically acquire the attribute too. > > This is *really* useful when used in conjunction with xfsdump -e, > because it means I can easily exclude entire subtrees from dumps. > > If this is really how the no-dump attribute is supposed to behave on > xfs, then I suggest documenting this in the xfsdump man page. The > current "excluding individual files" section is confusing with respect > to chattr +d, and certainly doesn't mention this useful behaviour. I > can't find it documented anywhere else, either... > > Regards, > > Gerard > From owner-linux-xfs@oss.sgi.com Sun Apr 2 23:04:23 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 02 Apr 2006 23:04:27 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k3364LgC015313 for ; Sun, 2 Apr 2006 23:04:22 -0700 Received: from puffy.melbourne.sgi.com (puffy.melbourne.sgi.com [134.14.55.166]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA09492; Tue, 4 Apr 2006 14:53:42 +1000 Received: by puffy.melbourne.sgi.com (Postfix, from userid 1000) id 0392E10D; Tue, 4 Apr 2006 14:50:24 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.melbourne.sgi.com Subject: TAKE 951422 - libdir paths in xfs-cmds Makefiles are wrong for many 64bit platforms Message-Id: <20060404045024.0392E10D@puffy.melbourne.sgi.com> Date: Tue, 4 Apr 2006 14:50:24 +1000 (EST) From: tes@puffy.melbourne.sgi.com (Timothy Shimmin) X-archive-position: 7575 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tes@puffy.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Status: O Content-Length: 6609 Lines: 100 fix lib64 installs Date: Tue Apr 4 14:51:15 AEST 2006 Workarea: puffy.melbourne.sgi.com:/home/tes/isms/xfs-cmds Inspected by: nathans@sgi.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:25657a dmapi/m4/multilib.m4 - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/dmapi/m4/multilib.m4 xfstests/m4/multilib.m4 - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/m4/multilib.m4 xfsdump/m4/multilib.m4 - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/m4/multilib.m4 acl/m4/multilib.m4 - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/m4/multilib.m4 xfsprogs/m4/multilib.m4 - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/m4/multilib.m4 attr/m4/multilib.m4 - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/m4/multilib.m4 acl/configure.in - 1.29 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/configure.in.diff?r1=text&tr1=1.29&r2=text&tr2=1.28&f=h acl/Makefile - 1.19 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/Makefile.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h acl/include/builddefs.in - 1.32 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/include/builddefs.in.diff?r1=text&tr1=1.32&r2=text&tr2=1.31&f=h attr/configure.in - 1.18 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/configure.in.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h attr/Makefile - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/Makefile.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h attr/include/builddefs.in - 1.28 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/include/builddefs.in.diff?r1=text&tr1=1.28&r2=text&tr2=1.27&f=h xfsprogs/configure.in - 1.35 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/configure.in.diff?r1=text&tr1=1.35&r2=text&tr2=1.34&f=h xfsprogs/Makefile - 1.27 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/Makefile.diff?r1=text&tr1=1.27&r2=text&tr2=1.26&f=h xfsprogs/include/builddefs.in - 1.46 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/builddefs.in.diff?r1=text&tr1=1.46&r2=text&tr2=1.45&f=h xfsdump/configure.in - 1.38 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/configure.in.diff?r1=text&tr1=1.38&r2=text&tr2=1.37&f=h xfsdump/Makefile - 1.19 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/Makefile.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h xfsdump/include/builddefs.in - 1.25 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/include/builddefs.in.diff?r1=text&tr1=1.25&r2=text&tr2=1.24&f=h xfstests/Makefile - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/Makefile.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h dmapi/configure.in - 1.21 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/dmapi/configure.in.diff?r1=text&tr1=1.21&r2=text&tr2=1.20&f=h dmapi/Makefile - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/dmapi/Makefile.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h dmapi/include/builddefs.in - 1.24 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/dmapi/include/builddefs.in.diff?r1=text&tr1=1.24&r2=text&tr2=1.23&f=h acl/m4/Makefile - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/m4/Makefile.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h acl/aclocal.m4 - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/aclocal.m4.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h attr/m4/Makefile - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/m4/Makefile.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h attr/aclocal.m4 - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/aclocal.m4.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h acl/m4/package_attrdev.m4 - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/m4/package_attrdev.m4.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h dmapi/m4/package_xfslibs.m4 - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/dmapi/m4/package_xfslibs.m4.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h dmapi/aclocal.m4 - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/dmapi/aclocal.m4.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h dmapi/m4/Makefile - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/dmapi/m4/Makefile.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h xfsprogs/aclocal.m4 - 1.21 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/aclocal.m4.diff?r1=text&tr1=1.21&r2=text&tr2=1.20&f=h xfsprogs/m4/Makefile - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/m4/Makefile.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h xfsdump/m4/package_xfslibs.m4 - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/m4/package_xfslibs.m4.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h xfsdump/aclocal.m4 - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/aclocal.m4.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h xfsdump/m4/package_attrdev.m4 - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/m4/package_attrdev.m4.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h xfsdump/m4/package_dmapidev.m4 - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/m4/package_dmapidev.m4.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h xfsdump/m4/Makefile - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/m4/Makefile.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h xfstests/m4/Makefile - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/m4/Makefile.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h xfstests/m4/package_acldev.m4 - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/m4/package_acldev.m4.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h xfstests/m4/package_attrdev.m4 - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/m4/package_attrdev.m4.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h xfstests/m4/package_dmapidev.m4 - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/m4/package_dmapidev.m4.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h xfstests/m4/package_gdbmdev.m4 - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/m4/package_gdbmdev.m4.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h xfstests/m4/package_xfslibs.m4 - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/m4/package_xfslibs.m4.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h xfstests/aclocal.m4 - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/aclocal.m4.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h From owner-linux-xfs@oss.sgi.com Mon Apr 3 01:45:49 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 03 Apr 2006 01:45:55 -0700 (PDT) Received: from pproxy.gmail.com (pproxy.gmail.com [64.233.166.180]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k338jmgC011020 for ; Mon, 3 Apr 2006 01:45:49 -0700 Received: by pproxy.gmail.com with SMTP id i75so1793338pye for ; Tue, 04 Apr 2006 01:41:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type; b=K5rJgszvnBb7QZmNNc1jamABP8wrft/ibXg+UaVBdf+tsajdK5TQOfVLPqHPh2/EmoXfMj8XPcwwhKJZT/oxKxJZm32zKgCQeVAQHqUxvTvoCghiyL3Phs4JLRxU8ndHsJU13kB5rUMqHh9op8Vn9S4b67UNZvJcpwDsCgCh9c0= Received: by 10.35.43.10 with SMTP id v10mr498086pyj; Tue, 04 Apr 2006 00:42:50 -0700 (PDT) Received: by 10.35.99.11 with HTTP; Tue, 4 Apr 2006 00:42:50 -0700 (PDT) Message-ID: Date: Tue, 4 Apr 2006 03:42:50 -0400 From: "Evgeniy Sharapov" Reply-To: sen@fnal.gov To: linux-xfs@oss.sgi.com Subject: XFS partition recovery MIME-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit X-archive-position: 7576 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: evgeniy.sharapov@gmail.com Precedence: bulk X-list: linux-xfs Status: O Content-Length: 13202 Lines: 310 I have XFS /home partition (fortunately not /). I can not mount it because of the error during reading the superblock. After running xfs_repair -nLv /dev/hda7 I got <------cut---------> ................................ would clear inode number in entry at offset 2416... entry "20060331122258" at block 2 offset 2448 in directory inode 16922661 references free inode 184775172 would clear inode number in entry at offset 2448... entry "20060331122336" at block 2 offset 2480 in directory inode 16922661 references free inode 201635562 would clear inode number in entry at offset 2480... entry "20060331122347" at block 2 offset 2512 in directory inode 16922661 references free inode 218356061 would clear inode number in entry at offset 2512... entry "20060331122411" at block 2 offset 2544 in directory inode 16922661 references free inode 235060608 would clear inode number in entry at offset 2544... entry "20060331122457" at block 2 offset 2576 in directory inode 16922661 references free inode 252033667 would clear inode number in entry at offset 2576... entry "20060331122757" at block 2 offset 2640 in directory inode 16922661 references free inode 17026280 would clear inode number in entry at offset 2640... entry "20060331122931" at block 2 offset 2672 in directory inode 16922661 references free inode 33982501 would clear inode number in entry at offset 2672... entry "20060331123023" at block 2 offset 2704 in directory inode 16922661 references free inode 50472830 would clear inode number in entry at offset 2704... entry "20060331124300" at block 2 offset 2736 in directory inode 16922661 references free inode 67334620 would clear inode number in entry at offset 2736... entry "20060331124322" at block 2 offset 2768 in directory inode 16922661 references free inode 87134914 would clear inode number in entry at offset 2768... - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 entry "saved_state" in shortform directory 117927296 references free inode 119856305 would have junked entry "saved_state" in directory inode 117927296 - agno = 8 - agno = 9 entry "lock" at block 0 offset 1400 in directory inode 151094696 references free inode 151094596 would clear inode number in entry at offset 1400... - agno = 10 - agno = 11 - agno = 12 - agno = 13 entry "prefs.js" at block 0 offset 184 in directory inode 218120250 references free inode 218356930 would clear inode number in entry at offset 184... entry "crashrecovery.bak" at block 0 offset 2064 in directory inode 218120250 references free inode 218356062 would clear inode number in entry at offset 2064... data fork in ino 218351246 claims dup extent, off - 0, start - 13762894, cnt 16 bad data fork in inode 218351246 would have cleared inode 218351246 data fork in ino 218356062 claims dup extent, off - 0, start - 13762907, cnt 1 bad data fork in inode 218356062 would have cleared inode 218356062 - agno = 14 - agno = 15 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem starting at / ... entry "saved_state" in shortform directory inode 117927296 points to free inode 119856305 would junk entry "saved_state" entry "lock" in directory inode 151094696 points to free inode 151094596, would junk entry entry "prefs.js" in directory inode 218120250 points to free inode 218356930, would junk entry entry "history.dat" in directory inode 218120250 points to free inode 218351246, would junk entry entry "crashrecovery.bak" in directory inode 218120250 points to free inode 218356062, would junk entry entry "20060331104725" in directory inode 16922661 points to free inode 167995662, would junk entry entry "20060331122258" in directory inode 16922661 points to free inode 184775172, would junk entry entry "20060331122336" in directory inode 16922661 points to free inode 201635562, would junk entry entry "20060331122347" in directory inode 16922661 points to free inode 218356061, would junk entry entry "20060331122411" in directory inode 16922661 points to free inode 235060608, would junk entry entry "20060331122457" in directory inode 16922661 points to free inode 252033667, would junk entry entry "20060331122757" in directory inode 16922661 points to free inode 17026280, would junk entry entry "20060331122931" in directory inode 16922661 points to free inode 33982501, would junk entry entry "20060331123023" in directory inode 16922661 points to free inode 50472830, would junk entry entry "20060331124300" in directory inode 16922661 points to free inode 67334620, would junk entry entry "20060331124322" in directory inode 16922661 points to free inode 87134914, would junk entry entry "E61AF434d01" in directory inode 432031 points to free inode 482273, would junk entry entry "4F7AC625d01" in directory inode 432031 points to free inode 565461, would junk entry entry "5BE8CE43d01" in directory inode 432031 points to free inode 565462, would junk entry entry "CA71364Cd01" in directory inode 432031 points to free inode 565463, would junk entry entry "5265B4CEd01" in directory inode 432031 points to free inode 557310, would junk entry entry "5ACFE1DBd01" in directory inode 432031 points to free inode 565464, would junk entry entry "A0038D5Dd01" in directory inode 432031 points to free inode 565465, would junk entry entry "CC8B81C1d01" in directory inode 432031 points to free inode 565466, would junk entry entry "21566C16d01" in directory inode 432031 points to free inode 565467, would junk entry entry "87FD77F2d01" in directory inode 432031 points to free inode 565468, would junk entry entry "043B9D90d01" in directory inode 432031 points to free inode 565469, would junk entry entry "FAC61E89d01" in directory inode 432031 points to free inode 565470, would junk entry entry "624CE5DFd01" in directory inode 432031 points to free inode 565471, would junk entry entry "2852617Bd01" in directory inode 432031 points to free inode 565492, would junk entry entry "54132227d01" in directory inode 432031 points to free inode 565493, would junk entry entry "2EEAE483d01" in directory inode 432031 points to free inode 565494, would junk entry entry "5053272Ad01" in directory inode 432031 points to free inode 565495, would junk entry entry "5A393CB6d01" in directory inode 432031 points to free inode 565496, would junk entry entry "E9D34479d01" in directory inode 432031 points to free inode 565497, would junk entry entry "48BFCCC0d01" in directory inode 432031 points to free inode 565498, would junk entry entry "C9CC7FE0d01" in directory inode 432031 points to free inode 565499, would junk entry entry "81B890F9d01" in directory inode 432031 points to free inode 565500, would junk entry entry "95EC210Ed01" in directory inode 432031 points to free inode 565501, would junk entry entry "D503BEA1d01" in directory inode 432031 points to free inode 565502, would junk entry entry "24F4B5ACd01" in directory inode 432031 points to free inode 565503, would junk entry entry "27BE8468d01" in directory inode 432031 points to free inode 565517, would junk entry entry "80F5F487d01" in directory inode 432031 points to free inode 565518, would junk entry entry "6B2A05DCd01" in directory inode 432031 points to free inode 565519, would junk entry entry "7AA62CD4d01" in directory inode 432031 points to free inode 565520, would junk entry entry "E442E09Ed01" in directory inode 432031 points to free inode 565521, would junk entry entry "652077F6d01" in directory inode 432031 points to free inode 565522, would junk entry entry "3452818Ed01" in directory inode 432031 points to free inode 565523, would junk entry entry "BDAB8D3Ed01" in directory inode 432031 points to free inode 565524, would junk entry entry "F34FA42Cd01" in directory inode 432031 points to free inode 565525, would junk entry entry "D2DCB468d01" in directory inode 432031 points to free inode 565526, would junk entry entry "FB102E32d01" in directory inode 432031 points to free inode 565527, would junk entry entry "10131699d01" in directory inode 432031 points to free inode 565528, would junk entry entry "DF9813B6d01" in directory inode 432031 points to free inode 565529, would junk entry entry "BF6B7290d01" in directory inode 432031 points to free inode 565530, would junk entry entry "2B2187FAd01" in directory inode 432031 points to free inode 565531, would junk entry entry "D102BB46d01" in directory inode 432031 points to free inode 565532, would junk entry entry "31334C17d01" in directory inode 432031 points to free inode 565533, would junk entry entry "C34B8538d01" in directory inode 432031 points to free inode 565534, would junk entry entry "C3508538d01" in directory inode 432031 points to free inode 565535, would junk entry entry "A2BD676Fd01" in directory inode 432031 points to free inode 565553, would junk entry entry "2750656Ed01" in directory inode 432031 points to free inode 565554, would junk entry entry "575336C8d01" in directory inode 432031 points to free inode 565555, would junk entry entry "773A2D72d01" in directory inode 432031 points to free inode 565556, would junk entry entry "D4C08B1Bd01" in directory inode 432031 points to free inode 565557, would junk entry entry "3D8E1824d01" in directory inode 432031 points to free inode 565558, would junk entry entry "2EC1600Cd01" in directory inode 432031 points to free inode 565559, would junk entry entry "124C7A75d01" in directory inode 432031 points to free inode 565560, would junk entry entry "6999FFD2d01" in directory inode 432031 points to free inode 565561, would junk entry entry "8250BEA1d01" in directory inode 432031 points to free inode 565562, would junk entry entry "26C76F3Fd01" in directory inode 432031 points to free inode 565563, would junk entry entry "2E243691d01" in directory inode 432031 points to free inode 565564, would junk entry entry "5C6481DFd01" in directory inode 432031 points to free inode 565565, would junk entry entry "3BD10BA5d01" in directory inode 432031 points to free inode 565566, would junk entry entry "55345258d01" in directory inode 432031 points to free inode 565567, would junk entry entry "E8F09616d01" in directory inode 432031 points to free inode 575999, would junk entry entry "2C0CEBA4d01" in directory inode 432031 points to free inode 576000, would junk entry entry "2C0FEBA4d01" in directory inode 432031 points to free inode 576001, would junk entry entry "5E9DDAECd01" in directory inode 432031 points to free inode 576002, would junk entry entry "FB688CBEd01" in directory inode 432031 points to free inode 576003, would junk entry bad hash table for directory inode 432031 (no data entry): would rebuild - traversal finished ... - traversing all unattached subtrees ... - traversals finished ... - moving disconnected inodes to lost+found ... disconnected inode 218356929, would move to lost+found disconnected inode 218356931, would move to lost+found disconnected inode 218356932, would move to lost+found disconnected inode 218356933, would move to lost+found disconnected inode 218356934, would move to lost+found Phase 7 - verify link counts... would have reset inode 16922661 nlinks from 330 to 331 No modify flag set, skipping filesystem flush and exiting. <----/cut-----------> Nothing unusual, i.e. There's no message about fatally corrupted filesystem. But xfs_repair fails when it's run in fixing mode. <-------cut------------> senntb ~ # xfs_repair -v /dev/hda7 Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... xfs_repair: read failed: Input/output error senntb ~ # xfs_repair -v /dev/hda7 Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... xfs_repair: read failed: Input/output error senntb ~ # xfs_repair -v /dev/hda7 Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... xfs_repair: read failed: Input/output error senntb ~ # <-------/cut------------> The same error when I start it with -L option added. I found here ( http://docs.cray.com/books/S-2377-22/html-S-2377-22/fixed6bhdyq9i26.html) that I have to <-------cut-------------> If xfs_repair failed in phase 2 or later, follow these steps: 1. Mount the file system using mount -r (read-only). 2. Make a file system backup with xfsdump. 3. Use mkfs to a make new file system on the same disk partition or XLV logical volume. 4. Restore the files from the backup with xfsrestore <-------/cut-------------> But I can't mount my home partition in read-only mode. <-------cut-------------> senntb ~ # mount -r /home mount: /dev/hda7: can't read superblock senntb ~ # <-------/cut-------------> I'm lost. How can I recover my /home partition ? It's really important. -- Evgeniy N. Sharapov ============================== Lehigh University Industrial & Systems Eng. Dpt. Bethlehem, Pennsylvania, USA ============================== phone: 630 779 3208 mail: ens205@lehigh.edu, sen@fnal.gov icq : 345482263 [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Mon Apr 3 14:26:27 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 03 Apr 2006 14:26:29 -0700 (PDT) Received: from mail.charite.de (mail.charite.de [160.45.207.131]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k33LQPgC027063 for ; Mon, 3 Apr 2006 14:26:26 -0700 Received: from localhost (localhost [127.0.0.1]) by mail.charite.de (Postfix) with ESMTP id ED533220CDA; Tue, 4 Apr 2006 23:21:46 +0200 (CEST) Received: from mail.charite.de ([127.0.0.1]) by localhost (mail.charite.de [127.0.0.1]) (amavisd-new, port 10025) with LMTP id 4sv8zhUnTL3k; Tue, 4 Apr 2006 23:21:44 +0200 (CEST) Received: from postamt.charite.de (postamt.charite.de [160.45.207.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.charite.de (Postfix) with ESMTP id BA7DD220CD5; Tue, 4 Apr 2006 23:21:44 +0200 (CEST) Received: by postamt.charite.de (Postfix, from userid 7945) id 7B6F9220781; Tue, 4 Apr 2006 23:21:44 +0200 (CEST) Date: Tue, 4 Apr 2006 23:21:44 +0200 From: Ralf Hildebrandt To: linux-kernel@vger.kernel.org Cc: linux-xfs@oss.sgi.com Subject: 2.6.16.1: XFS internal error xfs_btree_check_lblock at line 215 of file fs/xfs/xfs_btree.c Message-ID: <20060404212144.GM15722@charite.de> Mail-Followup-To: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.9i X-archive-position: 7578 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Ralf.Hildebrandt@charite.de Precedence: bulk X-list: linux-xfs Status: O Content-Length: 7005 Lines: 91 I was running xfs_fsr on our /home at night when this happened: (Kernel 2.6.16.1) Security Events =-=-=-=-=-=-=-= Apr 2 00:26:17 postamt kernel: xfs_force_shutdown(sda5,0x8) called from line 1032 of file fs/xfs/xfs_trans.c. Return address = 0xb1128274 System Events =-=-=-=-=-=-= Apr 2 00:17:10 postamt fsr[28019]: /home start inode=0 Apr 2 00:25:29 postamt fsr[28938]: /home start inode=0 Apr 2 00:26:17 postamt kernel: Filesystem "sda5": XFS internal error xfs_btree_check_lblock at line 215 of file fs/xfs/xfs_btree.c. Caller 0xb10dba58 Apr 2 00:26:17 postamt kernel: [xfs_btree_check_lblock+82/407] xfs_btree_check_lblock+0x52/0x197 Apr 2 00:26:17 postamt kernel: [xfs_bmbt_lookup+636/1471] xfs_bmbt_lookup+0x27c/0x5bf Apr 2 00:26:17 postamt kernel: [xfs_bmbt_lookup+636/1471] xfs_bmbt_lookup+0x27c/0x5bf Apr 2 00:26:17 postamt kernel: [xfs_bmap_del_extent+491/2774] xfs_bmap_del_extent+0x1eb/0xad6 Apr 2 00:26:17 postamt kernel: [xfs_mod_incore_sb_batch+60/134] xfs_mod_incore_sb_batch+0x3c/0x86 Apr 2 00:26:17 postamt kernel: [kmem_zone_alloc+61/176] kmem_zone_alloc+0x3d/0xb0 Apr 2 00:26:17 postamt kernel: [xfs_bmap_search_extents+117/279] xfs_bmap_search_extents+0x75/0x117 Apr 2 00:26:17 postamt kernel: [xfs_bunmapi+1851/4334] xfs_bunmapi+0x73b/0x10ee Apr 2 00:26:17 postamt kernel: [xfs_trans_ijoin+43/134] xfs_trans_ijoin+0x2b/0x86 Apr 2 00:26:17 postamt kernel: [xfs_itruncate_finish+617/942] xfs_itruncate_finish+0x269/0x3ae Apr 2 00:26:17 postamt kernel: [xfs_trans_ijoin+43/134] xfs_trans_ijoin+0x2b/0x86 Apr 2 00:26:17 postamt kernel: [xfs_inactive+1058/1282] xfs_inactive+0x422/0x502 Apr 2 00:26:17 postamt fsr[28938]: could not remove tmpdir: /home/.fsr/ag0: Input/output error Apr 2 00:26:17 postamt kernel: [linvfs_clear_inode+140/164] linvfs_clear_inode+0x8c/0xa4 Apr 2 00:26:17 postamt kernel: [dquot_drop+0/106] dquot_drop+0x0/0x6a Apr 2 00:26:17 postamt kernel: [clear_inode+173/290] clear_inode+0xad/0x122 Apr 2 00:26:17 postamt fsr[28938]: could not remove tmpdir: /home/.fsr/ag1: Input/output error Apr 2 00:26:17 postamt kernel: [truncate_inode_pages+23/27] truncate_inode_pages+0x17/0x1b Apr 2 00:26:17 postamt kernel: [generic_delete_inode+207/284] generic_delete_inode+0xcf/0x11c Apr 2 00:26:17 postamt kernel: [iput+83/101] iput+0x53/0x65 Apr 2 00:26:17 postamt kernel: [dput+106/302] dput+0x6a/0x12e Apr 2 00:26:17 postamt kernel: [__fput+258/350] __fput+0x102/0x15e Apr 2 00:26:17 postamt kernel: [filp_close+60/123] filp_close+0x3c/0x7b Apr 2 00:26:17 postamt kernel: [sys_close+86/143] sys_close+0x56/0x8f Apr 2 00:26:17 postamt fsr[28938]: could not remove tmpdir: /home/.fsr/ag2: Input/output error Apr 2 00:26:17 postamt kernel: [sysenter_past_esp+84/117] sysenter_past_esp+0x54/0x75 Apr 2 00:26:17 postamt kernel: Filesystem "sda5": XFS internal error xfs_trans_cancel at line 1031 of file fs/xfs/xfs_trans.c. Caller 0xb1118f9f Apr 2 00:26:17 postamt fsr[28938]: could not remove tmpdir: /home/.fsr/ag3: Input/output error Apr 2 00:26:17 postamt kernel: [xfs_trans_cancel+211/270] xfs_trans_cancel+0xd3/0x10e Apr 2 00:26:17 postamt fsr[28938]: could not remove tmpdir: /home/.fsr/ag4: Input/output error Apr 2 00:26:17 postamt kernel: [xfs_inactive+1080/1282] xfs_inactive+0x438/0x502 Apr 2 00:26:17 postamt kernel: [xfs_inactive+1080/1282] xfs_inactive+0x438/0x502 Apr 2 00:26:17 postamt kernel: [linvfs_clear_inode+140/164] linvfs_clear_inode+0x8c/0xa4 Apr 2 00:26:17 postamt fsr[28938]: could not remove tmpdir: /home/.fsr/ag5: Input/output error Apr 2 00:26:17 postamt kernel: [dquot_drop+0/106] dquot_drop+0x0/0x6a Apr 2 00:26:17 postamt fsr[28938]: could not remove tmpdir: /home/.fsr/ag6: Input/output error Apr 2 00:26:17 postamt kernel: [clear_inode+173/290] clear_inode+0xad/0x122 Apr 2 00:26:17 postamt kernel: [truncate_inode_pages+23/27] truncate_inode_pages+0x17/0x1b Apr 2 00:26:17 postamt fsr[28938]: could not remove tmpdir: /home/.fsr/ag7: Input/output error Apr 2 00:26:17 postamt kernel: [generic_delete_inode+207/284] generic_delete_inode+0xcf/0x11c Apr 2 00:26:17 postamt kernel: [iput+83/101] iput+0x53/0x65 Apr 2 00:26:17 postamt fsr[28938]: could not remove tmpdir: /home/.fsr/ag8: Input/output error Apr 2 00:26:17 postamt kernel: [dput+106/302] dput+0x6a/0x12e Apr 2 00:26:17 postamt kernel: [__fput+258/350] __fput+0x102/0x15e Apr 2 00:26:17 postamt kernel: [filp_close+60/123] filp_close+0x3c/0x7b Apr 2 00:26:17 postamt fsr[28938]: could not remove tmpdir: /home/.fsr/ag9: Input/output error Apr 2 00:26:17 postamt kernel: [sys_close+86/143] sys_close+0x56/0x8f Apr 2 00:26:17 postamt kernel: [sysenter_past_esp+84/117] sysenter_past_esp+0x54/0x75 Apr 2 00:26:17 postamt fsr[28938]: could not remove tmpdir: /home/.fsr/ag10: Input/output error Apr 2 00:26:17 postamt kernel: Filesystem "sda5": Corruption of in-memory data detected. Shutting down filesystem: sda5 Apr 2 00:26:17 postamt fsr[28938]: could not remove tmpdir: /home/.fsr/ag11: Input/output error Apr 2 00:26:17 postamt kernel: Please umount the filesystem, and rectify the problem(s) Apr 2 00:26:17 postamt fsr[28938]: could not remove tmpdir: /home/.fsr/ag12: Input/output error Apr 2 00:26:17 postamt fsr[28938]: could not remove tmpdir: /home/.fsr/ag13: Input/output error Apr 2 00:26:17 postamt fsr[28938]: could not remove tmpdir: /home/.fsr/ag14: Input/output error Apr 2 00:26:17 postamt fsr[28938]: could not remove tmpdir: /home/.fsr/ag15: Input/output error Apr 2 00:26:17 postamt fsr[28938]: could not remove tmpdir: /home/.fsr: Input/output error Apr 2 00:26:17 postamt fsr[29047]: /home start inode=0 Apr 2 00:26:17 postamt fsr[29047]: could not create tmpdir: /home/.fsr: Input/output error Apr 2 00:26:17 postamt fsr[29048]: /home start inode=0 Apr 2 00:26:17 postamt fsr[29048]: could not create tmpdir: /home/.fsr: Input/output error Apr 2 00:26:17 postamt fsr[29049]: /home start inode=0 Apr 2 00:26:17 postamt fsr[29049]: could not create tmpdir: /home/.fsr: Input/output error Apr 2 00:26:17 postamt fsr[29050]: /home start inode=0 Apr 2 00:26:17 postamt fsr[29050]: could not create tmpdir: /home/.fsr: Input/output error Apr 2 00:26:17 postamt fsr[29051]: /home start inode=0 Apr 2 00:26:17 postamt fsr[29051]: could not create tmpdir: /home/.fsr: Input/output error Apr 2 00:26:17 postamt fsr[29052]: /home start inode=0 Apr 2 00:26:17 postamt fsr[29052]: could not create tmpdir: /home/.fsr: Input/output error Apr 2 00:26:17 postamt fsr[29053]: /home start inode=0 Apr 2 00:26:17 postamt fsr[29053]: could not create tmpdir: /home/.fsr: Input/output error Apr 2 00:26:17 postamt fsr[25409]: Completed all 10 passes -- Ralf Hildebrandt (i.A. des IT-Zentrums) Ralf.Hildebrandt@charite.de Charite - Universitätsmedizin Berlin Tel. +49 (0)30-450 570-155 Gemeinsame Einrichtung von FU- und HU-Berlin Fax. +49 (0)30-450 570-962 IT-Zentrum Standort CBF send no mail to spamtrap@charite.de From owner-linux-xfs@oss.sgi.com Mon Apr 3 15:12:28 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 03 Apr 2006 15:12:31 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k33MCPgC000512 for ; Mon, 3 Apr 2006 15:12:27 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA01614; Wed, 5 Apr 2006 08:07:37 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k34M7YJC1100643; Wed, 5 Apr 2006 08:07:34 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k34M7WU81103108; Wed, 5 Apr 2006 08:07:32 +1000 (EST) Date: Wed, 5 Apr 2006 08:07:31 +1000 From: Nathan Scott To: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: 2.6.16.1: XFS internal error xfs_btree_check_lblock at line 215 of file fs/xfs/xfs_btree.c Message-ID: <20060405080731.B1071351@wobbly.melbourne.sgi.com> References: <20060404212144.GM15722@charite.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20060404212144.GM15722@charite.de>; from Ralf.Hildebrandt@charite.de on Tue, Apr 04, 2006 at 11:21:44PM +0200 X-archive-position: 7579 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Status: O Content-Length: 508 Lines: 14 On Tue, Apr 04, 2006 at 11:21:44PM +0200, Ralf Hildebrandt wrote: > I was running xfs_fsr on our /home at night when this happened: > (Kernel 2.6.16.1) > ... > Apr 2 00:26:17 postamt kernel: Filesystem "sda5": XFS internal error xfs_btree_check_lblock at line 215 of file fs/xfs/xfs_btree.c. Caller 0xb10dba58 > Apr 2 00:26:17 postamt kernel: [xfs_btree_check_lblock+82/407] xfs_btree_check_lblock+0x52/0x197 What does xfs_repair report? Is it (the forced shutdown) reproducible? thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Apr 3 15:26:03 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 03 Apr 2006 15:26:06 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k33MQ1gC002127 for ; Mon, 3 Apr 2006 15:26:02 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA01892; Wed, 5 Apr 2006 08:21:15 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k34MLCJC1102450; Wed, 5 Apr 2006 08:21:13 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k34ML9671103849; Wed, 5 Apr 2006 08:21:09 +1000 (EST) Date: Wed, 5 Apr 2006 08:21:08 +1000 From: Nathan Scott To: sen@fnal.gov Cc: linux-xfs@oss.sgi.com Subject: Re: XFS partition recovery Message-ID: <20060405082108.A1101521@wobbly.melbourne.sgi.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from evgeniy.sharapov@gmail.com on Tue, Apr 04, 2006 at 03:42:50AM -0400 X-archive-position: 7580 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Status: O Content-Length: 1192 Lines: 35 On Tue, Apr 04, 2006 at 03:42:50AM -0400, Evgeniy Sharapov wrote: > I have XFS /home partition (fortunately not /). I can not mount it because > of the error during reading the superblock. > ... Actually, looks like the superblock is fine, which is good - your error message seems to be coming from a failed read in the log. > - zero log... > xfs_repair: read failed: Input/output error > senntb ~ # xfs_repair -v /dev/hda7 > Phase 1 - find and verify superblock... > Phase 2 - using internal log > - zero log... > xfs_repair: read failed: Input/output error > senntb ~ # > <-------/cut------------> So, your IDE device is returning IO errors - you're in pretty bad shape. You have two options: - use dd (or dd_rescue) with error-skipping-mode enabled to get what data remains off to a working device. Then run xfs_repair on that. - restore from your last good backup, probably again to a different device since the one above looks like its on its last legs. > http://docs.cray.com/books/S-2377-22/html-S-2377-22/fixed6bhdyq9i26.html) Yeah, from a quick look that procedure will only help you if you've got a mountable filesystem, as you noticed. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Apr 3 17:48:08 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 03 Apr 2006 17:48:13 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k340m6gC028630 for ; Mon, 3 Apr 2006 17:48:07 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA04437; Wed, 5 Apr 2006 10:43:23 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 4B4704822BFF; Wed, 5 Apr 2006 10:43:22 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 951661 - fix SB imaxpct validation Message-Id: <20060405004322.4B4704822BFF@chook.melbourne.sgi.com> Date: Wed, 5 Apr 2006 10:43:22 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 7581 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Status: O Content-Length: 514 Lines: 15 Fix superblock validation regression for the zero imaxpct case. Thanks to kjamieson for noticing. Date: Wed Apr 5 10:42:53 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: dgc,kjamieson@bycast.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:25675a xfs_mount.c - 1.377 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_mount.c.diff?r1=text&tr1=1.377&r2=text&tr2=1.376&f=h From owner-linux-xfs@oss.sgi.com Mon Apr 3 17:50:04 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 03 Apr 2006 17:50:06 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k340o2gC029011 for ; Mon, 3 Apr 2006 17:50:03 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA04492; Wed, 5 Apr 2006 10:45:21 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 809624822BFF; Wed, 5 Apr 2006 10:45:21 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 951662 - fix writepage nonblock mode Message-Id: <20060405004521.809624822BFF@chook.melbourne.sgi.com> Date: Wed, 5 Apr 2006 10:45:21 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 7582 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Status: O Content-Length: 536 Lines: 15 Fix a writepage regression where we accidentally stopped honouring nonblock mode with the new IO path code (since 2.6.16). Date: Wed Apr 5 10:44:55 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: dgc The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:25676a linux-2.6/xfs_aops.c - 1.124 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_aops.c.diff?r1=text&tr1=1.124&r2=text&tr2=1.123&f=h From owner-linux-xfs@oss.sgi.com Mon Apr 3 18:02:13 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 03 Apr 2006 18:02:14 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k3412AgC032145 for ; Mon, 3 Apr 2006 18:02:11 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA04752; Wed, 5 Apr 2006 10:57:28 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 20C394822BFF; Wed, 5 Apr 2006 10:57:27 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 951418 - xfs_fsr Message-Id: <20060405005727.20C394822BFF@chook.melbourne.sgi.com> Date: Wed, 5 Apr 2006 10:57:27 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 7583 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Status: O Content-Length: 458 Lines: 14 Fix some memory and file descriptor leaks in xfs_fsr. Date: Wed Apr 5 10:57:02 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-cmds Inspected by: dgc The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:25680a xfsdump/fsr/xfs_fsr.c - 1.20 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/fsr/xfs_fsr.c.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h From owner-linux-xfs@oss.sgi.com Mon Apr 3 18:05:17 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 03 Apr 2006 18:05:19 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k3415FgC000444 for ; Mon, 3 Apr 2006 18:05:16 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA04887; Wed, 5 Apr 2006 11:00:34 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 5059A4822BFF; Wed, 5 Apr 2006 11:00:34 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 951419 - xfs_fsr Message-Id: <20060405010034.5059A4822BFF@chook.melbourne.sgi.com> Date: Wed, 5 Apr 2006 11:00:34 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 7584 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Status: O Content-Length: 511 Lines: 15 Fix incorrect handling of several extended inode flags/fields by xfs_fsr (project IDs, extsize, realtime). Date: Wed Apr 5 10:59:32 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-cmds Inspected by: dgc The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:25682a xfsdump/fsr/xfs_fsr.c - 1.22 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/fsr/xfs_fsr.c.diff?r1=text&tr1=1.22&r2=text&tr2=1.21&f=h From owner-linux-xfs@oss.sgi.com Mon Apr 3 19:27:32 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 03 Apr 2006 19:27:32 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k342RTgC014276 for ; Mon, 3 Apr 2006 19:27:31 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA05957; Wed, 5 Apr 2006 12:22:46 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16346) id ACC6C4822BFF; Wed, 5 Apr 2006 12:22:44 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: PARTIAL TAKE 951551 - System bogged down - shrink_icache_memory Message-Id: <20060405022244.ACC6C4822BFF@chook.melbourne.sgi.com> Date: Wed, 5 Apr 2006 12:22:44 +1000 (EST) From: dgc@sgi.com (David Chinner) X-archive-position: 7585 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: linux-xfs Status: O Content-Length: 1091 Lines: 27 Fix inode reclaim scalability regression. When a filesystem has millions of inodes cached and has sparse cluster population, removing inodes from the cluster hash consumes excessive amounts of CPU time. Reduce the CPU cost by making removal O(1) via use of a double linked list for the hash chains. Date: Wed Apr 5 12:21:54 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/dgc/isms/2.6.x-xfs Inspected by: nathans,tes The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:25683a fs/xfs/xfs_iget.c - 1.212 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_iget.c.diff?r1=text&tr1=1.212&r2=text&tr2=1.211&f=h - Convert cluster hash list to a double linked list to speed xfs_iextract() when large numbers of inodes are cached. fs/xfs/xfs_inode.h - 1.212 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode.h.diff?r1=text&tr1=1.212&r2=text&tr2=1.211&f=h - Convert cluster hash list to a double linked list to speed xfs_iextract() when large numbers of inodes are cached. From owner-linux-xfs@oss.sgi.com Mon Apr 3 22:13:06 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 03 Apr 2006 22:13:07 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k345D4gC003798 for ; Mon, 3 Apr 2006 22:13:05 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA08005; Wed, 5 Apr 2006 15:08:18 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16346) id 651FF4822BFF; Wed, 5 Apr 2006 15:08:16 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: PARTIAL TAKE 946321 - Inode use-after-free during an unpin Message-Id: <20060405050816.651FF4822BFF@chook.melbourne.sgi.com> Date: Wed, 5 Apr 2006 15:08:16 +1000 (EST) From: dgc@sgi.com (David Chinner) X-archive-position: 7586 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: linux-xfs Status: O Content-Length: 961 Lines: 25 Fix an inode use-after-free durin an unpin. When reclaiming inodes that have been unlinked, we may need to execute transactions during reclaim. By the time the transaction has hit the disk, the linux inode and xfs vnode may already have been freed so we can't reference them safely. Use the known xfs inode state to determine if it is safe to reference the vnode and linux inode during the unpin operation. Date: Wed Apr 5 15:06:48 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/dgc/isms/2.6.x-xfs Inspected by: nathans The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:25687a fs/xfs/xfs_inode.c - 1.436 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode.c.diff?r1=text&tr1=1.436&r2=text&tr2=1.435&f=h - Don't try to mark an inode dirty during an unpin if it is being reclaimed. If it is being reclaimed, the inode may have already been freed. From owner-linux-xfs@oss.sgi.com Tue Apr 4 17:10:28 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Apr 2006 17:10:30 -0700 (PDT) Received: from smtp.latinmail.com (smtp.latinmail.com [62.37.236.186]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k350ARgC024328 for ; Tue, 4 Apr 2006 17:10:28 -0700 Received: by smtp.latinmail.com (Postfix, from userid 65534) id 00DBCA55195; Wed, 5 Apr 2006 17:30:15 +0200 (CEST) Received: from unknown (unknown [172.17.224.53]) by smtp.latinmail.com (Postfix) with SMTP id DE7E2A53B63; Wed, 5 Apr 2006 17:30:15 +0200 (CEST) From: "Amobe Seko Philipe" To: "amobe.seko.philipe1@latinmail.com" Subject: Bonjour Content-Type: multipart/mixed; boundary="latinmail.com_ltwebml02.localdomain_23cb7995f275e04cd83b2bad00558740" Importance: normal MIME-Version: 1.0 Message-Id: <20060405153015.DE7E2A53B63@smtp.latinmail.com> Date: Wed, 5 Apr 2006 17:30:15 +0200 (CEST) X-Bogosity: No, tests=bogofilter, spamicity=0.226399, version=0.15.13 X-archive-position: 7587 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: amobe.seko.philipe1@latinmail.com Precedence: bulk X-list: linux-xfs Status: O Content-Length: 3250 Lines: 63 --latinmail.com_ltwebml02.localdomain_23cb7995f275e04cd83b2bad00558740 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Administrateur Ex=E9cutif du Comit=E9 d'Attribution des March=E9s et Contrats Corporation Nationale P=E9troli=E8re CI Email. amobe.seko.philipe1@latinmail.com / docteur_amobesekop@mail2doctor.com Tel : 22 508 569 621 (C.N.P.C.I) Bonjour, Je suis Docteur Amob=E9 S=E9ko Philipe, de la R=E9publique de C=F4te d'Ivoi= re, Administrateur Ex=E9cutif du Comit=E9 d'Attribution des March=E9s et Co= ntrats =E0 la Corporation Nationale P=E9troli=E8re de C=F4te d'Ivoire (C.N.P.C.I). J'ai =E9t=E9 dans cette posi= tion durant les cinq derni=E8res ann=E9es mais, je n'ai rien qui puisse mon= trer cela, j'aurais aim=E9 qu'ensemble, nous formions un partenariat d'affaires avec pour crit=E8res exclusifs l'ho= nn=EAtet=E9 et la confiance, partenariat dans lequel tous les deux, nous ti= rerons =E9norm=E9ment profit. En ma qualit=E9 d=92Administrateur Ex=E9cutif du Comit=E9 d'Attribution de = March=E9s et Contrats, je vous octroierai une faveur d'un contrat de 21 mil= lions ($ 21.000.000,00 USD) pour la fourniture =E0 nos Forages, Plateformes et Raffineries, de Turbines= =E0 Gaz, Turbocompresseurs, Foreuses verticales, Enrobeuses, Anneaux Pipel= ines et d'=E9quipements, ainsi une avance sur frais de 10,5 millions US sera mobili= s=E9e =E0 vous en tant que fournisseur au d=E9part pour commencer le travai= l. Mais aussit=F4t que les frais avanc=E9s de 10,5 millions sont en votre poss= ession, vous ne ferez aucune fourniture d'aucune sorte. Vous et moi m=EAme = partagerons, sur la base de 15% pour vous et 85% pour moi , les premiers frais avanc=E9s pour l= 'avance forfaitaire, de la sorte la seconde tranche du paiement servirait = =E0 r=E9gler un fournisseur agr=E9=E9 avec qui nous ferons de la sous-trait= ance pour la fourniture du mat=E9riel en temps exigible, le plus important= r=E9side dans la livraison du mat=E9riel en temps opportun car nous avons un boom de la consommation p=E9troli=E8re, donc un d=E9fit nouve= au =E0 relever de 350 000 nouveaux foyers =E0 fournir en gaz domestique et = environ 280 000 nouveaux v=E9hicules qui s'ajoutent au parc automobile national de notre pa= ys qui ont besoin dans l'imm=E9diat d'=EAtre servi en hydrocarbures pour le= urs consommations journali=E8res. Cette situation a conduit le Comit=E9 d'Attribution =E0 ouv= rir un march=E9 dont le projet de r=E9alisation n'exc=E8dera pas les 3 ( tr= ois) semaines, depuis la date d'attribution du march=E9 au fournisseur jusqu'=E0 la livraison du mat=E9ri= el dans nos locaux techniques. La raison pour laquelle je voudrais que nous partagions cette a= vance est que je suis l=92Administrateur Ex=E9cutif du Comit=E9 depuis cinq= ann=E9es, et je n'ai m=EAme pas une maison personnelle m'appartenant, mon = salaire tr=E8s l=E9ger, repr=E9sente celui d'un cadre africain de pays sous= -d=E9velopp=E9s. Je ne suis pas =E0 mesure de prendre soin ad=E9quatement d= e mes enfants. En fait, les choses sont tr=E8s difficiles pour moi et si je= pars =E0 la retraite, je n'aurai rien sur quoi reposer. --latinmail.com_ltwebml02.localdomain_23cb7995f275e04cd83b2bad00558740-- From owner-linux-xfs@oss.sgi.com Tue Apr 4 20:02:47 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Apr 2006 20:02:50 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k3532jgC009929 for ; Tue, 4 Apr 2006 20:02:46 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA25573; Thu, 6 Apr 2006 12:58:01 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k362vxJC1137623; Thu, 6 Apr 2006 12:57:59 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k362vu9R1136362; Thu, 6 Apr 2006 12:57:56 +1000 (EST) Date: Thu, 6 Apr 2006 12:57:56 +1000 From: Nathan Scott To: LKML Cc: linux-xfs@oss.sgi.com Subject: Re: Bonnie++ Burps on XFS Message-ID: <20060406125756.H1110920@wobbly.melbourne.sgi.com> References: <20060406023445.GB5806@kurtwerks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20060406023445.GB5806@kurtwerks.com>; from kwall@kurtwerks.com on Wed, Apr 05, 2006 at 10:34:45PM -0400 X-archive-position: 7588 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Status: O Content-Length: 794 Lines: 24 On Wed, Apr 05, 2006 at 10:34:45PM -0400, Kurt Wall wrote: > I've been using bonnie++ off and on for a long time. Suddenly, it has > started failing when run against an XFS filesystem situated on a SATA > drive. Here's the output of a run: [ Please report these things to linux-xfs@oss.sgi.com... ] > Delete files in sequential order...Bonnie: drastic I/O error (rmdir): Anything in your system log? > clear if the problems is XFS, some other piece of the kernel, or > bonnie++. Neither dmesg nor syslog shows anything amiss. I suppose > I could strace the run, but I'm not especially eager to deal with > a multi-gigabyte output file if there is a more focused method to > isolate the problem. See if 2.6.16.1 fails too for starters then we'll take it from there. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Apr 4 22:17:56 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 04 Apr 2006 22:18:02 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k355HsgC030037 for ; Tue, 4 Apr 2006 22:17:55 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA27111; Thu, 6 Apr 2006 15:13:08 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k365D5JC1139218; Thu, 6 Apr 2006 15:13:05 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k365D1Jm1137350; Thu, 6 Apr 2006 15:13:01 +1000 (EST) Date: Thu, 6 Apr 2006 15:13:01 +1000 From: Nathan Scott To: Kurt Wall Cc: LKML , linux-xfs@oss.sgi.com Subject: Re: Bonnie++ Burps on XFS Message-ID: <20060406151301.I1110920@wobbly.melbourne.sgi.com> References: <20060406023445.GB5806@kurtwerks.com> <20060406125756.H1110920@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20060406125756.H1110920@wobbly.melbourne.sgi.com>; from nathans@sgi.com on Thu, Apr 06, 2006 at 12:57:56PM +1000 X-archive-position: 7589 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Status: O Content-Length: 658 Lines: 22 On Thu, Apr 06, 2006 at 12:57:56PM +1000, Nathan Scott wrote: > On Wed, Apr 05, 2006 at 10:34:45PM -0400, Kurt Wall wrote: > > I've been using bonnie++ off and on for a long time. Suddenly, it has > > started failing when run against an XFS filesystem situated on a SATA > > drive. Here's the output of a run: > > [ Please report these things to linux-xfs@oss.sgi.com... ] > > > Delete files in sequential order...Bonnie: drastic I/O error (rmdir): > > Anything in your system log? Lemme answer that for you - "no". I've reproduced the problem, I'll get back to you once I've nutted out whats gone wrong. Thanks for reporting it. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Apr 5 02:10:59 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Apr 2006 02:11:04 -0700 (PDT) Received: from mail.ukfsn.org (s2.ukfsn.org [217.158.120.143]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k359AxgC015920 for ; Wed, 5 Apr 2006 02:10:59 -0700 Received: from localhost.localdomain (i-83-67-36-194.freedom2surf.net [83.67.36.194]) by mail.ukfsn.org (Postfix) with ESMTP id 83F37E719C; Thu, 6 Apr 2006 08:57:09 +0100 (BST) Received: from [10.0.0.90] (helo=[10.0.0.90]) by localhost.localdomain with esmtp (Exim 4.50) id 1FRPPH-00066w-IG; Thu, 06 Apr 2006 08:59:55 +0100 Message-ID: <4434CA7A.6020802@dgreaves.com> Date: Thu, 06 Apr 2006 08:59:54 +0100 From: David Greaves User-Agent: Debian Thunderbird 1.0.7 (X11/20051017) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nathan Scott Cc: Kurt Wall , LKML , linux-xfs@oss.sgi.com Subject: Re: Bonnie++ Burps on XFS References: <20060406023445.GB5806@kurtwerks.com> <20060406125756.H1110920@wobbly.melbourne.sgi.com> <20060406151301.I1110920@wobbly.melbourne.sgi.com> In-Reply-To: <20060406151301.I1110920@wobbly.melbourne.sgi.com> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 7590 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: david@dgreaves.com Precedence: bulk X-list: linux-xfs Status: O Content-Length: 1663 Lines: 69 Nathan Scott wrote: >On Thu, Apr 06, 2006 at 12:57:56PM +1000, Nathan Scott wrote: > > >>On Wed, Apr 05, 2006 at 10:34:45PM -0400, Kurt Wall wrote: >> >> >>>I've been using bonnie++ off and on for a long time. Suddenly, it has >>>started failing when run against an XFS filesystem situated on a SATA >>>drive. Here's the output of a run: >>> >>> >>[ Please report these things to linux-xfs@oss.sgi.com... ] >> >> >> >>>Delete files in sequential order...Bonnie: drastic I/O error (rmdir): >>> >>> >>Anything in your system log? >> >> > >Lemme answer that for you - "no". I've reproduced the problem, >I'll get back to you once I've nutted out whats gone wrong. > >Thanks for reporting it. > >cheers. > > > Me too. 2.6.16 I had filesystem corruption and needed ran xfs_repair. After I finished I removed most of the lost and found bits but was left with: haze:/scratch/lost+found# ll total 28 drwxr-xr-x 4 root root 38 2006-04-02 08:29 ./ drwxrwxrwx 26 root root 4096 2006-04-04 18:25 ../ drwxrwxr-x 2 1046 1046 8192 2006-04-02 08:30 658616481/ drwxrwxr-x 2 1046 1046 8192 2006-04-02 08:22 823441168/ haze:/scratch/lost+found# rmdir * rmdir: `658616481': Directory not empty rmdir: `823441168': Directory not empty haze:/scratch/lost+found# ll * 658616481: total 12 drwxrwxr-x 2 1046 1046 8192 2006-04-02 08:30 ./ drwxr-xr-x 4 root root 38 2006-04-02 08:29 ../ 823441168: total 12 drwxrwxr-x 2 1046 1046 8192 2006-04-02 08:22 ./ drwxr-xr-x 4 root root 38 2006-04-02 08:29 ../ Obviously I had an fs corruption (due to raid failure due to some bogus libata errors) so this may not be the same thing. David -- From owner-linux-xfs@oss.sgi.com Wed Apr 5 04:02:20 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Apr 2006 04:02:25 -0700 (PDT) Received: from elfstone.noviforum.si (elfstone.noviforum.si [193.189.169.107]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k35B2JgC026399 for ; Wed, 5 Apr 2006 04:02:19 -0700 Received: from localhost (localhost [127.0.0.1]) by elfstone.noviforum.si (ESMTP) with ESMTP id D235F1B914 for ; Thu, 6 Apr 2006 11:30:23 +0200 (CEST) Received: from dacun.noviforum.si (dacun.noviforum.si [192.168.2.26]) by elfstone.noviforum.si (ESMTP) with ESMTP id ACAE21B912 for ; Thu, 6 Apr 2006 11:30:23 +0200 (CEST) Subject: dcache.c From: Gorazd Golob To: linux-xfs@oss.sgi.com Content-Type: text/plain Date: Thu, 06 Apr 2006 11:34:13 +0200 Message-Id: <1144316053.23522.13.camel@dacun.noviforum.si> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 Content-Transfer-Encoding: 7bit X-archive-position: 7592 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: gorazd.golob@noviforum.si Precedence: bulk X-list: linux-xfs Status: O Content-Length: 1962 Lines: 47 Hello! Does this error have something to do with XFS or straight VFS? All partitions on systems are XFS. tnx, Gorazd [636117.626297] kernel BUG at fs/dcache.c:795! [636117.635583] invalid operand: 0000 [#5] [636117.644775] SMP [636117.653858] Modules linked in: [636117.662962] CPU: 1 [636117.662963] EIP: 0060:[] Not tainted VLI [636117.662965] EFLAGS: 00010202 (2.6.15.6-1) [636117.690389] EIP is at d_instantiate+0x1e/0x5f [636117.699631] eax: e43d1b7c ebx: e43d1bbc ecx: 00008000 edx: dfb3494c [636117.709144] esi: dfb3494c edi: e43d1b7c ebp: dfb347d0 esp: cfcb1d7c [636117.718682] ds: 007b es: 007b ss: 0068 [636117.728195] Process java (pid: 20902, threadinfo=cfcb0000 task=f68e9540) [636117.728527] Stack: 000081a4 00000000 00000000 c02f91e8 e43d1b7c dfb3494c cfcb1e3c cfcb1da8 [636117.738436] 00000000 dfb347b0 dfb3494c dfb3492c c017331f e43d194c dd2e6055 00000001 [636117.748284] dd2e6057 e43d194c cfcb1e14 ed111dac ffffffec c0180f47 ed111dac c06f8b00 [636117.758029] Call Trace: [636117.776745] [] linvfs_mknod+0x170/0x270 [636117.786377] [] sys_stat64+0x18/0x36 [636117.796020] [] dput+0x54/0x1e8 [636117.805665] [] __link_path_walk+0x5fb/0xed7 [636117.815453] [] mntput_no_expire+0x22/0x89 [636117.825225] [] permission+0x85/0xaa [636117.834949] [] linvfs_create+0x0/0xd [636117.844653] [] vfs_create+0x9e/0xf4 [636117.854239] [] open_namei+0xca/0x66c [636117.863769] [] filp_open+0x38/0x60 [636117.873169] [] sys_stat64+0x18/0x36 [636117.882422] [] do_sys_open+0x5b/0xf6 [636117.891487] [] syscall_call+0x7/0xb [636117.900374] Code: 04 24 e8 0a fe ff ff 83 c4 18 5b 5f c3 83 ec 0c 89 7c 24 08 8b 7c 24 10 89 1c 24 89 74 24 04 8d 5f 40 8b 74 24 14 39 5f 40 74 08 <0f> 0b 1b 03 7b 84 5d c0 b8 00 8b 6f c0 e8 49 f4 40 00 85 f6 74 [636117.946096] From owner-linux-xfs@oss.sgi.com Wed Apr 5 08:04:39 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 05 Apr 2006 08:04:43 -0700 (PDT) Received: from spooner.celestial.com (spooner.celestial.com [192.136.111.35]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k35F4dgC018988 for ; Wed, 5 Apr 2006 08:04:39 -0700 Received: from localhost (localhost [127.0.0.1]) by spooner.celestial.com (Postfix) with ESMTP id 076DB30E3E23; Thu, 6 Apr 2006 06:48:17 -0700 (PDT) Received: from spooner.celestial.com ([127.0.0.1]) by localhost (spooner.celestial.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 21471-02; Thu, 6 Apr 2006 06:48:16 -0700 (PDT) Received: from luther.kurtwerks.com (c-67-165-68-161.hsd1.pa.comcast.net [67.165.68.161]) by spooner.celestial.com (Postfix) with ESMTP id C86503036D31; Thu, 6 Apr 2006 06:48:16 -0700 (PDT) Received: by luther.kurtwerks.com (Postfix, from userid 1000) id 99CD034A418; Thu, 6 Apr 2006 09:48:15 -0400 (EDT) Date: Thu, 6 Apr 2006 09:48:15 -0400 From: Kurt Wall To: Nathan Scott Cc: linux-xfs@oss.sgi.com Subject: Re: Bonnie++ Burps on XFS Message-ID: <20060406134815.GA5678@kurtwerks.com> References: <20060406023445.GB5806@kurtwerks.com> <20060406125756.H1110920@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060406125756.H1110920@wobbly.melbourne.sgi.com> User-Agent: Mutt/1.4.2.1i X-Operating-System: Linux 2.6.16krw X-Woot: Woot! X-archive-position: 7593 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kwall@kurtwerks.com Precedence: bulk X-list: linux-xfs Status: O Content-Length: 781 Lines: 30 On Thu, Apr 06, 2006 at 12:57:56PM +1000, Nathan Scott took 29 lines to write: > On Wed, Apr 05, 2006 at 10:34:45PM -0400, Kurt Wall wrote: > > I've been using bonnie++ off and on for a long time. Suddenly, it has > > started failing when run against an XFS filesystem situated on a SATA > > drive. Here's the output of a run: > > [ Please report these things to linux-xfs@oss.sgi.com... ] Will do (note CC). > > Delete files in sequential order...Bonnie: drastic I/O error (rmdir): > > Anything in your system log? No. > See if 2.6.16.1 fails too for starters then we'll take it from there. As soon as the test completes on 2.6.16, I'll spin up a 2.6.16.1 kernel and try that. > cheers. Thanks, Kurt -- Chemistry is applied theology. -- Augustus Stanley Owsley III From owner-linux-xfs@oss.sgi.com Wed Apr 5 12:18:56 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Apr 2006 12:15:27 -0700 (PDT) Received: from saraswathi.solana.com ([198.99.130.12]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k35JIpgC009036 for ; Wed, 5 Apr 2006 12:18:55 -0700 Received: from ccure.user-mode-linux.org (littleton.addtoit.com [198.99.130.129]) by saraswathi.solana.com (8.13.1/8.13.1) with ESMTP id k36Hs8T1020291; Thu, 6 Apr 2006 13:54:08 -0400 Received: from ccure.user-mode-linux.org (localhost.localdomain [127.0.0.1]) by ccure.user-mode-linux.org (8.13.6/8.13.4) with ESMTP id k36GtMvc005146; Thu, 6 Apr 2006 12:55:23 -0400 Message-Id: <200604061655.k36GtMvc005146@ccure.user-mode-linux.org> X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.0.4 To: akpm@osdl.org cc: linux-xfs@oss.sgi.com, Daniel Phillips , linux-kernel@vger.kernel.org, user-mode-linux-devel@lists.sourceforge.net Subject: [PATCH 1/2] Add GFP_NOWAIT Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 06 Apr 2006 12:55:22 -0400 From: Jeff Dike X-archive-position: 7594 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jdike@addtoit.com Precedence: bulk X-list: linux-xfs Status: O Content-Length: 1426 Lines: 34 Introduce GFP_NOWAIT, as an alias for GFP_ATOMIC & ~__GFP_HIGH. This also changes XFS, which is the only in-tree user of this idiom that I could find. The XFS piece is compile-tested only. Signed-off-by: Jeff Dike Index: linux-2.6.16/fs/xfs/linux-2.6/xfs_buf.c =================================================================== --- linux-2.6.16.orig/fs/xfs/linux-2.6/xfs_buf.c 2006-04-06 12:16:14.000000000 -0400 +++ linux-2.6.16/fs/xfs/linux-2.6/xfs_buf.c 2006-04-06 12:16:54.000000000 -0400 @@ -182,7 +182,7 @@ free_address( { a_list_t *aentry; - aentry = kmalloc(sizeof(a_list_t), GFP_ATOMIC & ~__GFP_HIGH); + aentry = kmalloc(sizeof(a_list_t), GFP_NOWAIT); if (likely(aentry)) { spin_lock(&as_lock); aentry->next = as_free_head; Index: linux-2.6.16/include/linux/gfp.h =================================================================== --- linux-2.6.16.orig/include/linux/gfp.h 2006-03-21 11:50:12.000000000 -0500 +++ linux-2.6.16/include/linux/gfp.h 2006-04-06 12:15:18.000000000 -0400 @@ -57,6 +57,8 @@ struct vm_area_struct; __GFP_NOFAIL|__GFP_NORETRY|__GFP_NO_GROW|__GFP_COMP| \ __GFP_NOMEMALLOC|__GFP_HARDWALL) +/* This equals 0, but use constants in case they ever change */ +#define GFP_NOWAIT (GFP_ATOMIC & ~__GFP_HIGH) /* GFP_ATOMIC means both !wait (__GFP_WAIT not set) and use emergency pool */ #define GFP_ATOMIC (__GFP_HIGH) #define GFP_NOIO (__GFP_WAIT) From owner-linux-xfs@oss.sgi.com Thu Apr 6 15:12:25 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Apr 2006 15:12:36 -0700 (PDT) Received: from larry.melbourne.sgi.com ([61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k36MCNgC001296 for ; Thu, 6 Apr 2006 15:12:24 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA07326; Fri, 7 Apr 2006 08:12:02 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k36MBuJC1159397; Fri, 7 Apr 2006 08:11:57 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k36MBmKo1159170; Fri, 7 Apr 2006 08:11:48 +1000 (EST) Date: Fri, 7 Apr 2006 08:11:48 +1000 From: Nathan Scott To: Jeff Dike Cc: akpm@osdl.org, linux-xfs@oss.sgi.com, Daniel Phillips , linux-kernel@vger.kernel.org, user-mode-linux-devel@lists.sourceforge.net Subject: Re: [PATCH 1/2] Add GFP_NOWAIT Message-ID: <20060407081148.J1110920@wobbly.melbourne.sgi.com> References: <200604061655.k36GtMvc005146@ccure.user-mode-linux.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200604061655.k36GtMvc005146@ccure.user-mode-linux.org>; from jdike@addtoit.com on Thu, Apr 06, 2006 at 12:55:22PM -0400 X-archive-position: 7595 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Status: O Content-Length: 396 Lines: 16 On Thu, Apr 06, 2006 at 12:55:22PM -0400, Jeff Dike wrote: > Introduce GFP_NOWAIT, as an alias for GFP_ATOMIC & ~__GFP_HIGH. > > This also changes XFS, which is the only in-tree user of this idiom that I > could find. The XFS piece is compile-tested only. Looks fine, thanks Jeff. > Signed-off-by: Jeff Dike Acked-by: Nathan Scott cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Apr 6 19:08:57 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 06 Apr 2006 19:09:02 -0700 (PDT) Received: from spooner.celestial.com ([192.136.111.35]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k3728vgC023744 for ; Thu, 6 Apr 2006 19:08:57 -0700 Received: from localhost (localhost [127.0.0.1]) by spooner.celestial.com (Postfix) with ESMTP id 77E3630E6E2B; Thu, 6 Apr 2006 19:08:50 -0700 (PDT) Received: from spooner.celestial.com ([127.0.0.1]) by localhost (spooner.celestial.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 17763-02; Thu, 6 Apr 2006 19:08:50 -0700 (PDT) Received: from luther.kurtwerks.com (c-67-165-68-161.hsd1.pa.comcast.net [67.165.68.161]) by spooner.celestial.com (Postfix) with ESMTP id 3546B301DE1B; Thu, 6 Apr 2006 19:08:50 -0700 (PDT) Received: by luther.kurtwerks.com (Postfix, from userid 1000) id 8881C2958; Thu, 6 Apr 2006 22:08:49 -0400 (EDT) Date: Thu, 6 Apr 2006 22:08:48 -0400 From: Kurt Wall To: linux-xfs@oss.sgi.com Cc: nathans@sgi.com Subject: Re: Bonnie++ Burps on XFS Message-ID: <20060407020848.GA24446@kurtwerks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060406023445.GB5806@kurtwerks.com> User-Agent: Mutt/1.4.2.1i X-Operating-System: Linux 2.6.16krw X-Woot: Woot! X-archive-position: 7596 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kwall@kurtwerks.com Precedence: bulk X-list: linux-xfs Status: O Content-Length: 304 Lines: 13 Running Bonnie++ against XFS on 2.6.16 does not encounter the same fault. I'm running it against a 2.6.16.1 test now and will report the results shortly. Regards, Kurt -- Commitment, n.: Commitment can be illustrated by a breakfast of ham and eggs. The chicken was involved, the pig was committed. From owner-linux-xfs@oss.sgi.com Fri Apr 7 00:23:33 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Apr 2006 00:24:34 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k377NVgC024561 for ; Fri, 7 Apr 2006 00:23:32 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA13941; Fri, 7 Apr 2006 17:23:31 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k377NQJC1169741; Fri, 7 Apr 2006 17:23:28 +1000 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id k378JUDh002811; Fri, 7 Apr 2006 18:19:31 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id k378JSNb002809; Fri, 7 Apr 2006 18:19:28 +1000 Date: Fri, 7 Apr 2006 18:19:28 +1000 From: Nathan Scott To: Kurt Wall Cc: linux-xfs@oss.sgi.com Subject: Re: Bonnie++ Burps on XFS Message-ID: <20060407081928.GD1598@frodo> References: <20060406023445.GB5806@kurtwerks.com> <20060407020848.GA24446@kurtwerks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060407020848.GA24446@kurtwerks.com> User-Agent: Mutt/1.5.3i X-archive-position: 7597 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Status: O Content-Length: 566 Lines: 22 On Thu, Apr 06, 2006 at 10:08:48PM -0400, Kurt Wall wrote: > > Running Bonnie++ against XFS on 2.6.16 does not encounter the > same fault. I'm running it against a 2.6.16.1 test now and will > report the results shortly. Hi Kurt, I've got this narrowed down to a few XFS mods now, I'm still binary chopping through the last few to narrow it down to one (test case takes awhile for me). Should have it narrowed right down on Monday, and will get the owner of the offending change to fix it up then. I think you'll find 2.6.16.1 is OK too. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Fri Apr 7 01:50:34 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Apr 2006 01:50:37 -0700 (PDT) Received: from shark.2a.pl ([195.117.102.3]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k378oUgC000452 for ; Fri, 7 Apr 2006 01:50:33 -0700 Received: from localhost (av.2a.pl [10.0.0.99]) by shark.2a.pl (ESMTP) with ESMTP id 269C0A6E8E for ; Fri, 7 Apr 2006 10:50:23 +0200 (CEST) Received: from shark.2a.pl ([10.0.0.3]) by localhost (av.2a.pl [10.0.0.99]) (amavisd-new, port 10024) with ESMTP id 85147-02 for ; Fri, 7 Apr 2006 10:49:12 +0200 (CEST) Received: from [127.0.0.1] (bya38.internetdsl.tpnet.pl [83.19.4.38]) by shark.2a.pl (ESMTP) with ESMTP id 6CE49A6E7B for ; Fri, 7 Apr 2006 10:50:14 +0200 (CEST) Message-ID: <443627B1.5090100@ursynow.2a.pl> Date: Fri, 07 Apr 2006 10:49:53 +0200 From: =?ISO-8859-2?Q?Artur_Mak=F3wka?= User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: server crashing Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7598 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: juice@ursynow.2a.pl Precedence: bulk X-list: linux-xfs Status: O Content-Length: 3869 Lines: 82 Hello, i have heavy-traffic server that is crashing every few days. When it crashes i cannot login through ssh and no services are working. One time it 'crashed' when i was logged in though (i had luck), and i saw 'Input/Output Error' when this happened as i tried to run any command (like ps, ls or anything) it is RAID 0 array made from two sata drives. it happened yet another time today, after hard reset. machine was only responding to pings, all other actions was not possible, it was likely in this Input/Output error mode. i saw this in logs: Apr 7 10:24:52 alpha324 kernel: [] find_get_pages_tag+0x46/0x90 Apr 7 10:24:52 alpha324 kernel: [] linvfs_writepage+0x72/0x130 Apr 7 10:24:52 alpha324 kernel: [] linvfs_writepage+0x0/0x130 Apr 7 10:24:52 alpha324 kernel: [] mpage_writepages+0x25c/0x440 Apr 7 10:24:52 alpha324 kernel: [] xfs_iflush+0x371/0x4e0 Apr 7 10:24:52 alpha324 kernel: [] linvfs_writepage+0x0/0x130 Apr 7 10:24:52 alpha324 kernel: [] do_writepages+0x39/0x40 Apr 7 10:24:52 alpha324 kernel: [] __sync_single_inode+0x65/0x240 Apr 7 10:24:52 alpha324 kernel: [] __writeback_single_inode+0x46/0x180 Apr 7 10:24:52 alpha324 kernel: [] sync_sb_inodes+0x1ce/0x2b0 Apr 7 10:24:52 alpha324 kernel: [] writeback_inodes+0x4d/0xa0 Apr 7 10:24:52 alpha324 kernel: [] wb_kupdate+0xb5/0x130 Apr 7 10:24:52 alpha324 kernel: [] pdflush+0x0/0x30 Apr 7 10:24:52 alpha324 kernel: [] __pdflush+0x9d/0x140 Apr 7 10:24:52 alpha324 kernel: [] pdflush+0x28/0x30 Apr 7 10:24:52 alpha324 kernel: [] wb_kupdate+0x0/0x130 Apr 7 10:24:52 alpha324 kernel: [] kthread+0xb6/0xc0 Apr 7 10:24:52 alpha324 kernel: [] kthread+0x0/0xc0 Apr 7 10:24:52 alpha324 kernel: [] kernel_thread_helper+0x5/0xc Apr 7 10:24:52 alpha324 kernel: XFS internal error XFS_WANT_CORRUPTED_RETURN at line 298 of file fs/xfs/xfs_alloc.c. Caller 0xc01f5091 Apr 7 10:24:52 alpha324 kernel: [] xfs_alloc_fixup_trees+0x2ba/0x420 Apr 7 10:24:52 alpha324 kernel: [] xfs_alloc_ag_vextent_near+0x871/0xc80 Apr 7 10:24:52 alpha324 kernel: [] xfs_btree_init_cursor+0x38/0x1d0 Apr 7 10:24:52 alpha324 kernel: [] xfs_alloc_ag_vextent_near+0x871/0xc80 Apr 7 10:24:52 alpha324 kernel: [] xfs_alloc_ag_vextent+0x7d/0x110 Apr 7 10:24:52 alpha324 kernel: [] xfs_alloc_vextent+0x25a/0x590 Apr 7 10:24:52 alpha324 kernel: [] xfs_bmap_alloc+0x13f0/0x1a00 Apr 7 10:24:52 alpha324 kernel: [] kobject_release+0x0/0x10 Apr 7 10:24:52 alpha324 kernel: [] scsi_finish_command+0x24/0xb0 Apr 7 10:24:52 alpha324 kernel: [] xfs_bmap_do_search_extents+0xe5/0x470 This is longer, but it just mainly repeats itself. (at least it looks like to me, if you want full output, please let me know) When previous crashes happened, i ran xfs_repair and i thought it will help, but apparently it didnt. Of course i'm going to run it anyways at night, but i doubt this will help this time. i'm using kernel 2.6.15.7 but i was also using 2.6.14 kernels and 2.6.16.1 for just a test few days ago, and that didnt help. my xfs system is mounted like this: /dev/md0 on / type xfs (rw,noatime) on this server traffic is heavy, but not in terms of number of MB/s. It is just like constant 2-3 MB/s. It is rather number of I/O request heavy - i have like 200 apaches running constantly, many pure-ftpds, postfix, mysql and such. Although LA is usually around 2-3 maximum. Is it possible that this is some kind of XFS bug? (i don't have this list subscribed, if you dont mind replying to my mail...) thanks in advance and please let me know if you need any more info From owner-linux-xfs@oss.sgi.com Fri Apr 7 05:44:24 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 07 Apr 2006 05:44:27 -0700 (PDT) Received: from spooner.celestial.com (spooner.celestial.com [192.136.111.35]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k37CiNgC021800 for ; Fri, 7 Apr 2006 05:44:24 -0700 Received: from localhost (localhost [127.0.0.1]) by spooner.celestial.com (Postfix) with ESMTP id BA37930E6E4F; Fri, 7 Apr 2006 05:44:26 -0700 (PDT) Received: from spooner.celestial.com ([127.0.0.1]) by localhost (spooner.celestial.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 20411-05; Fri, 7 Apr 2006 05:44:26 -0700 (PDT) Received: from luther.kurtwerks.com (c-67-165-68-161.hsd1.pa.comcast.net [67.165.68.161]) by spooner.celestial.com (Postfix) with ESMTP id 6181230E6E45; Fri, 7 Apr 2006 05:44:26 -0700 (PDT) Received: by luther.kurtwerks.com (Postfix, from userid 1000) id 8845B6AF3C9; Fri, 7 Apr 2006 08:44:22 -0400 (EDT) Date: Fri, 7 Apr 2006 08:44:21 -0400 From: Kurt Wall To: Nathan Scott Cc: linux-xfs@oss.sgi.com Subject: Re: Bonnie++ Burps on XFS Message-ID: <20060407124421.GA5521@kurtwerks.com> References: <20060406023445.GB5806@kurtwerks.com> <20060407020848.GA24446@kurtwerks.com> <20060407081928.GD1598@frodo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060407081928.GD1598@frodo> User-Agent: Mutt/1.4.2.1i X-Operating-System: Linux 2.6.16krw X-Woot: Woot! X-archive-position: 7599 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kwall@kurtwerks.com Precedence: bulk X-list: linux-xfs Status: O Content-Length: 1202 Lines: 39 On Fri, Apr 07, 2006 at 06:19:28PM +1000, Nathan Scott took 22 lines to write: > On Thu, Apr 06, 2006 at 10:08:48PM -0400, Kurt Wall wrote: > > > > Running Bonnie++ against XFS on 2.6.16 does not encounter the > > same fault. I'm running it against a 2.6.16.1 test now and will > > report the results shortly. > > Hi Kurt, Hello, Nathan, > I've got this narrowed down to a few XFS mods now, I'm still > binary chopping through the last few to narrow it down to one > (test case takes awhile for me). > > Should have it narrowed right down on Monday, and will get the > owner of the offending change to fix it up then. No problem. When I booted to 2.6.16 and ran xfs_repair on my benchmark XFS partition, it fixed some sort of corruption and I was able to delete the empty directories. I find it curious that it only happens on SATA drives, so I'll be interested to see what the problem and solution ends up being. If it matters, the SATA drive in question uses the sata_sil driver. > I think you'll find 2.6.16.1 is OK too. Indeed I did. The test finished up over night without incident. Regards, Kurt -- Paul's Law: In America, it's not how much an item costs, it's how much you save. From owner-linux-xfs@oss.sgi.com Sun Apr 9 08:16:37 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 09 Apr 2006 08:16:40 -0700 (PDT) Received: from uproxy.gmail.com (uproxy.gmail.com [66.249.92.168]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k39FGZgC013667 for ; Sun, 9 Apr 2006 08:16:36 -0700 Received: by uproxy.gmail.com with SMTP id u2so441028uge for ; Sun, 09 Apr 2006 08:16:37 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:content-type; b=YH0mPoCLrShweXcBfIo4c71k6aavKP4OIOjOFSMvrAgPQghWaC3OwjyJMscoBNpRICSuuUcMIQ9P84xu/hQyxjFqRUXYtD/VJSgZ09624SldSngjcblL5qRVJ3G5d+ARiKXqsf5Z+xQfIufakuDD6w9XZ7e+rPNpf3ZPQRi7kXU= Received: by 10.66.249.10 with SMTP id w10mr2523431ugh; Sun, 09 Apr 2006 07:15:14 -0700 (PDT) Received: from ?192.168.1.9? ( [84.210.202.203]) by mx.gmail.com with ESMTP id k1sm20433ugf.2006.04.09.07.15.13; Sun, 09 Apr 2006 07:15:14 -0700 (PDT) Message-ID: <443916EC.10809@gmail.com> Date: Sun, 09 Apr 2006 16:15:08 +0200 From: =?ISO-8859-1?Q?Christian_R=F8snes?= User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: BUG: soft lockup detected on CPU#5 / xfsdatad Content-Type: multipart/mixed; boundary="------------050705090807090309030205" X-archive-position: 7601 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: christian.rosnes@gmail.com Precedence: bulk X-list: linux-xfs Status: O Content-Length: 42970 Lines: 932 This is a multi-part message in MIME format. --------------050705090807090309030205 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi I'm not sure if this is XFS specific, but here goes: This night a brand new Intel Xeon 2.80GHz 2cpu/dual-core server running: Debian 3.1 X86-64 (64-bit), Vanilla Linux 2.6.16 compiled from source, PostgreSQL 8.1.3 (64-bit) reported two 'BUG: soft lockup detected on CPU#5!' messages. A PostgreSQL 'vacuum analyze' job was running at the time (this job runs 4 times a day on this server). The server had been running previously for about 7 days without any problems. Both the root- and database-partition(/dev/sdb1) are xfs partitions. The database partition is residing on a DELL SAN. Any ideas what might have caused this 'soft lockup' ? Thanks Christian Also, please find enclosed a text file ('bug.2006.04.09.txt') containing additional information about this server. Bug message: =================================================== BUG: soft lockup detected on CPU#5 Apr 9 01:05:30 db2 kernel: CPU 5: Apr 9 01:05:30 db2 kernel: Modules linked in: qla2400 qla2xxx ipv6 ide_floppy generic hw_random tsdev mousedev joydev usbhid shpchp pci_hotplug ehci_hcd uhci_hcd usbcore siimage piix psmouse ide_generic ide_disk ide_cd ide_core genrtc unix Apr 9 01:05:30 db2 kernel: Pid: 242, comm: xfsdatad/5 Not tainted 2.6.16FC #1 Apr 9 01:05:30 db2 kernel: RIP: 0010:[] {_spin_unlock_irqrestore+8} Apr 9 01:05:30 db2 kernel: RSP: 0018:ffff81023f90dda0 EFLAGS: 00000292 Apr 9 01:05:30 db2 kernel: RAX: ffff810008e2bff0 RBX: ffffffff80127606 RCX: ffff810008e2bff0 Apr 9 01:05:30 db2 kernel: RDX: ffff810008e2bff0 RSI: 0000000000000292 RDI: ffff810008e2bfe8 Apr 9 01:05:30 db2 kernel: RBP: 0000000000000000 R08: 0000000000000000 R09: ffff81015489e280 Apr 9 01:05:30 db2 kernel: R10: 0000000000000200 R11: 0000000000000000 R12: ffffffff801412fe Apr 9 01:05:30 db2 kernel: R13: ffff81023f90dd58 R14: ffff81023f90dda8 R15: ffff810008e2bff0 Apr 9 01:05:30 db2 kernel: FS: 0000000000000000(0000) GS:ffff8101ffe2aa40(0000) knlGS:0000000000000000 Apr 9 01:05:30 db2 kernel: CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b Apr 9 01:05:30 db2 kernel: CR2: 00002aef2ca6fabf CR3: 000000018f9d3000 CR4: 00000000000006a0 Apr 9 01:05:30 db2 kernel: Apr 9 01:05:30 db2 kernel: Call Trace: {__wake_up_bit+41} {end_buffer_async_write+297} Apr 9 01:05:30 db2 kernel: {xfs_destroy_ioend+22} {xfs_destroy_ioend+31} Apr 9 01:05:30 db2 kernel: {run_workqueue+179} {keventd_create_kthread+0} Apr 9 01:05:30 db2 kernel: {worker_thread+301} {thread_return+0} Apr 9 01:05:30 db2 kernel: {default_wake_function+0} {default_wake_function+0} Apr 9 01:05:30 db2 kernel: {worker_thread+0} {worker_thread+0} Apr 9 01:05:30 db2 kernel: {kthread+147} {child_rip+8} Apr 9 01:05:30 db2 kernel: {keventd_create_kthread+0} {kthread+0} Apr 9 01:05:30 db2 kernel: {child_rip+0} Apr 9 01:05:47 db2 kernel: CPU 5: Apr 9 01:05:47 db2 kernel: Modules linked in: qla2400 qla2xxx ipv6 ide_floppy generic hw_random tsdev mousedev joydev usbhid shpchp pci_hotplug ehci_hcd uhci_hcd usbcore siimage piix psmouse ide_generic ide_disk ide_cd ide_core genrtc unix Apr 9 01:05:47 db2 kernel: Pid: 242, comm: xfsdatad/5 Not tainted 2.6.16FC #1 Apr 9 01:05:47 db2 kernel: RIP: 0010:[] {_spin_unlock_irqrestore+8} Apr 9 01:05:47 db2 kernel: RSP: 0018:ffff81023f90dda0 EFLAGS: 00000292 Apr 9 01:05:47 db2 kernel: RAX: ffff810008e28870 RBX: ffffffff80127606 RCX: ffff810008e28870 Apr 9 01:05:47 db2 kernel: RDX: ffff810008e28870 RSI: 0000000000000292 RDI: ffff810008e28868 Apr 9 01:05:47 db2 kernel: RBP: 0000000000000000 R08: 0000000000000000 R09: ffff81023f0b8f40 Apr 9 01:05:47 db2 kernel: R10: 0000000000000200 R11: 0000000000000000 R12: ffffffff801412fe Apr 9 01:05:47 db2 kernel: R13: ffff81023f90dd58 R14: ffff81023f90dda8 R15: ffff810008e28870 Apr 9 01:05:47 db2 kernel: FS: 0000000000000000(0000) GS:ffff8101ffe2aa40(0000) knlGS:0000000000000000 Apr 9 01:05:47 db2 kernel: CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b Apr 9 01:05:47 db2 kernel: CR2: 00002aef2c103abf CR3: 0000000210474000 CR4: 00000000000006a0 Apr 9 01:05:47 db2 kernel: Apr 9 01:05:47 db2 kernel: Call Trace: {__wake_up_bit+41} {end_buffer_async_write+297} Apr 9 01:05:47 db2 kernel: {xfs_destroy_ioend+22} {xfs_destroy_ioend+31} Apr 9 01:05:47 db2 kernel: {run_workqueue+179} {keventd_create_kthread+0} Apr 9 01:05:47 db2 kernel: {worker_thread+301} {thread_return+0} Apr 9 01:05:47 db2 kernel: {default_wake_function+0} {default_wake_function+0} Apr 9 01:05:47 db2 kernel: {worker_thread+0} {worker_thread+0} Apr 9 01:05:47 db2 kernel: {kthread+147} {child_rip+8} Apr 9 01:05:47 db2 kernel: {keventd_create_kthread+0} {kthread+0} Apr 9 01:05:47 db2 kernel: {child_rip+0} --------------050705090807090309030205 Content-Type: text/plain; name="bug.2006.04.09.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="bug.2006.04.09.txt" Bug text: Apr 9 01:05:30 db2 kernel: CPU 5: Apr 9 01:05:30 db2 kernel: Modules linked in: qla2400 qla2xxx ipv6 ide_floppy generic hw_random tsdev mousedev joydev usbhid shpchp pci_hotplug ehci_hcd uhci_hcd usbcore siimage piix psmouse ide_generic ide_disk ide_cd ide_core genrtc unix Apr 9 01:05:30 db2 kernel: Pid: 242, comm: xfsdatad/5 Not tainted 2.6.16FC #1 Apr 9 01:05:30 db2 kernel: RIP: 0010:[] {_spin_unlock_irqrestore+8} Apr 9 01:05:30 db2 kernel: RSP: 0018:ffff81023f90dda0 EFLAGS: 00000292 Apr 9 01:05:30 db2 kernel: RAX: ffff810008e2bff0 RBX: ffffffff80127606 RCX: ffff810008e2bff0 Apr 9 01:05:30 db2 kernel: RDX: ffff810008e2bff0 RSI: 0000000000000292 RDI: ffff810008e2bfe8 Apr 9 01:05:30 db2 kernel: RBP: 0000000000000000 R08: 0000000000000000 R09: ffff81015489e280 Apr 9 01:05:30 db2 kernel: R10: 0000000000000200 R11: 0000000000000000 R12: ffffffff801412fe Apr 9 01:05:30 db2 kernel: R13: ffff81023f90dd58 R14: ffff81023f90dda8 R15: ffff810008e2bff0 Apr 9 01:05:30 db2 kernel: FS: 0000000000000000(0000) GS:ffff8101ffe2aa40(0000) knlGS:0000000000000000 Apr 9 01:05:30 db2 kernel: CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b Apr 9 01:05:30 db2 kernel: CR2: 00002aef2ca6fabf CR3: 000000018f9d3000 CR4: 00000000000006a0 Apr 9 01:05:30 db2 kernel: Apr 9 01:05:30 db2 kernel: Call Trace: {__wake_up_bit+41} {end_buffer_async_write+297} Apr 9 01:05:30 db2 kernel: {xfs_destroy_ioend+22} {xfs_destroy_ioend+31} Apr 9 01:05:30 db2 kernel: {run_workqueue+179} {keventd_create_kthread+0} Apr 9 01:05:30 db2 kernel: {worker_thread+301} {thread_return+0} Apr 9 01:05:30 db2 kernel: {default_wake_function+0} {default_wake_function+0} Apr 9 01:05:30 db2 kernel: {worker_thread+0} {worker_thread+0} Apr 9 01:05:30 db2 kernel: {kthread+147} {child_rip+8} Apr 9 01:05:30 db2 kernel: {keventd_create_kthread+0} {kthread+0} Apr 9 01:05:30 db2 kernel: {child_rip+0} Apr 9 01:05:47 db2 kernel: CPU 5: Apr 9 01:05:47 db2 kernel: Modules linked in: qla2400 qla2xxx ipv6 ide_floppy generic hw_random tsdev mousedev joydev usbhid shpchp pci_hotplug ehci_hcd uhci_hcd usbcore siimage piix psmouse ide_generic ide_disk ide_cd ide_core genrtc unix Apr 9 01:05:47 db2 kernel: Pid: 242, comm: xfsdatad/5 Not tainted 2.6.16FC #1 Apr 9 01:05:47 db2 kernel: RIP: 0010:[] {_spin_unlock_irqrestore+8} Apr 9 01:05:47 db2 kernel: RSP: 0018:ffff81023f90dda0 EFLAGS: 00000292 Apr 9 01:05:47 db2 kernel: RAX: ffff810008e28870 RBX: ffffffff80127606 RCX: ffff810008e28870 Apr 9 01:05:47 db2 kernel: RDX: ffff810008e28870 RSI: 0000000000000292 RDI: ffff810008e28868 Apr 9 01:05:47 db2 kernel: RBP: 0000000000000000 R08: 0000000000000000 R09: ffff81023f0b8f40 Apr 9 01:05:47 db2 kernel: R10: 0000000000000200 R11: 0000000000000000 R12: ffffffff801412fe Apr 9 01:05:47 db2 kernel: R13: ffff81023f90dd58 R14: ffff81023f90dda8 R15: ffff810008e28870 Apr 9 01:05:47 db2 kernel: FS: 0000000000000000(0000) GS:ffff8101ffe2aa40(0000) knlGS:0000000000000000 Apr 9 01:05:47 db2 kernel: CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b Apr 9 01:05:47 db2 kernel: CR2: 00002aef2c103abf CR3: 0000000210474000 CR4: 00000000000006a0 Apr 9 01:05:47 db2 kernel: Apr 9 01:05:47 db2 kernel: Call Trace: {__wake_up_bit+41} {end_buffer_async_write+297} Apr 9 01:05:47 db2 kernel: {xfs_destroy_ioend+22} {xfs_destroy_ioend+31} Apr 9 01:05:47 db2 kernel: {run_workqueue+179} {keventd_create_kthread+0} Apr 9 01:05:47 db2 kernel: {worker_thread+301} {thread_return+0} Apr 9 01:05:47 db2 kernel: {default_wake_function+0} {default_wake_function+0} Apr 9 01:05:47 db2 kernel: {worker_thread+0} {worker_thread+0} Apr 9 01:05:47 db2 kernel: {kthread+147} {child_rip+8} Apr 9 01:05:47 db2 kernel: {keventd_create_kthread+0} {kthread+0} Apr 9 01:05:47 db2 kernel: {child_rip+0} =================================================== Running: sh ./ver_linux If some fields are empty or look unusual you may have an old version. Compare to the current minimal requirements in Documentation/Changes. Linux db2 2.6.16FC #1 SMP Wed Mar 22 12:31:28 CET 2006 x86_64 GNU/Linux Gnu C 3.3.5 Gnu make 3.80 binutils 2.15 util-linux 2.12p mount 2.12p module-init-tools 3.2-pre1 e2fsprogs 1.37 reiserfsprogs line reiser4progs line xfsprogs 2.6.20 PPP 2.4.3 nfs-utils 1.0.6 Linux C Library 2.3.2 Dynamic linker (ldd) 2.3.2 Procps 3.2.1 Net-tools 1.60 Console-tools 0.2.3 Sh-utils 5.2.1 Modules Loaded qla2400 qla2xxx ipv6 ide_floppy generic hw_random tsdev mousedev joydev usbhid shpchp pci_hotplug ehci_hcd uhci_hcd usbcore siimage piix psmouse ide_generic ide_disk ide_cd ide_core genrtc unix =================================================== df: Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda3 63208996 5892208 57316788 10% / tmpfs 4087716 0 4087716 0% /dev/shm /dev/sda1 466662 14176 427587 4% /boot /dev/sdb1 178170116 4246400 173923716 3% /san =================================================== mount: /dev/sda3 on / type xfs (rw,noatime) proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) devpts on /dev/pts type devpts (rw,gid=5,mode=620) tmpfs on /dev/shm type tmpfs (rw) /dev/sda1 on /boot type ext2 (rw,noatime) usbfs on /proc/bus/usb type usbfs (rw) /dev/sdb1 on /san type xfs (rw,noatime) =================================================== ===================================================== Running: cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7 0: 226 0 0 0 0 277717661 0 0 IO-APIC-edge timer 1: 0 0 0 0 0 9 0 0 IO-APIC-edge i8042 9: 0 0 0 0 0 0 0 0 IO-APIC-level acpi 14: 0 0 0 0 0 13 0 0 IO-APIC-edge ide0 169: 0 0 0 0 0 5649134 0 0 IO-APIC-level uhci_hcd:usb1, qla2400 185: 0 0 0 0 0 545423724 0 0 IO-APIC-level eth0 201: 0 0 0 0 0 215363073 0 0 IO-APIC-level megaraid 209: 0 0 0 0 0 63 0 0 IO-APIC-level ide2, ehci_hcd:usb4 217: 0 0 0 0 0 0 0 0 IO-APIC-level uhci_hcd:usb2 225: 0 0 0 0 0 0 0 0 IO-APIC-level uhci_hcd:usb3 NMI: 62452 249384 63225 62699 62361 249362 63203 62677 LOC: 277687412 277301786 277700824 277701522 277687319 277301693 277700731 277701429 ERR: 7 MIS: 0 ===================================================== Running: cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 4 model name : Intel(R) Xeon(TM) CPU 2.80GHz stepping : 8 cpu MHz : 2793.213 cache size : 2048 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 2 fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl est cid cx16 xtpr lahf_lm bogomips : 5591.58 clflush size : 64 cache_alignment : 128 address sizes : 36 bits physical, 48 bits virtual power management: processor : 1 vendor_id : GenuineIntel cpu family : 15 model : 4 model name : Intel(R) Xeon(TM) CPU 2.80GHz stepping : 8 cpu MHz : 2793.213 cache size : 2048 KB physical id : 1 siblings : 4 core id : 1 cpu cores : 2 fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl est cid cx16 xtpr lahf_lm bogomips : 5586.49 clflush size : 64 cache_alignment : 128 address sizes : 36 bits physical, 48 bits virtual power management: processor : 2 vendor_id : GenuineIntel cpu family : 15 model : 4 model name : Intel(R) Xeon(TM) CPU 2.80GHz stepping : 8 cpu MHz : 2793.213 cache size : 2048 KB physical id : 0 siblings : 4 core id : 1 cpu cores : 2 fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl est cid cx16 xtpr lahf_lm bogomips : 5586.50 clflush size : 64 cache_alignment : 128 address sizes : 36 bits physical, 48 bits virtual power management: processor : 3 vendor_id : GenuineIntel cpu family : 15 model : 4 model name : Intel(R) Xeon(TM) CPU 2.80GHz stepping : 8 cpu MHz : 2793.213 cache size : 2048 KB physical id : 1 siblings : 4 core id : 0 cpu cores : 2 fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl est cid cx16 xtpr lahf_lm bogomips : 5586.61 clflush size : 64 cache_alignment : 128 address sizes : 36 bits physical, 48 bits virtual power management: processor : 4 vendor_id : GenuineIntel cpu family : 15 model : 4 model name : Intel(R) Xeon(TM) CPU 2.80GHz stepping : 8 cpu MHz : 2793.213 cache size : 2048 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 2 fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl est cid cx16 xtpr lahf_lm bogomips : 5586.63 clflush size : 64 cache_alignment : 128 address sizes : 36 bits physical, 48 bits virtual power management: processor : 5 vendor_id : GenuineIntel cpu family : 15 model : 4 model name : Intel(R) Xeon(TM) CPU 2.80GHz stepping : 8 cpu MHz : 2793.213 cache size : 2048 KB physical id : 1 siblings : 4 core id : 1 cpu cores : 2 fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl est cid cx16 xtpr lahf_lm bogomips : 5586.60 clflush size : 64 cache_alignment : 128 address sizes : 36 bits physical, 48 bits virtual power management: processor : 6 vendor_id : GenuineIntel cpu family : 15 model : 4 model name : Intel(R) Xeon(TM) CPU 2.80GHz stepping : 8 cpu MHz : 2793.213 cache size : 2048 KB physical id : 0 siblings : 4 core id : 1 cpu cores : 2 fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl est cid cx16 xtpr lahf_lm bogomips : 5586.65 clflush size : 64 cache_alignment : 128 address sizes : 36 bits physical, 48 bits virtual power management: processor : 7 vendor_id : GenuineIntel cpu family : 15 model : 4 model name : Intel(R) Xeon(TM) CPU 2.80GHz stepping : 8 cpu MHz : 2793.213 cache size : 2048 KB physical id : 1 siblings : 4 core id : 0 cpu cores : 2 fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl est cid cx16 xtpr lahf_lm bogomips : 5586.54 clflush size : 64 cache_alignment : 128 address sizes : 36 bits physical, 48 bits virtual power management: ===================================================== Running: cat /proc/modules qla2400 201856 0 - Live 0xffffffff880f6000 qla2xxx 141548 2 qla2400, Live 0xffffffff880d2000 ipv6 292736 34 - Live 0xffffffff88130000 ide_floppy 22272 0 - Live 0xffffffff88129000 generic 7172 0 [permanent], Live 0xffffffff880cf000 hw_random 7720 0 - Live 0xffffffff880cc000 tsdev 10240 0 - Live 0xffffffff880c8000 mousedev 14956 0 - Live 0xffffffff880c3000 joydev 12800 0 - Live 0xffffffff880be000 usbhid 42784 0 - Live 0xffffffff880b2000 shpchp 51488 0 - Live 0xffffffff880a4000 pci_hotplug 32512 1 shpchp, Live 0xffffffff8809b000 ehci_hcd 35976 0 - Live 0xffffffff88091000 uhci_hcd 36896 0 - Live 0xffffffff88086000 usbcore 148008 4 usbhid,ehci_hcd,uhci_hcd, Live 0xffffffff88060000 siimage 14336 0 [permanent], Live 0xffffffff8805b000 piix 14212 0 [permanent], Live 0xffffffff88056000 psmouse 44048 0 - Live 0xffffffff8804a000 ide_generic 2816 0 [permanent], Live 0xffffffff88048000 ide_disk 19584 0 - Live 0xffffffff88042000 ide_cd 47240 0 - Live 0xffffffff88035000 ide_core 153892 7 ide_floppy,generic,siimage,piix,ide_generic,ide_disk,ide_cd, Live 0xffffffff8800e000 genrtc 12108 0 - Live 0xffffffff8800a000 unix 33560 164 - Live 0xffffffff88000000 ===================================================== Running: cat /proc/ioports 0000-001f : dma1 0020-0021 : pic1 0040-0043 : timer0 0050-0053 : timer1 0060-006f : keyboard 0080-008f : dma page reg 00a0-00a1 : pic2 00c0-00df : dma2 00f0-00ff : fpu 01f0-01f7 : ide0 03c0-03df : vga+ 03f6-03f6 : ide0 03f8-03ff : serial 0800-087f : 0000:00:1f.0 0800-0803 : PM1a_EVT_BLK 0804-0805 : PM1a_CNT_BLK 0808-080b : PM_TMR 0828-082f : GPE0_BLK 0880-08bf : 0000:00:1f.0 0cf8-0cff : PCI conf1 aca0-acbf : 0000:00:1d.2 aca0-acbf : uhci_hcd acc0-acdf : 0000:00:1d.1 acc0-acdf : uhci_hcd ace0-acff : 0000:00:1d.0 ace0-acff : uhci_hcd b000-bfff : PCI Bus #09 b800-b8ff : 0000:09:0d.0 bc70-bc7f : 0000:09:06.0 bc80-bcbf : 0000:09:05.1 bc80-bc87 : serial bcd0-bcd3 : 0000:09:06.0 bcd8-bcdf : 0000:09:06.0 bce4-bce7 : 0000:09:06.0 bce8-bcef : 0000:09:05.0 bcf0-bcf7 : 0000:09:06.0 bcf8-bcff : 0000:09:05.0 c000-dfff : PCI Bus #05 c000-cfff : PCI Bus #07 ccc0-ccff : 0000:07:08.0 ccc0-ccff : e1000 d000-dfff : PCI Bus #06 dcc0-dcff : 0000:06:07.0 dcc0-dcff : e1000 e000-efff : PCI Bus #04 ec00-ecff : 0000:04:00.0 ec00-ecff : qla2400 fc00-fc0f : 0000:00:1f.1 fc08-fc0f : ide1 ===================================================== Running: cat /proc/iomem 00000000-0009ffff : System RAM 000a0000-000bffff : Video RAM area 000c0000-000c7fff : Video ROM 000cb000-000cbfff : Adapter ROM 000cc000-000ccfff : Adapter ROM 000cd000-000d0bff : Adapter ROM 000d1000-000d31ff : Adapter ROM 000d3800-000d3dff : Adapter ROM 000f0000-000fffff : System ROM 00100000-bffbffff : System RAM 00100000-003e4cda : Kernel code 003e4cdb-00520b0f : Kernel data bffc0000-bffcfbff : ACPI Tables bffcfc00-bfffefff : reserved c0000000-c00003ff : 0000:00:1f.1 c8000000-d7ffffff : PCI Bus #09 c8000000-cfffffff : 0000:09:0d.0 d0000000-d007ffff : 0000:09:06.0 d0080000-d009ffff : 0000:09:0d.0 d00a0000-d00affff : 0000:09:05.0 d7f00000-d7f7ffff : 0000:09:05.1 d7fff000-d7ffffff : 0000:09:05.0 d8000000-d80fffff : PCI Bus #01 d8000000-d80fffff : PCI Bus #02 d80f0000-d80fffff : 0000:02:0e.0 d80f0000-d80fffff : MegaRAID: LSI Logic Corporation df300000-df4fffff : PCI Bus #09 df3e0000-df3effff : 0000:09:0d.0 df3fec00-df3fecff : 0000:09:06.0 df3fec00-df3fecff : SiI680 df3ff000-df3fffff : 0000:09:05.1 df500000-df9fffff : PCI Bus #05 df600000-df7fffff : PCI Bus #07 df6e0000-df6fffff : 0000:07:08.0 df6e0000-df6fffff : e1000 df800000-df9fffff : PCI Bus #06 df8e0000-df8fffff : 0000:06:07.0 df8e0000-df8fffff : e1000 dfa00000-dfbfffff : PCI Bus #04 dfafc000-dfafffff : 0000:04:00.0 dfafc000-dfafffff : qla2400 dfb00000-dfb3ffff : 0000:04:00.0 dfc00000-dfefffff : PCI Bus #01 dfd00000-dfefffff : PCI Bus #02 dfdc0000-dfdfffff : 0000:02:0e.0 dfdc0000-dfdfffff : MegaRAID: LSI Logic Corporation dfe00000-dfe1ffff : 0000:02:0e.0 dff00000-dff003ff : 0000:00:1d.7 dff00000-dff003ff : ehci_hcd e0000000-fec8ffff : reserved fed00000-fed003ff : reserved fee00000-fee0ffff : reserved ffb00000-ffffffff : reserved 100000000-1ffffdfff : System RAM 1ffffe000-1ffffffff : reserved 200000000-23fffffff : System RAM ===================================================== Running: lspci -vvv 0000:00:00.0 Host bridge: Intel Corp. Server Memory Controller Hub (rev 09) Subsystem: Dell: Unknown device 016d Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- Reset- FastB2B- Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [58] Message Signalled Interrupts: 64bit- Queue=0/1 Enable- Address: fee00000 Data: 0000 Capabilities: [64] #10 [0041] 0000:00:04.0 PCI bridge: Intel Corp. Memory Controller Hub PCI Express Port B0 (rev 09) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Reset- FastB2B- Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [58] Message Signalled Interrupts: 64bit- Queue=0/1 Enable- Address: fee00000 Data: 0000 Capabilities: [64] #10 [0141] 0000:00:05.0 PCI bridge: Intel Corp. Memory Controller Hub PCI Express Port B1 (rev 09) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Reset- FastB2B- Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [58] Message Signalled Interrupts: 64bit- Queue=0/1 Enable- Address: fee00000 Data: 0000 Capabilities: [64] #10 [0041] 0000:00:06.0 PCI bridge: Intel Corp. Memory Controller Hub PCI Express Port C0 (rev 09) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Reset- FastB2B- Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [58] Message Signalled Interrupts: 64bit- Queue=0/1 Enable- Address: fee00000 Data: 0000 Capabilities: [64] #10 [0141] 0000:00:1d.0 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #1 (rev 02) (prog-if 00 [UHCI]) Subsystem: Dell: Unknown device 016d Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- Reset- FastB2B- 0000:00:1f.0 ISA bridge: Intel Corp. 82801EB/ER (ICH5/ICH5R) LPC Bridge (rev 02) Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- Region 1: I/O ports at Region 2: I/O ports at Region 3: I/O ports at Region 4: I/O ports at fc00 [size=16] Region 5: Memory at c0000000 (32-bit, non-prefetchable) [size=1K] 0000:01:00.0 PCI bridge: Intel Corp. 80332 [Dobson] I/O processor (rev 06) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Reset- FastB2B- Capabilities: [44] #10 [0071] Capabilities: [5c] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable- Address: 0000000000000000 Data: 0000 Capabilities: [6c] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [d8] 0000:01:00.2 PCI bridge: Intel Corp. 80332 [Dobson] I/O processor (rev 06) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Reset- FastB2B- Capabilities: [44] #10 [0071] Capabilities: [5c] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable- Address: 0000000000000000 Data: 0000 Capabilities: [6c] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [d8] 0000:02:0e.0 RAID bus controller: Dell PowerEdge Expandable RAID controller 4 (rev 06) Subsystem: Dell PowerEdge Expandable RAID Controller 4e/Di Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping+ SERR+ FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- Reset- FastB2B- Capabilities: [44] #10 [0071] Capabilities: [5c] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable- Address: 0000000000000000 Data: 0000 Capabilities: [6c] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [d8] 0000:05:00.2 PCI bridge: Intel Corp. PCI Bridge Hub B (rev 09) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Reset- FastB2B- Capabilities: [44] #10 [0071] Capabilities: [5c] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable- Address: 0000000000000000 Data: 0000 Capabilities: [6c] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Capabilities: [d8] 0000:06:07.0 Ethernet controller: Intel Corp. 82541GI/PI Gigabit Ethernet Controller (rev 05) Subsystem: Dell: Unknown device 016d Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- ; Sun, 9 Apr 2006 18:46:56 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA12941; Mon, 10 Apr 2006 11:46:49 +1000 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k3A1l4PR3405399; Mon, 10 Apr 2006 11:47:04 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k3A1l1dB3409236; Mon, 10 Apr 2006 11:47:01 +1000 (AEST) Date: Mon, 10 Apr 2006 11:47:01 +1000 From: David Chinner To: Christian =?iso-8859-1?Q?R=F8snes?= Cc: linux-xfs@oss.sgi.com Subject: Re: BUG: soft lockup detected on CPU#5 / xfsdatad Message-ID: <20060410014701.GJ2732@melbourne.sgi.com> References: <443916EC.10809@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <443916EC.10809@gmail.com> User-Agent: Mutt/1.4.2.1i X-archive-position: 7602 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: linux-xfs Status: O Content-Length: 2856 Lines: 56 On Sun, Apr 09, 2006 at 04:15:08PM +0200, Christian Røsnes wrote: > Hi > > I'm not sure if this is XFS specific, but here goes: Not directly an XFS problem. __wake_up_bit() turns off interrupts on the cpu it runs on, and if there are a lot of processes to be woken up, then it can take some time to run. The buffer bitlock uses the generic waittable hashes, so this may simply be caused by hash collisions due to lots of processes sleeping in non-exclusive wait states (e.g. io_schedule()). If your flush process that triggers this, then you probably have lots of I/o going on at the time. I guess this comment in the waittable hash sizing code is relevant: /* * Once we have dozens or even hundreds of threads sleeping * on IO we've got bigger problems than wait queue collision. * Limit the size of the wait table to a reasonable size. */ FWIW: > ===================================================== > Running: cat /proc/interrupts > CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7 > 0: 226 0 0 0 0 277717661 0 0 IO-APIC-edge timer > 1: 0 0 0 0 0 9 0 0 IO-APIC-edge i8042 > 9: 0 0 0 0 0 0 0 0 IO-APIC-level acpi > 14: 0 0 0 0 0 13 0 0 IO-APIC-edge ide0 > 169: 0 0 0 0 0 5649134 0 0 IO-APIC-level uhci_hcd:usb1, qla2400 > 185: 0 0 0 0 0 545423724 0 0 IO-APIC-level eth0 > 201: 0 0 0 0 0 215363073 0 0 IO-APIC-level megaraid > 209: 0 0 0 0 0 63 0 0 IO-APIC-level ide2, ehci_hcd:usb4 > 217: 0 0 0 0 0 0 0 0 IO-APIC-level uhci_hcd:usb2 > 225: 0 0 0 0 0 0 0 0 IO-APIC-level uhci_hcd:usb3 > NMI: 62452 249384 63225 62699 62361 249362 63203 62677 > LOC: 277687412 277301786 277700824 277701522 277687319 277301693 277700731 277701429 > ERR: 7 > MIS: 0 CPU 5 is doing all your interrupt work for timers, usb, ethernet and your RAID. You might want to try to spread these interrupts to different CPus to reduce the interrupt load on this one CPU. That may improve the situation. Cheers, Dave. -- Dave Chinner R&D Software Enginner SGI Australian Software Group From owner-linux-xfs@oss.sgi.com Sun Apr 9 18:59:15 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 09 Apr 2006 18:59:17 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k3A1xDgC017407 for ; Sun, 9 Apr 2006 18:59:14 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA13089; Mon, 10 Apr 2006 11:59:06 +1000 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k3A1xJPR3404777; Mon, 10 Apr 2006 11:59:19 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k3A1xGKU3410473; Mon, 10 Apr 2006 11:59:16 +1000 (AEST) Date: Mon, 10 Apr 2006 11:59:16 +1000 From: David Chinner To: Artur =?iso-8859-1?Q?Mak=F3wka?= Cc: linux-xfs@oss.sgi.com Subject: Re: server crashing Message-ID: <20060410015916.GK2732@melbourne.sgi.com> References: <443627B1.5090100@ursynow.2a.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <443627B1.5090100@ursynow.2a.pl> User-Agent: Mutt/1.4.2.1i X-archive-position: 7603 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: linux-xfs Status: O Content-Length: 1270 Lines: 37 On Fri, Apr 07, 2006 at 10:49:53AM +0200, Artur Makówka wrote: > Hello, i have heavy-traffic server that is crashing every few days. When > it crashes i cannot login through ssh and no services are working. One > time it 'crashed' when i was logged in though (i had luck), and i saw > 'Input/Output Error' when this happened as i tried to run any command > (like ps, ls or anything) It's not crashing, a filesystem has shut down.... > it is RAID 0 array made from two sata drives. Any I/O errors in the logs? i.e. is it a SATA issue and XFS is shutting down to protect itself? > my xfs system is mounted like this: > > /dev/md0 on / type xfs (rw,noatime) Well, that explains why you can't log in - your root filesystem has shutdown. You need to separate your root filesystem from the data filesystem so that when the data filesystem has a problem it doesn't take the entire machine down (as you are currently experiencing). > thanks in advance and please let me know if you need any more info If there are no I/O errors being reported before the filesystem shuts down, can you provide more information of the type of I/O the system is executing when the shutdown occurs? Cheers, Dave. -- Dave Chinner R&D Software Enginner SGI Australian Software Group From owner-linux-xfs@oss.sgi.com Mon Apr 10 01:52:08 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 Apr 2006 01:52:10 -0700 (PDT) Received: from lucidpixels.com (lucidpixels.com [66.45.37.187]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k3A8q6gC015161 for ; Mon, 10 Apr 2006 01:52:07 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id 2B5D5163801; Mon, 10 Apr 2006 04:52:09 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id 28BB5100EC460 for ; Mon, 10 Apr 2006 04:52:09 -0400 (EDT) Date: Mon, 10 Apr 2006 04:52:09 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34 To: linux-xfs@oss.sgi.com Subject: Re: XFS corruption under 2.6.15.1 In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 7605 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: linux-xfs Status: O Content-Length: 3999 Lines: 85 And is there anyway to fix a FS if its mounted via loopback? # xfs_repair /dev/loop6 Phase 1 - find and verify superblock... superblock read failed, offset 0, size 524288, ag 0, rval 0 fatal error -- Invalid argument On Mon, 10 Apr 2006, Justin Piszcz wrote: > After > 70 days of uptime a FS on one my machines became corrupted. > > When I unmounted and remounted, at [6388318.818916], the problem persists. > > Any idea what happened here? > > [6371204.029520] XFS internal error XFS_WANT_CORRUPTED_GOTO at line 1563 of > file fs/xfs/xfs_alloc.c. Caller 0xc021e3c9 > [6371204.030411] [] xfs_free_ag_extent+0x376/0x750 > [6371204.030523] [] xfs_free_extent+0xe9/0xf0 > [6371204.030567] [] xfs_free_extent+0xe9/0xf0 > [6371204.030611] [] xfs_trans_get_efd+0x38/0x50 > [6371204.030661] [] xfs_bmap_finish+0x140/0x1e0 > [6371204.030730] [] xfs_itruncate_finish+0x214/0x440 > [6371204.030783] [] xfs_inactive+0x533/0x590 > [6371204.030825] [] linvfs_clear_inode+0x84/0xa0 > [6371204.030873] [] clear_inode+0xba/0xe0 > [6371204.030917] [] generic_delete_inode+0x100/0x110 > [6371204.030959] [] iput+0x62/0x80 > [6371204.030997] [] sys_unlink+0xfa/0x130 > [6371204.031043] [] filldir64+0x0/0x110 > [6371204.031053] [] sys_getdents64+0xa8/0xb2 > [6371204.031061] [] filldir64+0x0/0x110 > [6371204.031069] [] syscall_call+0x7/0xb > [6371204.031092] xfs_force_shutdown(loop6,0x8) called from line 4125 of file > fs/xfs/xfs_bmap.c. Return address = 0xc028b70c > [6371204.032677] Filesystem "loop6": Corruption of in-memory data detected. > Shutting down filesystem: loop6 > [6371204.032748] Please umount the filesystem, and rectify the problem(s) > [6388287.970034] xfs_force_shutdown(loop6,0x1) called from line 339 of file > fs/xfs/xfs_rw.c. Return address = 0xc028b70c > [6388318.818916] XFS mounting filesystem loop6 > [6388318.929946] Starting XFS recovery on filesystem: loop6 (logdev: > internal) > [6388318.970850] XFS internal error XFS_WANT_CORRUPTED_GOTO at line 1563 of > file fs/xfs/xfs_alloc.c. Caller 0xc021e3c9 > [6388318.971186] [] xfs_free_ag_extent+0x376/0x750 > [6388318.971264] [] xfs_free_extent+0xe9/0xf0 > [6388318.971308] [] xfs_free_extent+0xe9/0xf0 > [6388318.971350] [] xfs_trans_get_efd+0x38/0x50 > [6388318.971400] [] xlog_recover_process_efi+0x187/0x200 > [6388318.971442] [] xlog_recover_process_efis+0x56/0xb0 > [6388318.971483] [] xlog_recover_finish+0x20/0xd0 > [6388318.971524] [] xfs_log_mount_finish+0x3e/0x40 > [6388318.971563] [] xfs_mountfs+0xa3c/0xf50 > [6388318.971604] [] pagebuf_rele+0x20/0xc0 > [6388318.971647] [] xfs_readsb+0x196/0x200 > [6388318.971686] [] xfs_ioinit+0x26/0x50 > [6388318.971746] [] xfs_mount+0x3e3/0x660 > [6388318.971756] [] vfs_mount+0x34/0x40 > [6388318.971769] [] linvfs_fill_super+0x97/0x1f0 > [6388318.971778] [] snprintf+0x27/0x30 > [6388318.971796] [] disk_name+0xb1/0xc0 > [6388318.971809] [] sget+0x175/0x1b0 > [6388318.971825] [] sb_set_blocksize+0x2e/0x60 > [6388318.971834] [] get_sb_bdev+0xfb/0x140 > [6388318.971843] [] linvfs_get_sb+0x2f/0x60 > [6388318.971851] [] linvfs_fill_super+0x0/0x1f0 > [6388318.971859] [] do_kern_mount+0x5f/0xe0 > [6388318.971867] [] do_new_mount+0xa5/0xf0 > [6388318.971881] [] do_mount+0x199/0x200 > [6388318.971890] [] iret_exc+0x3b2/0x6f7 > [6388318.971906] [] copy_mount_options+0x78/0xc0 > [6388318.971914] [] sys_mount+0xa5/0xf0 > [6388318.971921] [] syscall_call+0x7/0xb > [6388319.427361] Ending XFS recovery on filesystem: loop6 (logdev: internal) > > Thanks, > > Justin. > > From owner-linux-xfs@oss.sgi.com Mon Apr 10 01:43:54 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 Apr 2006 01:43:59 -0700 (PDT) Received: from lucidpixels.com (lucidpixels.com [66.45.37.187]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k3A8hrgC013525 for ; Mon, 10 Apr 2006 01:43:54 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id 36502163801; Mon, 10 Apr 2006 04:43:51 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id 1C1D6100EC460 for ; Mon, 10 Apr 2006 04:43:51 -0400 (EDT) Date: Mon, 10 Apr 2006 04:43:51 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34 To: linux-xfs@oss.sgi.com Subject: XFS corruption under 2.6.15.1 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 7604 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: linux-xfs Status: O Content-Length: 3597 Lines: 72 After > 70 days of uptime a FS on one my machines became corrupted. When I unmounted and remounted, at [6388318.818916], the problem persists. Any idea what happened here? [6371204.029520] XFS internal error XFS_WANT_CORRUPTED_GOTO at line 1563 of file fs/xfs/xfs_alloc.c. Caller 0xc021e3c9 [6371204.030411] [] xfs_free_ag_extent+0x376/0x750 [6371204.030523] [] xfs_free_extent+0xe9/0xf0 [6371204.030567] [] xfs_free_extent+0xe9/0xf0 [6371204.030611] [] xfs_trans_get_efd+0x38/0x50 [6371204.030661] [] xfs_bmap_finish+0x140/0x1e0 [6371204.030730] [] xfs_itruncate_finish+0x214/0x440 [6371204.030783] [] xfs_inactive+0x533/0x590 [6371204.030825] [] linvfs_clear_inode+0x84/0xa0 [6371204.030873] [] clear_inode+0xba/0xe0 [6371204.030917] [] generic_delete_inode+0x100/0x110 [6371204.030959] [] iput+0x62/0x80 [6371204.030997] [] sys_unlink+0xfa/0x130 [6371204.031043] [] filldir64+0x0/0x110 [6371204.031053] [] sys_getdents64+0xa8/0xb2 [6371204.031061] [] filldir64+0x0/0x110 [6371204.031069] [] syscall_call+0x7/0xb [6371204.031092] xfs_force_shutdown(loop6,0x8) called from line 4125 of file fs/xfs/xfs_bmap.c. Return address = 0xc028b70c [6371204.032677] Filesystem "loop6": Corruption of in-memory data detected. Shutting down filesystem: loop6 [6371204.032748] Please umount the filesystem, and rectify the problem(s) [6388287.970034] xfs_force_shutdown(loop6,0x1) called from line 339 of file fs/xfs/xfs_rw.c. Return address = 0xc028b70c [6388318.818916] XFS mounting filesystem loop6 [6388318.929946] Starting XFS recovery on filesystem: loop6 (logdev: internal) [6388318.970850] XFS internal error XFS_WANT_CORRUPTED_GOTO at line 1563 of file fs/xfs/xfs_alloc.c. Caller 0xc021e3c9 [6388318.971186] [] xfs_free_ag_extent+0x376/0x750 [6388318.971264] [] xfs_free_extent+0xe9/0xf0 [6388318.971308] [] xfs_free_extent+0xe9/0xf0 [6388318.971350] [] xfs_trans_get_efd+0x38/0x50 [6388318.971400] [] xlog_recover_process_efi+0x187/0x200 [6388318.971442] [] xlog_recover_process_efis+0x56/0xb0 [6388318.971483] [] xlog_recover_finish+0x20/0xd0 [6388318.971524] [] xfs_log_mount_finish+0x3e/0x40 [6388318.971563] [] xfs_mountfs+0xa3c/0xf50 [6388318.971604] [] pagebuf_rele+0x20/0xc0 [6388318.971647] [] xfs_readsb+0x196/0x200 [6388318.971686] [] xfs_ioinit+0x26/0x50 [6388318.971746] [] xfs_mount+0x3e3/0x660 [6388318.971756] [] vfs_mount+0x34/0x40 [6388318.971769] [] linvfs_fill_super+0x97/0x1f0 [6388318.971778] [] snprintf+0x27/0x30 [6388318.971796] [] disk_name+0xb1/0xc0 [6388318.971809] [] sget+0x175/0x1b0 [6388318.971825] [] sb_set_blocksize+0x2e/0x60 [6388318.971834] [] get_sb_bdev+0xfb/0x140 [6388318.971843] [] linvfs_get_sb+0x2f/0x60 [6388318.971851] [] linvfs_fill_super+0x0/0x1f0 [6388318.971859] [] do_kern_mount+0x5f/0xe0 [6388318.971867] [] do_new_mount+0xa5/0xf0 [6388318.971881] [] do_mount+0x199/0x200 [6388318.971890] [] iret_exc+0x3b2/0x6f7 [6388318.971906] [] copy_mount_options+0x78/0xc0 [6388318.971914] [] sys_mount+0xa5/0xf0 [6388318.971921] [] syscall_call+0x7/0xb [6388319.427361] Ending XFS recovery on filesystem: loop6 (logdev: internal) Thanks, Justin. From owner-linux-xfs@oss.sgi.com Mon Apr 10 03:55:42 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 Apr 2006 03:56:07 -0700 (PDT) Received: from mx1.seznam.cz (mx1.seznam.cz [212.80.76.26]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k3AAtegC030611 for ; Mon, 10 Apr 2006 03:55:41 -0700 Received: (qmail 30945 invoked by uid 0); 10 Apr 2006 09:55:35 -0000 To: linux-xfs@oss.sgi.com Date: Mon, 10 Apr 2006 11:55:35 +0200 (CEST) Reply-To: =?us-ascii?Q?Petr=20Vacek?= From: =?us-ascii?Q?Petr=20Vacek?= Received: from [212.71.154.214] by email.seznam.cz with HTTP for auderon@seznam.cz; Mon, 10 Apr 2006 11:55:35 +0200 (CEST) Subject: =?us-ascii?Q?XFS=20filesystem=20for=20my=20operating=20system?= Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 Message-Id: <50.74-23827-698644376-1144662935@seznam.cz> X-Abuse: helpdesk@seznam.cz X-Seznam-User: auderon@seznam.cz X-archive-position: 7606 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: auderon@seznam.cz Precedence: bulk X-list: linux-xfs Status: O Content-Length: 433 Lines: 10 Good morning, I would like for its operating system Auderon Onward use your file system XFS. I'll with pleasure should are me provided this file system and I would have you most grateful. I want to had high power. In advance thank you. Yours truly Peter Vacek CZECH REPUBLIC From owner-linux-xfs@oss.sgi.com Mon Apr 10 06:47:23 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 Apr 2006 06:47:25 -0700 (PDT) Received: from uproxy.gmail.com (uproxy.gmail.com [66.249.92.172]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k3ADlMgC023597 for ; Mon, 10 Apr 2006 06:47:23 -0700 Received: by uproxy.gmail.com with SMTP id u2so556157uge for ; Mon, 10 Apr 2006 06:47:18 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=q4uPLx1o5Cxmfq622iIu+sRVEIYVfFW6bWvaEQXqrZkXvkXrAV5KrQ1A2EnJzOlGaPEypdrMEdb2QeXphpvQaKrUSbvZ448mxXvzQsNH3OvzQqpK0zZLorME+toEnxvwWtcx3+t3RJ68sGDxZfuOt3iC/T+Beg7ysFl8gretyHI= Received: by 10.66.222.8 with SMTP id u8mr3229886ugg; Mon, 10 Apr 2006 06:47:18 -0700 (PDT) Received: from ?192.168.1.9? ( [84.210.202.203]) by mx.gmail.com with ESMTP id a1sm378459ugf.2006.04.10.06.47.17; Mon, 10 Apr 2006 06:47:18 -0700 (PDT) Message-ID: <443A61DF.7080801@gmail.com> Date: Mon, 10 Apr 2006 15:47:11 +0200 From: =?ISO-8859-1?Q?Christian_R=F8snes?= User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: linux-xfs@oss.sgi.com CC: David Chinner Subject: Re: BUG: soft lockup detected on CPU#5 / xfsdatad References: <443916EC.10809@gmail.com> <20060410014701.GJ2732@melbourne.sgi.com> In-Reply-To: <20060410014701.GJ2732@melbourne.sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7607 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: christian.rosnes@gmail.com Precedence: bulk X-list: linux-xfs Status: O Content-Length: 4012 Lines: 78 David Chinner wrote: > FWIW: > >> ===================================================== >> Running: cat /proc/interrupts >> CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7 >> 0: 226 0 0 0 0 277717661 0 0 IO-APIC-edge timer >> 1: 0 0 0 0 0 9 0 0 IO-APIC-edge i8042 >> 9: 0 0 0 0 0 0 0 0 IO-APIC-level acpi >> 14: 0 0 0 0 0 13 0 0 IO-APIC-edge ide0 >> 169: 0 0 0 0 0 5649134 0 0 IO-APIC-level uhci_hcd:usb1, qla2400 >> 185: 0 0 0 0 0 545423724 0 0 IO-APIC-level eth0 >> 201: 0 0 0 0 0 215363073 0 0 IO-APIC-level megaraid >> 209: 0 0 0 0 0 63 0 0 IO-APIC-level ide2, ehci_hcd:usb4 >> 217: 0 0 0 0 0 0 0 0 IO-APIC-level uhci_hcd:usb2 >> 225: 0 0 0 0 0 0 0 0 IO-APIC-level uhci_hcd:usb3 >> NMI: 62452 249384 63225 62699 62361 249362 63203 62677 >> LOC: 277687412 277301786 277700824 277701522 277687319 277301693 277700731 277701429 >> ERR: 7 >> MIS: 0 > > CPU 5 is doing all your interrupt work for timers, usb, ethernet and > your RAID. You might want to try to spread these interrupts to > different CPus to reduce the interrupt load on this one CPU. That > may improve the situation. > > Cheers, > > Dave. Thank you for the information. Is there a preferred way of distributing interrupts across several Xeon cpus ? Also, does anyone know if Intel Xeons behave differently than AMD Opterons in this regard (interrupt cpu distibution on 64-bit kernels) ? Reason for my asking is that as opposed to the interrupt distribution shown in the table above, where most interrupts on that 2-cpu dual-core hyperthreaded Xeon is handled by cpu 5, my 2-cpu dual-core Opteron rig (kernel 2.6.15, 64-bit) show a more evenly distribution of interrupts across all its cpus: opteron# cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 0: 33072714 38007277 38475123 37457443 IO-APIC-edge timer 1: 29837 43445 34925 36416 IO-APIC-edge i8042 8: 265978968 264597467 333282019 333292177 IO-APIC-edge rtc 9: 0 0 0 0 IO-APIC-level acpi 12: 525534 951163 698370 667647 IO-APIC-edge i8042 14: 982569 1558280 1241299 1200781 IO-APIC-edge ide0 177: 4015581 6102627 5084144 5415943 IO-APIC-level libata, ehci_hcd:usb2 185: 5141100 8979803 6598927 6391688 IO-APIC-level libata, NVidia CK804 193: 134874 261894 280336 234794 IO-APIC-level megaraid 201: 0 0 0 3 IO-APIC-level ohci1394 209: 0 0 0 0 IO-APIC-level ohci_hcd:usb1 217: 192852160 1 3 810 IO-APIC-level eth0 225: 6879196 11640568 8902256 8644706 IO-APIC-level nvidia 233: 573425 874257 849441 1650900 IO-APIC-level arcmsr NMI: 113 61 79 62 LOC: 147019199 147019177 147019155 147019113 ERR: 0 MIS: 0 I would think that the Xeon could automatically distribute interrupts across all cpus similar to the Opteron. Maybe some specific kernel-compile-option- or proc-parameter setting is necessary on the Xeon for this to happen ? Thanks Christian From owner-linux-xfs@oss.sgi.com Mon Apr 10 08:54:53 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 Apr 2006 08:54:57 -0700 (PDT) Received: from astra.simleu.ro (astra.simleu.ro [80.97.18.177]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k3AFsqgC011886 for ; Mon, 10 Apr 2006 08:54:53 -0700 Received: from lapi.hq.k1024.org (unknown [216.239.55.7]) by astra.simleu.ro (Postfix) with ESMTP id D25B756; Mon, 10 Apr 2006 16:56:08 +0300 (EEST) Received: by lapi.hq.k1024.org (Postfix, from userid 4004) id AC8CB1B94BD; Mon, 10 Apr 2006 15:55:52 +0200 (CEST) Date: Mon, 10 Apr 2006 15:55:52 +0200 From: Iustin Pop To: Christian =?iso-8859-1?Q?R=F8snes?= Cc: linux-xfs@oss.sgi.com Subject: Re: BUG: soft lockup detected on CPU#5 / xfsdatad Message-ID: <20060410135552.GA6422@lapi.hq.k1024.org> Mail-Followup-To: Christian =?iso-8859-1?Q?R=F8snes?= , linux-xfs@oss.sgi.com References: <443916EC.10809@gmail.com> <20060410014701.GJ2732@melbourne.sgi.com> <443A61DF.7080801@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <443A61DF.7080801@gmail.com> X-Linux: This message was written on Linux X-Header: /usr/include gives great headers User-Agent: Mutt/1.5.11+cvs20060126 X-archive-position: 7608 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: iusty@k1024.org Precedence: bulk X-list: linux-xfs Status: O Content-Length: 722 Lines: 21 On Mon, Apr 10, 2006 at 03:47:11PM +0200, Christian Røsnes wrote: > Thank you for the information. > > Is there a preferred way of distributing interrupts across several Xeon > cpus ? I'm not sure, but how about irq-balance? ~$ apt-cache search irq balance irqbalance - Balances irq's for SMP systems Description: Balances irq's for SMP systems Daemon to balance irq's across multiple CPUs on systems with the 2.4 or 2.6 kernel. This can lead to better performance and IO balance on SMP systems. Useful mostly just for 2.4 kernels, or 2.6 kernels with CONFIG_IRQBALANCE turned off. So either you install this or configure the kernel with CONFIG_IRQBALANCE (though I have never seen this option). Regards, Iustin From owner-linux-xfs@oss.sgi.com Mon Apr 10 13:41:03 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 Apr 2006 13:41:04 -0700 (PDT) Received: from uproxy.gmail.com (uproxy.gmail.com [66.249.92.172]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k3AKf2gC017666 for ; Mon, 10 Apr 2006 13:41:02 -0700 Received: by uproxy.gmail.com with SMTP id u2so624094uge for ; Mon, 10 Apr 2006 13:41:01 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=MlAh5Td2FM6D4nWswB1ubNhNW19EDLtPgHBe/htfge8wPjmejieO2UxSx2xiX401717jEFThlYCTVfDbiEmKSpJDDCK5rsMerqaQP6wBiYrm7ds09lwvCh4Ufik0FDtocsjEoZSpAHxKEeHkoZD4pirJkA4mZj0tAcEBHn8iHgM= Received: by 10.67.24.15 with SMTP id b15mr2038782ugj; Mon, 10 Apr 2006 13:41:01 -0700 (PDT) Received: from ?192.168.1.9? ( [84.210.202.203]) by mx.gmail.com with ESMTP id m1sm54225uge.2006.04.10.13.41.00; Mon, 10 Apr 2006 13:41:01 -0700 (PDT) Message-ID: <443AC2D6.5030101@gmail.com> Date: Mon, 10 Apr 2006 22:40:54 +0200 From: =?ISO-8859-1?Q?Christian_R=F8snes?= User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: iusty@k1024.org, linux-xfs@oss.sgi.com Subject: Re: BUG: soft lockup detected on CPU#5 / xfsdatad References: <443916EC.10809@gmail.com> <20060410014701.GJ2732@melbourne.sgi.com> <443A61DF.7080801@gmail.com> <20060410135552.GA6422@lapi.hq.k1024.org> In-Reply-To: <20060410135552.GA6422@lapi.hq.k1024.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-archive-position: 7609 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: christian.rosnes@gmail.com Precedence: bulk X-list: linux-xfs Status: O Content-Length: 1000 Lines: 32 Iustin Pop wrote: > On Mon, Apr 10, 2006 at 03:47:11PM +0200, Christian Røsnes wrote: > >> Thank you for the information. >> >> Is there a preferred way of distributing interrupts across several Xeon >> cpus ? >> > I'm not sure, but how about irq-balance? > ~$ apt-cache search irq balance > irqbalance - Balances irq's for SMP systems > > Description: Balances irq's for SMP systems > Daemon to balance irq's across multiple CPUs on systems with the 2.4 > or 2.6 kernel. This can lead to better performance and IO balance on > SMP systems. Useful mostly just for 2.4 kernels, or 2.6 kernels with > CONFIG_IRQBALANCE turned off. > > So either you install this or configure the kernel with > CONFIG_IRQBALANCE (though I have never seen this option). > > Regards, > Iustin > > Thanks. Installed irqbalance on a Xeon server (running Debian) and the interrupts are now distributed across several cpus. I already had irqbalance running on the Opteron rig (running SUSE 9.3). Christian From owner-linux-xfs@oss.sgi.com Mon Apr 10 16:20:03 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 Apr 2006 16:20:05 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k3ANK1gC007801 for ; Mon, 10 Apr 2006 16:20:02 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA29024; Tue, 11 Apr 2006 09:19:57 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 7B3B14822BFF; Tue, 11 Apr 2006 09:19:57 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.snlinux@engr.sgi.com Subject: PARTIAL TAKE 949858 - utime fix Message-Id: <20060410231957.7B3B14822BFF@chook.melbourne.sgi.com> Date: Tue, 11 Apr 2006 09:19:57 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 7610 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Status: O Content-Length: 746 Lines: 21 Fix utime(2) in the case that no times parameter was passed in. Signed-off-by: Jes Sorensen Date: Tue Apr 11 09:19:22 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: jes,dgc The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:25717a linux-2.6/xfs_iops.c - 1.246 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_iops.c.diff?r1=text&tr1=1.246&r2=text&tr2=1.245&f=h linux-2.4/xfs_iops.c - 1.223 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_iops.c.diff?r1=text&tr1=1.223&r2=text&tr2=1.222&f=h - Fix utime(2) in the case that no times parameter was passed in. From owner-linux-xfs@oss.sgi.com Mon Apr 10 23:13:37 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 10 Apr 2006 23:13:39 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k3B6DZgC011419 for ; Mon, 10 Apr 2006 23:13:36 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA04095; Tue, 11 Apr 2006 16:13:30 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 23DF8494A275; Tue, 11 Apr 2006 16:13:29 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 951862 - inode alignment fix Message-Id: <20060411061329.23DF8494A275@chook.melbourne.sgi.com> Date: Tue, 11 Apr 2006 16:13:29 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 7611 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Status: O Content-Length: 468 Lines: 14 Fix a problem in aligning inode allocations to stripe unit boundaries. Date: Tue Apr 11 16:13:04 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: dgc The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:25726a xfs_ialloc.c - 1.187 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_ialloc.c.diff?r1=text&tr1=1.187&r2=text&tr2=1.186&f=h From owner-linux-xfs@oss.sgi.com Tue Apr 11 00:57:21 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 Apr 2006 00:57:27 -0700 (PDT) Received: from shark.2a.pl (shark.2a.pl [195.117.102.3]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k3B7vFgC022855 for ; Tue, 11 Apr 2006 00:57:20 -0700 Received: from localhost (av.2a.pl [10.0.0.99]) by shark.2a.pl (ESMTP) with ESMTP id C61D1A6E7F; Tue, 11 Apr 2006 09:57:11 +0200 (CEST) Received: from shark.2a.pl ([10.0.0.3]) by localhost (av.2a.pl [10.0.0.99]) (amavisd-new, port 10024) with ESMTP id 78247-04; Tue, 11 Apr 2006 09:55:38 +0200 (CEST) Received: from [127.0.0.1] (bya38.internetdsl.tpnet.pl [83.19.4.38]) by shark.2a.pl (ESMTP) with ESMTP id 2834DA6E65; Tue, 11 Apr 2006 09:55:50 +0200 (CEST) Message-ID: <443B60E8.6070004@ursynow.2a.pl> Date: Tue, 11 Apr 2006 09:55:20 +0200 From: =?ISO-8859-1?Q?Artur_Mak=F3wka?= User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: David Chinner Cc: linux-xfs@oss.sgi.com Subject: Re: server crashing References: <443627B1.5090100@ursynow.2a.pl> <20060410015916.GK2732@melbourne.sgi.com> In-Reply-To: <20060410015916.GK2732@melbourne.sgi.com> Content-Type: multipart/mixed; boundary="------------000309030707080508020601" X-archive-position: 7612 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: juice@ursynow.2a.pl Precedence: bulk X-list: linux-xfs Status: O Content-Length: 23475 Lines: 422 This is a multi-part message in MIME format. --------------000309030707080508020601 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit David Chinner napisal(a): > On Fri, Apr 07, 2006 at 10:49:53AM +0200, Artur Makówka wrote: >> Hello, i have heavy-traffic server that is crashing every few days. When >> it crashes i cannot login through ssh and no services are working. One >> time it 'crashed' when i was logged in though (i had luck), and i saw >> 'Input/Output Error' when this happened as i tried to run any command >> (like ps, ls or anything) > > It's not crashing, a filesystem has shut down.... > >> it is RAID 0 array made from two sata drives. > > Any I/O errors in the logs? i.e. is it a SATA issue and XFS is > shutting down to protect itself? no, no I/O errors, HDs seems to be fine > >> my xfs system is mounted like this: >> >> /dev/md0 on / type xfs (rw,noatime) > > Well, that explains why you can't log in - your root filesystem has > shutdown. You need to separate your root filesystem from the data > filesystem so that when the data filesystem has a problem it doesn't > take the entire machine down (as you are currently experiencing). oh, i didnt know that. i have to find a cause for this though. > >> thanks in advance and please let me know if you need any more info > > If there are no I/O errors being reported before the filesystem shuts down, > can you provide more information of the type of I/O the system is executing > when the shutdown occurs? I see many similar output to one i already posted, but it happened just AFTER first sucessful mount. the one output i'm pasting right now is ( i think) from just BEFORE crash. Also, there is nothing particular the server is doing durning that time. Durning the time of last 2 crashes it was refreshing awstats for every account in the system, so doing awstats.pl on the list of accounts. But it 'crashed' many times also durning the day - when awstats was not running. From the 'after' logs i dont see why this shows: "Apr 11 09:47:53 alpha324 kernel: XFS internal error XFS_WANT_CORRUPTED_RETURN at line 298 of file fs/xfs/xfs_alloc.c. Caller 0xc01f5091" what does it mean, and why xfs_repair didnt repaired it ? Ok, this is output i got just before crash (at least i think it's before), and the one from file i'm attaching is after crash. Apr 11 02:11:16 alpha324 kernel: c0134b03 Apr 11 02:11:16 alpha324 kernel: Modules linked in: Apr 11 02:11:16 alpha324 kernel: CPU: 0 Apr 11 02:11:16 alpha324 kernel: EIP: 0060:[] Not tainted VLI Apr 11 02:11:16 alpha324 kernel: EFLAGS: 00010002 (2.6.15.7) Apr 11 02:11:16 alpha324 kernel: EIP is at find_get_pages+0x53/0x60 Apr 11 02:11:16 alpha324 kernel: eax: 80010028 ebx: 00000001 ecx: c2affe88 edx: 20090000 Apr 11 02:11:16 alpha324 kernel: esi: 00000002 edi: 0000004f ebp: c2affe7c esp: c2affe34 Apr 11 02:11:16 alpha324 kernel: ds: 007b es: 007b ss: 0068 Apr 11 02:11:16 alpha324 kernel: Process kswapd0 (pid: 71, threadinfo=c2afe000 task=c2ac50b0) Apr 11 02:11:16 alpha324 kernel: Stack: e7fea7c0 c2affe84 00000000 0000000e c2affe7c 00000000 c013f1fb e7fea7bc Apr 11 02:11:16 alpha324 kernel: 00000000 0000000e c2affe84 e7fea724 c013f687 c2affe7c e7fea7bc 00000000 Apr 11 02:11:16 alpha324 kernel: 0000000e 00000000 00000000 00000000 c13ce900 20090000 c2440e20 c17437c0 Apr 11 02:11:16 alpha324 kernel: Call Trace: Apr 11 02:11:16 alpha324 kernel: [] pagevec_lookup+0x2b/0x40 Apr 11 02:11:16 alpha324 kernel: [] invalidate_mapping_pages+0xa7/0xf0 Apr 11 02:11:16 alpha324 kernel: [] invalidate_inode_pages+0x1f/0x30 Apr 11 02:11:16 alpha324 kernel: [] prune_icache+0x1a3/0x1b0 Apr 11 02:11:16 alpha324 kernel: [] shrink_icache_memory+0x45/0x50 Apr 11 02:11:16 alpha324 kernel: [] shrink_slab+0x136/0x1c0 Apr 11 02:11:16 alpha324 kernel: [] balance_pgdat+0x222/0x400 Apr 11 02:11:16 alpha324 kernel: [] kswapd+0xb4/0xf0 Apr 11 02:11:16 alpha324 kernel: [] autoremove_wake_function+0x0/0x60 Apr 11 02:11:16 alpha324 kernel: [] kswapd+0x0/0xf0 Apr 11 02:11:16 alpha324 kernel: [] kernel_thread_helper+0x5/0xc Apr 11 02:11:16 alpha324 kernel: Code: e8 e3 d9 14 00 85 c0 89 c6 75 0d fb 83 c4 10 89 f0 5b 5e c3 8d 74 26 00 89 d9 31 db eb 0b ff 42 04 43 83 c1 04 39 de 74 e2 8b 11 <8b> 02 f6 c4 40 74 ec 8b 52 0c eb e7 90 83 ec 24 89 7c 24 1c 89 > > Cheers, > > Dave. --------------000309030707080508020601 Content-Type: application/octet-stream; name="kern.log.bz2" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="kern.log.bz2" QlpoOTFBWSZTWW1t+IsDRDX/gH2WEABs7///////yr////BgZN9sYPqgGABs AAAAAAAAAAAHUcBo6Aw0pWO7gCQAAAA6AAAAOgkAACgAAAKANANcSusiCUAK KIVUANAxEgBoAANBVUAAJKAAoA7ZQAIgAFAHQAUAABruDOhQAAlSkaQK2kIg lKoClUqgJSKqlCgSI3cABuysjSqqlWtFTUhkBKIooimbCAlR20qGjVUSpVFw khE0EZDRoRNoAmmkeU1PU2INTagZMTZTNA1GglAJpDVKaMhk/U0h6gaaGRoG QAAAGhoAc0xGRk0yaAZDRkMmQAAAyNMjQMIZBzTEZGTTJoBkNGQyZAAADI0y NAwhkCapQmgE0JomRlGUntNTEnqGjINhT1DxRoGmgGmgUlJExBI0Q0aRkJml GNSbTRqY0T0EYg9QADR+hPl/5cTYuNS+SKUmfrv11/B7c4XB/HY6qB535H2v Z0U6cZGlF+55fb84qNNbPUy23SkeU/G5TF781JvXfK+nXTrb/srbbR/ucvm1 CAi/teTZ9P7badzPKLNFttvmuy/J0aG9tT2+aFk1sXQWzl7ZUGD0jr6qbPmM XpjOWtpXtxE6aN8VISQSAYBJH6YgOhDoYouJvPrihHaqyoLtBu3Nyqp0MFXU aEcjSlcjrbm220odDCmGFP0GHYbtzc222ttlVdhhS6GpDgwi4m677iO2Vc7b jZu24bTNISbRYoMyZkicLKVwFu3OEdmkudbgk6jVA4nXNmcNKitjFVNjbNAL WWEjSWKHBhFyNtJHBoFyMA5Wil26rtt1tDtkudc5tgjqskXVdu3OhS7JqJcT tuFDoYJhgncYXQ1ROo0gcTJTi0RcWAcrRS4MqTg1UtW2VLoZHSZKnSZUrlMD jKXH8l7ZXT97w/sK7fpJZxPYSuKcKoiHYdMY0/an41SgN/9lf1Tx5c2yvVOb dOG6w+2fUtxPt7aYP5Nzyz6aiUnTfG1+fq0n6YWw/4iFu+nL4C++uLOFJaom Q0h3GbqjYLT9EsFIcijMzMzMzMzMzH0c7iqBAkJCMX7z5CD7sDBJAkx/7R8G sQSY82NkKsECQkI11wlDYW526NM+O2deeYEm79t9TFc9vu+GHhN7nyQhQO2x AhJ1u8qEK8gJjC9da4YKR8dhpgWZu0GrtHzsoYjAeTKCVCAr9FI9jYnynpPA Y6ByfNzDD50xWFTOYVbS+QTPG6K2CXD76CJaM7o102wK2t60kCTJm2OPPkdQ dNrnCQuZvS84DL7HplV49BJTdteDEPC7mRuxdEgucz6wlankjSwRrrgjlH1N nTIDh+1ShGU+aEVMItGNUO7EO4ttY8zmD5yAI45mz5ZoEJeJjOZq0CEv591i kCt8FSDPrVSMsgvw011jPt4fBX6+h+g2/hB1GG2j+Y7jbf2i/4GTIw2/th5j /XT1Rpeo29FvZ0MyXKefLxHgeHg6jqPZDsmjR7R6jewvDJqNHqHmPVPVGV6T 1LtHaOqHSaNHkeo3kXpk1Gj1DzHqnqjK9J6lxOdh2HAdk0YeR6G8k9MmRh6D zHqnpGV6T0r2dx3O1XZHoevZHphkeq815HlO/UdR1Q8po0eB5jewvLJqMPMP MeqeqMr0nqXYdo6g6TRh5HqN5qemTIw9Q8x6T0jK9J6l2HYdA6TRh5HobyL0 yZGHqHmPSekZXpPUuw7R1B0mjDyPUbyL0yZGHqHmPVPSMr0nqXYdo6g6TRh5 HqN5F6ZMjD1DzHqnpGV6T1LtHaOiOk0YeR6jeRemTUYeoeY9U9IyvSepbo8O 4dCdieFOyWHgeE8D2L2TwORcT2DwGHgeE8D2eyO6nsPFXcdwd00YeR6G8C8M mRh6h5j0npGV6T1LsOw6B0mjDyPQ3mp6ZMjD1DzHpPSMr0nqXYdh0DpNGHke o3mp6ZMjD1DzHpPSMr0nqXYdo6g6TRh5HqN5qemTIw9Q8x6T0jK9J6l2HYdA 6TRh5Hobyp6ZMjD0HmPVPSMr0nqXYdh1VdDRh5Hobyp6aNDD1V5HpPUNL0PR e3cdx2B2TRh5Hob2U9MMjD1V5HpPUNL0novHcO4dgOxMjB5D0GeqTwZGoYPS ryHonpDJeiehe3cdx2B2TRh5Hob2U9MMjD1V5HpPUNL0nouw7DoHSaMPI9De VPTDIw9VeR6T1DS9J6LsHYOgOiZGDyHoM80noxMRg9KvIeieiMV6J6F2HYdA 6TRh5Hobyp6ZMjD1V5HpPSMr0nouw7DoHSaMPI9DeZPTJkYeqvI9J6Rlek9F 2HYdA6TRh5HobzJ6aNDD1V5HpPUNL0nouw7DpV0jyPAPKMPIeU8Jh4TxTyOw 6B0mjDyPQ3lT0yZGHqrzHpPUMr0nouw7DoHSaMPI9DeVPTJkYeqvMek9QyvS ei644mj0PXo8R7DwvDodDwDpNGHsPA3pTyyZGHqrzHpPUMr0nouw7DoHSaMP I9DeVPTJkYeg8x6T1DK9J6LsHYOgOiZGDyHoM8qnoxMRg9A8o9SeiMV6J6pd h2HQOk0YeR6G8qemTIw9B5j1T0jK9J6V2HYdRdJrD0Hp5K9Cw9VeQ9D0GT0n ouw5VxHsvDJkdq7J7V57O6d48Rg7j2lPBXgewrwRh5DxXlPMYeSeU6ORcHke hvT0nkPHlXcZdDoeQeU0Ydx5G8E8smRh6DzHpPSMr0npWjqOD2cHUXEdl0dR 4eKvHZO6vCdzo9o49qu6tXY7R57vKeY7+Fd/FdDpdeztXS64rsOix4jt3d6u 68uVxdvHhOh3TyTqOOTzXScOQ6cHUew4XI6Xdd045XY6ruHoYYYYdl7DuY7o ew6dDoDSSs3dRiGxlkQEKAkCkREwAqAoGR3G8KeGjQw81eR6T1DS9AZQRTIy zEOIZWKdWwuJmInLNTErE4pFppeGVpeFM5maw72VVtkEdUEInFF5zTuErK5V 3Spp1mCEw9oCQqBcLh7e2dqzPU39fn8pNPSW9Vm73IEJMZAUSEgZMIbnu9xF 4fIH/NTSK0gSB3J7ZtlHXpjkiMaTo+2HcLKtmu5HYthtgoZrtm86ptViI4KV XLcXSEhb/XhKWNTmHPx1dOaoWaS8jNoqrAa6usX7mlJAB0aSSMMN2qUUHvTO WlV6VetAhLkop+9yyYV8kIEJfVBm2eMyuwBCS2ZqKrs0dZXb9TdLcexAhK+X GQc7Z2abg19Hcgb4rZatFNlDJvs4jToQIS6ZkMjakkDMgOo5tupYN8bx9fh+ z/Z7lSUnwAf0w8PflUo/d+HsBInggQlY9EJISNz79um2RkwaCzyebN7Cs7sL LWsZJW4CQBYB2Gnmw1xKUZmfueJTm0nfneUk84qipp23dF3q2fFKrloxXoSB JQMIWOu6XRd5OI4Wapn3KR93w+X6L0+3+voVHy4/Oz0ScuEgeOHTr+H629Nq EFf8VhakEhkAkmATCBuzQeju8t+jlbvgDeX4X3OeeLK/Jm0IFoR4VBQgkISQ xmbhy9nQcjGoPNXVXNVDVBV284c51Vo1P2bs8y6uTtps0gAg26jCpCBpIQku TSA4kgiXycZd3HN1M7dtKusfe/fZr0dEGVmFWTeWfRz2Z9YkJJeVd5702bs7 /IrwrSQkmTJAJISYsbLm8KdkmartI8ajjc3xUpkmZAiTK/LDqCGPZywZ82DH by+oIOhrfc9NPS27Nw/E5fw8eOc5v3eG/hyIl/SO7JRxNUmWqv4PwAOoHkf3 D/ZVK/yU9nRGD5pK/zE4/2wyOywP5Iv6Kp4D9slXYf8SZYeoq+aFdF3uhGhW qrCRuUMKvKlNMhMrSsMGLVXB/idFK+E7ypX/aPsl2DyeaC+xSupI3SuK6xVd J+auQ2VX+SvCdQjySr2RV9B71KvQVdPiAdVSu6rwCNJV6PCeUuiVeZI5Shyi Roq7KDZFX4sRP78lfiAdw+nSPpVK6JT5qgc4MwyZDMkeALeI6euVOgt+U+cv 5L+jwdFbchfZYpYS0GKFU65i2/A9X18+kJT7hH+dv5Z5ce0KV8sQZPngc+jf o4T+mau3uZYxUzfhckg60kCXQ1YlNkq+XIPNljqM0eX18cy+Z3HeZrtHRgbG MUrv11JeXZVSo228VI//fy+JPpJx9vOTz5qp99UVsiX+Ayn3lPsl3hhh+A0c jDg1I5BgcBicTJxNVyNHIxODDgwcGHBo5GHBo5uaFwWU4pjjOMnEycTI4MOD SuJk4mDgw4MjkYcGDgw4Nzc0cGHBpXKanKaHBhwYnEycTJxZcWTgw4MVxMnE ynKanCzjONdKbJV6KxBlWSsxK3tldwjaUNrLrbEjlF6cUDdS1VYIdnHR7sw/ MdSVdi7VqdB0YloyW0WZMmKbDDFbLLDDVPmh2S7Bo0eDHKGg2iyYmjRyNHIw ww7Dkcj35zdNFwTM7M4mJhg1MnZhwYPQ5HIdhhwYcriuV2rnGGHccpyTRhkY runFwul3XRdLuuDg7DDiYtTVWZ3Z2VTB+VVeB4GGGBgZMmjRhhhhhhthaTMy ZMMMmTDDRhhq2w1ZMmGGTJllhhkyamTM9FK/Kir3VSvce68UF9D8x4DwYo2F mGTJNqw0G1YZT5D0YGhqqnqu6ZfaqV+AVd4O1XoehhhosDJk1owwYMM2RhZM mDDDJhhhhq1barD8E4OJhhhozLDDJkyZMz2Knc0u+NpB3qp9mqZaA6DhqDyM MNRemIuAHUd40aPc4hyhkyaNHI5HI0aNGjbnnoXQvE447OJxMMNTU0aNGjg4 ODlc524ODU1NGjJk4nFxdLg4OhxOJqanE449KSvBwx7KD2P8F58f2/n+v/Rs fLU6hgBCVBIB/PxJs8oXu7rJyZrBBsQcQeRyPuML90YdD+A6D+A9h3HB6H8B +8fqPAfqPYODwOh4HYeh2HsP4DoPkfI+ke0fQ6OR2jyOI+I+DB0PaOw4PgfQ +h9D4PB5Ho9j6Hodh4Pc9h7juOh9DuOD0fI4fQx3Po4eTsY+fpDwyHehvIPD xWm7UO8GQvkjJdVeougPgc0m3iDuDgPcHuD0D4B5ecmGsMD5B4A4q8qeVm3Y HZ0DA7qu7uD2B9RdlXyq+ZHp2h7V9Q5XaHvD5did0+k7pxPKZV8Jk6T3TomT unZPlPSek+k+k8k+k9icTwnSdJ4TJ6Tsnsn0nRPlPlPj6jqNHiPqNHUeuTNR 80vMd46jtHxHmPqPmPePUfUfUeY6jqOR5jR0vUa8Ry+o0e0fEcj3Ro+D4RyO w7DkfQwvQ+hg+B7DsOD5HoeR8jwHwPYODg9h0PQ8j2H0PQ+B9B3HRfSOD6GH cYXyL3HYdDg+B4H0Pgew8D6HwPI6HsOw8jsPoe49D4HA9D6GHsPocH1xHePo aHiPYcR9Re8d46HYfA8j6HyPYeR9DwHocHB5GHodx4HB9D4HuPofQw+nO29v rOvdjZNS8cXtxi9YIZsLcy2tmxnh4bXAgwCQaLOhdC9id3sjqL2qYR7iwdL6 DF1VPmp4qd1OKfSnlT4U+lPF1W2ZpM+Dq+lezOeA+rVPCnpO1mx3Dxp4U9lP kXdT2U8o6F9UfVtV4cdjy4ueDo7HcObb7likGihiBRKLFDYog4NjY0aLBzRR BsMYFKLJNGw5gU3NxjegQYQon0OJ9J8JwnwnZMTpO6dk5HzHmPQ+R4J7J9J4 jpOyfSeU7J7J9J3Tiek907J8p2T5T0nyng+g7jyPYcHge44HyMPcdx0HYew7 jg+R6HuPkeA+R7BweB0PA7Doe49hwfQ9DsPkfI6+lPan0nZOU7plXzTDpPA6 JvetvZO6cTz8Jo+k+U8k+k9h4aOk4P3uydnlMnundPCfYdE+k+k+ns7vr7I6 jsMPYYX0MPI4HuO47Dg+B5H2HyOw8D6HA4PA6Hgdh6HYew+R8D6HYdhwPj6R 2j6Gj2jUvmMPQ4j3jvHYcHwPI+h8D3HkfQ8BweR0PI7D3HYeB9D5H0Owww+X wHB9DxXB7DC+Re47jocr4rzX1XmvVea+q8K4P1rqvNdh9h7jyPtX0PsO1d64 iMghzIiiJzGqV4V8saS5eN75uNs61cu1rmpb33t9e/XxPgfQw6Hgd64Ow9xw PceawfQ8DsO9fNe9eq+a8q+a9ldDg4PYYeB3HccH1XmvQ96+K7j3HwPb6p2D unKcp8J5pyn0ntXGynzTJ7pwnsnsnanE+k9k90+k+yeU+k8fbTYuk9J2T0nZ PhO1PNPA+U+yevtHQ0e0fYdhyOwwuC8jsOh6HuPsPsPkeB5H0PAYYeBh0PI9 h9D2HQ+h8Dg+PonE6TJ9JlXpMPkcJ8J3TsnI+Y8x9R9R7p5T5TwPho6T1W3Z PUdo+E7J5T6HznqO30nx6T57J5jJ3j7R7F0vSy8r45bS+kfK7rpdl8L7L5Xy vK8LwvpeV8r7Li91l4PZZ5XHnL5XJ14XZeF7riO6xfZfZXsMOh2GHke44HuL g7Docr1X1XvXxXoeR4H0PNdDuPgeh2HsPsO44PgfI4PofIuDlfJOJ3T0nE9k yr4TPZPTonunhO6cTwn0nunwngnynsTieHSeE7J6Tsnsn0nRPlPkncfSmp9F qdqaD4pk9k4p6p3p2pxPdPpPpPlPdPKfSeCcp5TpPKdk96di8F9J8p9Kdk93 TOPpnTy4fC9O7p2e76NHBBZo0OWOMWKOSUMSKMaGNzAp0O/39vzafPXHg/4f 0e4vmjA1GFqMTIxMNFkapkYWRhZGFkYWRlMMGGLJhZGqZGqZGqZGUyMpkZTB qTIapgymDUmIymRpMjSaGUyMpkZTIymRlMjKmIymRkZGWJiMoxMjMViw0YYw 1NlDJAzM0245B58rYzaojTmzkXEkGQ5+u/GCne2Zo9P+REl+lJWg+w0fY0HI smTRyMi4GcYrgyYYYaMODg1bajiZGHE4WWGGTjUycTh+YcH5nQB9/Kh7/wHs GMMWq1ZVqWJoYdhg4MNSxGViYYMmKw8jg4MMNWhkwyarDViZMWLuvT+r4+3Y cwwiATiW3aSLcsAqFVeUL04uopkRoZEXl+ufDsAZXbgB+Ae9VV3fj377W7NK qq5RJPaCwBJtYgS8tEqOlpqIjzZIKt8qhHXJzyIXJV9lIaFOEsSS9Uporzok 9EqyLt8n4J0l5XiQvw8972fuh5Rx8/LydeY/IddUetKIuNu1tXHj2nEkdPS3 dIEt9sv7fb3IpSe4B8jpM8vy5/RjZ/o3x2cpamAvYcasLfhdImzIyQJLSYmt A6SGH7hoL2AP3Io98pTqKrwViqtgquRI8aXbPdXZCMCboRig0CPF2le1K+Et zX+EKk/dBaIwUYairVStUMVYkowbUlZLE1IPwWckYVWWUqwNKTKqWCxIYgZV WKJihlWIjEhhHPFKTSGUypKyiMKslkqJiEZBYAWVWKlYDXCoaFZRGJWFDJUL IoZVZMFK1BagMGlBlQYEalDjVSv9zqKrgVYjQZSGDEIyhGRIyoMiDVVWlMIN EDREuqiuOIVZGUGRExq4/Z7P9Tn1ztetvyEfYaozSjDKsMXfq73gilJ0/s/9 viPzGjDRhhqtGGjDRhow0YaMNFhow0YaMMMMNWGrBlYasNWDKw1YasNWGGGr DVhqwwwYMMMNWGGGGGrDJMMrbDV29+dc/POc7dvHxH7M/f8v2/DpLff6umld CNq+ZVNyoyJHWH9dNRZLBhhhthZhkyTDVhqWyy1X0ODin+/7eu0VT3/j/8nx +zsAfwAPPADzk/ryV7X0vMXaryL9FySiJalDjL388g/+3aqV4Q83Y/SSr8vX 7mcPEpzBd4lGdrJBOn9S9qpXcVT4g/cCOKpU9ooe2RtVab6VR/dkR811duLa 1hGVqEeul8cK5lFZKxF8khx8nfgrO678OskbI31yEL8nOpRXII15ZEotKB2l W+kWjwbVIvPnv03rXaPvd8btJV+h8OvgQL3ahX2Puoj7SqfAjwpK9SRkFtVZ R9gDdqpX60Vcpf6MBTyqHrdB3VKVxTCR5Z6efntmfVmvi0vP8t5/ZHqOJhyN HE5HI4nBwcThwaNHE5HBxODg4nI4OJyODicjg4nDBhwcTg4OJwcHE5HBxODg 4nBwcjg4ORwOBxHBwcjg4ORwOBwnBwcTg4OJwcHI4MmHByODg4mHBhyODg5H A4HCcHBxODg5ThaMbDg4mGw4cTDcDhyqYuDnBwcjx120SaHHd4d5Rv1EtWap gNrZ2MycPKTRLN2OnTYCVfiFX4B+Z/dwGZNoxh5HC4NhmydOKdF1x05yOk4c HBzibDYZqzaauVzodI5in8eoD8vL+3+PH/8cPXXzfjRqSufkm4UU7JfoJT+K fFCv21O97dnBSud4lNUu45Ar7eS70F/gKwEbFRe9KIlvKK519UnplN+vPfbk KLtFqVtenEj/nsENIKLecOoRrBeV57lXHkk5buUKsKHjJPc7VRLwRH12ql8A HzgDlAZPkvwPX7F29XpV3L4XtErzDsPudwiO7jynCkPsqh6b8awUYpK6QWIG WSupG5TnK0K8VZJqC2S+XFSfkH7oVfKXSJ+38/L69n3bn+/ePlPzo5s4nCcc ThOOJwnHE4MmJxxOUccTlHHE5RxxOUccTlHHCcTJkZNRxxOUccTlHHE5RxxO UccHEccTiOOE4Rw4nEccTiOOE4Rw4nEccTiOOJxHHE5RkyOOJxHHEzJxHHE4 jjhOKOG4mJxxOI44nBiZLJicZGZMWjgxA474PXEO8RBiXOY12WaawQVCSEnQ jUiOo/KMMMPsMODQyNDhgxwcoahgaDQbkXAciwOVk4mTJk4mTiajRloyrkcR yNGGGFwYcGGGFhwcjDiOIaxzlwWiwsLC4GU4GU4s4zMuOHExMTJicTDgYcGH BqWpkyZODJxMnGjgwww4MODDDRo0aNHBhwYYMMMMMLScrK5mOc4MGBwcHKNT NTU4mpxMTRhhhYcHE4mTJk4MnBk5wnFljLFlhhcWLgwYMMHBwcTJkyZOMnGT g1OU1NTU4mpxMWTMYzGcfkVKug/mG7/XY1vs3+eV5JREuYR2p6EYi43ljsqV 161H5SVd+yqdpOwXBpXUhd6FWKg6SdHZNV0opgvZykprsdL5k7l+Xsop2JVo lO9BcLlVImUeCDl0Urun2TpX38F49pKsr9C1Kpxq1k3ALzKqnJ1r01k+IPJH 4SfzVK7/Mj94co9qkTRVWJDcI+J6FWqg8FWCqvAfL2CrtKdUh4sg+n2XRIad JTauZIz4u9rJ6fbzo7SKYUwyvvqDnx93mdEUpPyXMfjsz1vHfy9yaqVxyPkc HuOD3HaODsMOh0RwHQO1XAdgdk4nZOycTsnaOR2jRyOow4Oh2HB2HYcHYYdD qODoYdDrnW66FwXVTsuSdlOuzpx2cdnZOJ2TJ2TsnYdDsOw4Ow7U4nZOycTs nYcHYYdDqOR1GHQ6HB0NXQ651uuhwdDtXK7DtTidkydU6Dg6GHQ6TidJk6Tq uLpZdLocHQw6HScTpOycTsnanKdqZOqdOOmdPtEi4fh+XbxH5e/w80+9JWiU 96V3BHxPrsIF+dCvqr06OFK54PcuwRHj1UV7SPz7UBeyXd2oq+Oee93xSnlV jdNA41oEcqI2klNIoYklXUQ471bQR248Kbqqq7v2u/T3/IvI+C8PvkeyU+Ic rw+O0Ljsj6cVK7yF7hU/J+Ep7PwcAjeuve+kXlVdKuARpN6Q1TlRV9ilaQvz efff7Ofn1nOfh6cGqw0sNLDFhiw0sMWGLDFhiw0sMjDDDMMWGLDFhiwxasWG qwaTDFhlYMphiwxYaMMWGLDBhiwysGUwyYMmGLBhYYWzVk87079c69vavz9r 47pfhFV6ifaSr9EX0qlfEvYPtAPL689DuPxVUnXb8ncfafSfn2iU9eqnc89i ItSvM7HXdyqV3xSun1XiPg6VPPE+yKviUH5/I9nxDxD5j3SV1ITwqDSn4l8J 8DtkUWJSnW67pD31XhOUWyOkX2qVfpKlfPyCPtSV8g+xyir2DsQOVSvAVYoq +7s9g6oV6+fw7Pv2j36Gw5HODkc4ODnBwatHODg5wcHODg5wcHODkc4OC1Yc 4ODnBwc4ODnBwc4ODnK4OcrgccVwc5XBzlcDjiuDnK4Ocrg5yuBzg4OcGw4O cHBzg4HHA4OcHBzlXBq5hwNXFREYBmAUUBWQFYBukrPhsO8uxES0zOmafDa4 uV401y58725+crrSGgRkodoB5Pwh9Rh3VT2h2X5J80F9J3fXns81SuTxJ2f1 XZzwWckq7tF6yRtrJHLjTpVniW/rbo8kRN3UU4JT6ftOiVeEVfgAfCPcKt8v olXw+qHtQ/Odk+alXyPxkqyPt14Uvv0H2rbBhqWGhhqWGhhgwwYaGGhhoYYj DBhgwwYaGGDVg1YGVg1YNWBgwYYMMGrJhgwwYZTDBhoMGhhkw2GTDLDKYYsM sMsMRhlq1TVvy7dPl2/i595T4S9D7ygwLjKNGRbVTMJbVYYjDAsuTtSHnOhV O8SNPeSO9xpDiqHG8sSGhVzyqlaCHupqnGLrzKpreFIZZRDy49B3nzd6Kvcd +ypSvCZGTRk0YmjJoyaMmjJoyaMLRk0ZNGTRk0ZNGGjJkYmjJoyZGJoyaMmj E0ZNGTIyaMmRiaMmsJqWTRhiMjRkyfTRymjU0amGLQ1MNTDUw1MNTDVWDUw1 MNTDUw1MMmGTBiYZMMmDEwyYZMMmGphkwyYZMMmDVMMWGTBkwYsMTDYZNPyl PzVfI5VK7n4neT9x80lch5Yg/NPp2KHcI3vPizmtvSslWFYxWSrUahqNBqNV k1DUaDUYGo0Go0GoxGo0TFoswNRgajA1Gg1GBqNVaGBqMBlGBqMDUYDKMDUY GowNRlWTA1GBqM0YGowNRgMowNRotLVZNKYmrIwMRoYjCyaJhgZG3akWGYiU SirDQ5k+oQhKCtCjYBpLQBXJMijJqHwvquofREfkuw9h+IwwcHA4OKuA5F+d cB06BxMmTiclxHI5GHBwYYcHA4OhhwYYdDkc25zVOKcRpMpjjhZOI4jg4ODD Dg4nBo44mHB8DocGHUcHBhhwcrlavjg465HK1auDiMnE4MmTDDDg4MnI4NGp i4uKw4rg4nE4mTJynE4mTFnGZx48x8/Cf4vt47fB4ql9oqvjgAAcdSAHpv52 9iBPx5VAABTcIxBX5rKeIVfC7OI8qfonT9/p2unM7pmHEfsUldOp5NZ+n8+u z9qb6ceUpi/Oh3XUP1h/CAfgPqvh91+9JXfkPUVXmv0Uq7roA7EpwlPKOw/C kryp2irnh+W+fr8Lu731Hs0bDYZhsNhsNhsNhsNhsNhsNhsGYbDYMw2Gw2DY ZhsNgzDGDYNWC2e3O3XW5ubt3XPYvdOvbrqHlHJKsPuMWGBgZMmjRhhhhhhm ynk4lwzIyYYZMmGHBwcHK5XBm1WGTUww0ZORxcWDDJkyYszj+Pvvy8X3Eq9K K5MKV9B8ukvJdvhXeh8SntO2+2j8k687wnsXPyR39LrvQX11Erg9x0jwn2h7 julvx5UKd3mQuYoptUqSzIBLMlMi/LvJV5R2APUPFT1SuUI5qDsSvXbRR/3u NXnV9qvX/H+75Z6ccrYayhInpn+G52cxAg3tko3tIEdEvS87YMHb7NAZ/6cL BXI6o4macTjurRyBy561OTnp/xnkOsp2XmiD0pklDCZ0/3M8MOKhmHF6WB2J MgK2HKviDfwmkTGQMNkMkJJUzOybbYSvkhCmSeuxmZtopZZM1tMzHPQc/qN6 8n0DCLrGP7kGDuJaGxZ51IQoSEVMCGkOLDB1x0cbc2sIBz1HDI6z3iTE+P7F VLldJTf3qFj2UU/u7On9M67uLzudO7+r+Od/NPS0jLUy0mWLJksmSyYWTCyY WTIZMTLJlky1MsmWTLExZMsmWJiyZZMsmWJlkxZMsmWkxamWGsmLJlRqZbex Ip53tQpvLa73OKLS3Si255pgE0ziVFzIp1345z13hJefZ2KlXPh26bp795C7 PNMamamZMyZqZkzJmTMmamZLMmZMyZkzJmTNTGozJmTGJmTMmajMmZMzMmZM YmZGZMxMZMxjMZObKKdVFO/nbpRT0JTAont77koLp/s6TzGTRk0ZMMjDJhkw yYZMMmFiYZMMmGTDJhow0YZGDDDDDEwZMMmGjDJhkwyYZMMmGJgyYZMMJhiY MTCyaPLe3tTVFMkC8+m4gI9uziiLrpuSSGezkQHru+CKde3Nz2Qi7O/HKTeN xvcrS310+H9IUlXvwIC/s+q1fdcP7/ptfov2fz7+V68LPdJ6IvC/w1fCv8pV wK81B+cge1K7kq/kqnZO0v0odB/NK2ukOEXSXxUNqRcZ5S+kr5Eq7vp8oq8u ncaO6Oq9x1S8w7AHB3VoKewBolXkoc4qvIodq0XJV4KjdQaID6o+YVeke4+I fgR4hPA+zV5RZ8AjxJV7niT3q7ruHIKriIdRDjlEYJG1JGxI2QjwEcoRxkjc qnQI7VQ8BHiqGxH9F7/h+Pv/LX9f9zji+Yzv7Bz0Eezw/J8/7n8IEJSskuoZ V6R0fAEREsWs7fqtf9/lpHLJpZ5v6aX9n+1SNV+64VcSwI8Xa/06555XL2zb SY4foUjNM7IkfmD2bzfegQluU7EMvdQP9qaBCVk0mzJ7wY/MEhJmXiZAhJwf GWMrlR72M5J9lQ02cCQ83hTdAVzjiY3Btyr00qW0SYuxHRJiggpqgRvV3vib XjGQwudjvbWTZWgbJVdThFWeMeVw7LPXB6G9Ay4IEJXcWBjMOYbBIQkyPr8Q VhGfxciBCUhLxW8VFMxYqaAQztdAobMgR1uFXlsvEnjjctr5vgpHRSOEncCE uWr22oEJOHzH6vb6bLKNoSSEma10ir6ZS7fT7Yv2vzpx8fl5iV1X93z+f9Hs cWu8+0Q8WqkdVI48HCX9uhllupH5FJeep/c08+uPwiV78fphSuzxwUE/58JF V/tS/3aID/mwkF/p0QVOHdSPu+7T75XttJHvUjqqkffV+2v4q4ov3dZVFsSN VD90VX7SSNKRYkj9gR/nqpXxRcaRcQjglJX6k4aSR+uq1Q+XsHtBqD/Wuegq w8pK/xI+Ye6/6+8qV8ntD2hPXXB3R8B8KSfjqg/6Y/Gp7Pd6iV7ouT/dVek/ ek8yD1pDeEYqqvMqmpSLwkOAh/CXtV+6C3BHuq72VxiDaLuq7iL1yRwKuIR3 iRoV52lvK9bEvCLeqHKC4UhxUG9Vwit09DzuB7K/OR2VZ9+yj6hjuOUK1C8e KH3XB5RfjR3P+4ckq91PchHu5/Cq2TvSG6Q0rpwS5jDye77fEO6pXcKvVD8J KvvSvMPx4SrIq7p2D4U/cAdFXIrgPCoYSNFqqt5NYvbwJWgU7J2g7RQxKvUq S1KHRIbaC4qvf5/jvftX41J7VWVKf9ieClcpK/55H+J9xhoyaDKsmo0MMMNG jJZGYxmLJhhkyYYaMMNGwyMjI7uRxZYYZMmpizlJX/j+sVdw+X+06+Dfw7V3 o7HH/f2kUpPKL/vPeU+53hhKvafxkdz0CP3h+tEvzzMgOyVXsmSeBR3US9qv l9fev4NDj+vrat0zP2B/Ea+p/qY7Pl/H+J/Y8mkuUlXUnUfdP3AD40VV9Ito W1ouKobXsINK6RSvZBT7D1VIWkaCp57i/seOP8ZeRVhHf7km/nrJHDLa1Vae maz3dVFd/P1KCN/wdyKUn/n9/sH2PYnv29eMj+f7oVfPoO/dFXbKRL2gvDkU Rw15XpfDT3N9+fdK2SY+l2u8F8o8V/uz6eE3v+Ojyir1+/OSqvqrIt9q2AeY RyhGghlFX6J9D1td30+3tQ90f0+fmv+168/P97+kP/nStR+3+VUr+Yf2qp/g P7hhoxjA0GTJoyMMMMMGjRnXCcqZjJiYYZMmTDDRhhyucYYNTJhhwcTlMsuy y6XQ4GTJi1Mz9hKv3R/M0F/hFV/mirVCNDyq1JDL8Kr70vmgciuig7ShoIcK rS1VL44EvoA9UODSQv/f7z7Kp+AfFVH5ffK+SQ90Qa70R2rwSH5NK8K9yqdI ZH/yetd6vs9avMI97lO3xP7z/GUTlFGJT1x1VLipx1VKzSJGaX8B+oI/29vn O/379lSukldvUCbf+HHN/2Gp+AB+nq/Jx8pIf8qkZUj3FD7SrTkifGGon9Yy MNJD+WQvs/f9v/MUkraKMKoswpBW9w+JRf5Kle3yHZF3Cr+00p71SvQI7lWh Q6dxCcar/yVWkkZ+dH80lXVJX8Q+r9zH7u0OWhV/p/5nsPqf5vAzdN6w59lK v5yOvtD8dOOfXdnd+ZcEI6FrfMplpelZaW35+u3TJz1uTBxLgIcoc5J/Po6h V/4eThnujaDS1B25OLbRWCr+fOnyqnPkqX3pX2HcPAxF0nxHxk8OLsOd0lef tVeHfa2rMueM+29+mptlYxwxcMmuZYZj82HWqh0wBwLfxpK/riq/sdiU/en9 KlX8qQ979R/MYYv1OVHIWTJo0YYYYYYbZTjimXHGjJhhkyYYYYatW2rDJkww 0aMGXlcrg4nE4mTJmcfwnxDQ9s+y1tiOARqnOqH2ztLhJ1flQjtK1U5VQ/ND hOKlPjgnTeV8EH1L8nxFV0n+LwSn5KD+M/OpV9yleSB+yAeJTKcDmHv+kOPt fzUqug+oVeAv5P3f4OSoaPaOXqVmu9Zm1cLb6JP27vmZwRDaZwmn0tCvz8ry KC4vF6WVW/3ZPvKy/kvEoew1ld5QZEOOipaNtQTiPwdzDmBtJ4BxPe/TDwwt NghCT1N4O3WHkWzhRXLYAREsKCDK1/SsuwDAbWrbuSc294L1HgNGDUMBkxNG RowYYNGDZhZUzGTEwwamJhg0aGGDZhhamlowZMTLFhgyYmplM07QnclXSAdy VZVpKu0EcqVd0dd934znPW55/qHpSr+gP6hh/IYf0HBjkX+DQ6VarqrJ0nSc TpOow6DkcG3QdT9NX7cnS7I7s6TJ0ODg4OnScTpMODDByuo1dJ0nQ6HQ6TpY cZMnSZOU6cPf9P7n6XKqru5/cO+kq/mf0CryFXeE+L/l4+VUJMXo0CO4RmFC A7AQkakIN2RlvXHxwmf247fXtXOV7VbxpV2SHUEfpl5kleYlX9rqhv5Q7F9g q9lTvB2TqiroO9fifoJV/XAL53f3/BJH4kI+Oqqe1W/KkORX2CHOkq/1fUCd n+f8tkX6h6h7/uivt0e1JIVyhJoLN46wbJx5E0VsH+trmuqrte2dsFl0rq5h EzcKbMEDE6kIHwBCRtEUCZqIknoSr79nClfDUf9h7uv6ofi+mSFE8MSU3ghM RzQ+IB/f+r/HxP+XnMNbnlOKD8u93fIeB9qrh+++vnzzlEjlrpEjs6VfZrBG u65IUYe25+HFF7v2iVnZx885uue910OEdoBzytH0jvXWr1/0fft07BHy/fkE qL3a8/NSNJXf+Tad8qi7eh10/L5PwHnx9+c53kffpdfhJV2oq95I41WiQ1EM rg4/Ya7ZSHKH+fxx6clOSOXj+5Rf5ff2J7E9L2r8fd7/PXVLEi70hrWQjKnA U+q8f93xd0efT0r6HSXiv4s8aj5unX8A/MnS96JGsEcvo/ns9+MZWKR8O3L8 7/SP7E5V/k9Iq/rGidoai/uNJ/QyqtSV0/k9/rfl7O5H+gjD5GKPzkjuUj89 kRGkX6O3erxcQn+SMPdPTVyFX2q/VVP3qfslaFR2UPPvzqvrazQqOcnsEWiS wTqAQsPQEwkLa4BMSTDVzxSWOunUel8a5Kh7sSH1oqsvjIHAqmiq6iuqdu3L 2/gdw/Uu3Q+/BK1SM99oFUXCZQSvsQi6+v9Dym4O1wcLPlhWYVw/FpX6ZIYV VZKot+Kofl/DOL57ylT2ZSlPPKgXhCrzPvT3iVZ/revbuc/Z+1fYEPwzRrWu stEIwrxFES7OYf7sdvbVV/tZ3ZfaAdu90c3/l6dv8e4Bde/lqpXXHd49uhS7 SX5NP7P87p9s/LxIBmKYgKlwSYaqFRkpVIC5sEgBZcf/D/L/rzz6PmyStq/q 32PJD18/g75iSXrQaUCErhgo1vPrunn89xiMSXBqx5RU1rE9cQq6TqHZ2oVc KaaAE0CEldoBBp2CEJMPTkkq/2uoVcRviR/7rvKlOj70X3BHdgU9pVD3r6Ux 0Sn5+O4wT8uuQ+//I4f3el8e7tmnjfel+RH2frOm+n9VO34P2e2DzheeuAjh IwekIXTEqK+M2WnHTl5S2r4KsWqrmqHwUjw1XnzCd/d7W+Mz/L/j2zjnT7Op OJ/7OJd/wkcKR8apDuU/iqN71UhTqp0lz9ph1/ma3H8cFdQqwA6RV2Uqu/lq l+bRK7HrnVzddXaLdUKRNqVV0oOQ4Af33jzo98/8e/t9x4iV/PjtQrI63r9Y lXv3guzvo+RK8G5zc6r9lB3I+PfRK/d+NzzyzxrBFpceOKsWmXfBRmBVK/C9 It1ygqq0VYqG/7JMVDb9P5OPZFXdLh/B789/iAZRSk8befzz15REcWtfZ7oL 6+mrhccnrlNfYd7wVa/H6FbcfARp7iRxCMQjWqGBH69u+euTv/r3hHytitB7 WVcqD9X7Kp+YbqUxM4eefh/oE8Aj71fgB3Xcp/2/tdTJ6JyiruodKD+HXx8d 17ZznL2/nzvnvv4IsS0we6bv32vxhGfzdvfJDvhGS42OuW+trOgxKuBwdPTg da7R5akrMaSbG/epK3uChTrtjno70apnU/D2A8Qq0Sr/w31lSr9Nlb9smb6C c3XOCkN8oho/c3n27XXPAb27ePOqSthSu3HZ2QHfvdnUjxUuq9mBV4797sFW lSn8Z/0+PGddc+3eKT4/rRwFNUUvtJpBfLhXmE2lItMhSmMJ8MVDpXy6SQ+e aX67SiGm2XX0RGZynKv4dvS4ZKHWsFVv2teHkCOUf6siuV4vjce2q6g0anjv /lfMFmMX9+NVriH3Z0woeVIfkFV6aQ7eeXmG21v29L8bipGVa9s2mIjS6Rar K6kh6G2Es6wZOtRiCEjCsa8Ym4cuy5fanLNrMxjiH9jNK1cwkOIxxJbEHJw1 YvWCIEuVSuyXLj65+cl6OyUrvB4jiEZfiMKtktkyq0JaShoMJGRZJsEaVWeO 6W6EWIVdChkF3pRrUhlddaQ2apOec4gyQNlB7XbLlVztg7+oBvH8ulFKTr4q lfu9qLz3+aDsqntxQZx25vZVPNR8P+CRSk9V7eJGkf8OdMf83m/D0jQ/p8eA /ImV+1xvh9ftn65e0h9Uc8qLoZJXsRSk9vHXXVxnxolc2mmxtr/iMqcRVoB9 KSuc9MuPX11HzUu8KvkwsH/l1V2R/H48+CtK6QR5BnUys1y+lCq4ZSjPluq0 u90nHLLK6kR3T6aEjjTisQnunPn8a5HZRfn1/NdvQzqR3laV0eMcvtdT59t2 +c0rS9qRD6K2zhbfj3KVtBQp8f5HnZ7u3Z+H1EruurfkXt8evJVXubnOZq4k rjonQVc5DbapbeIud6znlHdPwLu4WaUW+JlXVEOwNYVs6JL+KxPO0LNKrCIE qv7NAhqVZJ/ixFF+AR1qoaG9v2dn/T9e19Qlb8rDw6c93ISquFDEItLtVui9 V6pDtsVrCrWGUm+U/jZGWLj5lHBCNVmOvMjnUPXbq5X+r56/YSnvzxL/N7j5 B7xEadKta1qtd9b50J6/b/M450Uh6vGMcnl6dMnRTeO2q9+dl17fi8cKXfQb Sp17Ot7cceNJPZ/f0nVRfwZ61R4h4tAHzHPNO3fLn1Su0Ee9hPyylXkKN/b4 H9u/P6n8evj37fiad5xSzTygIInfwB0xy7uc3gkYAgcQN7SfuTpWHvR5pK70 PYZdBV1SV1DofiPBKdcdnf/Ul5Pbe3pgR7ZJXqHpF9lSuykrjwkOgjnaVxGR VXRV2JLweaNvL+Diir36+tFf9Gdk0AeJ4hrVYk5dK8e1b0IuxVYId+AlcSq6 I4HjUlXLdfbDfXN6Z1VrcpKi3SorXp8vXLUuIR64H1T9qX4Kfb5+Fy/D/j39 YA9gD6/GS8T48w14vYjRh21Pw9338ubw/Zc/Dt3J91k9pGd4vj+z4+T437Tn 7Hlfs6Tla7b9kmsXYTxVVXwkjCRor58zS46aQR5ePLh9ls0xO/cq6Lf13vPr QT6+K8unuP9apd6Cf3/1r/T9/v593x+aYd9dJpdpPNVeE+Moe8kayaRFehPK PP+jHjlx+zZJX363ahn6O/2/3/qpSv1D8ffz1UeL9P4YuKer8l4Hl90tV02F lxePlLSxLnLU35bJrittZzCrj1KSuSpT2o67cnt1HeRfVeu6VVaVlagMEMkI vbofrb/BVEXfIhDakKm1Ior9k9y7fUKu0hE+cgTBoF+z/SErzQqV8Cd6iU8O IX6sXDEi+Hqut78rv7WnPhBfKzfZv19wkCA9EHxlVnXUg4kl85gBo1MI/+Lu SKcKEg2tvxFg --------------000309030707080508020601-- From owner-linux-xfs@oss.sgi.com Tue Apr 11 01:42:03 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 Apr 2006 01:42:06 -0700 (PDT) Received: from elfstone.noviforum.si (elfstone.noviforum.si [193.189.169.107]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k3B8g2gC025596 for ; Tue, 11 Apr 2006 01:42:03 -0700 Received: from localhost (localhost [127.0.0.1]) by elfstone.noviforum.si (ESMTP) with ESMTP id AC1D11B91B for ; Tue, 11 Apr 2006 10:37:15 +0200 (CEST) Received: from dacun.noviforum.si (dacun.noviforum.si [192.168.2.26]) by elfstone.noviforum.si (ESMTP) with ESMTP id 7D2781B914 for ; Tue, 11 Apr 2006 10:37:15 +0200 (CEST) Subject: Error 990 From: Gorazd Golob To: linux-xfs@oss.sgi.com Content-Type: text/plain Date: Tue, 11 Apr 2006 10:41:55 +0200 Message-Id: <1144744915.10995.14.camel@dacun.noviforum.si> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 Content-Transfer-Encoding: 7bit X-archive-position: 7613 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: gorazd.golob@noviforum.si Precedence: bulk X-list: linux-xfs Status: O Content-Length: 342 Lines: 15 Hi! When I want to unlink symbolic link /export/software/mysql I got this message: rm: cannot remove `/export/software/mysql': Unknown error 990 If I try to list that symbolic link it not shown with ls - but I know that it was there before ;) (before reboot). What can be wrong - filesystem is XFS on 2.6.15.6 - x86_64. Thanks, Gorazd From owner-linux-xfs@oss.sgi.com Tue Apr 11 02:11:59 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 Apr 2006 02:12:09 -0700 (PDT) Received: from smtp103.sbc.mail.mud.yahoo.com (smtp103.sbc.mail.mud.yahoo.com [68.142.198.202]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k3B9BwgC027396 for ; Tue, 11 Apr 2006 02:11:59 -0700 Received: (qmail 24561 invoked from network); 11 Apr 2006 09:11:58 -0000 Received: from unknown (HELO stupidest.org) (cwedgwood@sbcglobal.net@70.231.236.95 with login) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 11 Apr 2006 09:11:58 -0000 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id E8E6A51FAC0; Tue, 11 Apr 2006 02:11:57 -0700 (PDT) Date: Tue, 11 Apr 2006 02:11:57 -0700 From: Chris Wedgwood To: Gorazd Golob Cc: linux-xfs@oss.sgi.com Subject: Re: Error 990 Message-ID: <20060411091157.GB4359@taniwha.stupidest.org> References: <1144744915.10995.14.camel@dacun.noviforum.si> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1144744915.10995.14.camel@dacun.noviforum.si> X-archive-position: 7614 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Status: O Content-Length: 237 Lines: 9 On Tue, Apr 11, 2006 at 10:41:55AM +0200, Gorazd Golob wrote: > What can be wrong - filesystem is XFS on 2.6.15.6 - x86_64. 990 is EFSCORRUPTED (nothing outside of XFS uses that error code hence the abiguity at times) try xfs_repair From owner-linux-xfs@oss.sgi.com Tue Apr 11 02:42:45 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 Apr 2006 02:42:46 -0700 (PDT) Received: from elfstone.noviforum.si (elfstone.noviforum.si [193.189.169.107]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k3B9gigC029579 for ; Tue, 11 Apr 2006 02:42:44 -0700 Received: from localhost (localhost [127.0.0.1]) by elfstone.noviforum.si (ESMTP) with ESMTP id 406181B917; Tue, 11 Apr 2006 11:38:05 +0200 (CEST) Received: from dacun.noviforum.si (dacun.noviforum.si [192.168.2.26]) by elfstone.noviforum.si (ESMTP) with ESMTP id 0DB541B914; Tue, 11 Apr 2006 11:38:04 +0200 (CEST) Subject: Re: Error 990 From: Gorazd Golob To: Chris Wedgwood Cc: linux-xfs@oss.sgi.com In-Reply-To: <20060411091157.GB4359@taniwha.stupidest.org> References: <1144744915.10995.14.camel@dacun.noviforum.si> <20060411091157.GB4359@taniwha.stupidest.org> Content-Type: text/plain Date: Tue, 11 Apr 2006 11:42:44 +0200 Message-Id: <1144748564.10995.16.camel@dacun.noviforum.si> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 Content-Transfer-Encoding: 7bit X-archive-position: 7615 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: gorazd.golob@noviforum.si Precedence: bulk X-list: linux-xfs Status: O Content-Length: 377 Lines: 15 On Tue, 2006-04-11 at 02:11 -0700, Chris Wedgwood wrote: > On Tue, Apr 11, 2006 at 10:41:55AM +0200, Gorazd Golob wrote: > > > What can be wrong - filesystem is XFS on 2.6.15.6 - x86_64. > > 990 is EFSCORRUPTED (nothing outside of XFS uses that error code hence > the abiguity at times) > > try xfs_repair > xfs_repair filled some of files with NULLs. Very uncool ;) > From owner-linux-xfs@oss.sgi.com Tue Apr 11 04:05:56 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 Apr 2006 04:05:57 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k3BB5sgC002445 for ; Tue, 11 Apr 2006 04:05:55 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA07640; Tue, 11 Apr 2006 21:05:44 +1000 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k3BB5wPR4065185; Tue, 11 Apr 2006 21:05:59 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k3BB5tAO4114088; Tue, 11 Apr 2006 21:05:55 +1000 (AEST) Date: Tue, 11 Apr 2006 21:05:55 +1000 From: David Chinner To: Gorazd Golob Cc: linux-xfs@oss.sgi.com Subject: Re: Error 990 Message-ID: <20060411110554.GG1484909@melbourne.sgi.com> References: <1144744915.10995.14.camel@dacun.noviforum.si> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1144744915.10995.14.camel@dacun.noviforum.si> User-Agent: Mutt/1.4.2.1i X-archive-position: 7616 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: linux-xfs Status: O Content-Length: 427 Lines: 19 On Tue, Apr 11, 2006 at 10:41:55AM +0200, Gorazd Golob wrote: > Hi! > > When I want to unlink symbolic link /export/software/mysql I got this > message: > > rm: cannot remove `/export/software/mysql': Unknown error 990 Are there any errors indicating I/O errors or a filesystem shutdown in your syslog? If there were, can you post them? Cheers, Dave. -- Dave Chinner R&D Software Enginner SGI Australian Software Group From owner-linux-xfs@oss.sgi.com Tue Apr 11 04:26:34 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 Apr 2006 04:27:29 -0700 (PDT) Received: from elfstone.noviforum.si (elfstone.noviforum.si [193.189.169.107]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k3BBQXgC008809 for ; Tue, 11 Apr 2006 04:26:34 -0700 Received: from localhost (localhost [127.0.0.1]) by elfstone.noviforum.si (ESMTP) with ESMTP id 4E5681B91B; Tue, 11 Apr 2006 13:21:49 +0200 (CEST) Received: from dacun.noviforum.si (dacun.noviforum.si [192.168.2.26]) by elfstone.noviforum.si (ESMTP) with ESMTP id 13E9E1B914; Tue, 11 Apr 2006 13:21:49 +0200 (CEST) Subject: Re: Error 990 From: Gorazd Golob To: David Chinner Cc: linux-xfs@oss.sgi.com In-Reply-To: <20060411110554.GG1484909@melbourne.sgi.com> References: <1144744915.10995.14.camel@dacun.noviforum.si> <20060411110554.GG1484909@melbourne.sgi.com> Content-Type: text/plain Date: Tue, 11 Apr 2006 13:26:29 +0200 Message-Id: <1144754789.10995.26.camel@dacun.noviforum.si> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 Content-Transfer-Encoding: 7bit X-archive-position: 7617 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: gorazd.golob@noviforum.si Precedence: bulk X-list: linux-xfs Status: O Content-Length: 559 Lines: 20 On Tue, 2006-04-11 at 21:05 +1000, David Chinner wrote: > On Tue, Apr 11, 2006 at 10:41:55AM +0200, Gorazd Golob wrote: > > Hi! > > > > When I want to unlink symbolic link /export/software/mysql I got this > > message: > > > > rm: cannot remove `/export/software/mysql': Unknown error 990 > > Are there any errors indicating I/O errors or a filesystem shutdown > in your syslog? If there were, can you post them? > No - no io errors. Can be something wrong with storage subsystem? - We have write back enabled on raid controler.. > Cheers, > > Dave. From owner-linux-xfs@oss.sgi.com Tue Apr 11 04:31:13 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 Apr 2006 04:31:15 -0700 (PDT) Received: from lucidpixels.com (lucidpixels.com [66.45.37.187]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k3BBVDgC009402 for ; Tue, 11 Apr 2006 04:31:13 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id DA072163801; Tue, 11 Apr 2006 07:31:12 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id D7FAE100EC460; Tue, 11 Apr 2006 07:31:12 -0400 (EDT) Date: Tue, 11 Apr 2006 07:31:12 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34 To: Gorazd Golob cc: Chris Wedgwood , linux-xfs@oss.sgi.com Subject: Re: Error 990 In-Reply-To: <1144748564.10995.16.camel@dacun.noviforum.si> Message-ID: References: <1144744915.10995.14.camel@dacun.noviforum.si> <20060411091157.GB4359@taniwha.stupidest.org> <1144748564.10995.16.camel@dacun.noviforum.si> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 7618 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: linux-xfs Status: O Content-Length: 561 Lines: 22 There is an option when you make the filesystem so it does not fill it with NULL's when it fsck's the filesystem I believe... On Tue, 11 Apr 2006, Gorazd Golob wrote: > On Tue, 2006-04-11 at 02:11 -0700, Chris Wedgwood wrote: >> On Tue, Apr 11, 2006 at 10:41:55AM +0200, Gorazd Golob wrote: >> >>> What can be wrong - filesystem is XFS on 2.6.15.6 - x86_64. >> >> 990 is EFSCORRUPTED (nothing outside of XFS uses that error code hence >> the abiguity at times) >> >> try xfs_repair >> > xfs_repair filled some of files with NULLs. Very uncool ;) >> > > > > From owner-linux-xfs@oss.sgi.com Tue Apr 11 08:14:30 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 Apr 2006 08:14:38 -0700 (PDT) Received: from smtp106.sbc.mail.mud.yahoo.com (smtp106.sbc.mail.mud.yahoo.com [68.142.198.205]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k3BFEUgC027105 for ; Tue, 11 Apr 2006 08:14:30 -0700 Received: (qmail 52018 invoked from network); 11 Apr 2006 15:14:31 -0000 Received: from unknown (HELO stupidest.org) (cwedgwood@sbcglobal.net@70.231.236.95 with login) by smtp106.sbc.mail.mud.yahoo.com with SMTP; 11 Apr 2006 15:14:31 -0000 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id 7707251FAC0; Tue, 11 Apr 2006 08:14:28 -0700 (PDT) Date: Tue, 11 Apr 2006 08:14:28 -0700 From: Chris Wedgwood To: Gorazd Golob Cc: linux-xfs@oss.sgi.com Subject: Re: Error 990 Message-ID: <20060411151428.GA11582@taniwha.stupidest.org> References: <1144744915.10995.14.camel@dacun.noviforum.si> <20060411091157.GB4359@taniwha.stupidest.org> <1144748564.10995.16.camel@dacun.noviforum.si> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1144748564.10995.16.camel@dacun.noviforum.si> X-archive-position: 7619 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Status: O Content-Length: 233 Lines: 9 On Tue, Apr 11, 2006 at 11:42:44AM +0200, Gorazd Golob wrote: > xfs_repair filled some of files with NULLs. Very uncool ;) unlikely you probably had unwritten data and what you are seeing are unwritten extents when when you read From owner-linux-xfs@oss.sgi.com Tue Apr 11 15:47:07 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 Apr 2006 15:47:18 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k3BMl5gC009578 for ; Tue, 11 Apr 2006 15:47:06 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA17171; Wed, 12 Apr 2006 08:46:59 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k3BMksJC1306695; Wed, 12 Apr 2006 08:46:54 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k3BMklc71307834; Wed, 12 Apr 2006 08:46:47 +1000 (EST) Date: Wed, 12 Apr 2006 08:46:47 +1000 From: Nathan Scott To: Justin Piszcz Cc: Gorazd Golob , Chris Wedgwood , linux-xfs@oss.sgi.com Subject: Re: Error 990 Message-ID: <20060412084647.D1288190@wobbly.melbourne.sgi.com> References: <1144744915.10995.14.camel@dacun.noviforum.si> <20060411091157.GB4359@taniwha.stupidest.org> <1144748564.10995.16.camel@dacun.noviforum.si> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jpiszcz@lucidpixels.com on Tue, Apr 11, 2006 at 07:31:12AM -0400 X-archive-position: 7621 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Status: O Content-Length: 867 Lines: 29 On Tue, Apr 11, 2006 at 07:31:12AM -0400, Justin Piszcz wrote: > There is an option when you make the filesystem so it does not fill it > with NULL's when it fsck's the filesystem I believe... Theres so many errors in that statement I don't even know where to start correcting it! > > On Tue, 2006-04-11 at 02:11 -0700, Chris Wedgwood wrote: > >> On Tue, Apr 11, 2006 at 10:41:55AM +0200, Gorazd Golob wrote: > >> > >>> What can be wrong - filesystem is XFS on 2.6.15.6 - x86_64. > >> > >> 990 is EFSCORRUPTED (nothing outside of XFS uses that error code hence > >> the abiguity at times) > >> > >> try xfs_repair > >> > > xfs_repair filled some of files with NULLs. Very uncool ;) Thats not correct either. Pretty sure theres a FAQ entry on the notorious "NULL files" issue. It has nothing to do with xfs_repair or unwritten extents FWIW. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Apr 11 16:20:05 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 Apr 2006 16:20:10 -0700 (PDT) Received: from lucidpixels.com (lucidpixels.com [66.45.37.187]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k3BNK4gC017443 for ; Tue, 11 Apr 2006 16:20:04 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id AEFC6163801; Tue, 11 Apr 2006 19:20:05 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id ACE4F100EC460; Tue, 11 Apr 2006 19:20:05 -0400 (EDT) Date: Tue, 11 Apr 2006 19:20:05 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34 To: Nathan Scott cc: Gorazd Golob , Chris Wedgwood , linux-xfs@oss.sgi.com Subject: Re: Error 990 In-Reply-To: <20060412084647.D1288190@wobbly.melbourne.sgi.com> Message-ID: References: <1144744915.10995.14.camel@dacun.noviforum.si> <20060411091157.GB4359@taniwha.stupidest.org> <1144748564.10995.16.camel@dacun.noviforum.si> <20060412084647.D1288190@wobbly.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 7622 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: linux-xfs Status: O Content-Length: 1076 Lines: 37 > Theres so many errors in that statement I don't even know where > to start correcting it! Must have been thinking of something else... On Wed, 12 Apr 2006, Nathan Scott wrote: > On Tue, Apr 11, 2006 at 07:31:12AM -0400, Justin Piszcz wrote: >> There is an option when you make the filesystem so it does not fill it >> with NULL's when it fsck's the filesystem I believe... > > Theres so many errors in that statement I don't even know where > to start correcting it! > >>> On Tue, 2006-04-11 at 02:11 -0700, Chris Wedgwood wrote: >>>> On Tue, Apr 11, 2006 at 10:41:55AM +0200, Gorazd Golob wrote: >>>> >>>>> What can be wrong - filesystem is XFS on 2.6.15.6 - x86_64. >>>> >>>> 990 is EFSCORRUPTED (nothing outside of XFS uses that error code hence >>>> the abiguity at times) >>>> >>>> try xfs_repair >>>> >>> xfs_repair filled some of files with NULLs. Very uncool ;) > > Thats not correct either. > > Pretty sure theres a FAQ entry on the notorious "NULL files" issue. > It has nothing to do with xfs_repair or unwritten extents FWIW. > > cheers. > > -- > Nathan > > From owner-linux-xfs@oss.sgi.com Tue Apr 11 19:04:37 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 11 Apr 2006 19:04:43 -0700 (PDT) Received: from larry.melbourne.sgi.com ([61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k3C24ZgC002502 for ; Tue, 11 Apr 2006 19:04:37 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA19989; Wed, 12 Apr 2006 12:04:18 +1000 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k3C24UPR4740184; Wed, 12 Apr 2006 12:04:30 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k3C24Rpp4741545; Wed, 12 Apr 2006 12:04:27 +1000 (AEST) Date: Wed, 12 Apr 2006 12:04:27 +1000 From: David Chinner To: Artur =?iso-8859-1?Q?Mak=F3wka?= Cc: linux-xfs@oss.sgi.com Subject: Re: server crashing Message-ID: <20060412020427.GI1484909@melbourne.sgi.com> References: <443627B1.5090100@ursynow.2a.pl> <20060410015916.GK2732@melbourne.sgi.com> <443B60E8.6070004@ursynow.2a.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <443B60E8.6070004@ursynow.2a.pl> User-Agent: Mutt/1.4.2.1i X-archive-position: 7623 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: linux-xfs Status: O Content-Length: 2085 Lines: 49 On Tue, Apr 11, 2006 at 09:55:20AM +0200, Artur Makówka wrote: > >If there are no I/O errors being reported before the filesystem shuts down, > >can you provide more information of the type of I/O the system is executing > >when the shutdown occurs? > > I see many similar output to one i already posted, but it happened just > AFTER first sucessful mount. the one output i'm pasting right now is ( i > think) from just BEFORE crash. Also, there is nothing particular the > server is doing durning that time. Durning the time of last 2 crashes it > was refreshing awstats for every account in the system, so doing > awstats.pl on the list of accounts. But it 'crashed' many times also > durning the day - when awstats was not running. From the 'after' logs > i dont see why this shows: "Apr 11 09:47:53 alpha324 kernel: XFS > internal error XFS_WANT_CORRUPTED_RETURN at line 298 of file > fs/xfs/xfs_alloc.c. Caller 0xc01f5091" > > what does it mean, from the line numbers in error report, it looks like we don't have a single contigous extent large enough in the AG we are allocating from, so we search the by-size between to find the closest fit possible. We searched the last leaf node of the by-size btree, found an extent and allocated it. We've then called xfs_alloc_fixup_trees() to update the by-block btree, but we've failed to find a match of the extent we just allocated from the by-size btree in the by-block btree. IOWs, the error indicates the AGF free space btrees are inconsistent or one of them is corrupted. > and why xfs_repair didnt repaired it ? xfs_repair doesn't check the free space btrees, it simply rebuilds them from scratch. Hence it won't warn about a corrupted AGF btree during repair. However, after a repair they should be consistent. OTOH, xfs_check will actually check the AGF btrees for corruption and consistency. Can you run xfs_check on the filesystem after one of these errors both before and after you run xfs_repair, and post the output? Cheers, Dave. -- Dave Chinner R&D Software Enginner SGI Australian Software Group From owner-linux-xfs@oss.sgi.com Wed Apr 12 15:27:07 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 Apr 2006 15:27:08 -0700 (PDT) Received: from virasto.com (virasto.com [212.213.212.50]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k3CMR6gC003209 for ; Wed, 12 Apr 2006 15:27:06 -0700 Received: by virasto.com (Postfix, from userid 1000) id 787E17514; Wed, 12 Apr 2006 23:37:19 +0300 (EEST) Date: Wed, 12 Apr 2006 23:37:19 +0300 From: Onis To: linux-xfs@oss.sgi.com Subject: Remounting read-only forces filesystem shutdown Message-ID: <20060412203719.GA22528@virasto.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-archive-position: 7624 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: onion@virasto.com Precedence: bulk X-list: linux-xfs Status: O Content-Length: 1649 Lines: 47 Hi! When remounting XFS filesystem read-only it causes xfs_force_shutdown and filesystem is unreadable. After umount/mount it is back again. I have 2 partitions with xfs. Both of them are affected. Problem does not occur when using Debian's stock kernel. xfs_check does not report any error. This impacts Debian shutdown script, so that system cannot shutdown properly. Shutdown process just hangs until reset button pressed. To repeat it, just do "mount -o remount,ro /mnt". System ------ * Debian Sarge AMD64 * gcc version 3.4.4 20050314 (prerelease) (Debian 3.4.3-13) * Tyan 2882 Dual Opteron 240 * 8 x Maxtor Maxline 300GB SATA * 1 x Maxtor 40GB PATA Tested kernel versions: * 2.6.17-rc1 * 2.6.17-rc1-mm2 * 2.6.17-rc1-git5 dmesg ----- I/O error in filesystem ("md0") meta-data dev md0 block 0x7a483000 ("xlog_iodone") error 5 buf count 131072 xfs_force_shutdown(md0,0x2) called from line 959 of file fs/xfs/xfs_log.c. Return address = 0xffffffff80317568 Filesystem "md0": Log I/O Error Detected. Shutting down filesystem: md0 Please umount the filesystem, and rectify the problem(s) xfs_info -------- meta-data=/mnt isize=256 agcount=32, agsize=16026176 blks = sectsz=512 data = bsize=4096 blocks=512836800, imaxpct=25 = sunit=32 swidth=224 blks, unwritten=1 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=32768, version=2 = sectsz=512 sunit=32 blks realtime =none extsz=917504 blocks=0, rtextents=0 - Onion From owner-linux-xfs@oss.sgi.com Wed Apr 12 17:00:07 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 Apr 2006 17:00:11 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k3D006gC014384 for ; Wed, 12 Apr 2006 17:00:07 -0700 Received: (qmail invoked by alias); 12 Apr 2006 23:00:06 -0000 Received: from p549D43CE.dip0.t-ipconnect.de (EHLO www2.afoctuelia.de) [84.157.67.206] by mail.gmx.net (mp038) with SMTP; 13 Apr 2006 01:00:06 +0200 X-Authenticated: #259646 From: "Andreas G. Filzer" To: linux-xfs@oss.sgi.com Subject: Bug-Report xfs_inode.c Date: Thu, 13 Apr 2006 00:59:47 +0200 User-Agent: KMail/1.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200604130059.54582.filzer@gmx.de> X-Y-GMX-Trusted: 0 X-archive-position: 7625 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: filzer@gmx.de Precedence: bulk X-list: linux-xfs Status: O Content-Length: 6729 Lines: 192 Hello, my english is not very well, but I get a nice Bug Message and so I send you this info. It's Ok ;-) Maybe you need some Infos more, but I don't find on your Website tips for me how you want to have a bug-report. Best regards Andreas Filzer Some Infos: 1. My Box is gentoo-linux - current status 2. Versions sys-fs/xfsprogs-2.7.11; 2.7.3; 2.6.36 3. vanilla-kernel-2.6.16.1 4. gcc-3.4.6; Pentium 4 5. I've a corrupt file on the fs hugo.html Date 11.11.1935 Size 12 568 817,4 TB 6. HD WDC WD1200BB-00CAA1 7. Filesystem 1K-blocks Used Available Use% Mounted on /dev/hdb1 48804640 20241268 28563372 42% ########################################################## ### shell ### command: xfs_repair /dev/hdb1 ########################################################## Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... zero_log: head block 2 tail block 2 - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 correcting nblocks for inode 103503311, was 0 - counted 1 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - clear lost+found (if it exists) ... - clearing existing "lost+found" inode - marking entry "lost+found" to be deleted - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 data fork in regular inode 103503311 claims used block 8102976 correcting nblocks for inode 103503311, was 1 - counted 0 - agno = 7 - agno = 8 - 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 - ensuring existence of lost+found directory - traversing filesystem starting at / ... rebuilding directory inode 128 - traversal finished ... - traversing all unattached subtrees ... - traversals finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... corrupt dinode 103503311, extent total = 1, nblocks = 0. This is a bug. Please report it to linux-xfs@oss.sgi.com. ########################################################### # dmesg ########################################################### [17190227.836000] Filesystem "hdb1": corrupt dinode 103503311, extent total = 1, nblocks = 0. Unmount and run xfs_repair. [17190227.836000] 0x0: 49 4e 81 ff 01 02 00 01 00 00 00 00 00 00 00 00 [17190227.836000] Filesystem "hdb1": XFS internal error xfs_iformat(1) at line 415 of file fs/xfs/xfs_inode.c. Caller 0xc02b4d40 [17190227.836000] [] xfs_iformat+0x17b/0x64a [17190227.836000] [] xfs_iread+0x1ad/0x200 [17190227.836000] [] xfs_iread+0x1ad/0x200 [17190227.836000] [] xfs_iread+0x1ad/0x200 [17190227.836000] [] xfs_iget_core+0xa7/0x503 [17190227.836000] [] iget_locked+0x7a/0x7c [17190227.836000] [] xfs_iget+0xd1/0x137 [17190227.836000] [] xfs_dir_lookup_int+0xbc/0x144 [17190227.836000] [] xfs_lookup+0x5d/0x92 [17190227.836000] [] linvfs_lookup+0x52/0x99 [17190227.836000] [] real_lookup+0xc3/0xf2 [17190227.836000] [] do_lookup+0x9d/0xa8 [17190227.836000] [] __link_path_walk+0x778/0xcf3 [17190227.836000] [] mntput_no_expire+0x22/0x85 [17190227.836000] [] link_path_walk+0x57/0xeb [17190227.836000] [] strncpy_from_user+0x3c/0x68 [17190227.836000] [] do_path_lookup+0xf3/0x250 [17190227.836000] [] __user_walk_fd+0x3c/0x5c [17190227.836000] [] vfs_lstat_fd+0x21/0x69 [17190227.836000] [] vfs_lstat+0x1f/0x23 [17190227.836000] [] sys_lstat64+0x18/0x36 [17190227.836000] [] syscall_call+0x7/0xb ############################################################## xfs_logprint: data device: 0x341 log device: 0x341 daddr: 48828512 length: 47680 cycle: 1 version: 1 lsn: 1,0 tail_lsn: 1,0 length of Log Record: 20 prev offset: -1 num ops: 1 uuid: f14d3060-17fc-4338-8612-4c742522eb91 format: little endian linux h_size: 32768 ---------------------------------------------------------------------------- Oper (0): tid: b0c0d0d0 len: 8 clientid: LOG flags: UNMOUNT Unmount filesystem ============================================================================ xfs_logprint: skipped 47678 zeroed blocks in range: 2 - 47679 xfs_logprint: physical end of log ============================================================================ xfs_logprint: logical end of log ============================================================================ ##################################################################### /usr/bin/xfs_db -r -c 'inode 103503311' -c print /dev/hdb1 core.magic = 0x494e core.mode = 0100777 core.version = 1 core.format = 2 (extents) core.nlinkv1 = 1 core.uid = 0 core.gid = 0 core.flushiter = 3 core.atime.sec = Mon Nov 22 01:30:00 2004 core.atime.nsec = 000000000 core.mtime.sec = Tue Nov 5 07:25:12 2002 core.mtime.nsec = 000000000 core.ctime.sec = Mon Nov 22 01:53:12 2004 core.ctime.nsec = 683756664 core.size = 2812 core.nblocks = 0 core.extsize = 0 core.nextents = 1 core.naextents = 0 core.forkoff = 0 core.aformat = 2 (extents) core.dmevmask = 0 core.dmstate = 0 core.newrtbm = 0 core.prealloc = 0 core.realtime = 0 core.immutable = 0 core.append = 0 core.sync = 0 core.noatime = 0 core.nodump = 0 core.rtinherit = 0 core.projinherit = 0 core.nosymlinks = 0 core.extsz = 0 core.extszinherit = 0 core.gen = 0 next_unlinked = null u.bmx[0] = [startoff,startblock,blockcount,extentflag] 0:[0,8102976,1,0] ############################################################ xfs_check /dev/hdb1 bad nblocks 0 for inode 103503311, counted 1 block 9/762944 type unknown not expected ############################################################ From owner-linux-xfs@oss.sgi.com Wed Apr 12 17:08:50 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 Apr 2006 17:08:51 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k3D08ngC015145 for ; Wed, 12 Apr 2006 17:08:50 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA06216; Thu, 13 Apr 2006 10:08:44 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k3D08gJC1336907; Thu, 13 Apr 2006 10:08:42 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k3D08eb31337031; Thu, 13 Apr 2006 10:08:40 +1000 (EST) Date: Thu, 13 Apr 2006 10:08:39 +1000 From: Nathan Scott To: Onis Cc: linux-xfs@oss.sgi.com Subject: Re: Remounting read-only forces filesystem shutdown Message-ID: <20060413100839.C1334248@wobbly.melbourne.sgi.com> References: <20060412203719.GA22528@virasto.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20060412203719.GA22528@virasto.com>; from onion@virasto.com on Wed, Apr 12, 2006 at 11:37:19PM +0300 X-archive-position: 7626 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Status: O Content-Length: 926 Lines: 28 On Wed, Apr 12, 2006 at 11:37:19PM, Onis wrote: > Hi! Hi there Onion, > When remounting XFS filesystem read-only it causes xfs_force_shutdown and > filesystem is unreadable. After umount/mount it is back again. I have > 2 partitions with xfs. Both of them are affected. Problem does not occur > when using Debian's stock kernel. xfs_check does not report any error. > > This impacts Debian shutdown script, so that system cannot shutdown > properly. Shutdown process just hangs until reset button pressed. > > To repeat it, just do "mount -o remount,ro /mnt". Ah, I think I see the problem - looks like we can enable write barriers accidentally during a remount,ro without checking to see if the drive likes that idea. Ugh. Just to be sure - when you initially mounted the filesystem (rw), did you get a dmesg message saying "disabling write barriers" or words to that effect? thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Apr 12 19:09:41 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 Apr 2006 19:09:42 -0700 (PDT) Received: from MAIL01HQ.adic.com (mail01hq.adic.com [63.81.117.10]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k3D29egC025387 for ; Wed, 12 Apr 2006 19:09:41 -0700 Received: from MAIL12HQ.adic.com ([172.16.9.216]) by MAIL01HQ.adic.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Apr 2006 19:09:33 -0700 Received: from [127.0.0.1] ([172.16.82.13]) by MAIL12HQ.adic.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Apr 2006 19:09:32 -0700 Message-ID: <443DB2D9.7070706@xfs.org> Date: Wed, 12 Apr 2006 21:09:29 -0500 From: Steve Lord User-Agent: Thunderbird 1.5 (X11/20060313) MIME-Version: 1.0 To: Nathan Scott CC: Onis , linux-xfs@oss.sgi.com Subject: Re: Remounting read-only forces filesystem shutdown References: <20060412203719.GA22528@virasto.com> <20060413100839.C1334248@wobbly.melbourne.sgi.com> In-Reply-To: <20060413100839.C1334248@wobbly.melbourne.sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Apr 2006 02:09:32.0927 (UTC) FILETIME=[4E1248F0:01C65E9F] X-archive-position: 7627 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@xfs.org Precedence: bulk X-list: linux-xfs Status: O Content-Length: 1209 Lines: 36 Hi Nathan, I have seen this too, and it is definitely on a system which reports no barrier support in the devices. Shutdown ends up with exactly this error - running 2.6.17-rc1 from Linus's git tree as of a couple of days ago. Steve Nathan Scott wrote: > On Wed, Apr 12, 2006 at 11:37:19PM, Onis wrote: >> Hi! > > Hi there Onion, > >> When remounting XFS filesystem read-only it causes xfs_force_shutdown and >> filesystem is unreadable. After umount/mount it is back again. I have >> 2 partitions with xfs. Both of them are affected. Problem does not occur >> when using Debian's stock kernel. xfs_check does not report any error. >> >> This impacts Debian shutdown script, so that system cannot shutdown >> properly. Shutdown process just hangs until reset button pressed. >> >> To repeat it, just do "mount -o remount,ro /mnt". > > Ah, I think I see the problem - looks like we can enable write > barriers accidentally during a remount,ro without checking to > see if the drive likes that idea. Ugh. > > Just to be sure - when you initially mounted the filesystem (rw), did > you get a dmesg message saying "disabling write barriers" or words to > that effect? > > thanks. > From owner-linux-xfs@oss.sgi.com Wed Apr 12 19:21:59 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 Apr 2006 19:22:01 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k3D2LvgC026279 for ; Wed, 12 Apr 2006 19:21:58 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA07877; Thu, 13 Apr 2006 12:21:44 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k3D2LfJC1318555; Thu, 13 Apr 2006 12:21:42 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k3D2Lcra1339866; Thu, 13 Apr 2006 12:21:38 +1000 (EST) Date: Thu, 13 Apr 2006 12:21:38 +1000 From: Nathan Scott To: Steve Lord , Onis Cc: linux-xfs@oss.sgi.com Subject: Re: Remounting read-only forces filesystem shutdown Message-ID: <20060413122138.A1338954@wobbly.melbourne.sgi.com> References: <20060412203719.GA22528@virasto.com> <20060413100839.C1334248@wobbly.melbourne.sgi.com> <443DB2D9.7070706@xfs.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <443DB2D9.7070706@xfs.org>; from lord@xfs.org on Wed, Apr 12, 2006 at 09:09:29PM -0500 X-archive-position: 7628 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Status: O Content-Length: 2135 Lines: 75 On Wed, Apr 12, 2006 at 09:09:29PM -0500, Steve Lord wrote: > >> To repeat it, just do "mount -o remount,ro /mnt". > > > > Ah, I think I see the problem - looks like we can enable write > > barriers accidentally during a remount,ro without checking to > > see if the drive likes that idea. Ugh. > > > > Just to be sure - when you initially mounted the filesystem (rw), did > > you get a dmesg message saying "disabling write barriers" or words to > > that effect? > > I have seen this too, and it is definitely on a system which reports > no barrier support in the devices. Shutdown ends up with exactly > this error - running 2.6.17-rc1 from Linus's git tree as of a > couple of days ago. Hey Steve, Onion, This patch to fs/xfs/xfs_vfsops.c should fix that right up... I'll get it merged in asap. Looks like the only way to catch some problems is to switch things on by default. ;) cheers. -- Nathan Index: xfs-linux/xfs_vfsops.c =================================================================== --- xfs-linux.orig/xfs_vfsops.c +++ xfs-linux/xfs_vfsops.c @@ -681,32 +681,22 @@ xfs_mntupdate( xfs_mount_t *mp = XFS_BHVTOM(bdp); int error; - if (args->flags & XFSMNT_BARRIER) - mp->m_flags |= XFS_MOUNT_BARRIER; - else - mp->m_flags &= ~XFS_MOUNT_BARRIER; - - if ((vfsp->vfs_flag & VFS_RDONLY) && - !(*flags & MS_RDONLY)) { - vfsp->vfs_flag &= ~VFS_RDONLY; - - if (args->flags & XFSMNT_BARRIER) + if (!(*flags & MS_RDONLY)) { /* rw/ro -> rw */ + if (vfsp->vfs_flag & VFS_RDONLY) + vfsp->vfs_flag &= ~VFS_RDONLY; + if (args->flags & XFSMNT_BARRIER) { + mp->m_flags |= XFS_MOUNT_BARRIER; xfs_mountfs_check_barriers(mp); - } - - if (!(vfsp->vfs_flag & VFS_RDONLY) && - (*flags & MS_RDONLY)) { + } else { + mp->m_flags &= ~XFS_MOUNT_BARRIER; + } + } else if (!(vfsp->vfs_flag & VFS_RDONLY)) { /* rw -> ro */ VFS_SYNC(vfsp, SYNC_FSDATA|SYNC_BDFLUSH|SYNC_ATTR, NULL, error); - xfs_quiesce_fs(mp); - - /* Ok now write out an unmount record */ - xfs_log_sbcount(mp, 1); xfs_log_unmount_write(mp); xfs_unmountfs_writesb(mp); vfsp->vfs_flag |= VFS_RDONLY; } - return 0; } From owner-linux-xfs@oss.sgi.com Wed Apr 12 22:08:41 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 Apr 2006 22:08:50 -0700 (PDT) Received: from ash25e.internode.on.net ([203.16.214.182]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k3D58egC005841 for ; Wed, 12 Apr 2006 22:08:41 -0700 Received: from saturn.flamingspork.com (ppp163-199.static.internode.on.net [150.101.163.199]) by ash25e.internode.on.net (8.13.6/8.13.5) with ESMTP id k3D58HhE017685; Thu, 13 Apr 2006 14:38:17 +0930 (CST) (envelope-from stewart@flamingspork.com) Received: from localhost.localdomain (unknown [192.168.1.100]) by saturn.flamingspork.com (Postfix) with ESMTP id 265BECA8394; Thu, 13 Apr 2006 15:08:17 +1000 (EST) Received: by localhost.localdomain (Postfix, from userid 1000) id EC7A2144487B; Thu, 13 Apr 2006 15:10:00 +1000 (EST) Subject: Re: howto preallocate to minimize fragmentation From: Stewart Smith To: Eric Sandeen Cc: Ying-Hung Chen , Andrew Ho , linux-xfs@oss.sgi.com In-Reply-To: <4332D17E.6060608@sgi.com> References: <43329839.2070005@yingternet.com> <4332A22B.6070708@sgi.com> <4332BFCC.8050803@yingternet.com> <4332C248.70503@sgi.com> <4332C636.9070509@yingternet.com> <4332CE65.2000500@animezone.org> <4332CF04.2060604@yingternet.com> <4332D17E.6060608@sgi.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-l3w6dTKrJBGyLoWXGiYn" Date: Thu, 13 Apr 2006 15:10:00 +1000 Message-Id: <1144905000.9181.32.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 X-archive-position: 7629 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: stewart@flamingspork.com Precedence: bulk X-list: linux-xfs Status: O Content-Length: 910 Lines: 31 --=-l3w6dTKrJBGyLoWXGiYn Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2005-09-22 at 10:45 -0500, Eric Sandeen wrote: > something like this: > err =3D xfsctl(argv[1], fd, XFS_IOC_RESVSP64, &fl); Are we going to see this be part of posix_fallocate in glibc any time soon? The patch would be fairly trivial and then let application programmers use a standard interface that has a nice fallback in case of non-XFS file systems. --=20 Stewart Smith (stewart@flamingspork.com) http://www.flamingspork.com/ --=-l3w6dTKrJBGyLoWXGiYn Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQBEPd0oKglWCUL+FDoRAuDaAKCuv5zIlpghucgN2XxdsACU0QXLlwCgjGaJ c9GlqY1PNeWWdDsYHjym4hY= =aJ+v -----END PGP SIGNATURE----- --=-l3w6dTKrJBGyLoWXGiYn-- From owner-linux-xfs@oss.sgi.com Wed Apr 12 22:23:44 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 Apr 2006 22:23:46 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k3D5NggC007110 for ; Wed, 12 Apr 2006 22:23:43 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA09884; Thu, 13 Apr 2006 15:23:38 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k3D5NYJC1344313; Thu, 13 Apr 2006 15:23:35 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k3D5NTTP1343644; Thu, 13 Apr 2006 15:23:29 +1000 (EST) Date: Thu, 13 Apr 2006 15:23:29 +1000 From: Nathan Scott To: Stewart Smith Cc: Eric Sandeen , Ying-Hung Chen , Andrew Ho , linux-xfs@oss.sgi.com Subject: Re: howto preallocate to minimize fragmentation Message-ID: <20060413152329.G1338954@wobbly.melbourne.sgi.com> References: <43329839.2070005@yingternet.com> <4332A22B.6070708@sgi.com> <4332BFCC.8050803@yingternet.com> <4332C248.70503@sgi.com> <4332C636.9070509@yingternet.com> <4332CE65.2000500@animezone.org> <4332CF04.2060604@yingternet.com> <4332D17E.6060608@sgi.com> <1144905000.9181.32.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1144905000.9181.32.camel@localhost.localdomain>; from stewart@flamingspork.com on Thu, Apr 13, 2006 at 03:10:00PM +1000 X-archive-position: 7630 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Status: O Content-Length: 766 Lines: 24 On Thu, Apr 13, 2006 at 03:10:00PM +1000, Stewart Smith wrote: > On Thu, 2005-09-22 at 10:45 -0500, Eric Sandeen wrote: > > something like this: > > err = xfsctl(argv[1], fd, XFS_IOC_RESVSP64, &fl); > > Are we going to see this be part of posix_fallocate in glibc any time > soon? I'd be dumbstruck if so. It really needs a proper fs-independent system call. This keeps coming up, and an interface has even been discussed on LKML in the past - just needs some guy to go do it. Some guy called "Stewart" maybe. ;) > The patch would be fairly trivial and then let application > programmers use a standard interface that has a nice fallback in case of > non-XFS file systems. The patch to MySQL would be just as trivial, surely. ;) cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Apr 12 22:56:06 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 12 Apr 2006 22:56:07 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k3D5u4gC008866 for ; Wed, 12 Apr 2006 22:56:05 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA10285; Thu, 13 Apr 2006 15:55:59 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id BE346494E447; Thu, 13 Apr 2006 15:55:57 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 951944 - barriers on remount,ro Message-Id: <20060413055557.BE346494E447@chook.melbourne.sgi.com> Date: Thu, 13 Apr 2006 15:55:57 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 7631 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Status: O Content-Length: 479 Lines: 15 Fix a possible forced shutdown due to mishandling write barriers with remount,ro. Date: Thu Apr 13 15:55:32 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: tes The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:25742a xfs_vfsops.c - 1.502 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vfsops.c.diff?r1=text&tr1=1.502&r2=text&tr2=1.501&f=h From owner-linux-xfs@oss.sgi.com Thu Apr 13 00:05:04 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Apr 2006 00:05:10 -0700 (PDT) Received: from smtp1.adl2.internode.on.net (smtp1.adl2.internode.on.net [203.16.214.181]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k3D753gC014095 for ; Thu, 13 Apr 2006 00:05:04 -0700 Received: from saturn.flamingspork.com (ppp163-199.static.internode.on.net [150.101.163.199]) by smtp1.adl2.internode.on.net (8.13.6/8.13.5) with ESMTP id k3D74ibb001171; Thu, 13 Apr 2006 16:34:44 +0930 (CST) (envelope-from stewart@flamingspork.com) Received: from localhost.localdomain (unknown [192.168.1.100]) by saturn.flamingspork.com (Postfix) with ESMTP id 117C9CA8394; Thu, 13 Apr 2006 17:04:44 +1000 (EST) Received: by localhost.localdomain (Postfix, from userid 1000) id 2FB3E144487B; Thu, 13 Apr 2006 17:06:28 +1000 (EST) Subject: Re: howto preallocate to minimize fragmentation From: Stewart Smith To: Nathan Scott Cc: Eric Sandeen , Ying-Hung Chen , Andrew Ho , linux-xfs@oss.sgi.com In-Reply-To: <20060413152329.G1338954@wobbly.melbourne.sgi.com> References: <43329839.2070005@yingternet.com> <4332A22B.6070708@sgi.com> <4332BFCC.8050803@yingternet.com> <4332C248.70503@sgi.com> <4332C636.9070509@yingternet.com> <4332CE65.2000500@animezone.org> <4332CF04.2060604@yingternet.com> <4332D17E.6060608@sgi.com> <1144905000.9181.32.camel@localhost.localdomain> <20060413152329.G1338954@wobbly.melbourne.sgi.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-uHArShyNzDwFAcgxruAo" Date: Thu, 13 Apr 2006 17:06:27 +1000 Message-Id: <1144911987.9181.110.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 X-archive-position: 7632 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: stewart@flamingspork.com Precedence: bulk X-list: linux-xfs Status: O Content-Length: 1761 Lines: 53 --=-uHArShyNzDwFAcgxruAo Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2006-04-13 at 15:23 +1000, Nathan Scott wrote: > On Thu, Apr 13, 2006 at 03:10:00PM +1000, Stewart Smith wrote: > > On Thu, 2005-09-22 at 10:45 -0500, Eric Sandeen wrote: > > > something like this: > > > err =3D xfsctl(argv[1], fd, XFS_IOC_RESVSP64, &fl); > >=20 > > Are we going to see this be part of posix_fallocate in glibc any time > > soon? >=20 > I'd be dumbstruck if so. It really needs a proper fs-independent > system call. This keeps coming up, and an interface has even been > discussed on LKML in the past - just needs some guy to go do it. > Some guy called "Stewart" maybe. ;) maybe I'll get around to that this weekend :) I've got some ideas for some good API features that we could use (being people who are rather picky about performance and predictability in certain areas) > > The patch would be fairly trivial and then let application > > programmers use a standard interface that has a nice fallback in case of > > non-XFS file systems. >=20 > The patch to MySQL would be just as trivial, surely. ;) yeah - it's all about elegance though :) At some point I should go and convince the OSX guys to do the same (from a unix api, not just Carbon)... I'm working on motivation.. :) --=20 Stewart Smith (stewart@flamingspork.com) http://www.flamingspork.com/ --=-uHArShyNzDwFAcgxruAo Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQBEPfhzKglWCUL+FDoRAuqAAKCHN5xzaB8DBubYWokMNEabKZYVAgCfeQQX cQW8/loZbPMGSofG3c3NV2I= =MPQL -----END PGP SIGNATURE----- --=-uHArShyNzDwFAcgxruAo-- From owner-linux-xfs@oss.sgi.com Thu Apr 13 04:01:38 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Apr 2006 04:01:40 -0700 (PDT) Received: from shark.2a.pl ([195.117.102.3]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k3DB1YgC000458 for ; Thu, 13 Apr 2006 04:01:38 -0700 Received: from localhost (av.2a.pl [10.0.0.99]) by shark.2a.pl (ESMTP) with ESMTP id 5D3AFA6E58; Thu, 13 Apr 2006 13:01:25 +0200 (CEST) Received: from shark.2a.pl ([10.0.0.3]) by localhost (av.2a.pl [10.0.0.99]) (amavisd-new, port 10024) with ESMTP id 27611-02; Thu, 13 Apr 2006 12:59:47 +0200 (CEST) Received: from [127.0.0.1] (bya38.internetdsl.tpnet.pl [83.19.4.38]) by shark.2a.pl (ESMTP) with ESMTP id 20FCCA6E5F; Thu, 13 Apr 2006 13:01:19 +0200 (CEST) Message-ID: <443E2F64.8010703@ursynow.2a.pl> Date: Thu, 13 Apr 2006 13:00:52 +0200 From: =?ISO-8859-1?Q?Artur_Mak=F3wka?= User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: David Chinner Cc: linux-xfs@oss.sgi.com Subject: Re: server crashing References: <443627B1.5090100@ursynow.2a.pl> <20060410015916.GK2732@melbourne.sgi.com> <443B60E8.6070004@ursynow.2a.pl> <20060412020427.GI1484909@melbourne.sgi.com> In-Reply-To: <20060412020427.GI1484909@melbourne.sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-archive-position: 7633 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: juice@ursynow.2a.pl Precedence: bulk X-list: linux-xfs Status: O Content-Length: 1480 Lines: 37 David Chinner napisal(a): > On Tue, Apr 11, 2006 at 09:55:20AM +0200, Artur Makówka wrote: >> and why xfs_repair didnt repaired it ? > > xfs_repair doesn't check the free space btrees, it simply rebuilds > them from scratch. Hence it won't warn about a corrupted AGF btree > during repair. However, after a repair they should be consistent. > > OTOH, xfs_check will actually check the AGF btrees for corruption > and consistency. Can you run xfs_check on the filesystem after one of > these errors both before and after you run xfs_repair, and post > the output? i can't run it so often, because to run it i think i have to unmount my filesystem. and of course this means longer downtime for my users, which for now i just can't do. Maybe there is some kind of bug with this situation, because i forgot to tell you one thing: i have one more XFS partition that is inside this one big XFS partition. its in fstab like this: /var/eaccelerator /eaccelerator xfs loop 0 0 and i did /var/eaccelerator with dd ( dd if=/dev/zero of=/var/eaccelerator ) with size of 1GB. i deleted it for test purposes, and it didnt crash yet (but that doesnt mean anything, there were already times of 5 and more days working without crash and then suddenly it was happening) so, does this loop partition can have anything to do ? i will run xfs_check in a few days, unless there is a way to run it on mounted partition without the risk of wrong corruption reports From owner-linux-xfs@oss.sgi.com Thu Apr 13 07:21:25 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Apr 2006 07:21:27 -0700 (PDT) Received: from linux01.gwdg.de (linux01.gwdg.de [134.76.13.21]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k3DELOgC024456 for ; Thu, 13 Apr 2006 07:21:25 -0700 Received: from linux01.gwdg.de (localhost [127.0.0.1]) by linux01.gwdg.de (8.13.3/8.13.3/SuSE Linux 0.7) with ESMTP id k3DELKZA018363; Thu, 13 Apr 2006 16:21:22 +0200 Received: from localhost (jengelh@localhost) by linux01.gwdg.de (8.13.3/8.13.3/Submit) with ESMTP id k3DELJiR018357; Thu, 13 Apr 2006 16:21:19 +0200 Date: Thu, 13 Apr 2006 16:21:18 +0200 (MEST) From: Jan Engelhardt To: Herbert Poetzl cc: Jes Sorensen , Con Kolivas , Linux Kernel ML , linux-xfs@oss.sgi.com, xfs-masters@oss.sgi.com, stern@rowland.harvard.edu, sekharan@us.ibm.com, akpm@osdl.org, David Chinner Subject: Re: notifier chain problem? (was Re: 2.6.17-rc1 did break XFS) In-Reply-To: <20060413135000.GB6663@MAIL.13thfloor.at> Message-ID: References: <20060413052145.GA31435@MAIL.13thfloor.at> <20060413072325.GF2732@melbourne.sgi.com> <20060413135000.GB6663@MAIL.13thfloor.at> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 7635 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jengelh@linux01.gwdg.de Precedence: bulk X-list: linux-xfs Status: O Content-Length: 638 Lines: 19 >> >> Looks strange, the faulting address is in the same region as the >> eip. I am not that strong on x86 layouts, so I am not sure whether >> 0x78xxxxxx is the kernel's mapping or it's module space. Almost looks >> like something else had registered a notifier and then gone away >> without unregistering it. > >sorry, the essential data I didn't provide here is >probably that I configured the 2G/2G split, which for >unknown reasons actually is a 2.125/1.875 split and >starts at 0x78000000 (instead of 0x80000000) That's how it is coded in arch/i386/Kconfig. It says 78 rather than 80. Maybe Con has an idea? Jan Engelhardt -- From owner-linux-xfs@oss.sgi.com Thu Apr 13 07:18:01 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Apr 2006 07:18:03 -0700 (PDT) Received: from linux01.gwdg.de (linux01.gwdg.de [134.76.13.21]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k3DEI0gC024038 for ; Thu, 13 Apr 2006 07:18:00 -0700 Received: from linux01.gwdg.de (localhost [127.0.0.1]) by linux01.gwdg.de (8.13.3/8.13.3/SuSE Linux 0.7) with ESMTP id k3DEHs9h018277; Thu, 13 Apr 2006 16:17:56 +0200 Received: from localhost (jengelh@localhost) by linux01.gwdg.de (8.13.3/8.13.3/Submit) with ESMTP id k3DEHsJu018271; Thu, 13 Apr 2006 16:17:54 +0200 Date: Thu, 13 Apr 2006 16:17:53 +0200 (MEST) From: Jan Engelhardt To: Keith Owens cc: Nathan Scott , dgc@melbourne.sgi.com, Linux Kernel ML , linux-xfs@oss.sgi.com, xfs-masters@oss.sgi.com, stern@rowland.harvard.edu, sekharan@us.ibm.com Subject: Re: 2.6.17-rc1 did break XFS In-Reply-To: <9020.1144920230@kao2.melbourne.sgi.com> Message-ID: References: <9020.1144920230@kao2.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 7634 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jengelh@linux01.gwdg.de Precedence: bulk X-list: linux-xfs Status: O Content-Length: 491 Lines: 14 >notifier_chain_register() is running the existing chain to find the >place where XFS needs to be inserted, and the existing chain is >corrupt. Probably not an XFS problem. > Aye. I booted 2.6.17-rc1 for some minutes to test CSCAN - root filesystem is XFS - and did not have any such early oops. Since `updatedb` happened to run automatically by cron just after I started that laptop, I also would not say it being an XFS problem. I do use VMSPLIT_3G_OPT however. Jan Engelhardt -- From owner-linux-xfs@oss.sgi.com Thu Apr 13 11:28:25 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Apr 2006 11:28:26 -0700 (PDT) Received: from virasto.com (virasto.com [212.213.212.50]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k3DISOgC017314 for ; Thu, 13 Apr 2006 11:28:25 -0700 Received: by virasto.com (Postfix, from userid 1000) id 334D67514; Thu, 13 Apr 2006 21:28:25 +0300 (EEST) Date: Thu, 13 Apr 2006 21:28:25 +0300 From: Onis To: Nathan Scott Cc: Steve Lord , linux-xfs@oss.sgi.com Subject: Re: Remounting read-only forces filesystem shutdown Message-ID: <20060413182825.GA23178@virasto.com> References: <20060412203719.GA22528@virasto.com> <20060413100839.C1334248@wobbly.melbourne.sgi.com> <443DB2D9.7070706@xfs.org> <20060413122138.A1338954@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060413122138.A1338954@wobbly.melbourne.sgi.com> User-Agent: Mutt/1.3.28i X-archive-position: 7636 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: onion@virasto.com Precedence: bulk X-list: linux-xfs Status: O Content-Length: 926 Lines: 26 On Thu, Apr 13, 2006 at 12:21:38PM +1000, Nathan Scott wrote: > On Wed, Apr 12, 2006 at 09:09:29PM -0500, Steve Lord wrote: > > >> To repeat it, just do "mount -o remount,ro /mnt". > > > > > > Ah, I think I see the problem - looks like we can enable write > > > barriers accidentally during a remount,ro without checking to > > > see if the drive likes that idea. Ugh. > > > > > > Just to be sure - when you initially mounted the filesystem (rw), did > > > you get a dmesg message saying "disabling write barriers" or words to > > > that effect? Yes, dmesg says: Filesystem "md0": Disabling barriers, not supported by the underlying device > This patch to fs/xfs/xfs_vfsops.c should fix that right up... I'll get > it merged in asap. Looks like the only way to catch some problems is > to switch things on by default. ;) This definitely fixes the problem. Now I can boot and leave filesystem clean! Thanks! - Onion From owner-linux-xfs@oss.sgi.com Thu Apr 13 17:04:56 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Apr 2006 17:05:00 -0700 (PDT) Received: from smtp108.sbc.mail.mud.yahoo.com (smtp108.sbc.mail.mud.yahoo.com [68.142.198.207]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k3E04tgC015764 for ; Thu, 13 Apr 2006 17:04:56 -0700 Received: (qmail 5185 invoked from network); 14 Apr 2006 00:04:56 -0000 Received: from unknown (HELO stupidest.org) (cwedgwood@sbcglobal.net@70.231.253.108 with login) by smtp108.sbc.mail.mud.yahoo.com with SMTP; 14 Apr 2006 00:04:56 -0000 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id 3E3FB51FAC0; Thu, 13 Apr 2006 17:04:55 -0700 (PDT) Date: Thu, 13 Apr 2006 17:04:55 -0700 From: Chris Wedgwood To: Stewart Smith Cc: Eric Sandeen , Ying-Hung Chen , Andrew Ho , linux-xfs@oss.sgi.com Subject: Re: howto preallocate to minimize fragmentation Message-ID: <20060414000455.GA17751@taniwha.stupidest.org> References: <43329839.2070005@yingternet.com> <4332A22B.6070708@sgi.com> <4332BFCC.8050803@yingternet.com> <4332C248.70503@sgi.com> <4332C636.9070509@yingternet.com> <4332CE65.2000500@animezone.org> <4332CF04.2060604@yingternet.com> <4332D17E.6060608@sgi.com> <1144905000.9181.32.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1144905000.9181.32.camel@localhost.localdomain> X-archive-position: 7637 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs Status: O Content-Length: 530 Lines: 15 On Thu, Apr 13, 2006 at 03:10:00PM +1000, Stewart Smith wrote: > Are we going to see this be part of posix_fallocate in glibc any > time soon? i did kernel patches and an attempt at the glibc part of it for i386 and amd64, it needs a cleanup and reposting though. right now there is only support for xfs and ext[23], im not sure if other fs's can provide anything > The patch would be fairly trivial and then let application > programmers use a standard interface that has a nice fallback in > case of non-XFS file systems. From owner-linux-xfs@oss.sgi.com Thu Apr 13 20:14:17 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Apr 2006 20:14:18 -0700 (PDT) Received: from shark.2a.pl (shark.2a.pl [195.117.102.3]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k3E3EGgC031660 for ; Thu, 13 Apr 2006 20:14:17 -0700 Received: from localhost (av.2a.pl [10.0.0.99]) by shark.2a.pl (ESMTP) with ESMTP id AC4DAA6DF8; Fri, 14 Apr 2006 05:14:11 +0200 (CEST) Received: from shark.2a.pl ([10.0.0.3]) by localhost (av.2a.pl [10.0.0.99]) (amavisd-new, port 10024) with ESMTP id 42398-03; Fri, 14 Apr 2006 05:12:31 +0200 (CEST) Received: from [127.0.0.1] (bya38.internetdsl.tpnet.pl [83.19.4.38]) by shark.2a.pl (ESMTP) with ESMTP id 6DD8DA6DFA; Fri, 14 Apr 2006 05:14:06 +0200 (CEST) Message-ID: <443F136F.7090201@ursynow.2a.pl> Date: Fri, 14 Apr 2006 05:13:51 +0200 From: =?ISO-8859-1?Q?Artur_Mak=F3wka?= User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: David Chinner Cc: linux-xfs@oss.sgi.com Subject: Re: server crashing References: <443627B1.5090100@ursynow.2a.pl> <20060410015916.GK2732@melbourne.sgi.com> <443B60E8.6070004@ursynow.2a.pl> <20060412020427.GI1484909@melbourne.sgi.com> <443E2F64.8010703@ursynow.2a.pl> In-Reply-To: <443E2F64.8010703@ursynow.2a.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-archive-position: 7638 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: juice@ursynow.2a.pl Precedence: bulk X-list: linux-xfs Status: O Content-Length: 1387 Lines: 31 Artur Makówka napisal(a): > David Chinner napisal(a): >> On Tue, Apr 11, 2006 at 09:55:20AM +0200, Artur Makówka wrote: >>> and why xfs_repair didnt repaired it ? >> >> xfs_repair doesn't check the free space btrees, it simply rebuilds >> them from scratch. Hence it won't warn about a corrupted AGF btree >> during repair. However, after a repair they should be consistent. >> >> OTOH, xfs_check will actually check the AGF btrees for corruption >> and consistency. Can you run xfs_check on the filesystem after one of >> these errors both before and after you run xfs_repair, and post >> the output? > > i can't run it so often, because to run it i think i have to unmount my > filesystem. and of course this means longer downtime for my users, which > for now i just can't do. > > Maybe there is some kind of bug with this situation, because i forgot to > tell you one thing: i have one more XFS partition that is inside this > one big XFS partition. > guess it's not. it crashed again after i removed loop-mounted XFS partition - so that's not it. i also ran xfs_check on unmounted system, but output was empty. it just didn't say anything, and finished checking after like 10-20 minutes with no output. is it normal? i did xfs_check /dev/md0 1>>logs 2>>logs. And it finished with file logs with 0 bytes. Should i run it with -v ? -v generates a lot of output though. From owner-linux-xfs@oss.sgi.com Thu Apr 13 20:54:36 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 13 Apr 2006 20:54:39 -0700 (PDT) Received: from larry.melbourne.sgi.com ([61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k3E3sYgC007205 for ; Thu, 13 Apr 2006 20:54:35 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA24570; Fri, 14 Apr 2006 13:54:14 +1000 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k3E3sOPR6267155; Fri, 14 Apr 2006 13:54:25 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k3E3sMVH6264136; Fri, 14 Apr 2006 13:54:22 +1000 (AEST) Date: Fri, 14 Apr 2006 13:54:22 +1000 From: David Chinner To: Artur =?iso-8859-1?Q?Mak=F3wka?= Cc: David Chinner , linux-xfs@oss.sgi.com Subject: Re: server crashing Message-ID: <20060414035422.GO1484909@melbourne.sgi.com> References: <443627B1.5090100@ursynow.2a.pl> <20060410015916.GK2732@melbourne.sgi.com> <443B60E8.6070004@ursynow.2a.pl> <20060412020427.GI1484909@melbourne.sgi.com> <443E2F64.8010703@ursynow.2a.pl> <443F136F.7090201@ursynow.2a.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <443F136F.7090201@ursynow.2a.pl> User-Agent: Mutt/1.4.2.1i X-archive-position: 7639 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: linux-xfs Status: O Content-Length: 2147 Lines: 51 On Fri, Apr 14, 2006 at 05:13:51AM +0200, Artur Makówka wrote: > Artur Makówka napisal(a): > >David Chinner napisal(a): > >>On Tue, Apr 11, 2006 at 09:55:20AM +0200, Artur Makówka wrote: > >>>and why xfs_repair didnt repaired it ? > >> > >>xfs_repair doesn't check the free space btrees, it simply rebuilds > >>them from scratch. Hence it won't warn about a corrupted AGF btree > >>during repair. However, after a repair they should be consistent. > >> > >>OTOH, xfs_check will actually check the AGF btrees for corruption > >>and consistency. Can you run xfs_check on the filesystem after one of > >>these errors both before and after you run xfs_repair, and post > >>the output? > > > >i can't run it so often, because to run it i think i have to unmount my > >filesystem. and of course this means longer downtime for my users, which > >for now i just can't do. You can run xfs_check -n on a mounted filesystem, but it can give spurious errors in that case. if you do run it on a mounted filesystem, make sure you run 'sync' first.... > >Maybe there is some kind of bug with this situation, because i forgot to > >tell you one thing: i have one more XFS partition that is inside this > >one big XFS partition. > > guess it's not. it crashed again after i removed loop-mounted XFS > partition - so that's not it. i also ran xfs_check on unmounted system, > but output was empty. it just didn't say anything, and finished checking > after like 10-20 minutes with no output. is it normal? i did xfs_check No output means there is nothing wrong with the filesystem i.e. there is no corruption on disk. That tends to implicate an in-memory corruption of some sort. Does you machine have ECC RAM? Can you run memtest86 to determine if there is bad memory in your machine? > /dev/md0 1>>logs 2>>logs. And it finished with file logs with 0 bytes. > Should i run it with -v ? -v generates a lot of output though. No, -v is really only useful for debugging xfs_check problems. The command you ran will report anything it finds wrong with the filesystem. Cheers, Dave. -- Dave Chinner R&D Software Enginner SGI Australian Software Group From owner-linux-xfs@oss.sgi.com Sat Apr 15 08:54:48 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 15 Apr 2006 08:55:44 -0700 (PDT) Received: from mail.e-iei.com (59-125-103-118.HINET-IP.hinet.net [59.125.103.118]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k3FFshgE006765 for ; Sat, 15 Apr 2006 08:54:46 -0700 Received: from EPORTALWEB ([172.16.2.19]) by mail.e-iei.com (8.12.8/8.12.8) with SMTP id k3FE6QZf029747; Sat, 15 Apr 2006 22:06:36 +0800 Reply-To: From: "DELIA HU" Bcc: Subject: 19" 1U Pentium 4 / LGA775 Server -- ISRV-1121B Date: Sat, 15 Apr 2006 22:06:24 +0800 Message-ID: <2b79301c66095$c7b57770$130210ac@ieinet.org> MIME-Version: 1.0 X-Mailer: Microsoft CDO for Windows 2000 Thread-Index: AcZglcez0QJR09N5Ri+Ge+f/18UX3g== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit X-archive-position: 7640 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: igs@e-iei.com Precedence: bulk X-list: linux-xfs Status: RO Content-Length: 2274 Lines: 86 New Product Notice: ISRV-1121B Dear Valuable Partner, New product phase-in notice : 1U Pentium 4/LGA775 Server with 1 x SATA HDD ISRV-1121B 1U Pentium 4/LGA 775 brings greater throughput capability to the entrylevel. Redefining cost-effectiveness and ever-improving the cost/performance ratio, IEI's ISRV-1121B single-processor Pentium 4 rackmount server provides an ideal platform for small-business, e-commerce, or any entry-level computing needs. ISRV-1121B also offers small form factor rackmount servers for space-limited applications Main Features: - Intel Pentium 4 LGA775 Package 800MHz FSB, Celeron 533MHz FSB - Up to 4GB DDRII 400 / 533MHz Unbuffered ECC / Non-ECC SDRAM - 1 x 64-bit 133MHz Full-height / half length PCI-X Slot - 2x Broadcom BCM5721 Gigabit LAN Controllers ISRV-1121B Processor Single LGA775 (Prescott) Socket Supports an Intel Pentium 4 processor (800MHz FSB) System Bus 800 / 533 MHz system bus Memory Capacity Four 240-pin DIMM sockets Supports up to 4 GB DDRII 400MHz/533MHz unbuffered ECC/non-ECC memory Chipset Intel E7221+ICH6R Serial ATA SATA controller integrated in Intel ICH6R+SATA controller integrated in Intel ICH6RSATA controller integrated in Intel ICH6R RAID 0, 1, 10 support Network Controllers 2x Broadcom BCM5721 10/100/1000 Gigabit Ethernet Controllers Graphics Onboard integrated server quality video graphics in MCH Expansion Slots 1x 64-bit PCI-X 133MHz slot (with Riser Card) Input / Output One 3.5" SATA / IDE hard drive supported One EIDE channel supports up to two UDMA / IDE devices 1 Floppy controller; 1.44 MB 2x RJ45 LAN port 2x rear USB 2.0 / 1.1 ports 2x front USB 2.0 / 1.1 ports 1x VGA port 1x PS/2 keyboard and 1x PS/2 mouse ports 1x Fast UART 16550 serial ports 1x serial header 1x ECP/EEP Parallel Port Dimensions(HxWxD) 1.7" (43mm) x16.75" (426mm) x14" (355.6mm) Gross Weight 16.5 lbs (7.5kg) For further information, please visit our website: www.ieiworld.com.tw I don't want to recevie this news again [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Mon Apr 17 07:19:56 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 17 Apr 2006 07:20:02 -0700 (PDT) Received: from usbb-lacimss1.unisys.com (usbb-lacimss1.unisys.com [192.63.108.51]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k3HEJtgC005438 for ; Mon, 17 Apr 2006 07:19:56 -0700 Received: from USBB-LACGW3.na.uis.unisys.com ([129.224.98.43]) by usbb-lacimss1 with InterScan Messaging Security Suite; Mon, 17 Apr 2006 09:07:33 -0400 Received: from USBB-LACGW3.na.uis.unisys.com ([129.224.98.44]) by USBB-LACGW3.na.uis.unisys.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Apr 2006 08:48:10 -0400 Received: from gbmk-eugw2.eu.uis.unisys.com ([129.221.133.27]) by USBB-LACGW3.na.uis.unisys.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Apr 2006 08:48:10 -0400 Received: from inblr-exch1.eu.uis.unisys.com ([129.221.252.12]) by gbmk-eugw2.eu.uis.unisys.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Apr 2006 13:47:51 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Regarding compiling LTP on IA-64 architecture Date: Mon, 17 Apr 2006 18:17:49 +0530 Message-ID: <88299102B8C1F54BB5C8E47F30B2FBE2021FAEF8@inblr-exch1.eu.uis.unisys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Regarding compiling LTP on IA-64 architecture Thread-Index: AcZiHSI7IxlPSqGAQPy8etD0rncxMw== From: "Verma, Divyanshu" To: Cc: "Kathiresan, Lekshmanan" X-OriginalArrivalTime: 17 Apr 2006 12:47:51.0951 (UTC) FILETIME=[23B891F0:01C6621D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id k3HEJugC005449 X-archive-position: 7641 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Divyanshu.Verma@in.unisys.com Precedence: bulk X-list: linux-xfs Status: O Content-Length: 474 Lines: 16 Hi, I am trying to compile and run LTP (ltp-20060411) on IA-64 architecture.But I am getting lots of compilation error. Say, rules.mk file does not have IA-64 defined for "arch' variable. Can u please advise us the steps that we need to follwo to get a clean compilation. We have compiled it successfully for IA-32 (PC architecture) and with slight modifications on x86-64 architecture. thanks and regards, Divyanshu Linux kernel Development team Unisys Corporation From owner-linux-xfs@oss.sgi.com Mon Apr 17 09:10:43 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 17 Apr 2006 09:10:52 -0700 (PDT) Received: from nproxy.gmail.com (nproxy.gmail.com [64.233.182.185]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k3HGAggC020214 for ; Mon, 17 Apr 2006 09:10:42 -0700 Received: by nproxy.gmail.com with SMTP id o60so1071493nfa for ; Mon, 17 Apr 2006 09:10:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:to:subject:from:content-type:mime-version:content-transfer-encoding:message-id:user-agent; b=Qwh2K4vCX07KB1p+OCQSqB1flwhWbCUmleEeHMRmNQi74WCcbfqecUcc99QCSW+AmtUQjWlX3EbK2QPy0Cwrg4Su9EZBkBpHvMeG+xJcFiwdr0L9vxrHwTdKAfc35kxjpUHobn7SjQ2uBuYjj8x1KN6qVmPdgNPnUqEBDrrCFO0= Received: by 10.48.217.12 with SMTP id p12mr1881182nfg; Mon, 17 Apr 2006 08:06:25 -0700 (PDT) Received: from undecomp ( [213.137.239.70]) by mx.gmail.com with ESMTP id m15sm1076377nfc.2006.04.17.08.06.23; Mon, 17 Apr 2006 08:06:25 -0700 (PDT) Date: Mon, 17 Apr 2006 19:07:28 +0400 To: linux-xfs@oss.sgi.com Subject: Some questions about XFS design From: unDEFER Content-Type: text/plain; format=flowed; delsp=yes; charset=koi8-r MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: User-Agent: Opera M2/8.50 (Linux, build 1358) X-archive-position: 7642 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: undefer@gmail.com Precedence: bulk X-list: linux-xfs Status: O Content-Length: 3540 Lines: 92 Hello! I try to understand XFS structure (I need it so as I will write build_xfs util like build_e2fs for anyfs-tools.sf.net project) and have some questions. I have understood superblock structure, alocation and inode allocation B-trees structures, inode core, extent list and directory structures, but I have some problem with Block Map. According information in xfsprogs-2.7.11/include/xfs_dinode.h, if di_format field of di_core have value 3 (XFS_DINODE_FMT_BTREE), then union inode have xfs_bmdr_block_t structure format, but seems it is not so. Below, I put some commented hexdump of structure of 0x84 inode (I expect, you have monospace type in your mail reader): ***Start of dxfs_dinode structure*** ***Start of di_core structure*** +-- di_magic ('IN') | | +-- di_mode (it is regular file) | | | | +-- di_version | | | | | | +-- di_format (XFS_DINODE_FMT_BTREE) | | | | +---+ +---+ ++ ++ 00008400 49 4e 81 a4 01 03 00 01 00 00 01 f4 00 00 01 f5 |IN ¤.......ô...õ| 00008410 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 e5 |...............å| 00008420 44 3a 80 d7 1e 54 43 d0 41 e8 68 9a 00 00 00 00 |D: ×.TCÐAèh ....| 00008430 42 1b 7d 18 2c d5 ec 08 00 00 00 00 27 c0 04 00 |B.}.,Õì.....'À..| +-- di_nextents (10 extents) | +---------+ 00008440 00 00 00 00 00 02 7c 02 00 00 00 00 00 00 00 0a |......|.........| 00008450 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 0e |................| ***End of di_core structure*** +-- di_next_unlinked (it is not unlinked file) | | +-- bb_level of xfs_bmdr_block_t structure??? | | | | +-- bb_numrecs of xfs_bmdr_block_t structure??? | | | | | | +-- Why we have zeroes here? | | | | +---------+ +---+ +---+ +---------------------+ 00008460 ff ff ff ff 00 01 00 01 00 00 00 00 00 00 00 00 |ÿÿÿÿ............| !!! Here we have piece of old data of extent list. Why??? !!! 00008470 e5 a1 c8 00 00 00 00 00 03 90 00 00 00 00 00 8d |å¡È...... ..... | 00008480 41 a0 11 40 00 00 00 00 03 b2 80 00 00 00 00 91 |A .@.....² .... | 00008490 e1 a0 12 e0 00 00 00 00 03 d8 40 00 00 00 00 96 |á .à.....Ø@.... | 000084a0 ad a0 14 60 00 00 00 00 04 01 00 00 00 00 00 9c |­ .`........... | !!! End if piece of old data of extent list !!! +-- It is seems, 64 bit link to btree block. | +---------------------+ 000084b0 00 00 00 00 00 05 e0 6f 00 00 00 00 00 00 00 00 |......ào........| 000084c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000084d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000084e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000084f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| ***End of Inode*** So, I don't understand why we skip 0x50 bytes after some structure similar to btree root and what is it if not btree root block... Sorry for bad english. My native language is russian. -- registered Linux user #360474 Don't worry, I can read OpenOffice.org From owner-linux-xfs@oss.sgi.com Mon Apr 17 09:42:49 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 17 Apr 2006 09:42:52 -0700 (PDT) Received: from nproxy.gmail.com (nproxy.gmail.com [64.233.182.191]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k3HGgmgC024468 for ; Mon, 17 Apr 2006 09:42:48 -0700 Received: by nproxy.gmail.com with SMTP id o25so427454nfa for ; Mon, 17 Apr 2006 09:42:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:subject:references:content-type:mime-version:content-transfer-encoding:message-id:in-reply-to:user-agent; b=Hw2gog4dYY+24rn+hgT96oRXIAVs6YGNfek8W/yL+y89HybP248QqCoBDOOjRiSQb38zl5q+zWok53bpU5KtbHXJIole6LeRCd0T76K+c+WqeIlWu0Lcp+QnP1+DX8k9zpMbn1W7Mnb1HDXm/Gy+II47sea59py/eUUsMTV8uqI= Received: by 10.48.30.1 with SMTP id d1mr2636616nfd; Mon, 17 Apr 2006 09:42:47 -0700 (PDT) Received: from undecomp ( [213.137.239.70]) by mx.gmail.com with ESMTP id d2sm13082nfe.2006.04.17.09.42.23; Mon, 17 Apr 2006 09:42:47 -0700 (PDT) Date: Mon, 17 Apr 2006 20:43:32 +0400 From: unDEFER To: "linux-xfs@oss.sgi.com" Subject: Re: Some questions about XFS design References: Content-Type: text/plain; format=flowed; delsp=yes; charset=koi8-r MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: User-Agent: Opera M2/8.50 (Linux, build 1358) X-archive-position: 7643 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: undefer@gmail.com Precedence: bulk X-list: linux-xfs Status: O Content-Length: 2761 Lines: 61 ÷ ÐÉÓØÍÅ ÏÔ Mon, 17 Apr 2006 19:07:28 +0400, unDEFER ÓÏÏÂÝÁÌ: Sorry for bad formatting in prevision message. ***Start of dxfs_dinode structure*** ***Start of di_core structure*** +-- di_magic ('IN') | | +-- di_mode (it is regular file) | | | | +-- di_version | | | | | | +-- di_format (XFS_DINODE_FMT_BTREE) | | | | +---+ +---+ ++ ++ 00008400 49 4e 81 a4 01 03 00 01 00 00 01 f4 00 00 01 f5 |IN ¤.......ô...õ| 00008410 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 e5 |...............å| 00008420 44 3a 80 d7 1e 54 43 d0 41 e8 68 9a 00 00 00 00 |D: ×.TCÐAèh ....| 00008430 42 1b 7d 18 2c d5 ec 08 00 00 00 00 27 c0 04 00 |B.}.,Õì.....'À..| +-- di_nextents (10 extents) | +---------+ 00008440 00 00 00 00 00 02 7c 02 00 00 00 00 00 00 00 0a |......|.........| 00008450 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 0e |................| ***End of di_core structure*** +-- di_next_unlinked (it is not unlinked file) | | +-- bb_level of xfs_bmdr_block_t structure??? | | | | +-- bb_numrecs of xfs_bmdr_block_t structure??? | | | | | | +-- Why we have zeroes here? | | | | +---------+ +---+ +---+ +---------------------+ 00008460 ff ff ff ff 00 01 00 01 00 00 00 00 00 00 00 00 |ÿÿÿÿ............| !!! Here we have piece of old data of extent list. Why??? !!! 00008470 e5 a1 c8 00 00 00 00 00 03 90 00 00 00 00 00 8d |å¡È...... ..... | 00008480 41 a0 11 40 00 00 00 00 03 b2 80 00 00 00 00 91 |A .@.....² .... | 00008490 e1 a0 12 e0 00 00 00 00 03 d8 40 00 00 00 00 96 |á .à.....Ø@.... | 000084a0 ad a0 14 60 00 00 00 00 04 01 00 00 00 00 00 9c |­ .`........... | !!! End if piece of old data of extent list !!! +-- It is seems, 64 bit link to btree block. | +---------------------+ 000084b0 00 00 00 00 00 05 e0 6f 00 00 00 00 00 00 00 00 |......ào........| 000084c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000084d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000084e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 000084f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| ***End of Inode*** -- registered Linux user #360474 Don't worry, I can read OpenOffice.org From owner-linux-xfs@oss.sgi.com Mon Apr 17 16:10:37 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 17 Apr 2006 16:10:40 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k3HNAZgC029071 for ; Mon, 17 Apr 2006 16:10:36 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA04629; Tue, 18 Apr 2006 09:10:26 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k3HNANJC1431542; Tue, 18 Apr 2006 09:10:23 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k3HNAKXo1456744; Tue, 18 Apr 2006 09:10:20 +1000 (EST) Date: Tue, 18 Apr 2006 09:10:19 +1000 From: Nathan Scott To: unDEFER Cc: linux-xfs@oss.sgi.com Subject: Re: Some questions about XFS design Message-ID: <20060418091019.B1478752@wobbly.melbourne.sgi.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from undefer@gmail.com on Mon, Apr 17, 2006 at 07:07:28PM +0400 X-archive-position: 7644 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Status: O Content-Length: 3726 Lines: 109 On Mon, Apr 17, 2006 at 07:07:28PM +0400, unDEFER wrote: > Hello! Hi there, > I try to understand XFS structure (I need it so as I will write build_xfs > util like build_e2fs for anyfs-tools.sf.net project) and have some > questions. > I have understood superblock structure, alocation and inode allocation > B-trees structures, inode core, extent list and directory structures, but > I have some problem with Block Map. > According information in xfsprogs-2.7.11/include/xfs_dinode.h, if > di_format field of di_core have value 3 (XFS_DINODE_FMT_BTREE), then union > inode have xfs_bmdr_block_t structure format, but seems it is not so. > Below, I put some commented hexdump of structure of 0x84 inode (I expect, > you have monospace type in your mail reader): You should be able to figure out the answers to your questions through clever use of xfs_db - something along the lines... # xfs_db /dev/sdb5 xfs_db> sb xfs_db> p rootino rootino = 128 xfs_db> inode 128 xfs_db> print core.magic = 0x494e core.mode = 040755 core.version = 1 core.format = 1 (local) core.nlinkv1 = 2 core.uid = 0 core.gid = 0 core.flushiter = 1 core.atime.sec = Thu Apr 13 16:30:06 2006 core.atime.nsec = 969575000 core.mtime.sec = Thu Apr 13 16:30:08 2006 core.mtime.nsec = 533941750 core.ctime.sec = Thu Apr 13 16:30:08 2006 core.ctime.nsec = 533941750 core.size = 21 core.nblocks = 0 core.extsize = 0 core.nextents = 0 core.naextents = 0 core.forkoff = 0 core.aformat = 2 (extents) core.dmevmask = 0 core.dmstate = 0 core.newrtbm = 0 core.prealloc = 0 core.realtime = 0 core.immutable = 0 core.append = 0 core.sync = 0 core.noatime = 0 core.nodump = 0 core.rtinherit = 0 core.projinherit = 0 core.nosymlinks = 0 core.extsz = 0 core.extszinherit = 0 core.gen = 0 next_unlinked = null u.sfdir2.hdr.count = 1 u.sfdir2.hdr.i8count = 0 u.sfdir2.hdr.parent.i4 = 128 u.sfdir2.list[0].namelen = 8 u.sfdir2.list[0].offset = 0x30 u.sfdir2.list[0].name = "4100.tmp" u.sfdir2.list[0].inumber.i4 = 131 xfs_db> type text xfs_db> p 00: 49 4e 41 ed 01 01 00 02 00 00 00 00 00 00 00 00 INA............. 10: 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 01 ................ 20: 44 3d ef ee 39 ca 8a 58 44 3d ef f0 1f d3 4d f6 D...9..XD.....M. 30: 44 3d ef f0 1f d3 4d f6 00 00 00 00 00 00 00 15 D.....M......... 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 50: 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00 ................ 60: ff ff ff ff 01 00 00 00 00 80 08 00 30 34 31 30 ............0410 70: 30 2e 74 6d 70 00 00 00 83 00 00 00 00 00 00 00 0.tmp........... 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ xfs_db> and now with some cunning use of xfs_io to setup inodes into their various states, you're able to figure out the entire ondisk state of all the different file types. Don't put too much faith in the comments and those unions over in dinode.h - the unions in particular are not like that on-disk - we keep those there mainly for documentation I guess. In particular, there will often be multiple copies of one of the entries from that union, and the attr fork "union" doesn't follow immediately after the data fork "union" ondisk. Good luck. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Apr 17 19:26:55 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 17 Apr 2006 19:26:57 -0700 (PDT) Received: from jg555.com (jg555.com [64.30.195.78]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k3I2QtgC021418 for ; Mon, 17 Apr 2006 19:26:55 -0700 Received: from [172.16.0.155] (W2RZ8L4S01.jg555.com [::ffff:172.16.0.155]) (AUTH: PLAIN root, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by jg555.com with esmtp; Mon, 17 Apr 2006 17:36:25 -0700 id 001D460E.44443489.00000C9D Message-ID: <44443458.4010201@jg555.com> Date: Mon, 17 Apr 2006 17:35:36 -0700 From: Jim Gifford User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: XFS Issues Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7645 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lfs@jg555.com Precedence: bulk X-list: linux-xfs Status: O Content-Length: 2013 Lines: 53 Trying to do a system build using XFS as my default file system. Keep getting oops like the one posted below. System is Cross-LFS system - GCC 4.1 - Glibc 2.4 - Binutils 2.16.1 Any suggestions? Unable to handle kernel paging request at virtual address 548bc35f printing eip: c01b7810 *pde = 00000000 Oops: 0002 [#1] CPU: 0 EIP: 0060:[] Not tainted VLI EFLAGS: 00010296 (2.6.16.5 #1) EIP is at xfs_dir2_leafn_lookup_int+0x3f0/0x4e0 eax: 00000002 ebx: 00000000 ecx: d9ac3cb4 edx: 000001b7 esi: dcb0c438 edi: 0000fc01 ebp: d6d1bdd0 esp: d9ac3b64 ds: 007b es: 007b ss: 0068 Process tar (pid: 7109, threadinfo=d9ac2000 task=c16fd590) Stack: <0>dcb0c438 d9ac3cb4 db229d7c c01ae3d0 dcb0c438 d9ac3cb4 db229d8c db229d68 c01e51aa c1710d20 d9ac3cb4 000001fc 000001fc 00000002 d9ac3cb4 00000000 c01b6403 db229d68 d9ac3c1c d9ac3bc0 00000246 d6d1bffc 00000003 03000000 Call Trace: [] xfs_da_node_lookup_int+0x250/0x320 [] kmem_zone_zalloc+0x2a/0x60 [] xfs_dir2_node_addname+0x43/0x9e0 [] xfs_da_buf_done+0x9f/0xc0 [] xfs_dir2_leaf_to_node+0x146/0x160 [] xfs_da_buf_done+0x9f/0xc0 [] xfs_dir2_leaf_addname+0x955/0x9a0 [] xfs_dir2_isleaf+0x1d/0x60 [] xfs_dir2_createname+0x139/0x140 [] xfs_trans_reserve+0x83/0x1e0 [] xfs_create+0x445/0x660 [] linvfs_mknod+0x14a/0x280 [] xfs_dir2_lookup+0xf7/0x120 [] vfs_create+0x79/0xa0 [] open_namei+0x4b5/0x560 [] xfs_inactive_free_eofblocks+0x1cb/0x220 [] do_filp_open+0x20/0x40 [] get_unused_fd+0x43/0xa0 [] do_sys_open+0x35/0x80 [] sys_open+0x13/0x20 [] syscall_call+0x7/0xb Code: 8b 5c 24 10 8b 4c 24 5c 89 99 38 01 00 00 c7 81 4c 01 00 00 44 32 44 58 8b 44 24 58 8b 54 24 20 89 10 b8 02 00 00 00 83 c4 3c 5b <20> a0 5d c3 8b 54 24 14 c7 83 4c 01 3c c0 46 32 00 10 e0 01 32 Segmentation fault From owner-linux-xfs@oss.sgi.com Mon Apr 17 20:51:39 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 17 Apr 2006 20:51:42 -0700 (PDT) Received: from PLUTO.corp.eastlink.ca (fw-n6.eastlink.ca [24.222.1.6]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k3I3pcgC031696 for ; Mon, 17 Apr 2006 20:51:38 -0700 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6603.0 MIME-Version: 1.0 Subject: Hellp Date: Mon, 17 Apr 2006 23:49:26 -0300 Message-ID: <6057BA56F69D5848B31A02DA7AB43EE80EFA21@PLUTO.corp.eastlink.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: Hellp Thread-index: AcZikrUTkxgqil2fRKW5hGI0NK1usA== From: "Roger Payne" To: Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit X-archive-position: 7646 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Roger.Payne@corp.eastlink.ca Precedence: bulk X-list: linux-xfs Status: O Content-Length: 489 Lines: 13 hello i was using a software called darma NAS OS and was using one drive that was 250G using xfs my computer failer after a power failer now i get LILO timestamp mismatch error it wont load i have another computer running ubuntu live from cd but cant seam to read the drive to get my info off it what can i do to mount teh HDD to any linus live cd to get my data darma will not support this software because =... i have no idea, your my last hope [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Mon Apr 17 21:02:59 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 17 Apr 2006 21:03:03 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k3I42vgC032604 for ; Mon, 17 Apr 2006 21:02:58 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA07744; Tue, 18 Apr 2006 14:02:49 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k3I42kJC1487852; Tue, 18 Apr 2006 14:02:46 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k3I42iju1487185; Tue, 18 Apr 2006 14:02:44 +1000 (EST) Date: Tue, 18 Apr 2006 14:02:43 +1000 From: Nathan Scott To: Roger Payne Cc: linux-xfs@oss.sgi.com Subject: Re: Hellp Message-ID: <20060418140243.A1485540@wobbly.melbourne.sgi.com> References: <6057BA56F69D5848B31A02DA7AB43EE80EFA21@PLUTO.corp.eastlink.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <6057BA56F69D5848B31A02DA7AB43EE80EFA21@PLUTO.corp.eastlink.ca>; from Roger.Payne@corp.eastlink.ca on Mon, Apr 17, 2006 at 11:49:26PM -0300 X-archive-position: 7647 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Status: O Content-Length: 748 Lines: 21 On Mon, Apr 17, 2006 at 11:49:26PM -0300, Roger Payne wrote: > hello i was using a software called darma NAS OS and was using one drive that was 250G using xfs > > my computer failer after a power failer now i get LILO timestamp mismatch error it wont load > > i have another computer running ubuntu live from cd but cant seam to read the drive to get my info off it > > what can i do to mount teh HDD to any linus live cd to get my data > > darma will not support this software because =... i have no idea, your my last hope > There should be a message in your system log as to why the mount attempt failed - send that here and people may be able to help. dmesg(8) will show it, or look in /var/log/messages (usually). cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Apr 18 14:22:36 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Apr 2006 14:22:40 -0700 (PDT) Received: from orca.ele.uri.edu (orca.ele.uri.edu [131.128.51.63]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k3ILMagC018279 for ; Tue, 18 Apr 2006 14:22:36 -0700 Received: from [192.168.1.4] (c-71-232-42-50.hsd1.ma.comcast.net [71.232.42.50]) (authenticated bits=0) by orca.ele.uri.edu (8.13.4/8.13.4) with ESMTP id k3IKJXLF030106 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 18 Apr 2006 16:19:36 -0400 Subject: disable preallocation From: Ming Zhang Reply-To: mingz@ele.uri.edu To: linux-xfs@oss.sgi.com Content-Type: text/plain Date: Tue, 18 Apr 2006 16:19:27 -0400 Message-Id: <1145391567.8601.183.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.52 on 131.128.51.63 X-archive-position: 7650 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mingz@ele.uri.edu Precedence: bulk X-list: linux-xfs Status: O Content-Length: 825 Lines: 22 Hi folks, I checked the archive and found some discussion about how to do pre-allocation. Interestingly, my questions is how to disable the pre-allocation. What I want is no matter how much data I write to XFS, as long as the size are multiple of file system block size, the fs will not preallocate some blocks for me. Because if fs does not do pre-allocation, later I read the block that no previous written data, it can give me all 0, otherwise it might be some strange data. I am dumping many huge sparse martrix to disk and if that whole block is full of 0, i will not write it to disk at all, so have a hole there. later when read back, i want to get all 0 as well. if fs do preallocation, then i probably will get some random data. I found that ext2/3 will do pre-allocation. will xfs do it or not? Thanks! Ming From owner-linux-xfs@oss.sgi.com Tue Apr 18 14:43:13 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Apr 2006 14:43:14 -0700 (PDT) Received: from astra.simleu.ro (astra.simleu.ro [80.97.18.177]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k3ILhCgC020377 for ; Tue, 18 Apr 2006 14:43:12 -0700 Received: from lapi.hq.k1024.org (84-74-6-159.dclient.hispeed.ch [84.74.6.159]) by astra.simleu.ro (Postfix) with ESMTP id 0008250; Wed, 19 Apr 2006 00:43:05 +0300 (EEST) Received: by lapi.hq.k1024.org (Postfix, from userid 4004) id 700871B94B3; Tue, 18 Apr 2006 23:42:52 +0200 (CEST) Date: Tue, 18 Apr 2006 23:42:52 +0200 From: Iustin Pop To: Ming Zhang Cc: linux-xfs@oss.sgi.com Subject: Re: disable preallocation Message-ID: <20060418214252.GA3300@lapi.hq.k1024.org> Mail-Followup-To: Ming Zhang , linux-xfs@oss.sgi.com References: <1145391567.8601.183.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1145391567.8601.183.camel@localhost.localdomain> X-Linux: This message was written on Linux X-Header: /usr/include gives great headers User-Agent: Mutt/1.5.11+cvs20060403 X-archive-position: 7651 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: iusty@k1024.org Precedence: bulk X-list: linux-xfs Status: O Content-Length: 1531 Lines: 44 On Tue, Apr 18, 2006 at 04:19:27PM -0400, Ming Zhang wrote: > Hi folks, > > I checked the archive and found some discussion about how to do > pre-allocation. Interestingly, my questions is how to disable the > pre-allocation. What I want is no matter how much data I write to XFS, > as long as the size are multiple of file system block size, the fs will > not preallocate some blocks for me. Because if fs does not do > pre-allocation, later I read the block that no previous written data, it > can give me all 0, otherwise it might be some strange data. > I am dumping many huge sparse martrix to disk and if that whole block is > full of 0, i will not write it to disk at all, so have a hole there. if you have a hole (i.e. you seek-ed over the block), any filesystem that supports holes will not allocate the block on disk, and will return 0 on read. if the filesystem does not support holes, it will write a block full of 0, I think. > later when read back, i want to get all 0 as well. if fs do > preallocation, then i probably will get some random data. No, as far as I know XFS will never return random data. Try it and see. > I found that ext2/3 will do pre-allocation. will xfs do it or not? Yes, but it will not return random data from disk, but 0. If you have python installed, try this simple program: #!/usr/bin/python f = file("test", "w+") f.seek(4096, 0) f.write("test") f.seek(0, 0) data = f.read(4096) if data != "\0" * 4096: print "bad!" else: print "ok" And see what you get. Regards, Iustin From owner-linux-xfs@oss.sgi.com Tue Apr 18 14:54:57 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Apr 2006 14:54:59 -0700 (PDT) Received: from orca.ele.uri.edu (orca.ele.uri.edu [131.128.51.63]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k3ILsugC021896 for ; Tue, 18 Apr 2006 14:54:57 -0700 Received: from [192.168.1.4] (c-71-232-42-50.hsd1.ma.comcast.net [71.232.42.50]) (authenticated bits=0) by orca.ele.uri.edu (8.13.4/8.13.4) with ESMTP id k3ILspI7027686 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 18 Apr 2006 17:54:51 -0400 Subject: Re: disable preallocation From: Ming Zhang Reply-To: mingz@ele.uri.edu To: Iustin Pop Cc: linux-xfs@oss.sgi.com In-Reply-To: <20060418214252.GA3300@lapi.hq.k1024.org> References: <1145391567.8601.183.camel@localhost.localdomain> <20060418214252.GA3300@lapi.hq.k1024.org> Content-Type: text/plain Date: Tue, 18 Apr 2006 17:54:45 -0400 Message-Id: <1145397286.8601.202.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.52 on 131.128.51.63 X-archive-position: 7652 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mingz@ele.uri.edu Precedence: bulk X-list: linux-xfs Status: O Content-Length: 2474 Lines: 69 On Tue, 2006-04-18 at 23:42 +0200, Iustin Pop wrote: > On Tue, Apr 18, 2006 at 04:19:27PM -0400, Ming Zhang wrote: > > Hi folks, > > > > I checked the archive and found some discussion about how to do > > pre-allocation. Interestingly, my questions is how to disable the > > pre-allocation. What I want is no matter how much data I write to XFS, > > as long as the size are multiple of file system block size, the fs will > > not preallocate some blocks for me. Because if fs does not do > > pre-allocation, later I read the block that no previous written data, it > > can give me all 0, otherwise it might be some strange data. > > > I am dumping many huge sparse martrix to disk and if that whole block is > > full of 0, i will not write it to disk at all, so have a hole there. > if you have a hole (i.e. you seek-ed over the block), any filesystem > that supports holes will not allocate the block on disk, and will return > 0 on read. if the filesystem does not support holes, it will write a > block full of 0, I think. yes, xfs supports file hole. so about ext2, how to understand this in "understanding linux kernel" "the file system preallocate disk data blocks to regular files before they are actually used. thus, when the file increase in size, several blocks are already reserved at physically adjacent positions, reducing file fragmentation" and also XFS has a preallocation ioctl control that can pre-allocate some space for a file. so if that space is allocated, what will happen on read these space with no previous write happen? it will be troublesome for xfs to judge that space is preserved, but not used. that is 2 independent lookup services and overheads. > > > later when read back, i want to get all 0 as well. if fs do > > preallocation, then i probably will get some random data. > No, as far as I know XFS will never return random data. Try it and see. > > > I found that ext2/3 will do pre-allocation. will xfs do it or not? > Yes, but it will not return random data from disk, but 0. > > If you have python installed, try this simple program: > > #!/usr/bin/python > > f = file("test", "w+") > f.seek(4096, 0) > f.write("test") > f.seek(0, 0) > data = f.read(4096) > if data != "\0" * 4096: > print "bad!" > else: > print "ok" i have a c program do this and so far return 0. but test can never mean 100%, right? only from xfs implementation logic can validate this. > > And see what you get. > > Regards, > Iustin From owner-linux-xfs@oss.sgi.com Tue Apr 18 15:36:08 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Apr 2006 15:36:09 -0700 (PDT) Received: from astra.simleu.ro (astra.simleu.ro [80.97.18.177]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k3IMa8gC025578 for ; Tue, 18 Apr 2006 15:36:08 -0700 Received: from lapi.hq.k1024.org (84-74-6-159.dclient.hispeed.ch [84.74.6.159]) by astra.simleu.ro (Postfix) with ESMTP id E0A3C50; Wed, 19 Apr 2006 01:36:06 +0300 (EEST) Received: by lapi.hq.k1024.org (Postfix, from userid 4004) id 922521B94B3; Wed, 19 Apr 2006 00:35:53 +0200 (CEST) Date: Wed, 19 Apr 2006 00:35:53 +0200 From: Iustin Pop To: Ming Zhang Cc: linux-xfs@oss.sgi.com Subject: Re: disable preallocation Message-ID: <20060418223553.GB3300@lapi.hq.k1024.org> Mail-Followup-To: Ming Zhang , linux-xfs@oss.sgi.com References: <1145391567.8601.183.camel@localhost.localdomain> <20060418214252.GA3300@lapi.hq.k1024.org> <1145397286.8601.202.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1145397286.8601.202.camel@localhost.localdomain> X-Linux: This message was written on Linux X-Header: /usr/include gives great headers User-Agent: Mutt/1.5.11+cvs20060403 X-archive-position: 7653 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: iusty@k1024.org Precedence: bulk X-list: linux-xfs Status: O Content-Length: 2076 Lines: 46 On Tue, Apr 18, 2006 at 05:54:45PM -0400, Ming Zhang wrote: > yes, xfs supports file hole. > > so about ext2, how to understand this in "understanding linux kernel" > > "the file system preallocate disk data blocks to regular files before > they are actually used. thus, when the file increase in size, several > blocks are already reserved at physically adjacent positions, reducing > file fragmentation" The key part here is "when the file increases in size". That only happens when you do a write(), not when you do a seek(). So if you do a seek(some-very-large-value), the file will not increase in size (on-disk). No space will be pre-allocated here. So that's why you will always get 0 on read. > and also XFS has a preallocation ioctl control that can pre-allocate > some space for a file. so if that space is allocated, what will happen > on read these space with no previous write happen? it will be > troublesome for xfs to judge that space is preserved, but not used. that > is 2 independent lookup services and overheads. This is different from the standard hole thing, and needs to be addressed by someone with proper knowledge of XFS. I tried to look at the source code, and found this comment in xfs_vnodeops.c: /* * XFS_IOC_RESVSP and XFS_IOC_UNRESVSP will reserve or unreserve * file space. * These calls do NOT zero the data space allocated to the file, * nor do they change the file size. * * XFS_IOC_ALLOCSP and XFS_IOC_FREESP will allocate and free file * space. * These calls cause the new file data to be zeroed and the file * size to be changed. */ It seems as soon as you do an XFS_IOC_ALLOCSP they will zero the data. However, I don't understand the difference between RESVSP and ALLOCSP... > i have a c program do this and so far return 0. but test can never mean > 100%, right? only from xfs implementation logic can validate this. Yes, and the fact that I think it has been said on list that XFS won't return unwritten data. Regards, Iustin From owner-linux-xfs@oss.sgi.com Tue Apr 18 16:06:42 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Apr 2006 16:06:44 -0700 (PDT) Received: from orca.ele.uri.edu (orca.ele.uri.edu [131.128.51.63]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k3IN6ggC029053 for ; Tue, 18 Apr 2006 16:06:42 -0700 Received: from [192.168.1.4] (c-71-232-42-50.hsd1.ma.comcast.net [71.232.42.50]) (authenticated bits=0) by orca.ele.uri.edu (8.13.4/8.13.4) with ESMTP id k3IN6bmr015220 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 18 Apr 2006 19:06:38 -0400 Subject: Re: disable preallocation From: Ming Zhang Reply-To: mingz@ele.uri.edu To: Iustin Pop Cc: linux-xfs@oss.sgi.com In-Reply-To: <20060418223553.GB3300@lapi.hq.k1024.org> References: <1145391567.8601.183.camel@localhost.localdomain> <20060418214252.GA3300@lapi.hq.k1024.org> <1145397286.8601.202.camel@localhost.localdomain> <20060418223553.GB3300@lapi.hq.k1024.org> Content-Type: text/plain Date: Tue, 18 Apr 2006 19:06:32 -0400 Message-Id: <1145401592.8601.211.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.52 on 131.128.51.63 X-archive-position: 7654 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mingz@ele.uri.edu Precedence: bulk X-list: linux-xfs Status: O Content-Length: 2621 Lines: 70 On Wed, 2006-04-19 at 00:35 +0200, Iustin Pop wrote: > On Tue, Apr 18, 2006 at 05:54:45PM -0400, Ming Zhang wrote: > > yes, xfs supports file hole. > > > > so about ext2, how to understand this in "understanding linux kernel" > > > > "the file system preallocate disk data blocks to regular files before > > they are actually used. thus, when the file increase in size, several > > blocks are already reserved at physically adjacent positions, reducing > > file fragmentation" > The key part here is "when the file increases in size". That only > happens when you do a write(), not when you do a seek(). ;) if that block is preserved already, what happen when there is a read on that LBA? read return 0 or read from preserved block? assume i write LBA 0 4KB and then ext2 preserve LBA 8-16 for this file, then a read on that will return what? > > So if you do a seek(some-very-large-value), the file will not increase > in size (on-disk). No space will be pre-allocated here. So that's why > you will always get 0 on read. agree. > > > and also XFS has a preallocation ioctl control that can pre-allocate > > some space for a file. so if that space is allocated, what will happen > > on read these space with no previous write happen? it will be > > troublesome for xfs to judge that space is preserved, but not used. that > > is 2 independent lookup services and overheads. > This is different from the standard hole thing, and needs to be > addressed by someone with proper knowledge of XFS. I tried to look at > the source code, and found this comment in xfs_vnodeops.c: > /* > * XFS_IOC_RESVSP and XFS_IOC_UNRESVSP will reserve or unreserve > * file space. > * These calls do NOT zero the data space allocated to the file, > * nor do they change the file size. > * > * XFS_IOC_ALLOCSP and XFS_IOC_FREESP will allocate and free file > * space. > * These calls cause the new file data to be zeroed and the file > * size to be changed. > */ > It seems as soon as you do an XFS_IOC_ALLOCSP they will zero the data. > However, I don't understand the difference between RESVSP and ALLOCSP... i think ALLOCSP is like xfs specifc/quicker way to get space allocated and zeroed. but what RESVSP do? > > > i have a c program do this and so far return 0. but test can never mean > > 100%, right? only from xfs implementation logic can validate this. > Yes, and the fact that I think it has been said on list that XFS won't > return unwritten data. thx. hope a xfs guy can confirm this. > > Regards, > Iustin From owner-linux-xfs@oss.sgi.com Tue Apr 18 16:29:35 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Apr 2006 16:29:36 -0700 (PDT) Received: from astra.simleu.ro (astra.simleu.ro [80.97.18.177]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k3INTZgC003162 for ; Tue, 18 Apr 2006 16:29:35 -0700 Received: from lapi.hq.k1024.org (84-74-6-159.dclient.hispeed.ch [84.74.6.159]) by astra.simleu.ro (Postfix) with ESMTP id 12F4350; Wed, 19 Apr 2006 02:29:34 +0300 (EEST) Received: by lapi.hq.k1024.org (Postfix, from userid 4004) id 8914A1B94B3; Wed, 19 Apr 2006 01:29:20 +0200 (CEST) Date: Wed, 19 Apr 2006 01:29:20 +0200 From: Iustin Pop To: Ming Zhang Cc: linux-xfs@oss.sgi.com Subject: Re: disable preallocation Message-ID: <20060418232920.GC3300@lapi.hq.k1024.org> Mail-Followup-To: Ming Zhang , linux-xfs@oss.sgi.com References: <1145391567.8601.183.camel@localhost.localdomain> <20060418214252.GA3300@lapi.hq.k1024.org> <1145397286.8601.202.camel@localhost.localdomain> <20060418223553.GB3300@lapi.hq.k1024.org> <1145401592.8601.211.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1145401592.8601.211.camel@localhost.localdomain> X-Linux: This message was written on Linux X-Header: /usr/include gives great headers User-Agent: Mutt/1.5.11+cvs20060403 X-archive-position: 7655 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: iusty@k1024.org Precedence: bulk X-list: linux-xfs Status: O Content-Length: 813 Lines: 20 On Tue, Apr 18, 2006 at 07:06:32PM -0400, Ming Zhang wrote: > ;) if that block is preserved already, what happen when there is a read > on that LBA? read return 0 or read from preserved block? > > assume i write LBA 0 4KB and then ext2 preserve LBA 8-16 for this file, > then a read on that will return what? So - you have a new file. You write 4KB at offset 0. ext2, behind your back, as an optimisation, will pre-allocate space the next three blocks (from 4097 to 16385). And now you try to read them. You will not get 0, you will not get random data, you will get EOF. Simple as that - preallocation is an optimisation which is transparent to the userspace. Since you did not write that data, you are not able to read it. Not as 0, not as random. At least, that's how I understand thing works :) Iustin From owner-linux-xfs@oss.sgi.com Tue Apr 18 17:01:36 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Apr 2006 17:01:39 -0700 (PDT) Received: from orca.ele.uri.edu (orca.ele.uri.edu [131.128.51.63]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k3J01ZgC007407 for ; Tue, 18 Apr 2006 17:01:35 -0700 Received: from [192.168.1.4] (c-71-232-42-50.hsd1.ma.comcast.net [71.232.42.50]) (authenticated bits=0) by orca.ele.uri.edu (8.13.4/8.13.4) with ESMTP id k3J01U5Q028337 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 18 Apr 2006 20:01:31 -0400 Subject: Re: disable preallocation From: Ming Zhang Reply-To: mingz@ele.uri.edu To: Iustin Pop Cc: linux-xfs@oss.sgi.com In-Reply-To: <20060418232920.GC3300@lapi.hq.k1024.org> References: <1145391567.8601.183.camel@localhost.localdomain> <20060418214252.GA3300@lapi.hq.k1024.org> <1145397286.8601.202.camel@localhost.localdomain> <20060418223553.GB3300@lapi.hq.k1024.org> <1145401592.8601.211.camel@localhost.localdomain> <20060418232920.GC3300@lapi.hq.k1024.org> Content-Type: text/plain Date: Tue, 18 Apr 2006 20:01:25 -0400 Message-Id: <1145404885.8601.214.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.52 on 131.128.51.63 X-archive-position: 7656 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mingz@ele.uri.edu Precedence: bulk X-list: linux-xfs Status: O Content-Length: 1050 Lines: 27 On Wed, 2006-04-19 at 01:29 +0200, Iustin Pop wrote: > On Tue, Apr 18, 2006 at 07:06:32PM -0400, Ming Zhang wrote: > > ;) if that block is preserved already, what happen when there is a read > > on that LBA? read return 0 or read from preserved block? > > > > assume i write LBA 0 4KB and then ext2 preserve LBA 8-16 for this file, > > then a read on that will return what? > > So - you have a new file. You write 4KB at offset 0. ext2, behind your > back, as an optimisation, will pre-allocate space the next three blocks > (from 4097 to 16385). > > And now you try to read them. You will not get 0, you will not get > random data, you will get EOF. Simple as that - preallocation is an > optimisation which is transparent to the userspace. Since you did not > write that data, you are not able to read it. Not as 0, not as random. so one step further. if i seek to somewhere like LBA=1000, and write some data, then come back and read this LBA 8, what i got? not EOF right? > > At least, that's how I understand thing works :) > > Iustin From owner-linux-xfs@oss.sgi.com Tue Apr 18 17:04:26 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Apr 2006 17:04:27 -0700 (PDT) Received: from astra.simleu.ro (astra.simleu.ro [80.97.18.177]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k3J04PgC007854 for ; Tue, 18 Apr 2006 17:04:25 -0700 Received: from lapi.hq.k1024.org (84-74-6-159.dclient.hispeed.ch [84.74.6.159]) by astra.simleu.ro (Postfix) with ESMTP id 3148050; Wed, 19 Apr 2006 03:04:24 +0300 (EEST) Received: by lapi.hq.k1024.org (Postfix, from userid 4004) id 07FC91B94B3; Wed, 19 Apr 2006 02:04:09 +0200 (CEST) Date: Wed, 19 Apr 2006 02:04:09 +0200 From: Iustin Pop To: Ming Zhang Cc: linux-xfs@oss.sgi.com Subject: Re: disable preallocation Message-ID: <20060419000409.GD3300@lapi.hq.k1024.org> Mail-Followup-To: Ming Zhang , linux-xfs@oss.sgi.com References: <1145391567.8601.183.camel@localhost.localdomain> <20060418214252.GA3300@lapi.hq.k1024.org> <1145397286.8601.202.camel@localhost.localdomain> <20060418223553.GB3300@lapi.hq.k1024.org> <1145401592.8601.211.camel@localhost.localdomain> <20060418232920.GC3300@lapi.hq.k1024.org> <1145404885.8601.214.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1145404885.8601.214.camel@localhost.localdomain> X-Linux: This message was written on Linux X-Header: /usr/include gives great headers User-Agent: Mutt/1.5.11+cvs20060403 X-archive-position: 7657 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: iusty@k1024.org Precedence: bulk X-list: linux-xfs Status: O Content-Length: 1346 Lines: 27 On Tue, Apr 18, 2006 at 08:01:25PM -0400, Ming Zhang wrote: > On Wed, 2006-04-19 at 01:29 +0200, Iustin Pop wrote: > > On Tue, Apr 18, 2006 at 07:06:32PM -0400, Ming Zhang wrote: > > > ;) if that block is preserved already, what happen when there is a read > > > on that LBA? read return 0 or read from preserved block? > > > > > > assume i write LBA 0 4KB and then ext2 preserve LBA 8-16 for this file, > > > then a read on that will return what? > > > > So - you have a new file. You write 4KB at offset 0. ext2, behind your > > back, as an optimisation, will pre-allocate space the next three blocks > > (from 4097 to 16385). > > > > And now you try to read them. You will not get 0, you will not get > > random data, you will get EOF. Simple as that - preallocation is an > > optimisation which is transparent to the userspace. Since you did not > > write that data, you are not able to read it. Not as 0, not as random. > > so one step further. if i seek to somewhere like LBA=1000, and write > some data, then come back and read this LBA 8, what i got? not EOF > right? No, ignoring rounding issues (holes occur only on entire blocks), there will be a hole between lba 8 and 1000. You will get 0 in that range. This is mandated by posix standards. I don't know how pre-allocation interacts with that, but you won't get random data. From owner-linux-xfs@oss.sgi.com Tue Apr 18 17:34:16 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Apr 2006 17:34:19 -0700 (PDT) Received: from orca.ele.uri.edu (orca.ele.uri.edu [131.128.51.63]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k3J0YGgC010436 for ; Tue, 18 Apr 2006 17:34:16 -0700 Received: from [192.168.1.4] (c-71-232-42-50.hsd1.ma.comcast.net [71.232.42.50]) (authenticated bits=0) by orca.ele.uri.edu (8.13.4/8.13.4) with ESMTP id k3J0YB3l005007 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 18 Apr 2006 20:34:12 -0400 Subject: Re: disable preallocation From: Ming Zhang Reply-To: mingz@ele.uri.edu To: Iustin Pop Cc: linux-xfs@oss.sgi.com In-Reply-To: <20060419000409.GD3300@lapi.hq.k1024.org> References: <1145391567.8601.183.camel@localhost.localdomain> <20060418214252.GA3300@lapi.hq.k1024.org> <1145397286.8601.202.camel@localhost.localdomain> <20060418223553.GB3300@lapi.hq.k1024.org> <1145401592.8601.211.camel@localhost.localdomain> <20060418232920.GC3300@lapi.hq.k1024.org> <1145404885.8601.214.camel@localhost.localdomain> <20060419000409.GD3300@lapi.hq.k1024.org> Content-Type: text/plain Date: Tue, 18 Apr 2006 20:34:05 -0400 Message-Id: <1145406846.8601.216.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.52 on 131.128.51.63 X-archive-position: 7658 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mingz@ele.uri.edu Precedence: bulk X-list: linux-xfs Status: O Content-Length: 1675 Lines: 35 On Wed, 2006-04-19 at 02:04 +0200, Iustin Pop wrote: > On Tue, Apr 18, 2006 at 08:01:25PM -0400, Ming Zhang wrote: > > On Wed, 2006-04-19 at 01:29 +0200, Iustin Pop wrote: > > > On Tue, Apr 18, 2006 at 07:06:32PM -0400, Ming Zhang wrote: > > > > ;) if that block is preserved already, what happen when there is a read > > > > on that LBA? read return 0 or read from preserved block? > > > > > > > > assume i write LBA 0 4KB and then ext2 preserve LBA 8-16 for this file, > > > > then a read on that will return what? > > > > > > So - you have a new file. You write 4KB at offset 0. ext2, behind your > > > back, as an optimisation, will pre-allocate space the next three blocks > > > (from 4097 to 16385). > > > > > > And now you try to read them. You will not get 0, you will not get > > > random data, you will get EOF. Simple as that - preallocation is an > > > optimisation which is transparent to the userspace. Since you did not > > > write that data, you are not able to read it. Not as 0, not as random. > > > > so one step further. if i seek to somewhere like LBA=1000, and write > > some data, then come back and read this LBA 8, what i got? not EOF > > right? > > No, ignoring rounding issues (holes occur only on entire blocks), there > will be a hole between lba 8 and 1000. You will get 0 in that range. > This is mandated by posix standards. I don't know how pre-allocation > interacts with that, but you won't get random data. so u mean even there are preallocated space, file system should be able to know that is a hole, and that space is preallocated, not prewritten, and it will return all 0? where is this posix standard i can check? thx ming From owner-linux-xfs@oss.sgi.com Tue Apr 18 17:51:45 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Apr 2006 17:51:51 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k3J0pigC012157 for ; Tue, 18 Apr 2006 17:51:45 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA24271; Wed, 19 Apr 2006 10:51:25 +1000 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k3J0paPR9497217; Wed, 19 Apr 2006 10:51:37 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k3J0pXuN9494801; Wed, 19 Apr 2006 10:51:33 +1000 (AEST) Date: Wed, 19 Apr 2006 10:51:33 +1000 From: David Chinner To: Ming Zhang Cc: Iustin Pop , linux-xfs@oss.sgi.com Subject: Re: disable preallocation Message-ID: <20060419005133.GF7574742@melbourne.sgi.com> References: <1145391567.8601.183.camel@localhost.localdomain> <20060418214252.GA3300@lapi.hq.k1024.org> <1145397286.8601.202.camel@localhost.localdomain> <20060418223553.GB3300@lapi.hq.k1024.org> <1145401592.8601.211.camel@localhost.localdomain> <20060418232920.GC3300@lapi.hq.k1024.org> <1145404885.8601.214.camel@localhost.localdomain> <20060419000409.GD3300@lapi.hq.k1024.org> <1145406846.8601.216.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1145406846.8601.216.camel@localhost.localdomain> User-Agent: Mutt/1.4.2.1i X-archive-position: 7659 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: linux-xfs Status: O Content-Length: 945 Lines: 26 On Tue, Apr 18, 2006 at 08:34:05PM -0400, Ming Zhang wrote: > > so u mean even there are preallocated space, file system should be able > to know that is a hole, and that space is preallocated, not prewritten, Preallocated space in XFS is not a hole - it is an unwritten extent. That is different from a hole in that the extent has been physically allocated, just marked as unwritten. Any attempt to read an unwritten extent will return lots of zero, just like reading from a hole. > and it will return all 0? where is this posix standard i can check? thx posix_fallocate()? Except it doesn't define what the contents of the area allocated must contain, and is not implemented on Linux in the filesystems. Instead, it is poorly emulated in glibc by writing chunks of zeros to disk and hence it returns zeros when the space is read before it is "written". Cheers, Dave. -- Dave Chinner R&D Software Enginner SGI Australian Software Group From owner-linux-xfs@oss.sgi.com Tue Apr 18 18:14:39 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Apr 2006 18:14:45 -0700 (PDT) Received: from orca.ele.uri.edu (orca.ele.uri.edu [131.128.51.63]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k3J1EcgC015178 for ; Tue, 18 Apr 2006 18:14:39 -0700 Received: from [192.168.1.4] (c-71-232-42-50.hsd1.ma.comcast.net [71.232.42.50]) (authenticated bits=0) by orca.ele.uri.edu (8.13.4/8.13.4) with ESMTP id k3J1EYEH016049 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 18 Apr 2006 21:14:34 -0400 Subject: Re: disable preallocation From: Ming Zhang Reply-To: mingz@ele.uri.edu To: David Chinner Cc: Iustin Pop , linux-xfs@oss.sgi.com In-Reply-To: <20060419005133.GF7574742@melbourne.sgi.com> References: <1145391567.8601.183.camel@localhost.localdomain> <20060418214252.GA3300@lapi.hq.k1024.org> <1145397286.8601.202.camel@localhost.localdomain> <20060418223553.GB3300@lapi.hq.k1024.org> <1145401592.8601.211.camel@localhost.localdomain> <20060418232920.GC3300@lapi.hq.k1024.org> <1145404885.8601.214.camel@localhost.localdomain> <20060419000409.GD3300@lapi.hq.k1024.org> <1145406846.8601.216.camel@localhost.localdomain> <20060419005133.GF7574742@melbourne.sgi.com> Content-Type: text/plain Date: Tue, 18 Apr 2006 21:14:28 -0400 Message-Id: <1145409269.8601.229.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.52 on 131.128.51.63 X-archive-position: 7660 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mingz@ele.uri.edu Precedence: bulk X-list: linux-xfs Status: O Content-Length: 1688 Lines: 46 On Wed, 2006-04-19 at 10:51 +1000, David Chinner wrote: > On Tue, Apr 18, 2006 at 08:34:05PM -0400, Ming Zhang wrote: > > > > so u mean even there are preallocated space, file system should be able > > to know that is a hole, and that space is preallocated, not prewritten, > > Preallocated space in XFS is not a hole - it is an unwritten extent. > That is different from a hole in that the extent has been physically > allocated, just marked as unwritten. Any attempt to read an unwritten > extent will return lots of zero, just like reading from a hole. are preallocated space and hole are exclusive? assume we do a preallocation from LBA 0 to 100 for a start-empty file, then write LBA 0-7 (assume 4KB block size), then write LBA 16-23. then about area lba 8-15 * it is a preallocated space, * it is also marked as unwritten, * is it a hole? i guess when xfs get a read request, it will check some metadata and find out whether it is a hole, or/and a space allocated but unwritten, then return 0 without any disk io. am i correct? could u point out the related code that doing this? if i do not use that ioctl to preallocate, will XFS do this automatically base on write pattern? > > > and it will return all 0? where is this posix standard i can check? thx > > posix_fallocate()? Except it doesn't define what the contents of > the area allocated must contain, and is not implemented on Linux > in the filesystems. Instead, it is poorly emulated in glibc > by writing chunks of zeros to disk and hence it returns zeros > when the space is read before it is "written". so this is why preallocate is recommended instead of doing a dd with zero out? > > Cheers, > > Dave. From owner-linux-xfs@oss.sgi.com Tue Apr 18 19:10:36 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 18 Apr 2006 19:10:42 -0700 (PDT) Received: from orca.ele.uri.edu (orca.ele.uri.edu [131.128.51.63]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k3J2AagC023044 for ; Tue, 18 Apr 2006 19:10:36 -0700 Received: from [192.168.1.4] (c-71-232-42-50.hsd1.ma.comcast.net [71.232.42.50]) (authenticated bits=0) by orca.ele.uri.edu (8.13.4/8.13.4) with ESMTP id k3J2ASWp030293 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 18 Apr 2006 22:10:31 -0400 Subject: Re: disable preallocation From: Ming Zhang Reply-To: mingz@ele.uri.edu To: David Chinner Cc: Iustin Pop , linux-xfs@oss.sgi.com In-Reply-To: <1145409269.8601.229.camel@localhost.localdomain> References: <1145391567.8601.183.camel@localhost.localdomain> <20060418214252.GA3300@lapi.hq.k1024.org> <1145397286.8601.202.camel@localhost.localdomain> <20060418223553.GB3300@lapi.hq.k1024.org> <1145401592.8601.211.camel@localhost.localdomain> <20060418232920.GC3300@lapi.hq.k1024.org> <1145404885.8601.214.camel@localhost.localdomain> <20060419000409.GD3300@lapi.hq.k1024.org> <1145406846.8601.216.camel@localhost.localdomain> <20060419005133.GF7574742@melbourne.sgi.com> <1145409269.8601.229.camel@localhost.localdomain> Content-Type: text/plain Date: Tue, 18 Apr 2006 22:10:23 -0400 Message-Id: <1145412624.25396.8.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.52 on 131.128.51.63 X-archive-position: 7661 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mingz@ele.uri.edu Precedence: bulk X-list: linux-xfs Status: O Content-Length: 2683 Lines: 71 i finished the reading on related section in ULK and i think i knew why my wrong understanding is wrong now. preallocation is not a persistent action that give the space to file persistently. in fact, it is preserved to that file and if there are write operations on that file, the prealloated space will possibly be used. if nothing happen on that file, file closed, or truncated, that preallocated is freed and maybe new preallocation will be given later. so if there is no write on certain offset, but a seek over it, it will form a hole in that area and no physical storage back it. hope i have a right understanding now. so a read will check inode and find out that no space available for that file block (corresponding disk lba is 0), then it knows it met a hole. could u tell me in which function in xfs code handle this? thanks Ming On Tue, 2006-04-18 at 21:14 -0400, Ming Zhang wrote: > On Wed, 2006-04-19 at 10:51 +1000, David Chinner wrote: > > On Tue, Apr 18, 2006 at 08:34:05PM -0400, Ming Zhang wrote: > > > > > > so u mean even there are preallocated space, file system should be able > > > to know that is a hole, and that space is preallocated, not prewritten, > > > > Preallocated space in XFS is not a hole - it is an unwritten extent. > > That is different from a hole in that the extent has been physically > > allocated, just marked as unwritten. Any attempt to read an unwritten > > extent will return lots of zero, just like reading from a hole. > > are preallocated space and hole are exclusive? > > assume we do a preallocation from LBA 0 to 100 for a start-empty file, > then write LBA 0-7 (assume 4KB block size), then write LBA 16-23. > then about area lba 8-15 > > * it is a preallocated space, > * it is also marked as unwritten, > * is it a hole? > > i guess when xfs get a read request, it will check some metadata and > find out whether it is a hole, or/and a space allocated but unwritten, > then return 0 without any disk io. am i correct? could u point out the > related code that doing this? > > if i do not use that ioctl to preallocate, will XFS do this > automatically base on write pattern? > > > > > > and it will return all 0? where is this posix standard i can check? thx > > > > posix_fallocate()? Except it doesn't define what the contents of > > the area allocated must contain, and is not implemented on Linux > > in the filesystems. Instead, it is poorly emulated in glibc > > by writing chunks of zeros to disk and hence it returns zeros > > when the space is read before it is "written". > > so this is why preallocate is recommended instead of doing a dd with > zero out? > > > > > Cheers, > > > > Dave. > From owner-linux-xfs@oss.sgi.com Wed Apr 19 08:59:07 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Apr 2006 08:59:12 -0700 (PDT) Received: from orca.ele.uri.edu (orca.ele.uri.edu [131.128.51.63]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k3JFx7gC018780 for ; Wed, 19 Apr 2006 08:59:07 -0700 Received: from [192.168.1.4] (c-71-232-42-50.hsd1.ma.comcast.net [71.232.42.50]) (authenticated bits=0) by orca.ele.uri.edu (8.13.4/8.13.4) with ESMTP id k3JFx2ZV018782 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 19 Apr 2006 11:59:03 -0400 Subject: [PATCH] trivial comment typo From: Ming Zhang Reply-To: mingz@ele.uri.edu To: xfs Content-Type: text/plain Date: Wed, 19 Apr 2006 11:58:57 -0400 Message-Id: <1145462337.8608.58.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.52 on 131.128.51.63 X-archive-position: 7662 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mingz@ele.uri.edu Precedence: bulk X-list: linux-xfs Status: O Content-Length: 727 Lines: 19 I think this comment has a small issue. bmv_count is give as input about how many bmap structures are available. Hope my understanding is correct. Signed-off-by Ming Zhang < mingz@ele.uri.edu> --- fs/xfs/xfs_fs.h.old 2006-04-19 11:52:47.000000000 -0400 +++ fs/xfs/xfs_fs.h 2006-04-19 11:53:52.000000000 -0400 @@ -72,7 +72,7 @@ /* * Structure for XFS_IOC_GETBMAP. * On input, fill in bmv_offset and bmv_length of the first structure - * to indicate the area of interest in the file, and bmv_entry with the + * to indicate the area of interest in the file, and bmv_count with the * number of array elements given. The first structure is updated on * return to give the offset and length for the next call. */ From owner-linux-xfs@oss.sgi.com Wed Apr 19 11:07:04 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 19 Apr 2006 11:07:11 -0700 (PDT) Received: from service.eng.exegy.net (68-191-203-42.static.stls.mo.charter.com [68.191.203.42]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k3JI73gC000652 for ; Wed, 19 Apr 2006 11:07:04 -0700 Received: from HANAFORD.eng.exegy.net (hanaford.eng.exegy.net [10.19.1.4]) by service.eng.exegy.net (8.13.1/8.13.1) with ESMTP id k3JGP9i3005169 for ; Wed, 19 Apr 2006 11:25:09 -0500 Received: from [10.19.4.98] ([10.19.4.98]) by HANAFORD.eng.exegy.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Apr 2006 11:25:09 -0500 Message-ID: <44466464.8050505@exegy.com> Date: Wed, 19 Apr 2006 11:25:08 -0500 From: Dave Lloyd User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Tuning for tons of small files? Content-Type: multipart/mixed; boundary="------------010906050205060103070509" X-OriginalArrivalTime: 19 Apr 2006 16:25:09.0170 (UTC) FILETIME=[D355D120:01C663CD] X-archive-position: 7663 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dlloyd@exegy.com Precedence: bulk X-list: linux-xfs Status: O Content-Length: 1863 Lines: 58 This is a multi-part message in MIME format. --------------010906050205060103070509 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I'm trying to tune XFS for faster read and write times when accessing tons of small files. System is 2.6.16 on a 2x2 core opteron. Options that the fs was made with: -f -d sunit=128,swidth=512,unwritten=1 -l version=2,sunit=128 Mount options: noatime,largeio,ihashsize=131072,attr2,barrier,allocsize=1073741824 This is across four hardware raid0 filesystems. Right now the read and write performance for larger files (~8gb) just kills ext3, perhaps between 2-4x faster in some instances, but ext3 kills xfs for accessing lots of small files. I've seen that tuning the logbufs up may help out, so that's my next step. I was also thinking that configuring the hardware raids as a 16 disk JBOD and making it a concat md volume may also distribute out the I/O as what I believe what is killing us here is seek time (of course, this is if md is smart and tells xfs how the dev is laid out so it can put the ags at the correct place to round-robin I/O to the different phys devs and I'm not so sure that md is that smart). Any other ideas to tune XFS for better performance when accessing tons of small files? -- Dave Lloyd Test Engineer, Exegy, Inc. 314.450.5342 dlloyd@exegy.com --------------010906050205060103070509 Content-Type: text/x-vcard; charset=utf-8; name="dlloyd.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="dlloyd.vcf" begin:vcard fn:Dave Lloyd n:Lloyd;Dave org:Exegy, INC adr:Suite 300;;3668 S. Geyer Road;St. Louis;MO;63127;USA email;internet:dlloyd@exegy.com title:Test Engineer tel;work:314.450.5342 x-mozilla-html:FALSE url:http://www.exegy.com/ version:2.1 end:vcard --------------010906050205060103070509-- From owner-linux-xfs@oss.sgi.com Fri Apr 21 00:49:33 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 21 Apr 2006 00:49:37 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.13.6/8.12.10/SuSE Linux 0.7) with ESMTP id k3L7nWCK019202 for ; Fri, 21 Apr 2006 00:49:32 -0700 Received: from [10.0.0.4] (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 04EE118009C14; Thu, 20 Apr 2006 23:14:16 -0500 (CDT) Message-ID: <44485C17.5070505@sandeen.net> Date: Thu, 20 Apr 2006 23:14:15 -0500 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mingz@ele.uri.edu Cc: David Chinner , Iustin Pop , linux-xfs@oss.sgi.com Subject: Re: disable preallocation References: <1145391567.8601.183.camel@localhost.localdomain> <20060418214252.GA3300@lapi.hq.k1024.org> <1145397286.8601.202.camel@localhost.localdomain> <20060418223553.GB3300@lapi.hq.k1024.org> <1145401592.8601.211.camel@localhost.localdomain> <20060418232920.GC3300@lapi.hq.k1024.org> <1145404885.8601.214.camel@localhost.localdomain> <20060419000409.GD3300@lapi.hq.k1024.org> <1145406846.8601.216.camel@localhost.localdomain> <20060419005133.GF7574742@melbourne.sgi.com> <1145409269.8601.229.camel@localhost.localdomain> <1145412624.25396.8.camel@localhost.localdomain> In-Reply-To: <1145412624.25396.8.camel@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7664 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: linux-xfs Status: O Content-Length: 1253 Lines: 29 Ming, the short answer to your original question is that xfs will not give you back any data that was not explicitly written to the file. Feel free to seek, allocate, write, truncate, open, close etc to your heart's content. Do a read, and you will get back either 0s, or data that you wrote. Run fsx over xfs for a while to convince yourself of this. -Eric Ming Zhang wrote: > i finished the reading on related section in ULK and i think i knew why > my wrong understanding is wrong now. > > preallocation is not a persistent action that give the space to file > persistently. in fact, it is preserved to that file and if there are > write operations on that file, the prealloated space will possibly be > used. if nothing happen on that file, file closed, or truncated, that > preallocated is freed and maybe new preallocation will be given later. > > so if there is no write on certain offset, but a seek over it, it will > form a hole in that area and no physical storage back it. > > hope i have a right understanding now. > > so a read will check inode and find out that no space available for that > file block (corresponding disk lba is 0), then it knows it met a hole. > could u tell me in which function in xfs code handle this? From owner-linux-xfs@oss.sgi.com Sat Apr 22 15:10:40 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 22 Apr 2006 15:10:42 -0700 (PDT) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by oss.sgi.com (8.13.6/8.12.10/SuSE Linux 0.7) with ESMTP id k3MMAafS019570 for ; Sat, 22 Apr 2006 15:10:40 -0700 Received: from root by ciao.gmane.org with local (Exim 4.43) id 1FXOoo-0003Dm-Mg for linux-xfs@oss.sgi.com; Sat, 22 Apr 2006 22:35:02 +0200 Received: from 210.120.111.45 ([210.120.111.45]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 22 Apr 2006 22:35:02 +0200 Received: from kubisuro by 210.120.111.45 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 22 Apr 2006 22:35:02 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: linux-xfs@oss.sgi.com From: "Ryan M." Subject: "XFS internal error xfs_ialloc_read_agi" Date: Sun, 23 Apr 2006 05:25:06 +0900 Message-ID: Reply-To: kubisuro@att.net Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 210.120.111.45 User-Agent: Thunderbird 1.5 (X11/20051201) X-archive-position: 7667 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kubisuro@att.net Precedence: bulk X-list: linux-xfs Status: O Content-Length: 4157 Lines: 65 Hello, I've been using XFS for a few years; this is the first operational problem I've ran into. I'm using ix86 2.6.16-ck4 (includes 2.6.16.2), I'd be extremely surprised if the -ck patch had anything to do with this, but I understand anything is up for suspicion. Realized this failure today in /var/log/syslog after I noticed a lot of drop outs from my media player. This seemed to have begun 16 April. Apr 22 13:10:34 core kernel: Filesystem "hdc1": XFS internal error xfs_ialloc_read_agi at line 1357 of file fs/xfs/xfs_ialloc.c. Caller 0xf09f5e1b Apr 22 13:10:34 core kernel: [] xfs_ialloc_read_agi+0xaa/0xef [xfs] Apr 22 13:10:34 core kernel: [] xfs_ialloc_ag_select+0x105/0x25b [xfs] Apr 22 13:10:34 core last message repeated 2 times Apr 22 13:10:34 core kernel: [] xfs_dialloc+0x48/0x891 [xfs] Apr 22 13:10:34 core kernel: [] kmem_getpages+0x75/0x8d Apr 22 13:10:34 core kernel: [] xlog_grant_log_space+0xe8/0x208 [xfs] Apr 22 13:10:34 core kernel: [] xlog_grant_log_space+0x1cd/0x208 [xfs] Apr 22 13:10:34 core kernel: [] xfs_ialloc+0x44/0x444 [xfs] Apr 22 13:10:34 core kernel: [] xlog_grant_push_ail+0x2b/0xf0 [xfs] Apr 22 13:10:34 core kernel: [] xfs_dir_ialloc+0x5e/0x21b [xfs] Apr 22 13:10:34 core kernel: [] xfs_trans_reserve+0xa9/0x16d [xfs] Apr 22 13:10:34 core kernel: [] xfs_mkdir+0x2c5/0x554 [xfs] Apr 22 13:10:34 core kernel: [] xfs_buf_free+0x79/0x7e [xfs] Apr 22 13:10:34 core kernel: [] xfs_da_brelse+0x6e/0x90 [xfs] Apr 22 13:10:34 core kernel: [] linvfs_mknod+0x154/0x278 [xfs] Apr 22 13:10:34 core kernel: [] __d_lookup+0xa2/0xc5 Apr 22 13:10:34 core kernel: [] xfs_dir2_leaf_lookup+0x1f/0xcf [xfs] Apr 22 13:10:34 core kernel: [] xfs_dir2_isleaf+0x1b/0x56 [xfs] Apr 22 13:10:34 core kernel: [] xfs_dir2_lookup+0xda/0x110 [xfs] Apr 22 13:10:34 core kernel: [] __journal_file_buffer+0xe1/0x1c0 Apr 22 13:10:34 core kernel: [] xfs_dir_lookup_int+0x2d/0xab [xfs] Apr 22 13:10:34 core kernel: [] linvfs_lookup+0x51/0x69 [xfs] Apr 22 13:10:34 core kernel: [] linvfs_mkdir+0x17/0x1b [xfs] Apr 22 13:10:34 core kernel: [] vfs_mkdir+0x58/0x8f Apr 22 13:10:34 core kernel: [] sys_mkdirat+0x87/0xc1 Apr 22 13:10:34 core kernel: [] sys_mkdir+0xf/0x13 Apr 22 13:10:34 core kernel: [] syscall_call+0x7/0xb It seems this would happen every time XFS hit a file / directory with an inconsistency -- and that happened to be a great number. Interestingly, it did not affect the most recently written files. The bug really hated Tom Waits. An example of what xfs_repair did follows; I apologize that I didn't manage to save the output of xfs_check. The console buffer was set too low :-( clearing inode number in entry at offset 1304... entry "Inspiral_Carpets_-_L01_Real_Thing.flac" at block 0 offset 112 in directory inode 165 references non-existent inode 22864296 ... rebuilding directory inode 132 - traversal finished ... - traversing all unattached subtrees ... rebuilding directory inode 135759756 ... Phase 7 - verify and correct link counts... resetting inode 128 nlinks from 140 to 120 XFS did an admirable job repairing the underlying file system, but it emptied my hdd pretty well. Fortunately I have redundant storage on an external USB drive. It uses XFS as well, and checks fine. Is this journal corruption? `badblocks` did not find any media problems. "smart" did not find any media problems. During r[e]sync, no errors were logged by Smart or xfs. All things considered, xfs did a remarkable job not causing system interruptions! xfs_repair also did a decent job saving what it could in lost+found (presumably any file that managed to be separated from it's errant parent directory). If I didn't have rsync and a backup medium, I'd have been terribly happy with that. It saved 11gb of data. Anyway, hopefully the errors above might help to find a bug. Thanks for all that you do, Ryan Mikulovsky From owner-linux-xfs@oss.sgi.com Sun Apr 23 05:19:05 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 23 Apr 2006 05:19:08 -0700 (PDT) Received: from dynamicweb.hu (ns.dynamicweb.hu [195.228.155.139]) by oss.sgi.com (8.13.6/8.12.10/SuSE Linux 0.7) with ESMTP id k3NCJ2W1018714 for ; Sun, 23 Apr 2006 05:19:04 -0700 Received: from dcccs (53d827c6.adsl.enternet.hu [83.216.39.198]) by dynamicweb.hu (8.12.8/8.12.8) with SMTP id k3NAqxcK030286 for ; Sun, 23 Apr 2006 12:53:00 +0200 Message-ID: <00c301c666c4$813f72c0$1600a8c0@dcccs> From: "JaniD++" To: Subject: xfs_growfs - question Date: Sun, 23 Apr 2006 12:55:56 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-archive-position: 7672 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: djani22@dynamicweb.hu Precedence: bulk X-list: linux-xfs Status: RO Content-Length: 898 Lines: 31 Hello, list, I plan to use xfs_growfs to grow my 8 TB fs to 13 TB. Is there a way to "save" some information during the xfs_growfs works to be able to "undo" the operation if it fails? I will reach some limitation about 32/64 bit , and >2TB devices. My 8TB fs is full, and contains a lot of important data, what i cannot backup. It is safe to run it with strace? What is the best and recommended way? Another theme: I have a frequent , but not exactly reproducible bug what causes this: Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - ensuring existence of lost+found directory - traversing filesystem starting at / ... rebuilding directory inode 128 - traversal finished ... Always the #128, on all of my xfs filesystems! Kernel 2.6.15.7, but this was found on previous versions too. Thanks a lot! Janos From owner-linux-xfs@oss.sgi.com Mon Apr 24 04:20:38 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 24 Apr 2006 04:20:43 -0700 (PDT) Received: from dynamicweb.hu (ns.dynamicweb.hu [195.228.155.139]) by oss.sgi.com (8.13.6/8.12.10/SuSE Linux 0.7) with ESMTP id k3OBKYrB031318 for ; Mon, 24 Apr 2006 04:20:37 -0700 Received: from dcccs (3e44ad23.adsl.enternet.hu [62.68.173.35]) by dynamicweb.hu (8.12.8/8.12.8) with SMTP id k3OBBVcK016465; Mon, 24 Apr 2006 13:11:31 +0200 Message-ID: <01aa01c66790$422d1480$1600a8c0@dcccs> From: "JaniD++" To: "Nathan Scott" Cc: References: <00c301c666c4$813f72c0$1600a8c0@dcccs> <20060424085255.B1655705@wobbly.melbourne.sgi.com> Subject: Re: xfs_growfs - question Date: Mon, 24 Apr 2006 13:14:26 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-archive-position: 7676 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: djani22@dynamicweb.hu Precedence: bulk X-list: linux-xfs Status: O Content-Length: 1652 Lines: 65 ----- Original Message ----- From: "Nathan Scott" To: "JaniD++" Cc: Sent: Monday, April 24, 2006 12:52 AM Subject: Re: xfs_growfs - question > On Sun, Apr 23, 2006 at 12:55:56PM +0200, JaniD++ wrote: > > Hello, list, > > > > I plan to use xfs_growfs to grow my 8 TB fs to 13 TB. > > Is there a way to "save" some information during the xfs_growfs works to be > > able to "undo" the operation if it fails? > > xfsdump? ;) No, there is no growfs-specific undo. > > > I will reach some limitation about 32/64 bit , and >2TB devices. > > My 8TB fs is full, and contains a lot of important data, what i cannot > > backup. > > Is using multiple filesystems an option? What do you mean exactly? This is one big fs from 4x 3.3 TB nbd device, wich is currently limited to 4x 2.0 TB I need this space in one mount point. (This is a free web storage, with dynamically growing, shrinkink, and moving users.) > > > It is safe to run it with strace? > > Yes. > > > Phase 6 - check inode connectivity... > > - resetting contents of realtime bitmap and summary inodes > > - ensuring existence of lost+found directory > > - traversing filesystem starting at / ... > > rebuilding directory inode 128 > > - traversal finished ... > > > > Always the #128, on all of my xfs filesystems! > > 128 is likely to be the root inode, and what you're seeing there is > the "lost+found" directory being re-linked in. If you rmdir it in- > between xfs_repair runs, this message should disappear. Well, ok. :-) I will check it. Thanks, Janos > > cheers. > > -- > Nathan From owner-linux-xfs@oss.sgi.com Tue Apr 25 02:49:21 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Apr 2006 02:49:28 -0700 (PDT) Received: from ns37.alterhosting.net (ns37.alterhosting.net [207.44.220.104]) by oss.sgi.com (8.13.6/8.12.10/SuSE Linux 0.7) with ESMTP id k3P9nKUm027689 for ; Tue, 25 Apr 2006 02:49:21 -0700 Received: (qmail 8043 invoked by uid 48); 25 Apr 2006 04:31:30 -0400 Cc: recipient list not shown: ; Received: from 82.169.148.35 (SquirrelMail authenticated user info@hamiltonhammer.net) by hamiltonhammer.net with HTTP; Tue, 25 Apr 2006 04:31:30 -0400 (EDT) Message-ID: <23554.82.169.148.35.1145953890.squirrel@hamiltonhammer.net> Date: Tue, 25 Apr 2006 04:31:30 -0400 (EDT) Subject: Prize Award Message - Notification From: info@hamiltonhammer.net User-Agent: SquirrelMail/1.4.4-4.rhel3.art MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 1 (Highest) Importance: High X-archive-position: 7678 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: info@hamiltonhammer.net Precedence: bulk X-list: linux-xfs Content-Length: 2623 Lines: 66 Prize Award Message - Notification Customer Service Unit Tsoft Sweepstakes Ltd. Frisians Bay Centrum 7721NL PL34. Ref No: TSL-885159-11/06. Serial No: 119244 Date: APRIL 25th, 2006. Dear Sir/Madam, SWEEPSTAKE PRIZE AWARD INFORMATION. This email message is to personally notify you of the result of our Tsoft Internet Sweepstakes program that was conducted on the 24th day of April 2006 and that this email address which was attached to our Serial Numbers from 119244 and selected by our Internet E-games Selection System (IESS) has won the recipient of this email address our promotional sweepstakes in the general prize category. You have now been selected among the winners to claim a total payment sum of USD$980,000:00 (NINE HUNDRED AND EIGHTY THOUSAND US DOLLARS ONLY) each as attaches to payment file Ref No: TSL-885159-11/06. We are aware of the surprises that do follow such a notification message based on the fact that you have not purchase a lottery ticket any time, but be informed here that! it was a promotional program from our software companies with the major aim of introducing our sweepstake services and at the same time promoting the benefit of the Internet usage. All email addresses that were use for this program were extracted from the internet through our associates. These approved funds can only be claimed by contacting our assign payment house. Due to the nature of this program, we ask that you keep a copy of this email message safe until your claim has been processed and collected from out payment house; as this is the only security measure that has been put in place to save guild each winner interest. You can begin your claim now by contacting the Payment house (ECTB Finance & Logistics) on email address: info@eurocreditbureau.com with your Complete Names, Postal (Resident) Address, Telephone and Fax Numbers, Occupation, Reference Numbers and the amount approved (Won) for the processing of this claim. A! ll funds not applied for after the 8th day of May 2006 will be return back to us. Felicitations as we do expect you to make better use of these funds. Sincerely Yours, Brenda Hopkins Sr. Customer Services Unit. *************************************************************************** Note: In accordance with the Tsoft Sweepstakes policy and regulations, this notification is dispatched directly to the prize Winners only. If you are not the rightful recipient and feel you have received this message by error, kindly destroy any copy in your possession for you are not authorized to read, print, retain or disseminate any part of it. From owner-linux-xfs@oss.sgi.com Tue Apr 25 13:03:46 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Apr 2006 13:03:54 -0700 (PDT) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.18.13]) by oss.sgi.com (8.13.6/8.12.10/SuSE Linux 0.7) with ESMTP id k3PK3iP6003584 for ; Tue, 25 Apr 2006 13:03:46 -0700 Received: (qmail 23047 invoked from network); 25 Apr 2006 18:58:13 -0000 Received: from unknown (HELO box.local) (524231@[84.155.168.135]) (envelope-sender ) by smtprelay01.ispgateway.de (qmail-ldap-1.03) with SMTP for ; 25 Apr 2006 18:58:13 -0000 Received: from pcgeiger (pcgeiger [10.10.10.5]) by box.local (Postfix) with ESMTP id 0B314580D691 for ; Tue, 25 Apr 2006 20:58:12 +0200 (CEST) From: "Michael Geiger" To: Subject: Corrupt filesystem in 2.6.16, xfs_repair finds no error Date: Tue, 25 Apr 2006 20:58:13 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-archive-position: 7679 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: gege@mgeiger.de Precedence: bulk X-list: linux-xfs Content-Length: 2411 Lines: 54 Hello, my linux box reports a xfs filesystem corruption, and I'm not able to repair it. When I'm running xfs_repair (version 2.6.36 on SuSE 10.0 rescue system) I get no problems reported, only "rebuilding directory inode 128" on phase 6. Here's my problem: Apr 24 19:46:32 box kernel: Filesystem "hda7": corrupt dinode 92529896, extent total = 67, nblocks = 1. Unmount and run xfs_repair. Apr 24 19:46:32 box kernel: 0x0: 49 4e 81 a4 01 02 00 01 00 00 00 00 00 00 00 00 Apr 24 19:46:32 box kernel: Filesystem "hda7": XFS internal error xfs_iformat(1) at line 415 of file fs/xfs/xfs_inode.c. Caller 0xc01d8bae Apr 24 19:46:32 box kernel: [] xfs_corruption_error+0xd1/0x100 Apr 24 19:46:32 box kernel: [] xfs_iget+0x15e/0x594 Apr 24 19:46:32 box kernel: [] xfs_fs_vcmn_err+0x55/0x90 Apr 24 19:46:32 box kernel: [] xfs_fs_vcmn_err+0x5f/0x90 Apr 24 19:46:32 box kernel: [] xfs_fs_cmn_err+0x1b/0x20 Apr 24 19:46:32 box kernel: [] xfs_iread+0x5e8/0x6a0 Apr 24 19:46:32 box kernel: [] xfs_iget+0x15e/0x594 Apr 24 19:46:32 box kernel: [] xfs_iget+0x15e/0x594 Apr 24 19:46:32 box kernel: [] xfs_dir_lookup_int+0x66/0xe0 Apr 24 19:46:32 box kernel: [] xfs_lookup+0x4e/0x80 Apr 24 19:46:32 box kernel: [] xfs_access+0x30/0x40 Apr 24 19:46:32 box kernel: [] linvfs_lookup+0x36/0x80 Apr 24 19:46:32 box kernel: [] do_lookup+0x11f/0x150 Apr 24 19:46:32 box kernel: [] __link_path_walk+0x759/0xd30 Apr 24 19:46:32 box kernel: [] link_path_walk+0x64/0xd0 Apr 24 19:46:32 box kernel: [] mntput_no_expire+0x14/0x60 Apr 24 19:46:32 box kernel: [] link_path_walk+0x45/0xd0 Apr 24 19:46:32 box kernel: [] do_path_lookup+0xd7/0x240 Apr 24 19:46:32 box kernel: [] getname+0x54/0xe0 Apr 24 19:46:32 box kernel: [] __user_walk_fd+0x28/0x40 Apr 24 19:46:32 box kernel: [] vfs_lstat_fd+0x17/0x50 Apr 24 19:46:32 box kernel: [] vfs_lstat+0x11/0x20 Apr 24 19:46:32 box kernel: [] sys_lstat64+0x11/0x30 Apr 24 19:46:32 box kernel: [] syscall_call+0x7/0xb (repeated many times) The system is SuSE 10.0 with kernel 2.6.16.1. I don't have high load on it, so the problem is only reported every 1-5 days. Could someone please help me? How can I fix it? Thanx Michael From owner-linux-xfs@oss.sgi.com Tue Apr 25 13:31:45 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Apr 2006 13:31:53 -0700 (PDT) Received: from iolanthe.rowland.org ([192.131.102.54]) by oss.sgi.com (8.13.6/8.12.10/SuSE Linux 0.7) with SMTP id k3PKVhZp006175 for ; Tue, 25 Apr 2006 13:31:45 -0700 Received: (qmail 1016 invoked by uid 2102); 25 Apr 2006 16:26:12 -0400 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 25 Apr 2006 16:26:12 -0400 Date: Tue, 25 Apr 2006 16:26:12 -0400 (EDT) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: Linus Torvalds cc: Chandra Seetharaman , , , , , Subject: Re: [PATCH 3/3] Assert notifier_block and notifier_call are not in init section In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 7680 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: stern@rowland.harvard.edu Precedence: bulk X-list: linux-xfs Content-Length: 640 Lines: 16 On Tue, 25 Apr 2006, Linus Torvalds wrote: > > 2) Unrelated to this patch: If the _code_ section is never reallocated > > or reused, what is the purpose of putting _code_ in the init section ? > > Only to make sure that the init calls are called in order ? > > No, the code section is re-used, it's just never re-used for any other > code (since we don't generate code on the fly). So if you pass in a > function pointer, you know that if it's in the init section, it means that > init-code that was discarded. What about loadable modules? Is their code never loaded into memory that used to be part of an init section? Alan Stern From owner-linux-xfs@oss.sgi.com Tue Apr 25 21:30:13 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Apr 2006 21:30:21 -0700 (PDT) Received: from kungfu.dreamhost.com (kungfu.dreamhost.com [66.33.216.126]) by oss.sgi.com (8.13.6/8.12.10/SuSE Linux 0.7) with ESMTP id k3Q4UBJd018660 for ; Tue, 25 Apr 2006 21:30:12 -0700 Received: from skewer.dreamhost.com (skewer.dreamhost.com [64.111.107.13]) by kungfu.dreamhost.com (Postfix) with ESMTP id 533461F2B46 for ; Tue, 25 Apr 2006 19:17:51 -0700 (PDT) Received: from alcatraz.bla.cl (pc-27-66-104-200.cm.vtr.net [200.104.66.27]) by skewer.dreamhost.com (Postfix) with ESMTP id 4CC4F7C3B8 for ; Tue, 25 Apr 2006 19:17:46 -0700 (PDT) Received: by alcatraz.bla.cl (Postfix, from userid 1000) id 857CAC0867A; Tue, 25 Apr 2006 22:17:43 -0400 (CLT) Date: Tue, 25 Apr 2006 22:17:43 -0400 From: Yonathan Dossow To: linux-xfs@oss.sgi.com Subject: xfs bug Message-ID: <20060426021743.GA3165@alcatraz.bla.cl> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.4.2.1i X-archive-position: 7681 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ydossow@bla.cl Precedence: bulk X-list: linux-xfs Content-Length: 2911 Lines: 95 hi. i do a xfs_repair /dev/hda6, and i get the following: -- begin error -- 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 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 correcting nblocks for inode 48838848, was 0 - counted 1 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - clear lost+found (if it exists) ... - clearing existing "lost+found" inode - deleting existing "lost+found" entry - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 data fork in regular inode 48838848 claims used block 3052432 correcting nblocks for inode 48838848, was 1 - counted 0 - agno = 6 - agno = 7 - agno = 8 - 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 - ensuring existence of lost+found directory - traversing filesystem starting at / ... corrupt dinode 48838848, extent total = 1, nblocks = 0. This is a bug. Please report it to linux-xfs@oss.sgi.com. fatal error -- couldn't map inode 48838848, err = 990 -- end error -- mi partition table: [root@alcatraz ~]# fdisk -l /dev/hda Disk /dev/hda: 120.0 GB, 120034123776 bytes 255 heads, 63 sectors/track, 14593 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/hda1 1 2867 23029146 83 Linux /dev/hda2 2868 4779 15358140 83 Linux /dev/hda3 4780 14593 78830955 f W95 Ext'd (LBA) /dev/hda5 4780 4841 497983+ 82 Linux swap / Solaris /dev/hda6 4842 8275 27583573+ 83 Linux /dev/hda7 8276 10825 20482843+ 83 Linux /dev/hda8 10826 14593 30266428+ 83 Linux what can i do?. thanks. -- Yonathan H. Dossow Acuña http://kronin.bla.cl Estudiante Ingenieria Civil Informatica Universidad Tecnica Federico Santa Maria Valparaiso, Chile From owner-linux-xfs@oss.sgi.com Tue Apr 25 22:00:42 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 25 Apr 2006 22:00:48 -0700 (PDT) Received: from amanpulo.hosting.qsr.com.ph (amanpulo.hosting.qsr.com.ph [64.34.170.22]) by oss.sgi.com (8.13.6/8.12.10/SuSE Linux 0.7) with ESMTP id k3Q50eN6021240 for ; Tue, 25 Apr 2006 22:00:41 -0700 Received: from localhost (localhost [127.0.0.1]) by amanpulo.hosting.qsr.com.ph (Postfix) with ESMTP id BA7E4C078D49 for ; Wed, 26 Apr 2006 12:55:08 +0800 (PHT) Received: from musang.free.net.ph (amanpulo.hosting.qsr.com.ph [64.34.170.22]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by amanpulo.hosting.qsr.com.ph (Postfix) with ESMTP id 26291C03F958 for ; Wed, 26 Apr 2006 12:54:54 +0800 (PHT) Received: by musang.free.net.ph (Postfix, from userid 1000) id 893A6207C3CF; Wed, 26 Apr 2006 12:54:20 +0800 (PHT) Date: Wed, 26 Apr 2006 12:54:20 +0800 From: Federico Sevilla III To: linux-xfs@oss.sgi.com Subject: Re: xfs bug Message-ID: <20060426045420.GJ2913@free.net.ph> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20060426021743.GA3165@alcatraz.bla.cl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060426021743.GA3165@alcatraz.bla.cl> X-Personal-URL: http://jijo.free.net.ph User-Agent: Mutt/1.5.11+cvs20060126 X-archive-position: 7682 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jijo@free.net.ph Precedence: bulk X-list: linux-xfs Content-Length: 1046 Lines: 31 On Tue, Apr 25, 2006 at 10:17:43PM -0400, Yonathan Dossow wrote: > corrupt dinode 48838848, extent total = 1, nblocks = 0. This is a bug. > Please report it to linux-xfs@oss.sgi.com. > > fatal error -- couldn't map inode 48838848, err = 990 This looks familiar. I had one machine that for the life of me I couldn't figure out why every time it would shut down, one or two files would have this problem. I had no recourse but to use xfs_db to manually remove the files, then use xfs_repair again to fix the filesystem. It was never fixed, despite best efforts on my end to report the problem to the best of my knowledge. It's not a common bug, though, and now that the particular machine has been retired I don't have an active system with this problem. You can search the archives[1] for my reports, with the 990 error as keyword. [1] http://archives.free.net.ph/list/linux-xfs.html Cheers! --> Jijo -- Federico Vicente C. Sevilla III Information Technology Consultant Q Software Research Corporation Website: http://jijo.free.net.ph From owner-linux-xfs@oss.sgi.com Wed Apr 26 08:55:22 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 26 Apr 2006 08:55:27 -0700 (PDT) Received: from iolanthe.rowland.org ([192.131.102.54]) by oss.sgi.com (8.13.6/8.12.10/SuSE Linux 0.7) with SMTP id k3QFtIre030600 for ; Wed, 26 Apr 2006 08:55:21 -0700 Received: (qmail 6404 invoked by uid 2102); 26 Apr 2006 11:49:46 -0400 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 26 Apr 2006 11:49:46 -0400 Date: Wed, 26 Apr 2006 11:49:46 -0400 (EDT) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: Andrew Morton cc: sekharan@us.ibm.com, , , , , , Ashok Raj Subject: Re: Linux 2.6.17-rc2 - notifier chain problem? In-Reply-To: <20060424162817.764fa244.akpm@osdl.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 7685 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: stern@rowland.harvard.edu Precedence: bulk X-list: linux-xfs Content-Length: 3003 Lines: 72 On Mon, 24 Apr 2006, Andrew Morton wrote: > Chandra Seetharaman wrote: > > > > On Mon, 2006-04-24 at 15:03 -0700, Andrew Morton wrote: > > > Chandra Seetharaman wrote: > > > > > > > > Thanks for the steps. With that i was able to reproduce the problem and > > > > i found the bug. > > > > > > > > While i go ahead and generate the patch, i wanted to hear if my > > > > conclusion is correct. > > > > > > > > The problem is due to the fact that most notifier registrations > > > > incorrectly use __devinitdata to define the callback structure, as in: > > > > > > > > static struct notifier_block __devinitdata hrtimers_nb = { > > > > .notifier_call = hrtimer_cpu_notify, > > > > }; > > > > > > > > devinitdata'd data is not _expected to be available_ after the > > > > initialization(unless CONFIG_HOTPLUG is defined). > > > > > > > > I do not know how it was working until now :), anybody has a theory that > > > > can explain it (or my conclusion is wrong) ? > > > > > > That sounds right. There are several __devinitdata notifier_blocks in the > > > tree - please be sure to check them all. > > > > Yes, I am covering all notifier blocks. > > > > Another issue... many of the notifier callback functions are marked as > > init calls (__cpuinit, __devinit etc.,) as in: > > > > static int __cpuinit pageset_cpuup_callback(struct notifier_block *nfb, > > unsigned long action, > > void *hcpu) > > hm. This needs some care and thought. We _should_ be oopsing all over the > place because of this. So why aren't we? > > iirc, the cpu notifier chain is never used after bootup if > !CONFIG_HOTPLUG_CPU, so there's a good chance that we have things on that > list which have been unloaded, but which never get accessed. > > It could be similar with the __devinit things - they're on the list, > they're unloaded, but nothing ever happens in a !CONFIG_HOTPLUG kernel to > cause them to be dereferenced. > > Really, these notifier chains just shouldn't exist at all if they're not > going to be used. We're a bit sloppy here. Ashok and I spent some time > working on making lots of code and data structures go away if > !CONFIG_HOTPLUG_CPU, but it's a bit tricky due to the way we do SMP > bringup. > > I guess for now, bringing those things into .text and .data when there's > doubt is a reasonable thing to do. It seems clear that this particular oops was caused by the xfs driver trying to register a cpu_notifier at a time when that notifier chain was expected to be completely idle. Instead of moving all this code and data out of the init sections, wouldn't it be better to fix the individual drivers (like xfs) so they won't try to use inaccessible notifier chains? For that matter, if lots of entries on the cpu_notifier chain are marked with __cpuinit, then shouldn't the chain header itself plus register_cpu_notifier and unregister_cpu_notifier be marked the same way? Alan Stern From owner-linux-xfs@oss.sgi.com Thu Apr 27 02:46:54 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 27 Apr 2006 02:47:01 -0700 (PDT) Received: from taiwan.yingternet.net (59-124-122-220.HINET-IP.hinet.net [59.124.122.220]) by oss.sgi.com (8.13.6/8.12.10/SuSE Linux 0.7) with ESMTP id k3R9kq1Z003896 for ; Thu, 27 Apr 2006 02:46:54 -0700 Received: from [127.0.0.1] (localhost [127.0.0.1]) by taiwan.yingternet.net (Postfix) with ESMTP id 0BC16701CA0 for ; Thu, 27 Apr 2006 16:37:14 +0800 (CST) Message-ID: <445082B4.1000400@yingternet.com> Date: Thu, 27 Apr 2006 16:37:08 +0800 From: Ying-Hung Chen User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: xfs_check problem X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 7686 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ying@yingternet.com Precedence: bulk X-list: linux-xfs Content-Length: 2863 Lines: 69 Hi there, we are currently having problem (kernel panic) running xfs_check on xfs partition >= 300G, while it doesn't happen EVERYTIME, but it happens about 50% of time (especially true when unexpected interruption happened, such as power failure and with bigger partition) I can run xfs_repair fine and xfs filesystem seems to be working fine. I know in the xfs_check man page, it mentioned about xfs_check may run out of meory in large filesystem, but i definitely does not expect kernel to panic. we are running kernel 2.6.14.2, xfsprogs at 2.6.13. anything I can try? or i shouldn't need to perform xfs_check everytime (or just run xfs_repair on startup?) thanks. I am attaching the panic log.. kernel BUG at :48363! invalid operand: 0000 [#1] Modules linked in: ds40xxhc dm_mod ftdi_sio usbserial uhci_hcd ehci_hcd i2c_i801 i2c_core CPU: 0 EIP: 0060:[try_to_unmap+74/85] Not tainted VLI EIP: 0060:[] Not tainted VLI EFLAGS: 00010202 (2.6.14.2lm) EIP is at try_to_unmap+0x4a/0x55 eax: 40008419 ebx: c1310000 ecx: 00000000 edx: 000000d0 esi: c1310000 edi: c15f1eac ebp: c15f1f48 esp: c15f1e20 ds: 007b es: 007b ss: 0068 Process kswapd0 (pid: 175, threadinfo=c15f1000 task=c15e8a50) Stack: c041ea80 c013eef0 00000001 00000000 c041ea80 00000000 00000000 c131fff8 c131fff8 00000000 00000001 c0146d5a 00000001 00000001 00000000 c11ee5a0 00000000 c15f1eb4 c041e42c 00000004 00000000 c013e0a5 00000202 c013f7a7 Call Trace: [shrink_list+367/1012] shrink_list+0x16f/0x3f4 [] shrink_list+0x16f/0x3f4 [page_referenced_anon+65/104] page_referenced_anon+0x41/0x68 [] page_referenced_anon+0x41/0x68 [__pagevec_release+21/29] __pagevec_release+0x15/0x1d [] __pagevec_release+0x15/0x1d [refill_inactive_zone+823/865] refill_inactive_zone+0x337/0x361 [] refill_inactive_zone+0x337/0x361 [shrink_cache+220/608] shrink_cache+0xdc/0x260 [] shrink_cache+0xdc/0x260 [shrink_zone+170/204] shrink_zone+0xaa/0xcc [] shrink_zone+0xaa/0xcc [balance_pgdat+592/959] balance_pgdat+0x250/0x3bf [] balance_pgdat+0x250/0x3bf [kswapd+205/267] kswapd+0xcd/0x10b [] kswapd+0xcd/0x10b [autoremove_wake_function+0/55] autoremove_wake_function+0x0/0x37 [] autoremove_wake_function+0x0/0x37 [autoremove_wake_function+0/55] autoremove_wake_function+0x0/0x37 [] autoremove_wake_function+0x0/0x37 [kswapd+0/267] kswapd+0x0/0x10b [] kswapd+0x0/0x10b [kernel_thread_helper+5/11] kernel_thread_helper+0x5/0xb [] kernel_thread_helper+0x5/0xb Code: 8b 43 08 5b 85 c0 b8 00 00 00 00 0f 48 d0 89 d0 c3 89 d8 e8 d6 fd ff ff 89 c2 8b 43 08 5b 85 c0 b8 00 00 00 00 0f 48 d0 89 d0 c3 <0f> 0b eb bc 0f 0b eb be 90 90 90 57 89 cf 56 89 d6 53 83 ec 10 From owner-linux-xfs@oss.sgi.com Thu Apr 27 03:33:59 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 27 Apr 2006 03:34:03 -0700 (PDT) Received: from MAIL01HQ.adic.com (mail01hq.adic.com [63.81.117.10]) by oss.sgi.com (8.13.6/8.12.10/SuSE Linux 0.7) with ESMTP id k3RAXuO3008519 for ; Thu, 27 Apr 2006 03:33:57 -0700 Received: from MAIL12HQ.adic.com ([172.16.9.216]) by MAIL01HQ.adic.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Apr 2006 03:28:25 -0700 Received: from [127.0.0.1] ([172.16.82.13]) by MAIL12HQ.adic.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Apr 2006 03:28:24 -0700 Message-ID: <44509CC6.2060905@xfs.org> Date: Thu, 27 Apr 2006 05:28:22 -0500 From: Steve Lord User-Agent: Thunderbird 1.5 (X11/20060313) MIME-Version: 1.0 To: Ying-Hung Chen CC: linux-xfs@oss.sgi.com Subject: Re: xfs_check problem References: <445082B4.1000400@yingternet.com> In-Reply-To: <445082B4.1000400@yingternet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Apr 2006 10:28:25.0080 (UTC) FILETIME=[50CEDF80:01C669E5] X-archive-position: 7687 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 3438 Lines: 82 Hi There, I would direct this to the linux kernel mailing list, and reproduce, if you can, with a very recent kernel. This looks like memory stress caused by xfs_check is causing the vm to crash. This is not an XFS bug, you could probably find different applications which would do the same thing. xfs_check merely does a bunch of block I/O and allocates a lot of user memory, it has no kernel component. Steve Ying-Hung Chen wrote: > Hi there, > > we are currently having problem (kernel panic) running xfs_check on xfs > partition >= 300G, while it doesn't happen EVERYTIME, but it happens > about 50% of time (especially true when unexpected interruption > happened, such as power failure and with bigger partition) > > I can run xfs_repair fine and xfs filesystem seems to be working fine. I > know in the xfs_check man page, it mentioned about xfs_check may run out > of meory in large filesystem, but i definitely does not expect kernel to > panic. > > we are running kernel 2.6.14.2, xfsprogs at 2.6.13. > > anything I can try? or i shouldn't need to perform xfs_check everytime > (or just run xfs_repair on startup?) thanks. > > I am attaching the panic log.. > > kernel BUG at :48363! > invalid operand: 0000 [#1] > Modules linked in: ds40xxhc dm_mod ftdi_sio usbserial uhci_hcd ehci_hcd > i2c_i801 i2c_core > CPU: 0 > EIP: 0060:[try_to_unmap+74/85] Not tainted VLI > EIP: 0060:[] Not tainted VLI > EFLAGS: 00010202 (2.6.14.2lm) > EIP is at try_to_unmap+0x4a/0x55 > eax: 40008419 ebx: c1310000 ecx: 00000000 edx: 000000d0 > esi: c1310000 edi: c15f1eac ebp: c15f1f48 esp: c15f1e20 > ds: 007b es: 007b ss: 0068 > Process kswapd0 (pid: 175, threadinfo=c15f1000 task=c15e8a50) > Stack: c041ea80 c013eef0 00000001 00000000 c041ea80 00000000 00000000 > c131fff8 > c131fff8 00000000 00000001 c0146d5a 00000001 00000001 00000000 > c11ee5a0 > 00000000 c15f1eb4 c041e42c 00000004 00000000 c013e0a5 00000202 > c013f7a7 > Call Trace: > [shrink_list+367/1012] shrink_list+0x16f/0x3f4 > [] shrink_list+0x16f/0x3f4 > [page_referenced_anon+65/104] page_referenced_anon+0x41/0x68 > [] page_referenced_anon+0x41/0x68 > > [__pagevec_release+21/29] __pagevec_release+0x15/0x1d > [] __pagevec_release+0x15/0x1d > [refill_inactive_zone+823/865] refill_inactive_zone+0x337/0x361 > [] refill_inactive_zone+0x337/0x361 > [shrink_cache+220/608] shrink_cache+0xdc/0x260 > [] shrink_cache+0xdc/0x260 > [shrink_zone+170/204] shrink_zone+0xaa/0xcc > [] shrink_zone+0xaa/0xcc > [balance_pgdat+592/959] balance_pgdat+0x250/0x3bf > [] balance_pgdat+0x250/0x3bf > [kswapd+205/267] kswapd+0xcd/0x10b > [] kswapd+0xcd/0x10b > [autoremove_wake_function+0/55] autoremove_wake_function+0x0/0x37 > [] autoremove_wake_function+0x0/0x37 > [autoremove_wake_function+0/55] autoremove_wake_function+0x0/0x37 > [] autoremove_wake_function+0x0/0x37 > [kswapd+0/267] kswapd+0x0/0x10b > [] kswapd+0x0/0x10b > [kernel_thread_helper+5/11] kernel_thread_helper+0x5/0xb > [] kernel_thread_helper+0x5/0xb > Code: 8b 43 08 5b 85 c0 b8 00 00 00 00 0f 48 d0 89 d0 c3 89 d8 e8 d6 fd > ff ff 89 c2 8b 43 08 5b 85 c0 > b8 00 00 00 00 0f 48 d0 89 d0 c3 <0f> 0b eb bc 0f 0b eb be 90 90 90 57 > 89 cf 56 89 d6 53 83 ec 10 > From owner-linux-xfs@oss.sgi.com Thu Apr 27 12:54:44 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 27 Apr 2006 12:54:47 -0700 (PDT) Received: from omx1.americas.sgi.com (omx1.americas.sgi.com [198.149.16.13]) by oss.sgi.com (8.13.6/8.12.10/SuSE Linux 0.7) with ESMTP id k3RJsh4b014420 for ; Thu, 27 Apr 2006 12:54:43 -0700 Received: from imr2.americas.sgi.com (imr2.americas.sgi.com [198.149.16.18]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id k3RIjCnx028833 for ; Thu, 27 Apr 2006 13:45:12 -0500 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by imr2.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id k3RJ3h7p26539109; Thu, 27 Apr 2006 12:03:43 -0700 (PDT) Received: from attica.americas.sgi.com (attica.americas.sgi.com [128.162.236.44]) by poppy-e236.americas.sgi.com (8.12.9/ASC-news-1.4) with ESMTP id k3RIj9SQ7348772; Thu, 27 Apr 2006 13:45:09 -0500 (CDT) Received: by attica.americas.sgi.com (Postfix, from userid 3682) id 37FBB105CB32; Thu, 27 Apr 2006 13:45:09 -0500 (CDT) To: sgi.bugs.xfs@SGI.com, linux-xfs@SGI.com Cc: sgi.bugs.snlinux@SGI.com Subject: TAKE 952291 - funky kmem_free arguments in xfs_iext_direct_to_inline() Message-Id: <20060427184509.37FBB105CB32@attica.americas.sgi.com> Date: Thu, 27 Apr 2006 13:45:09 -0500 (CDT) From: alkirkco@SGI.com (Mandy Miklos) X-archive-position: 7689 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: alkirkco@SGI.com Precedence: bulk X-list: linux-xfs Content-Length: 478 Lines: 17 Fix size argument in kmem_free(). Date: Thu Apr 27 11:42:55 PDT 2006 Workarea: attica.americas.sgi.com:/data/lwork/attica2/alkirkco/XFS/xfs-linux Inspected by: olaf,lachlan The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:209807a xfs_inode.c - 1.438 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode.c.diff?r1=text&tr1=1.438&r2=text&tr2=1.437&f=h - Fix size argument in kmem_free(). From owner-linux-xfs@oss.sgi.com Thu Apr 27 21:22:39 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 27 Apr 2006 21:22:46 -0700 (PDT) Received: from taiwan.yingternet.net (59-124-122-220.HINET-IP.hinet.net [59.124.122.220]) by oss.sgi.com (8.13.6/8.12.10/SuSE Linux 0.7) with ESMTP id k3S4MavN000684 for ; Thu, 27 Apr 2006 21:22:38 -0700 Received: from [127.0.0.1] (localhost [127.0.0.1]) by taiwan.yingternet.net (Postfix) with ESMTP id 80A9C701CA0; Fri, 28 Apr 2006 12:17:04 +0800 (CST) Message-ID: <4451973A.1090502@yingternet.com> Date: Fri, 28 Apr 2006 12:16:58 +0800 From: Ying-Hung Chen User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Steve Lord CC: linux-xfs@oss.sgi.com Subject: Re: xfs_check problem References: <445082B4.1000400@yingternet.com> <44509CC6.2060905@xfs.org> In-Reply-To: <44509CC6.2060905@xfs.org> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 7690 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ying@yingternet.com Precedence: bulk X-list: linux-xfs Content-Length: 3998 Lines: 99 Hi Steve, I have try the new kernel 2.6.16.11 this morning, xfs_check doesn't cause it to crash anymore but it does leave some ugly looking message "Trying to fix it up, but a reboot is needed", i'll try to do more testing and see what happens. Anyhow, I just want to know if there is any event that we want to run xfs_check instead of xfs_repair directly (since we usually want check the filesystem AND fix them if there is any errors) Thanks, -Ying Steve Lord wrote: > Hi There, > > I would direct this to the linux kernel mailing list, and reproduce, if > you can, with a very recent kernel. This looks like memory stress > caused by xfs_check is causing the vm to crash. This is not an XFS > bug, you could probably find different applications which would > do the same thing. xfs_check merely does a bunch of block I/O and > allocates a lot of user memory, it has no kernel component. > > Steve > > Ying-Hung Chen wrote: >> Hi there, >> >> we are currently having problem (kernel panic) running xfs_check on xfs >> partition >= 300G, while it doesn't happen EVERYTIME, but it happens >> about 50% of time (especially true when unexpected interruption >> happened, such as power failure and with bigger partition) >> >> I can run xfs_repair fine and xfs filesystem seems to be working fine. I >> know in the xfs_check man page, it mentioned about xfs_check may run out >> of meory in large filesystem, but i definitely does not expect kernel to >> panic. >> >> we are running kernel 2.6.14.2, xfsprogs at 2.6.13. >> >> anything I can try? or i shouldn't need to perform xfs_check everytime >> (or just run xfs_repair on startup?) thanks. >> >> I am attaching the panic log.. >> >> kernel BUG at :48363! >> invalid operand: 0000 [#1] >> Modules linked in: ds40xxhc dm_mod ftdi_sio usbserial uhci_hcd ehci_hcd >> i2c_i801 i2c_core >> CPU: 0 >> EIP: 0060:[try_to_unmap+74/85] Not tainted VLI >> EIP: 0060:[] Not tainted VLI >> EFLAGS: 00010202 (2.6.14.2lm) >> EIP is at try_to_unmap+0x4a/0x55 >> eax: 40008419 ebx: c1310000 ecx: 00000000 edx: 000000d0 >> esi: c1310000 edi: c15f1eac ebp: c15f1f48 esp: c15f1e20 >> ds: 007b es: 007b ss: 0068 >> Process kswapd0 (pid: 175, threadinfo=c15f1000 task=c15e8a50) >> Stack: c041ea80 c013eef0 00000001 00000000 c041ea80 00000000 00000000 >> c131fff8 >> c131fff8 00000000 00000001 c0146d5a 00000001 00000001 00000000 >> c11ee5a0 >> 00000000 c15f1eb4 c041e42c 00000004 00000000 c013e0a5 00000202 >> c013f7a7 >> Call Trace: >> [shrink_list+367/1012] shrink_list+0x16f/0x3f4 >> [] shrink_list+0x16f/0x3f4 >> [page_referenced_anon+65/104] page_referenced_anon+0x41/0x68 >> [] page_referenced_anon+0x41/0x68 >> >> [__pagevec_release+21/29] __pagevec_release+0x15/0x1d >> [] __pagevec_release+0x15/0x1d >> [refill_inactive_zone+823/865] refill_inactive_zone+0x337/0x361 >> [] refill_inactive_zone+0x337/0x361 >> [shrink_cache+220/608] shrink_cache+0xdc/0x260 >> [] shrink_cache+0xdc/0x260 >> [shrink_zone+170/204] shrink_zone+0xaa/0xcc >> [] shrink_zone+0xaa/0xcc >> [balance_pgdat+592/959] balance_pgdat+0x250/0x3bf >> [] balance_pgdat+0x250/0x3bf >> [kswapd+205/267] kswapd+0xcd/0x10b >> [] kswapd+0xcd/0x10b >> [autoremove_wake_function+0/55] autoremove_wake_function+0x0/0x37 >> [] autoremove_wake_function+0x0/0x37 >> [autoremove_wake_function+0/55] autoremove_wake_function+0x0/0x37 >> [] autoremove_wake_function+0x0/0x37 >> [kswapd+0/267] kswapd+0x0/0x10b >> [] kswapd+0x0/0x10b >> [kernel_thread_helper+5/11] kernel_thread_helper+0x5/0xb >> [] kernel_thread_helper+0x5/0xb >> Code: 8b 43 08 5b 85 c0 b8 00 00 00 00 0f 48 d0 89 d0 c3 89 d8 e8 d6 fd >> ff ff 89 c2 8b 43 08 5b 85 c0 >> b8 00 00 00 00 0f 48 d0 89 d0 c3 <0f> 0b eb bc 0f 0b eb be 90 90 90 57 >> 89 cf 56 89 d6 53 83 ec 10 >> From owner-linux-xfs@oss.sgi.com Fri Apr 28 09:37:58 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 28 Apr 2006 09:38:00 -0700 (PDT) Received: from hotmail.com (bay103-f1.bay103.hotmail.com [65.54.174.11]) by oss.sgi.com (8.13.6/8.12.10/SuSE Linux 0.7) with ESMTP id k3SGbvhK003747 for ; Fri, 28 Apr 2006 09:37:58 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 28 Apr 2006 09:32:25 -0700 Message-ID: Received: from 65.54.174.200 by by103fd.bay103.hotmail.msn.com with HTTP; Fri, 28 Apr 2006 16:32:21 GMT X-Originating-IP: [85.36.106.214] X-Originating-Email: [pupilla@hotmail.com] X-Sender: pupilla@hotmail.com From: "Marco Berizzi" To: linux-xfs@oss.sgi.com Subject: TAKE 951944 - barriers on remount,ro Date: Fri, 28 Apr 2006 18:32:21 +0200 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 28 Apr 2006 16:32:25.0376 (UTC) FILETIME=[550D5200:01C66AE1] X-archive-position: 7691 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: pupilla@hotmail.com Precedence: bulk X-list: linux-xfs Content-Length: 45 Lines: 3 Will this fix be included in linux 2.6.17? From owner-linux-xfs@oss.sgi.com Fri Apr 28 10:11:32 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 28 Apr 2006 10:11:36 -0700 (PDT) Received: from postfix1-c.free.fr (postfix1-c.free.fr [213.228.0.79]) by oss.sgi.com (8.13.6/8.12.10/SuSE Linux 0.7) with ESMTP id k3SH9U7S006235 for ; Fri, 28 Apr 2006 10:11:31 -0700 Received: from smtp6-g19.free.fr (smtp6-g19.free.fr [212.27.42.36]) by postfix1-c.free.fr (Postfix) with ESMTP id 5D7961A478DA for ; Fri, 28 Apr 2006 18:00:12 +0200 (CEST) Received: from imp5-g19.free.fr (imp5-g19.free.fr [212.27.42.5]) by smtp6-g19.free.fr (Postfix) with ESMTP id 12E2F222BC; Fri, 28 Apr 2006 17:59:55 +0200 (CEST) Received: by imp5-g19.free.fr (Postfix, from userid 33) id CCD03B8D9; Fri, 28 Apr 2006 17:59:55 +0200 (CEST) Received: from 81.91.239.5 ([81.91.239.5]) by imp5-g19.free.fr (IMP) with HTTP for ; Fri, 28 Apr 2006 17:59:54 +0200 Message-ID: <1146239994.44523bfaf26ed@imp5-g19.free.fr> Date: Fri, 28 Apr 2006 17:59:54 +0200 From: PETER KAMARA Reply-To: peterkamara16@katamail.com Subject: Bonjour votre =?iso-8859-1?b?ZnLocmU=?= Mr.P.Kamara MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.5 X-Originating-IP: 81.91.239.5 To: undisclosed-recipients: ; X-archive-position: 7692 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: peterkamara17@katamail.com Precedence: bulk X-list: linux-xfs Content-Length: 6937 Lines: 109 Mr Peter KAMARA Email: peterkamara23@katamail.com Tel : 00229 97 17 75 85. Mon cher, Je sais que mon message sera d'une grande surprise quand il vous parviendra. Donc' je vous présente toutes mes excuses. J’ai prie pendant plusieurs jours et après cela j'ai choisi de vous contacter parmi plusieurs autres personnes. Je pense que vous étés digne de la recommandation de ma prière. Je vous écris sincèrement dans le but d'obtenir votre coopération et votre confiance pouvant me permettre d'effectuer une affaire urgente avec vous. Aussi je profite de l'occasion pour vous faire nécessite cette affaire et ma position actuelle. L’idée de vous écrire m'est arrivée d'une nécessite et d'une frustration qui a pour base des perturbations momentanées issues de ma famille d'adoption de monsieur et madame KABA williams. Mon père adoptif. Toute sa famille et lui travaillait dans un monde d'affaire concernant l'or pendant longtemps : ce qui jusque la n'a pas encore été reconnu comme étant un vaste domaine riche en or qui a été acquis. Je suis Mr Peter KAMARA originaire de la sierra Leone et ma famille d’adoption celle de Mr et mme KABA williams originaire de la Guinée Conakry. Mon ancien père adoptif est un important homme d’affaire qui Intervient dans le domaine du cacao et beaucoup d’autres matières dans un autre pays a Abidjan capitale de la cote d'ivoire située en Afrique de l' Ouest depuis 1983.mon père adoptif a achète un domaine (un hectare) qu’il a confie pour la plantation du cacao et d’autres cultures en Guinée conakry. il a acquis un hectare de terre auprès des membres l'ethnie susu a Conakry capitale de la Guinée et entre temps Quatre ans après que le domaine ai été prépare pour la culture du cacao et son exploration. il a été découvert par des expatries français que ledit domaine est très riche en or quand mon ancien père adoptif l'acheta en 1983.comme ce domaine se retrouvait en zone très recule elle n'était pas considérée et n'avait même pas été enregistre par l'état sur la liste des affaires domaniales . Quand la découverte fut faite et que mon père et les expatries français commencèrent par extraire et exporter l’or sur d’autres pays a travers le monde entier et que mon père décida de construire une habitation pour l’installation de toute sa famille sur le domaine a cause des exigences de son métier et que les villageois et autres découvrirent la richesse en mines d'or du terrain. Ils devinrent très jaloux de lui et commencèrent par le menacer et lui créer des problèmes de tout genre comme quoi le terrain ne lui avait pas été réellement vendu et ils commencèrent par le lui disputer. Devant la justice, mon père remporta le procès car il avait tous les documents devant prouver son titre de propriétaire légal. Après la décision de la cour en faveur de mon ancien père adoptif, les villageois aides par d'importantes personnalités du gouvernement interjetèrent appel près la haute cour d’appel et obtinrent satisfaction car le président est issu de leur tribu. Voulant taire à jamais cette histoire. Des assassins furent envoies la nuit du 07 avril 2000 dans l'habitation de ma famille adoptive tuer tout le monde jusqu’aux enfants. Mais mon père adoptif n’avait pas succombe sur le champ à l’époque j’étais à l’internat (école). Il avait été emmené aux soins par des hommes de sécurité qui ont accouru parce qu'ayant entendu des coups de feu et ont alerté la police. A l'hôpital avant de s’éteindre, MR KABA Williams m'a fait venir de l’internat et m'a relaté toute l'histoire. Par ailleurs il m'a soufflé très bas où se trouvaient les clés de la souterraine ou il cachait toute sa fortune, où se trouvaient tous ses documents importants et autres .et où sont cachés les documents des marchandises qu’il a confié a une société de gardiennage a Cotonou en République du Bénin et il m'a ajouté que la marchandise déposée contient( 65.000.000 $US ) qu’il a couvert avec des pièces informatiques. Il a déclaré près de la société de gardiennage que les marchandises confiées étaient un ensemble de biens personnels (pièces informatiques) depuis que le gouvernement guinéen a bloqué son compte et tous ses biens qui se trouvent en Guinée. Après la mort de mon feu père. J’ai du quitter la Guinée Conakry sous l’emprise de la peur pour venir habiter dans un autre pays (République du Bénin) où se trouvent les marchandises les fonds et profiter de l'occasion pour voir comment faire le retrait des trois males de marchandises, après les renseignements auprès de la société de gardiennage. C’est la semaine dernière que la société de gardiennage a accepté faire la mutation au nom de celui qui ferra le retrait de la marchandise. Je viens ainsi solliciter votre aide pour le retrait de la marchandise qui Contient les fonds ci haut indiques ici a Cotonou en République du Bénin. Je désire aussi déplacer l'argent de ce pays pour le votre et l'investir soit dans votre compagnie ou dans toute autre activité lucrative que vous me proposerez mais rappelez vous que mon feu père adoptif m'a dit que la société de gardiennage n'est pas au courant du fait que la marchandise a pour contenu de l'argent. Tout ce qu’elle sait c’est que le contenu a rapport a des pièces informatiques et c'est d'ailleurs pour cela que je recherche un partenaire étranger ou une association étrangère qui pourra m'aider dans l'investissement de fonds car je ne maîtrise pas ce domaine, et bien avant cela mon feu père adoptif m’a défendu d'informer quelque membre de sa famille et quelque ami que ce soit car ils doivent avoir participé de leur manière a cet événement douloureux. Je m’engage a vous donner 50% des fonds se trouvant dans la marchandise comme récompense pour vos interventions et le reste je le garde pour moi pour mes propres investissements chez vous. Après avoir reçu votre réponse. Je vous donnerai l'adresse de la société de gardiennage et aussitôt que vous vous serrez engagé pour m’aider à récupérer tous les biens. Je vous fournirai le numéro de téléphone et le fax de la société avec les certificats de dépôt des trois males qui contiennent les fonds puis l'adresse de la société de gardiennage ou se trouvent les marchandises pour raison de sécurité et le certificat de décès de mon feu père adoptif MR KABA Williams ,cela vous permettra de rentrer en contact avec la société de gardiennage et d'obtenir tous les renseignements nécessaires aussi demander les formalités a remplir et la procédure à suivre pour la mutation en votre nom et pour le retrait des marchandises. N’oubliez pas de me répondre sous mon email adresse privé : peterkamara24@katamail.com et vous pouvez me joindre sur mon numéro mobile a tout moment pour avoir plus d’information. Tel : 00229 97 17 75 85. J’attends votre réponse au plus vite possible. Que Dieu vous bénisse. Votre frère. MR PETER KAMARA Email: peterkamara23@katamail.com Tel : 00229 97 17 75 85. From owner-linux-xfs@oss.sgi.com Fri Apr 28 13:30:02 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 28 Apr 2006 13:30:07 -0700 (PDT) Received: from mail.ukfsn.org (s2.ukfsn.org [217.158.120.143]) by oss.sgi.com (8.13.6/8.12.10/SuSE Linux 0.7) with ESMTP id k3SKS1x8023056 for ; Fri, 28 Apr 2006 13:30:02 -0700 Received: from localhost.localdomain (i-83-67-36-194.freedom2surf.net [83.67.36.194]) by mail.ukfsn.org (Postfix) with ESMTP id BA828E709D; Fri, 28 Apr 2006 21:17:22 +0100 (BST) Received: from [10.0.0.90] (helo=[10.0.0.90]) by localhost.localdomain with esmtp (Exim 4.50) id 1FZZTw-0006XY-2P; Fri, 28 Apr 2006 21:22:28 +0100 Message-ID: <4452797F.70700@dgreaves.com> Date: Fri, 28 Apr 2006 21:22:23 +0100 From: David Greaves User-Agent: Mail/News 1.5 (X11/20060228) MIME-Version: 1.0 To: "'linux-kernel@vger.kernel.org'" , linux-xfs@oss.sgi.com Subject: Bad page state in process 'nfsd' with xfs X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 7693 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: david@dgreaves.com Precedence: bulk X-list: linux-xfs Content-Length: 1893 Lines: 57 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This was with 2.6.16.9 There's an nfs export from an xfs on an lvm on a raid5 on some libata/sata disks. (cc'ing xfs since I recall rumoured(?) badness in old nfs/xfs/md/lvm setups and xfs_sendfile is mentioned) dmesg had: Bad page state in process 'nfsd' page:b1602060 flags:0x80000008 mapping:00000000 mapcount:0 count:16777216 Trying to fix it up, but a reboot is needed Backtrace: [] bad_page+0x62/0x90 [] prep_new_page+0x78/0x80 [] buffered_rmqueue+0xf6/0x1f0 [] get_page_from_freelist+0x92/0xb0 [] __alloc_pages+0x56/0x300 [] __do_page_cache_readahead+0xdc/0x120 [] blockable_page_cache_readahead+0x59/0xd0 [] make_ahead_window+0x7a/0xb0 [] page_cache_readahead+0xbf/0x1b0 [] do_generic_mapping_read+0x4b1/0x4c0 [] generic_file_sendfile+0x62/0x70 [] nfsd_read_actor+0x0/0xd0 [nfsd] [] xfs_sendfile+0xc0/0x190 [] nfsd_read_actor+0x0/0xd0 [nfsd] [] linvfs_open+0x48/0x50 [] linvfs_sendfile+0x57/0x60 [] nfsd_read_actor+0x0/0xd0 [nfsd] [] nfsd_vfs_read+0x1ff/0x370 [nfsd] [] nfsd_read_actor+0x0/0xd0 [nfsd] [] nfsd_read+0x103/0x120 [nfsd] [] nfsd3_proc_read+0xe4/0x170 [nfsd] [] nfsd_dispatch+0xd9/0x210 [nfsd] [] svc_process+0x482/0x670 [sunrpc] [] nfsd+0x18c/0x300 [nfsd] [] nfsd+0x0/0x300 [nfsd] [] kernel_thread_helper+0x5/0x14 more info on request but I have rebooted as suggested. David - -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEUnl+8LvjTle4P1gRAip3AJ9izpp3+/6/fPgzSbJdxuc74Uus5wCZAWtF QHY+xcDh9cf6bYhBCx+DzJE= =XZDc -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Fri Apr 28 15:10:42 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 28 Apr 2006 15:11:42 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.13.6/8.12.10/SuSE Linux 0.7) with SMTP id k3SM8cqd028883 for ; Fri, 28 Apr 2006 15:10:40 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id GAA28970; Sat, 29 Apr 2006 06:52:10 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k3SKq7JC1798920; Sat, 29 Apr 2006 06:52:08 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k3SKq5NV1780343; Sat, 29 Apr 2006 06:52:05 +1000 (EST) Date: Sat, 29 Apr 2006 06:52:05 +1000 From: Nathan Scott To: Marco Berizzi Cc: linux-xfs@oss.sgi.com Subject: Re: TAKE 951944 - barriers on remount,ro Message-ID: <20060429065204.A1798762@wobbly.melbourne.sgi.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from pupilla@hotmail.com on Fri, Apr 28, 2006 at 06:32:21PM +0200 X-archive-position: 7694 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 130 Lines: 9 On Fri, Apr 28, 2006 at 06:32:21PM +0200, Marco Berizzi wrote: > Will this fix be included in linux 2.6.17? > Yes. -- Nathan From owner-linux-xfs@oss.sgi.com Fri Apr 28 21:08:03 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 28 Apr 2006 21:08:07 -0700 (PDT) Received: from nproxy.gmail.com (nproxy.gmail.com [64.233.182.185]) by oss.sgi.com (8.13.6/8.12.10/SuSE Linux 0.7) with ESMTP id k3T461tv024349 for ; Fri, 28 Apr 2006 21:08:03 -0700 Received: by nproxy.gmail.com with SMTP id o60so2564765nfa for ; Fri, 28 Apr 2006 21:00:29 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=YQNxdBkuIGYoqvWbT1RuTtbmlhS41A305a1gG00cInW3EH+7ILDOFKHxLABSAfaeGdmN6Do/y43s0eXsAH4vbJQe8O8x1x/VbkNvSCqvNY1tDKrU8nZjmgr2UDFHX7yMrRR4vwWcKPFvg4O6nvlzbydC+FBbaSZhK+jhex7Jjfk= Received: by 10.49.64.16 with SMTP id r16mr6985096nfk; Fri, 28 Apr 2006 19:11:09 -0700 (PDT) Received: by 10.49.58.9 with HTTP; Fri, 28 Apr 2006 19:11:09 -0700 (PDT) Message-ID: <54791f640604281911x47856bd1k9d68ae5c6bb208f@mail.gmail.com> Date: Fri, 28 Apr 2006 23:11:09 -0300 From: silos To: linux-xfs@oss.sgi.com Subject: large files MIME-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit X-archive-position: 7695 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: gsilos@gmail.com Precedence: bulk X-list: linux-xfs Content-Length: 2123 Lines: 71 Hello people, Doing tests to open a >2GB file (large file) using open() syscall on 32 and 64 bit machine using SuSe I got what I call of a "strange behaviour" on the 32 bit machine. I would like to share this test with you to see if it there is a workaround to my problem. I compiled two versions of a short program to execute the 'open' syscall. version1 - called test1 int main(void) { int fd; if((fd = open("morethan2gbfile", O_RDONLY)) < 0) { printf("TEST: ERRO"); } else { printf("TEST: OK"); close(fd); } version2 - called test2 int main(void) { int fd; if((fd = open("morethan2gbfile", O_RDONLY | O_LARGEFILE))) < 0) { printf("TEST: ERRO"); } else { printf("TEST: OK"); close(fd); } Here are the scenarios: 1) *64bit* machine SUSE Version 9 PATCHLEVEL 3 kernel 2.6.5-7.252-smp xfsprogs-2.6.25-0.6 XFS partition mount options: rw,noatime,nodiratime glibc-2.3.3-98.61 ran 'test1' on a XFS partition -> output: TEST: OK 2) *32bit* machine SUSE Version 9 PATCHLEVEL 3 kernel 2.6.5-7.252-smp xfsprogs-2.6.25-0.6 XFS partition mount options: rw,noatime,nodiratime glibc-2.3.3-98.61 ran 'test1' on a XFS partition -> output: TEST: ERRO ran 'test2' on a XFS partition -> output: TEST: OK 3) *32bit* machine SUSE Version 9 PATCHLEVEL 3 kernel 2.6.5-7.252-smp reiserfs-3.6.19-3.2 ReiserFS partition mount options: rw glibc-2.3.3-98.61 ran 'test1' on a ReiserFS partition -> output: TEST: OK The point is that when I ran my 'test2' program (using O_LARGEFILE) on the scenario 2 I got "TEST: OK". So, XFS DO support large files with this trick but there are softwares like OpenLDAP that does not make use of O_LARGEFILE flag on its open() calls, so if I want to use LDAP on this archtecture I have to fix openldap to make it use O_LARGEFILE (and I think this work will not worth if there is something I can do in XFS space ;) Well, the question here is WHY :) Why do I need to make use of O_LARGEFILE when open()ing large files (>2GB) from a XFS filesystem and do not when using ReiserFS filesystem ? Thanks in advance, Fabiano Silos Reis Brasil Telecom Internet [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Sat Apr 29 20:13:44 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 29 Apr 2006 20:13:48 -0700 (PDT) Received: from smtp104.mail.mud.yahoo.com (smtp104.mail.mud.yahoo.com [209.191.85.214]) by oss.sgi.com (8.13.6/8.12.10/SuSE Linux 0.7) with SMTP id k3U3BgjX019734 for ; Sat, 29 Apr 2006 20:13:44 -0700 Received: (qmail 93015 invoked from network); 30 Apr 2006 02:06:10 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=Received:Message-ID:Date:From:User-Agent:X-Accept-Language:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=nKFc+aD/7+R4dfQ9uocOwYUDTDHe3Dex9IbKjyi87SO0etkP7v+Sx62zuhwM3YquOfCZ3CQTfQx+ardLgOXlFDsx/VyjsVQLvc68r+Q+isXMy5qFShyrDD/cAfYMkDTVq+mXkomj7m5iSzovc7dlzq25hhBoVlDOMK2c2ErQ5kI= ; Received: from unknown (HELO ?192.168.0.1?) (nickpiggin@203.173.2.239 with plain) by smtp104.mail.mud.yahoo.com with SMTP; 30 Apr 2006 02:06:09 -0000 Message-ID: <44541B91.3060104@yahoo.com.au> Date: Sun, 30 Apr 2006 12:06:09 +1000 From: Nick Piggin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20051007 Debian/1.7.12-1 X-Accept-Language: en MIME-Version: 1.0 To: David Greaves CC: "'linux-kernel@vger.kernel.org'" , linux-xfs@oss.sgi.com Subject: Re: Bad page state in process 'nfsd' with xfs References: <4452797F.70700@dgreaves.com> In-Reply-To: <4452797F.70700@dgreaves.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7698 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nickpiggin@yahoo.com.au Precedence: bulk X-list: linux-xfs Content-Length: 835 Lines: 29 David Greaves wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > This was with 2.6.16.9 > > There's an nfs export from an xfs on an lvm on a raid5 on some > libata/sata disks. > (cc'ing xfs since I recall rumoured(?) badness in old nfs/xfs/md/lvm > setups and xfs_sendfile is mentioned) > > dmesg had: > > Bad page state in process 'nfsd' > page:b1602060 flags:0x80000008 mapping:00000000 mapcount:0 count:16777216 > Trying to fix it up, but a reboot is needed > Backtrace: > [] bad_page+0x62/0x90 > [] prep_new_page+0x78/0x80 Looks like you have a bit flipped in 'count', which was not flipped when the page was last freed. Probably buggy RAM. Running memtest overnight might confirm that. -- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com