From owner-linux-xfs Fri Oct 1 00:28:25 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 01 Oct 2004 00:28:31 -0700 (PDT) Received: from phoenix.infradead.org (imladris.demon.co.uk [193.237.130.41]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i917SOlM032286 for ; Fri, 1 Oct 2004 00:28:25 -0700 Received: from hch by phoenix.infradead.org with local (Exim 4.42 #2 (Red Hat Linux)) id 1CDHpi-0000Bj-8c; Fri, 01 Oct 2004 08:28:02 +0100 Date: Fri, 1 Oct 2004 08:28:02 +0100 From: Christoph Hellwig To: vijaya saradhi uppaluri Cc: Dean Roehrich , linux-xfs@oss.sgi.com Subject: Re: xfs setting inode ctime Message-ID: <20041001082802.A697@infradead.org> References: <200409291514.i8TFE3xM456020@tulip-e236.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from uvsaradhi@gmail.com on Fri, Oct 01, 2004 at 09:47:03AM +0530 X-SRS-Rewrite: SMTP reverse-path rewritten from by phoenix.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 4203 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs On Fri, Oct 01, 2004 at 09:47:03AM +0530, vijaya saradhi uppaluri wrote: > Dean, > > Thanks for your response. I am currently working on stack of file > systems where I set the attribute ATTR_CTIME and expect the underlying > file-system to set the ctime to the value I pass. It is working on > other file-systems(ext2) on linux. Dean, I think we should change change XFS to use the value provided by ->setattr to conform to the inkernel API specified by the Linux kernel. From owner-linux-xfs Fri Oct 1 08:59:39 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 01 Oct 2004 08:59:43 -0700 (PDT) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i91FxccY021384 for ; Fri, 1 Oct 2004 08:59:39 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i91FxQQh024007 for ; Fri, 1 Oct 2004 10:59:26 -0500 Received: from tulip-e236.americas.sgi.com (tulip-e236.americas.sgi.com [128.162.236.208]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i91FxFOV48325736; Fri, 1 Oct 2004 10:59:15 -0500 (CDT) Received: from sgi.com (chewtoy.americas.sgi.com [128.162.233.33]) by tulip-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i91FxFxM835898; Fri, 1 Oct 2004 10:59:15 -0500 (CDT) Message-Id: <200410011559.i91FxFxM835898@tulip-e236.americas.sgi.com> To: Christoph Hellwig cc: vijaya saradhi uppaluri , linux-xfs@oss.sgi.com Subject: Re: xfs setting inode ctime Date: Fri, 01 Oct 2004 10:59:15 -0500 From: Dean Roehrich X-archive-position: 4204 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: roehrich@sgi.com Precedence: bulk X-list: linux-xfs >From: Christoph Hellwig >On Fri, Oct 01, 2004 at 09:47:03AM +0530, vijaya saradhi uppaluri wrote: >> Dean, >> >> Thanks for your response. I am currently working on stack of file >> systems where I set the attribute ATTR_CTIME and expect the underlying >> file-system to set the ctime to the value I pass. It is working on >> other file-systems(ext2) on linux. > >Dean, I think we should change change XFS to use the value provided >by ->setattr to conform to the inkernel API specified by the Linux kernel. I agree. Ug, xfs_setattr is a real beaut, isn't it? Dean From owner-linux-xfs Fri Oct 1 16:00:19 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 01 Oct 2004 16:00:22 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i91N0JFD007616 for ; Fri, 1 Oct 2004 16:00:19 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i91N0JGH007615 for linux-xfs@oss.sgi.com; Fri, 1 Oct 2004 16:00:19 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i91N0I0V007601 for ; Fri, 1 Oct 2004 16:00:18 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i91Md6TD005974; Fri, 1 Oct 2004 15:39:06 -0700 Date: Fri, 1 Oct 2004 15:39:06 -0700 Message-Id: <200410012239.i91Md6TD005974@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 363] segfault of user-app while triggering dmapi event X-Bugzilla-Reason: AssignedTo X-archive-position: 4205 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=363 ------- Additional Comments From mmontour@bycast.com 2004-01-10 15:39 PDT ------- I see a similar problem with the current linux-2.4-xfs kernel tree. I found one issue in fs/xfs/xfs_dmapi.c xfs_dm_send_namesp_event: error = dm_send_namesp_event(event, vfsp ? vfsp->vfs_super: NULL, LINVFS_GET_IP(vp1), vp1_right, LINVFS_GET_IP(vp2), vp2_right, name1, name2, mode, retcode, flags); In a CREATE event, vnode_t *vp2 is NULL. I changed the code to not call LINVFS_GET_IP on a NULL value (using "vp2 ? LINVFS_GET_IP(vp2) : NULL"), and now I successfully get CREATE and POSTCREATE events without any kernel oopses or segfaults. I haven't investigated this further, so I don't know (A) if this is correct or (B) if this same issue appears elsewhere in the code. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Fri Oct 1 20:42:19 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 01 Oct 2004 20:42:21 -0700 (PDT) Received: from visualfx.animezone.org (CPE006097a16e12-CM400026313227.cpe.net.cable.rogers.com [24.101.19.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i923gIHL019095 for ; Fri, 1 Oct 2004 20:42:19 -0700 Received: from [192.168.68.5] (picasso.animezone.org [192.168.68.5]) by visualfx.animezone.org (8.12.8/8.12.8) with ESMTP id i923RqJM031052 for ; Fri, 1 Oct 2004 23:27:53 -0400 Message-ID: <415E2385.4020308@animezone.org> Date: Fri, 01 Oct 2004 23:41:57 -0400 From: Andrew Ho User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs Subject: 2.4.21-20.EL - XFS Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.43 X-archive-position: 4206 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: andrewho@animezone.org Precedence: bulk X-list: linux-xfs I am looking for this kernel for testing. Thanks, Andrew From owner-linux-xfs Sun Oct 3 17:22:00 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 03 Oct 2004 17:22:01 -0700 (PDT) Received: from snort.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i940LwGS005915 for ; Sun, 3 Oct 2004 17:21:59 -0700 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i940Ldxu27541614 for ; Mon, 4 Oct 2004 10:21:40 +1000 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i940Lcqu27591292 for linux-xfs@oss.sgi.com; Mon, 4 Oct 2004 10:21:38 +1000 (EST) Date: Mon, 4 Oct 2004 10:21:38 +1000 (EST) From: Nathan Scott Message-Id: <200410040021.i940Lcqu27591292@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE 907752 - fix userspace dmapi build X-archive-position: 4207 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Fix DMAPI userspace source to include fewer kernel headers directly, and include XFS headers via the usual libxfs.h interface. Date: Sun Oct 3 17:20:59 PDT 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/us-xfs-cmds Inspected by: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:180254a dmapi/include/dmapi_kern.h - 1.15 dmapi/libdm/dm_handle2path.c - 1.12 dmapi/libdm/dm_handle.c - 1.8 From owner-linux-xfs Sun Oct 3 19:05:11 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 03 Oct 2004 19:05:15 -0700 (PDT) Received: from tyo202.gate.nec.co.jp (TYO202.gate.nec.co.jp [202.32.8.202]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i942597p007806 for ; Sun, 3 Oct 2004 19:05:10 -0700 Received: from mailgate4.nec.co.jp (mailgate54.nec.co.jp [10.7.69.193]) by tyo202.gate.nec.co.jp (8.11.7/3.7W01080315) with ESMTP id i9424on06897 for ; Mon, 4 Oct 2004 11:04:50 +0900 (JST) Received: (from root@localhost) by mailgate4.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id i9424np22052 for linux-xfs@oss.sgi.com; Mon, 4 Oct 2004 11:04:49 +0900 (JST) Received: from secsv3.tnes.nec.co.jp (tnesvc2.tnes.nec.co.jp [10.1.101.15]) by mailsv5.nec.co.jp (8.11.7/3.7W-MAILSV4-NEC) with ESMTP id i9424gN25573 for ; Mon, 4 Oct 2004 11:04:42 +0900 (JST) Received: from tnesvc2.tnes.nec.co.jp ([10.1.101.15]) by secsv3.tnes.nec.co.jp (ExpressMail 5.10) with SMTP id 20041004.111023.03101996 for ; Mon, 4 Oct 2004 11:10:23 +0900 Received: FROM tnesgate.tnes.nec.co.jp BY tnesvc2.tnes.nec.co.jp ; Mon Oct 04 11:10:21 2004 +0900 Received: from rifu.bsd.tnes.nec.co.jp (rifu.bsd.tnes.nec.co.jp [10.1.104.1]) by tnesgate.tnes.nec.co.jp (8.11.6/3.7W00091816) with ESMTP id i9424el37262; Mon, 4 Oct 2004 11:04:40 +0900 (JST) Received: from tnes.nec.co.jp (TNESB9148.bsd.tnes.nec.co.jp [10.1.104.178]) by rifu.bsd.tnes.nec.co.jp (8.11.6/3.7W/BSD-TNES-MX01) with SMTP id i9424eX00619; Mon, 4 Oct 2004 11:04:40 +0900 From: "Tatsuko Yasugahira(Ohata)" To: ASANO Masahiro , nathans@sgi.com Cc: linux-xfs@oss.sgi.com Subject: Re: a deadlock at xfs_growfs Date: Mon, 04 Oct 2004 11:04:40 +0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="Boundary-bJSx4WX8uyVvfWdP65HLB" X-Mailer: TuruKame 3.66 (WinNT,501) In-Reply-To: <20040825.182131.466644752.masano@tnes.nec.co.jp> References: <20040825.182131.466644752.masano@tnes.nec.co.jp> Message-Id: <82C4A9B682002Ftatsu@tnes.nec.co.jp> X-archive-position: 4208 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tatsu@tnes.nec.co.jp Precedence: bulk X-list: linux-xfs --Boundary-bJSx4WX8uyVvfWdP65HLB Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Content-Description: Mail message body Hi SGI guys, From: ASANO Masahiro To: nathans@sgi.com Date: Wed, 25 Aug 2004 18:21:31 +0900 (JST) >> > The following is a kernel backtrace. Its kernel version was 2.4.25, >> > but I guess that the recent kernel also has the same problem. What do >> > you think of it? >> >> I would expect this deadlock still exists, I don't remember fixing >> it or seeing anyone else fix it - do you have a reproducible test >> case? > >I'll do it later. This deadlock problem were reproduced in the environment of 2.4.25+maxagi.patch and 2.4.27+maxagi.patch. I made the test tool which can reproduce the problem. growfs.sh subgrowfs.sh Please, try them. I made patch for 2.4.25+maxagi.patch. growfs.patch This patch changed the allocation method of m_perag and deleted the lock of m_peraglock. When applying this patch, the deadlock problem seems to be fixed. But, when the error has occurred, the memory leak problem happens. What do you think of this patch? ----- tatsu --Boundary-bJSx4WX8uyVvfWdP65HLB Content-Type: application/octet-stream; name="growfs.sh" Content-Disposition: attachment; filename="growfs.sh" Content-Transfer-Encoding: BASE64 IyEvYmluL2Jhc2gKCm95YV9kaXI9L3RtcAprb19zaGVsbD0vdG1wL3N1Ymdy b3dmcy5zaAptb3VudGRpcj0vbW50L3Njb3JlCmRldmljZWRpcj0vZGV2L3Zn NTAvc2NvcmUKCmNudD0xCm1rZGlyICRtb3VudGRpcgoKdHJhcCAnZWNobyAi LS0gdHJhcCAiCiAgICAgICAgY2QgJG95YV9kaXIKICAgICAgICBmdXNlciAt bWsgJG1vdW50ZGlyCiAgICAgICAgc2xlZXAgNQogICAgICAgIHBzIC1hdXgK ICAgICAgICB1bW91bnQgJGRldmljZWRpcgogICAgICAgIGV4aXQgMSAnIDIK CmVjaG8gIl8vXy9fLyBTVEFSVCBUUCIKd2hpbGUgdHJ1ZQpkbwogICAgICAg IGVjaG8gIl8vXy8gJGNudCB0aW1lKHMpLiIKICAgICAgICBpZiAvc2Jpbi9t a2ZzLnhmcyAtZiAtZCBzaXplPTEwMDBtICRkZXZpY2VkaXIKICAgICAgICB0 aGVuCiAgICAgICAgICAgICAgICBlY2hvIG1rZnMueGZzCiAgICAgICAgZWxz ZQogICAgICAgICAgICAgICAgZXhpdCAxCiAgICAgICAgZmkKCiAgICAgICAg aWYgbW91bnQgLXQgeGZzICRkZXZpY2VkaXIgJG1vdW50ZGlyCiAgICAgICAg dGhlbgogICAgICAgICAgICAgICAgZWNobyBtb3VudAogICAgICAgIGVsc2UK ICAgICAgICAgICAgICAgIGV4aXQgMQogICAgICAgIGZpCgogICAgICAgIG1r ZGlyICRtb3VudGRpci9hCiAgICAgICAgbWtkaXIgJG1vdW50ZGlyL2IKICAg ICAgICBta2RpciAkbW91bnRkaXIvYwogICAgICAgIG1rZGlyICRtb3VudGRp ci9kCgogICAgICAgIGlmIGNkICRtb3VudGRpci9hCiAgICAgICAgdGhlbgog ICAgICAgICAgICAgICAgc2ggJGtvX3NoZWxsICYKICAgICAgICBmaQoKICAg ICAgICBpZiBjZCAkbW91bnRkaXIvYgogICAgICAgIHRoZW4KICAgICAgICAg ICAgICAgIHNsZWVwIDMwCiAgICAgICAgICAgICAgICBzaCAka29fc2hlbGwg JgogICAgICAgIGZpCgogICAgICAgIGlmIGNkICRtb3VudGRpci9jCiAgICAg ICAgdGhlbgogICAgICAgICAgICAgICAgc2xlZXAgMzAKICAgICAgICAgICAg ICAgIHNoICRrb19zaGVsbCAmCiAgICAgICAgZmkKCiAgICAgICAgaWYgY2Qg JG1vdW50ZGlyL2QKICAgICAgICB0aGVuCiAgICAgICAgICAgICAgICBzbGVl cCAyMAogICAgICAgICAgICAgICAgc2ggJGtvX3NoZWxsICYKICAgICAgICBm aQoKICAgICAgICBzbGVlcCA2MAogICAgICAgIGVjaG8gZ3Jvd2ZzLS0xCiAg ICAgICAgL3Vzci9zYmluL3hmc19ncm93ZnMgLUQgNDAwMDAwICRtb3VudGRp cgogICAgICAgIHNsZWVwIDQwCiAgICAgICAgZWNobyBncm93ZnMtLTIKICAg ICAgICAvdXNyL3NiaW4veGZzX2dyb3dmcyAtRCA1MDAwMDAgJG1vdW50ZGly CiAgICAgICAgc2xlZXAgMjAKICAgICAgICBlY2hvIGdyb3dmcy0tMwogICAg ICAgIC91c3Ivc2Jpbi94ZnNfZ3Jvd2ZzIC1EIDYwMDAwMCAkbW91bnRkaXIK ICAgICAgICBzbGVlcCAzMAogICAgICAgIGVjaG8gZ3Jvd2ZzLS00CiAgICAg ICAgL3Vzci9zYmluL3hmc19ncm93ZnMgLUQgNzAwMDAwICRtb3VudGRpcgog ICAgICAgIHNsZWVwIDIwCiAgICAgICAgZWNobyBncm93ZnMtLTUKICAgICAg ICAvdXNyL3NiaW4veGZzX2dyb3dmcyAtRCA4MDAwMDAgJG1vdW50ZGlyCiAg ICAgICAgc2xlZXAgMjAKICAgICAgICBlY2hvIGdyb3dmcy0tNgogICAgICAg IC91c3Ivc2Jpbi94ZnNfZ3Jvd2ZzIC1EIDkwMDAwMCAkbW91bnRkaXIKCiAg ICAgICAgY2QgJG95YV9kaXIKCiAgICAgICAgZWNobyAiQmVmb3JlIGtpbGwi CiAgICAgICAgcHMgLWF1eAoKICAgICAgICBmdXNlciAtbWsgJG1vdW50ZGly CgogICAgICAgIHNsZWVwIDE1CiAgICAgICAgZWNobyAiQWZ0ZXIga2lsbCIK ICAgICAgICBwcyAtYXV4CgogICAgICAgIHVtb3VudCAkZGV2aWNlZGlyCiAg ICAgICAgaWYgWyAkPyAtbmUgMCBdO3RoZW4KICAgICAgICAgICAgICAgIGVj aG8gInVtb3VudCBlcnJvci4iCiAgICAgICAgICAgICAgICBicmVhawogICAg ICAgIGZpCgogICAgICAgIGxldCBjbnQ9JGNudCsxCiMgICAgICAgIGlmIFsg JGNudCAtZ3QgMiBdO3RoZW4KIyAgICAgICAgICAgICAgICBicmVhawojICAg ICAgICBmaQpkb25lCgplY2hvICJfL18vXy8gRU5EIFRQIgo= --Boundary-bJSx4WX8uyVvfWdP65HLB Content-Type: application/octet-stream; name="subgrowfs.sh" Content-Disposition: attachment; filename="subgrowfs.sh" Content-Transfer-Encoding: BASE64 IyEvYmluL2Jhc2gKCndoaWxlIFsgMSBdCmRvCiAgICAgICAgdGFyIC16eGYg L3RtcC9saW51eC1zcmMudGd6CiAgICAgICAgcm0gLXJmIGxpbnV4Kgpkb25l Cg== --Boundary-bJSx4WX8uyVvfWdP65HLB Content-Type: application/octet-stream; name="growfs.patch" Content-Disposition: attachment; filename="growfs.patch" Content-Transfer-Encoding: BASE64 LS0tIGxpbnV4LTIuNC4yNS9mcy94ZnMveGZzX2FsbG9jLmMub3JnCTIwMDQt MDgtMjcgMjE6NDc6MzIuMDAwMDAwMDAwICswOTAwCisrKyBsaW51eC0yLjQu MjUvZnMveGZzL3hmc19hbGxvYy5jCTIwMDQtMDgtMjcgMjI6MDM6MDkuMDAw MDAwMDAwICswOTAwCkBAIC0xNzYyLDcgKzE3NjIsNyBAQCB4ZnNfZnJlZV9h Z19leHRlbnQoCiAJCXhmc19wZXJhZ190CSpwYWc7CQkvKiBwZXIgYWxsb2Nh dGlvbiBncm91cCBkYXRhICovCiAKIAkJYWdmID0gWEZTX0JVRl9UT19BR0Yo YWdicCk7Ci0JCXBhZyA9ICZtcC0+bV9wZXJhZ1thZ25vXTsKKwkJcGFnID0g bXAtPm1fcGVyYWdbYWdub107CiAJCUlOVF9NT0QoYWdmLT5hZ2ZfZnJlZWJs a3MsIEFSQ0hfQ09OVkVSVCwgbGVuKTsKIAkJeGZzX3RyYW5zX2FnYmxvY2tz X2RlbHRhKHRwLCBsZW4pOwogCQlwYWctPnBhZ2ZfZnJlZWJsa3MgKz0gbGVu OwpAQCAtMjAzNSw3ICsyMDM1LDcgQEAgeGZzX2FsbG9jX2dldF9mcmVlbGlz dCgKIAl4ZnNfdHJhbnNfYnJlbHNlKHRwLCBhZ2ZsYnApOwogCWlmIChJTlRf R0VUKGFnZi0+YWdmX2ZsZmlyc3QsIEFSQ0hfQ09OVkVSVCkgPT0gWEZTX0FH RkxfU0laRShtcCkpCiAJCUlOVF9aRVJPKGFnZi0+YWdmX2ZsZmlyc3QsIEFS Q0hfQ09OVkVSVCk7Ci0JcGFnID0gJm1wLT5tX3BlcmFnW0lOVF9HRVQoYWdm LT5hZ2Zfc2Vxbm8sIEFSQ0hfQ09OVkVSVCldOworCXBhZyA9IG1wLT5tX3Bl cmFnW0lOVF9HRVQoYWdmLT5hZ2Zfc2Vxbm8sIEFSQ0hfQ09OVkVSVCldOwog CUlOVF9NT0QoYWdmLT5hZ2ZfZmxjb3VudCwgQVJDSF9DT05WRVJULCAtMSk7 CiAJeGZzX3RyYW5zX2FnZmxpc3RfZGVsdGEodHAsIC0xKTsKIAlwYWctPnBh Z2ZfZmxjb3VudC0tOwpAQCAtMjEzNSw3ICsyMTM1LDcgQEAgeGZzX2FsbG9j X3B1dF9mcmVlbGlzdCgKIAlJTlRfTU9EKGFnZi0+YWdmX2ZsbGFzdCwgQVJD SF9DT05WRVJULCAxKTsKIAlpZiAoSU5UX0dFVChhZ2YtPmFnZl9mbGxhc3Qs IEFSQ0hfQ09OVkVSVCkgPT0gWEZTX0FHRkxfU0laRShtcCkpCiAJCUlOVF9a RVJPKGFnZi0+YWdmX2ZsbGFzdCwgQVJDSF9DT05WRVJUKTsKLQlwYWcgPSAm bXAtPm1fcGVyYWdbSU5UX0dFVChhZ2YtPmFnZl9zZXFubywgQVJDSF9DT05W RVJUKV07CisJcGFnID0gbXAtPm1fcGVyYWdbSU5UX0dFVChhZ2YtPmFnZl9z ZXFubywgQVJDSF9DT05WRVJUKV07CiAJSU5UX01PRChhZ2YtPmFnZl9mbGNv dW50LCBBUkNIX0NPTlZFUlQsIDEpOwogCXhmc190cmFuc19hZ2ZsaXN0X2Rl bHRhKHRwLCAxKTsKIAlwYWctPnBhZ2ZfZmxjb3VudCsrOwpAQCAtMjIwMiw3 ICsyMjAyLDcgQEAgeGZzX2FsbG9jX3JlYWRfYWdmKAogCQl4ZnNfdHJhbnNf YnJlbHNlKHRwLCBicCk7CiAJCXJldHVybiBYRlNfRVJST1IoRUZTQ09SUlVQ VEVEKTsKIAl9Ci0JcGFnID0gJm1wLT5tX3BlcmFnW2Fnbm9dOworCXBhZyA9 IG1wLT5tX3BlcmFnW2Fnbm9dOwogCWlmICghcGFnLT5wYWdmX2luaXQpIHsK IAkJcGFnLT5wYWdmX2ZyZWVibGtzID0gSU5UX0dFVChhZ2YtPmFnZl9mcmVl YmxrcywgQVJDSF9DT05WRVJUKTsKIAkJcGFnLT5wYWdmX2ZsY291bnQgPSBJ TlRfR0VUKGFnZi0+YWdmX2ZsY291bnQsIEFSQ0hfQ09OVkVSVCk7CkBAIC0y MjkwLDggKzIyOTAsNyBAQCB4ZnNfYWxsb2NfdmV4dGVudCgKIAkJICogVGhl c2UgdGhyZWUgZm9yY2UgdXMgaW50byBhIHNpbmdsZSBhLmcuCiAJCSAqLwog CQlhcmdzLT5hZ25vID0gWEZTX0ZTQl9UT19BR05PKG1wLCBhcmdzLT5mc2Ju byk7Ci0JCWRvd25fcmVhZCgmbXAtPm1fcGVyYWdsb2NrKTsKLQkJYXJncy0+ cGFnID0gJm1wLT5tX3BlcmFnW2FyZ3MtPmFnbm9dOworCQlhcmdzLT5wYWcg PSBtcC0+bV9wZXJhZ1thcmdzLT5hZ25vXTsKIAkJYXJncy0+bWlubGVmdCA9 IDA7CiAJCWVycm9yID0geGZzX2FsbG9jX2ZpeF9mcmVlbGlzdChhcmdzLCAw KTsKIAkJYXJncy0+bWlubGVmdCA9IG1pbmxlZnQ7CkBAIC0yMzAwLDE0ICsy Mjk5LDEyIEBAIHhmc19hbGxvY192ZXh0ZW50KAogCQkJZ290byBlcnJvcjA7 CiAJCX0KIAkJaWYgKCFhcmdzLT5hZ2JwKSB7Ci0JCQl1cF9yZWFkKCZtcC0+ bV9wZXJhZ2xvY2spOwogCQkJVFJBQ0VfQUxMT0MoIm5vYWdicCIsIGFyZ3Mp OwogCQkJYnJlYWs7CiAJCX0KIAkJYXJncy0+YWdibm8gPSBYRlNfRlNCX1RP X0FHQk5PKG1wLCBhcmdzLT5mc2Jubyk7CiAJCWlmICgoZXJyb3IgPSB4ZnNf YWxsb2NfYWdfdmV4dGVudChhcmdzKSkpCiAJCQlnb3RvIGVycm9yMDsKLQkJ dXBfcmVhZCgmbXAtPm1fcGVyYWdsb2NrKTsKIAkJYnJlYWs7CiAJY2FzZSBY RlNfQUxMT0NUWVBFX1NUQVJUX0JOTzoKIAkJLyoKQEAgLTIzNTYsOSArMjM1 Myw4IEBAIHhmc19hbGxvY192ZXh0ZW50KAogCQkgKiBMb29wIG92ZXIgYWxs b2NhdGlvbiBncm91cHMgdHdpY2U7IGZpcnN0IHRpbWUgd2l0aAogCQkgKiB0 cnlsb2NrIHNldCwgc2Vjb25kIHRpbWUgd2l0aG91dC4KIAkJICovCi0JCWRv d25fcmVhZCgmbXAtPm1fcGVyYWdsb2NrKTsKIAkJZm9yICg7OykgewotCQkJ YXJncy0+cGFnID0gJm1wLT5tX3BlcmFnW2FyZ3MtPmFnbm9dOworCQkJYXJn cy0+cGFnID0gbXAtPm1fcGVyYWdbYXJncy0+YWdub107CiAJCQlpZiAobm9f bWluKSBhcmdzLT5taW5sZWZ0ID0gMDsKIAkJCWVycm9yID0geGZzX2FsbG9j X2ZpeF9mcmVlbGlzdChhcmdzLCBmbGFncyk7CiAJCQlhcmdzLT5taW5sZWZ0 ID0gbWlubGVmdDsKQEAgLTI0MDUsNyArMjQwMSw2IEBAIHhmc19hbGxvY192 ZXh0ZW50KAogCQkJCX0KIAkJCX0KIAkJfQotCQl1cF9yZWFkKCZtcC0+bV9w ZXJhZ2xvY2spOwogCQlpZiAoYnVtcF9yb3RvciB8fCAodHlwZSA9PSBYRlNf QUxMT0NUWVBFX0FOWV9BRykpCiAJCQltcC0+bV9hZ2Zyb3RvciA9IChhcmdz LT5hZ25vICsgMSkgJSBtcC0+bV9zYi5zYl9hZ2NvdW50OwogCQlicmVhazsK QEAgLTI0MjcsNyArMjQyMiw2IEBAIHhmc19hbGxvY192ZXh0ZW50KAogCX0K IAlyZXR1cm4gMDsKIGVycm9yMDoKLQl1cF9yZWFkKCZtcC0+bV9wZXJhZ2xv Y2spOwogCXJldHVybiBlcnJvcjsKIH0KIApAQCAtMjQ1Niw4ICsyNDUwLDcg QEAgeGZzX2ZyZWVfZXh0ZW50KAogCWFyZ3MuYWdibm8gPSBYRlNfRlNCX1RP X0FHQk5PKGFyZ3MubXAsIGJubyk7CiAJYXJncy5hbGlnbm1lbnQgPSAxOwog CWFyZ3MubWlubGVuID0gYXJncy5taW5sZWZ0ID0gYXJncy5taW5hbGlnbnNs b3AgPSAwOwotCWRvd25fcmVhZCgmYXJncy5tcC0+bV9wZXJhZ2xvY2spOwot CWFyZ3MucGFnID0gJmFyZ3MubXAtPm1fcGVyYWdbYXJncy5hZ25vXTsKKwlh cmdzLnBhZyA9IGFyZ3MubXAtPm1fcGVyYWdbYXJncy5hZ25vXTsKIAlpZiAo KGVycm9yID0geGZzX2FsbG9jX2ZpeF9mcmVlbGlzdCgmYXJncywgMCkpKQog CQlnb3RvIGVycm9yMDsKICNpZmRlZiBERUJVRwpAQCAtMjQ2OCw3ICsyNDYx LDYgQEAgeGZzX2ZyZWVfZXh0ZW50KAogCWVycm9yID0geGZzX2ZyZWVfYWdf ZXh0ZW50KHRwLCBhcmdzLmFnYnAsIGFyZ3MuYWdubywgYXJncy5hZ2JubywK IAkJbGVuLCAwKTsKIGVycm9yMDoKLQl1cF9yZWFkKCZhcmdzLm1wLT5tX3Bl cmFnbG9jayk7CiAJcmV0dXJuIGVycm9yOwogfQogCkBAIC0yNDkxLDE0ICsy NDgzLDE2IEBAIHhmc19hbGxvY19tYXJrX2J1c3koeGZzX3RyYW5zX3QgKnRw LAogewogCXhmc19tb3VudF90CQkqbXA7CiAJeGZzX3BlcmFnX2J1c3lfdAkq YnN5OworCXhmc19wZXJhZ190CQkqcGFnOwogCWludAkJCW47CiAJU1BMREVD TChzKTsKIAogCW1wID0gdHAtPnRfbW91bnRwOwotCXMgPSBtdXRleF9zcGlu bG9jaygmbXAtPm1fcGVyYWdbYWdub10ucGFnYl9sb2NrKTsKKwlwYWcgPSBt cC0+bV9wZXJhZ1thZ25vXTsKKwlzID0gbXV0ZXhfc3BpbmxvY2soJnBhZy0+ cGFnYl9sb2NrKTsKIAogCS8qIHNlYXJjaCBwYWdiX2xpc3QgZm9yIGFuIG9w ZW4gc2xvdCAqLwotCWZvciAoYnN5ID0gbXAtPm1fcGVyYWdbYWdub10ucGFn Yl9saXN0LCBuID0gMDsKKwlmb3IgKGJzeSA9IHBhZy0+cGFnYl9saXN0LCBu ID0gMDsKIAkgICAgIG4gPCBYRlNfUEFHQl9OVU1fU0xPVFM7CiAJICAgICBi c3krKywgbisrKSB7CiAJCWlmIChic3ktPmJ1c3lfdHAgPT0gTlVMTCkgewpA QCAtMjUwNyw4ICsyNTAxLDggQEAgeGZzX2FsbG9jX21hcmtfYnVzeSh4ZnNf dHJhbnNfdCAqdHAsCiAJfQogCiAJaWYgKG4gPCBYRlNfUEFHQl9OVU1fU0xP VFMpIHsKLQkJYnN5ID0gJm1wLT5tX3BlcmFnW2Fnbm9dLnBhZ2JfbGlzdFtu XTsKLQkJbXAtPm1fcGVyYWdbYWdub10ucGFnYl9jb3VudCsrOworCQlic3kg PSAmcGFnLT5wYWdiX2xpc3Rbbl07CisJCXBhZy0+cGFnYl9jb3VudCsrOwog CQlUUkFDRV9CVVNZKCJ4ZnNfYWxsb2NfbWFya19idXN5IiwgImdvdCIsIGFn bm8sIGJubywgbGVuLCBuLCB0cCk7CiAJCWJzeS0+YnVzeV9zdGFydCA9IGJu bzsKIAkJYnN5LT5idXN5X2xlbmd0aCA9IGxlbjsKQEAgLTI1MjUsNyArMjUx OSw3IEBAIHhmc19hbGxvY19tYXJrX2J1c3koeGZzX3RyYW5zX3QgKnRwLAog CQl4ZnNfdHJhbnNfc2V0X3N5bmModHApOwogCX0KIAotCW11dGV4X3NwaW51 bmxvY2soJm1wLT5tX3BlcmFnW2Fnbm9dLnBhZ2JfbG9jaywgcyk7CisJbXV0 ZXhfc3BpbnVubG9jaygmcGFnLT5wYWdiX2xvY2ssIHMpOwogfQogCiB2b2lk CkBAIC0yNTM1LDIzICsyNTI5LDI1IEBAIHhmc19hbGxvY19jbGVhcl9idXN5 KHhmc190cmFuc190ICp0cCwKIHsKIAl4ZnNfbW91bnRfdAkJKm1wOwogCXhm c19wZXJhZ19idXN5X3QJKmxpc3Q7CisJeGZzX3BlcmFnX3QJCSpwYWc7CiAJ U1BMREVDTChzKTsKIAogCW1wID0gdHAtPnRfbW91bnRwOwogCi0JcyA9IG11 dGV4X3NwaW5sb2NrKCZtcC0+bV9wZXJhZ1thZ25vXS5wYWdiX2xvY2spOwot CWxpc3QgPSBtcC0+bV9wZXJhZ1thZ25vXS5wYWdiX2xpc3Q7CisJcGFnID0g bXAtPm1fcGVyYWdbYWdub107CisJcyA9IG11dGV4X3NwaW5sb2NrKCZwYWct PnBhZ2JfbG9jayk7CisJbGlzdCA9IHBhZy0+cGFnYl9saXN0OwogCiAJQVNT RVJUKGlkeCA8IFhGU19QQUdCX05VTV9TTE9UUyk7CiAJaWYgKGxpc3RbaWR4 XS5idXN5X3RwID09IHRwKSB7CiAJCVRSQUNFX1VOQlVTWSgieGZzX2FsbG9j X2NsZWFyX2J1c3kiLCAiZm91bmQiLCBhZ25vLCBpZHgsIHRwKTsKIAkJbGlz dFtpZHhdLmJ1c3lfdHAgPSBOVUxMOwotCQltcC0+bV9wZXJhZ1thZ25vXS5w YWdiX2NvdW50LS07CisJCXBhZy0+cGFnYl9jb3VudC0tOwogCX0gZWxzZSB7 CiAJCVRSQUNFX1VOQlVTWSgieGZzX2FsbG9jX2NsZWFyX2J1c3kiLCAibWlz c2luZyIsIGFnbm8sIGlkeCwgdHApOwogCX0KIAotCW11dGV4X3NwaW51bmxv Y2soJm1wLT5tX3BlcmFnW2Fnbm9dLnBhZ2JfbG9jaywgcyk7CisJbXV0ZXhf c3BpbnVubG9jaygmcGFnLT5wYWdiX2xvY2ssIHMpOwogfQogCiAKQEAgLTI1 NjYsNiArMjU2Miw3IEBAIHhmc19hbGxvY19zZWFyY2hfYnVzeSh4ZnNfdHJh bnNfdCAqdHAsCiB7CiAJeGZzX21vdW50X3QJCSptcDsKIAl4ZnNfcGVyYWdf YnVzeV90CSpic3k7CisJeGZzX3BlcmFnX3QJCSpwYWc7CiAJaW50CQkJbjsK IAl4ZnNfYWdibG9ja190CQl1ZW5kLCBiZW5kOwogCXhmc19sc25fdAkJbHNu OwpAQCAtMjU3MywxNCArMjU3MCwxNSBAQCB4ZnNfYWxsb2Nfc2VhcmNoX2J1 c3koeGZzX3RyYW5zX3QgKnRwLAogCVNQTERFQ0wocyk7CiAKIAltcCA9IHRw LT50X21vdW50cDsKKwlwYWcgPSBtcC0+bV9wZXJhZ1thZ25vXTsKIAotCXMg PSBtdXRleF9zcGlubG9jaygmbXAtPm1fcGVyYWdbYWdub10ucGFnYl9sb2Nr KTsKLQljbnQgPSBtcC0+bV9wZXJhZ1thZ25vXS5wYWdiX2NvdW50OworCXMg PSBtdXRleF9zcGlubG9jaygmcGFnLT5wYWdiX2xvY2spOworCWNudCA9IHBh Zy0+cGFnYl9jb3VudDsKIAogCXVlbmQgPSBibm8gKyBsZW4gLSAxOwogCiAJ Lyogc2VhcmNoIHBhZ2JfbGlzdCBmb3IgdGhpcyBzbG90LCBza2lwcGluZyBv cGVuIHNsb3RzICovCi0JZm9yIChic3kgPSBtcC0+bV9wZXJhZ1thZ25vXS5w YWdiX2xpc3QsIG4gPSAwOworCWZvciAoYnN5ID0gcGFnLT5wYWdiX2xpc3Qs IG4gPSAwOwogCSAgICAgY250OyBic3krKywgbisrKSB7CiAKIAkJLyoKQEAg LTI2MDcsMTIgKzI2MDUsMTIgQEAgeGZzX2FsbG9jX3NlYXJjaF9idXN5KHhm c190cmFuc190ICp0cCwKIAlpZiAoY250KSB7CiAJCVRSQUNFX0JVU1lTRUFS Q0goInhmc19hbGxvY19zZWFyY2hfYnVzeSIsICJmb3VuZCIsIGFnbm8sIGJu bywgbGVuLCBuLCB0cCk7CiAJCWxzbiA9IGJzeS0+YnVzeV90cC0+dF9jb21t aXRfbHNuOwotCQltdXRleF9zcGludW5sb2NrKCZtcC0+bV9wZXJhZ1thZ25v XS5wYWdiX2xvY2ssIHMpOworCQltdXRleF9zcGludW5sb2NrKCZwYWctPnBh Z2JfbG9jaywgcyk7CiAJCXhmc19sb2dfZm9yY2UobXAsIGxzbiwgWEZTX0xP R19GT1JDRXxYRlNfTE9HX1NZTkMpOwogCX0gZWxzZSB7CiAJCVRSQUNFX0JV U1lTRUFSQ0goInhmc19hbGxvY19zZWFyY2hfYnVzeSIsICJub3QtZm91bmQi LCBhZ25vLCBibm8sIGxlbiwgbiwgdHApOwogCQluID0gLTE7Ci0JCW11dGV4 X3NwaW51bmxvY2soJm1wLT5tX3BlcmFnW2Fnbm9dLnBhZ2JfbG9jaywgcyk7 CisJCW11dGV4X3NwaW51bmxvY2soJnBhZy0+cGFnYl9sb2NrLCBzKTsKIAl9 CiAKIAlyZXR1cm4gbjsKLS0tIGxpbnV4LTIuNC4yNS9mcy94ZnMveGZzX2Fs bG9jX2J0cmVlLmMub3JnCTIwMDQtMDgtMjcgMjE6NDc6NDkuMDAwMDAwMDAw ICswOTAwCisrKyBsaW51eC0yLjQuMjUvZnMveGZzL3hmc19hbGxvY19idHJl ZS5jCTIwMDQtMDgtMjcgMjE6NDk6MTEuMDAwMDAwMDAwICswOTAwCkBAIC0y MTAsNyArMjEwLDcgQEAgeGZzX2FsbG9jX2RlbHJlYygKIAkJICovCiAJCWVs c2UKIAkJCUlOVF9aRVJPKGFnZi0+YWdmX2xvbmdlc3QsIEFSQ0hfQ09OVkVS VCk7Ci0JCW1wLT5tX3BlcmFnW0lOVF9HRVQoYWdmLT5hZ2Zfc2Vxbm8sIEFS Q0hfQ09OVkVSVCldLnBhZ2ZfbG9uZ2VzdCA9CisJCW1wLT5tX3BlcmFnW0lO VF9HRVQoYWdmLT5hZ2Zfc2Vxbm8sIEFSQ0hfQ09OVkVSVCldLT5wYWdmX2xv bmdlc3QgPQogCQkJSU5UX0dFVChhZ2YtPmFnZl9sb25nZXN0LCBBUkNIX0NP TlZFUlQpOwogCQl4ZnNfYWxsb2NfbG9nX2FnZihjdXItPmJjX3RwLCBjdXIt PmJjX3ByaXZhdGUuYS5hZ2JwLAogCQkJWEZTX0FHRl9MT05HRVNUKTsKQEAg LTIzMyw3ICsyMzMsNyBAQCB4ZnNfYWxsb2NfZGVscmVjKAogCQkJYm5vID0g SU5UX0dFVChhZ2YtPmFnZl9yb290c1tjdXItPmJjX2J0bnVtXSwgQVJDSF9D T05WRVJUKTsKIAkJCUlOVF9DT1BZKGFnZi0+YWdmX3Jvb3RzW2N1ci0+YmNf YnRudW1dLCAqbHBwLCBBUkNIX0NPTlZFUlQpOwogCQkJSU5UX01PRChhZ2Yt PmFnZl9sZXZlbHNbY3VyLT5iY19idG51bV0sIEFSQ0hfQ09OVkVSVCwgLTEp OwotCQkJbXAtPm1fcGVyYWdbSU5UX0dFVChhZ2YtPmFnZl9zZXFubywgQVJD SF9DT05WRVJUKV0ucGFnZl9sZXZlbHNbY3VyLT5iY19idG51bV0tLTsKKwkJ CW1wLT5tX3BlcmFnW0lOVF9HRVQoYWdmLT5hZ2Zfc2Vxbm8sIEFSQ0hfQ09O VkVSVCldLT5wYWdmX2xldmVsc1tjdXItPmJjX2J0bnVtXS0tOwogCQkJLyoK IAkJCSAqIFB1dCB0aGlzIGJ1ZmZlci9ibG9jayBvbiB0aGUgYWcncyBmcmVl bGlzdC4KIAkJCSAqLwpAQCAtODEyLDcgKzgxMiw3IEBAIHhmc19hbGxvY19p bnNyZWMoCiAJCSAqIHRoYW4gdGhlIHByZXZpb3VzIGxvbmdlc3QgYmxvY2ss IHVwZGF0ZSBpdC4KIAkJICovCiAJCUlOVF9DT1BZKGFnZi0+YWdmX2xvbmdl c3QsIHJlY3AtPmFyX2Jsb2NrY291bnQsIEFSQ0hfQ09OVkVSVCk7Ci0JCWN1 ci0+YmNfbXAtPm1fcGVyYWdbSU5UX0dFVChhZ2YtPmFnZl9zZXFubywgQVJD SF9DT05WRVJUKV0ucGFnZl9sb25nZXN0CisJCWN1ci0+YmNfbXAtPm1fcGVy YWdbSU5UX0dFVChhZ2YtPmFnZl9zZXFubywgQVJDSF9DT05WRVJUKV0tPnBh Z2ZfbG9uZ2VzdAogCQkJPSBJTlRfR0VUKHJlY3AtPmFyX2Jsb2NrY291bnQs IEFSQ0hfQ09OVkVSVCk7CiAJCXhmc19hbGxvY19sb2dfYWdmKGN1ci0+YmNf dHAsIGN1ci0+YmNfcHJpdmF0ZS5hLmFnYnAsCiAJCQlYRlNfQUdGX0xPTkdF U1QpOwpAQCAtMTM0Miw3ICsxMzQyLDcgQEAgeGZzX2FsbG9jX25ld3Jvb3Qo CiAJCUlOVF9TRVQoYWdmLT5hZ2Zfcm9vdHNbY3VyLT5iY19idG51bV0sIEFS Q0hfQ09OVkVSVCwgbmJubyk7CiAJCUlOVF9NT0QoYWdmLT5hZ2ZfbGV2ZWxz W2N1ci0+YmNfYnRudW1dLCBBUkNIX0NPTlZFUlQsIDEpOwogCQlzZXFubyA9 IElOVF9HRVQoYWdmLT5hZ2Zfc2Vxbm8sIEFSQ0hfQ09OVkVSVCk7Ci0JCW1w LT5tX3BlcmFnW3NlcW5vXS5wYWdmX2xldmVsc1tjdXItPmJjX2J0bnVtXSsr OworCQltcC0+bV9wZXJhZ1tzZXFub10tPnBhZ2ZfbGV2ZWxzW2N1ci0+YmNf YnRudW1dKys7CiAJCXhmc19hbGxvY19sb2dfYWdmKGN1ci0+YmNfdHAsIGN1 ci0+YmNfcHJpdmF0ZS5hLmFnYnAsCiAJCQlYRlNfQUdGX1JPT1RTIHwgWEZT X0FHRl9MRVZFTFMpOwogCX0KQEAgLTIxODQsNyArMjE4NCw3IEBAIHhmc19h bGxvY191cGRhdGUoCiAKIAkJYWdmID0gWEZTX0JVRl9UT19BR0YoY3VyLT5i Y19wcml2YXRlLmEuYWdicCk7CiAJCXNlcW5vID0gSU5UX0dFVChhZ2YtPmFn Zl9zZXFubywgQVJDSF9DT05WRVJUKTsKLQkJY3VyLT5iY19tcC0+bV9wZXJh Z1tzZXFub10ucGFnZl9sb25nZXN0ID0gbGVuOworCQljdXItPmJjX21wLT5t X3BlcmFnW3NlcW5vXS0+cGFnZl9sb25nZXN0ID0gbGVuOwogCQlJTlRfU0VU KGFnZi0+YWdmX2xvbmdlc3QsIEFSQ0hfQ09OVkVSVCwgbGVuKTsKIAkJeGZz X2FsbG9jX2xvZ19hZ2YoY3VyLT5iY190cCwgY3VyLT5iY19wcml2YXRlLmEu YWdicCwKIAkJCVhGU19BR0ZfTE9OR0VTVCk7Ci0tLSBsaW51eC0yLjQuMjUv ZnMveGZzL3hmc19ibWFwLmMub3JnCTIwMDQtMDgtMjcgMjE6NDc6NTUuMDAw MDAwMDAwICswOTAwCisrKyBsaW51eC0yLjQuMjUvZnMveGZzL3hmc19ibWFw LmMJMjAwNC0wOC0yNyAyMTo0OToyNC4wMDAwMDAwMDAgKzA5MDAKQEAgLTI1 NDAsMTMgKzI1NDAsMTEgQEAgeGZzX2JtYXBfYWxsb2MoCiAJCQkgKi8KIAkJ CXN0YXJ0YWcgPSBhZyA9IFhGU19GU0JfVE9fQUdOTyhtcCwgYXJncy5mc2Ju byk7CiAJCQlub3Rpbml0ID0gMDsKLQkJCWRvd25fcmVhZCgmbXAtPm1fcGVy YWdsb2NrKTsKIAkJCXdoaWxlIChibGVuIDwgYXAtPmFsZW4pIHsKLQkJCQlw YWcgPSAmbXAtPm1fcGVyYWdbYWddOworCQkJCXBhZyA9IG1wLT5tX3BlcmFn W2FnXTsKIAkJCQlpZiAoIXBhZy0+cGFnZl9pbml0ICYmCiAJCQkJICAgIChl cnJvciA9IHhmc19hbGxvY19wYWdmX2luaXQobXAsIGFyZ3MudHAsCiAJCQkJ CSAgICBhZywgWEZTX0FMTE9DX0ZMQUdfVFJZTE9DSykpKSB7Ci0JCQkJCXVw X3JlYWQoJm1wLT5tX3BlcmFnbG9jayk7CiAJCQkJCXJldHVybiBlcnJvcjsK IAkJCQl9CiAJCQkJLyoKQEAgLTI1NjksNyArMjU2Nyw2IEBAIHhmc19ibWFw X2FsbG9jKAogCQkJCWlmIChhZyA9PSBzdGFydGFnKQogCQkJCQlicmVhazsK IAkJCX0KLQkJCXVwX3JlYWQoJm1wLT5tX3BlcmFnbG9jayk7CiAJCQkvKgog CQkJICogU2luY2UgdGhlIGFib3ZlIGxvb3AgZGlkIGEgQlVGX1RSWUxPQ0ss IGl0IGlzCiAJCQkgKiBwb3NzaWJsZSB0aGF0IHRoZXJlIGlzIHNwYWNlIGZv ciB0aGlzIHJlcXVlc3QuCi0tLSBsaW51eC0yLjQuMjUvZnMveGZzL3hmc19p YWxsb2MuYy5vcmcJMjAwNC0wOC0yNyAyMTo0ODoxMC4wMDAwMDAwMDAgKzA5 MDAKKysrIGxpbnV4LTIuNC4yNS9mcy94ZnMveGZzX2lhbGxvYy5jCTIwMDQt MDgtMjcgMjE6NDk6NTEuMDAwMDAwMDAwICswOTAwCkBAIC0yOTYsOSArMjk2 LDcgQEAgeGZzX2lhbGxvY19hZ19hbGxvYygKIAl9CiAJSU5UX01PRChhZ2kt PmFnaV9jb3VudCwgQVJDSF9DT05WRVJULCBuZXdsZW4pOwogCUlOVF9NT0Qo YWdpLT5hZ2lfZnJlZWNvdW50LCBBUkNIX0NPTlZFUlQsIG5ld2xlbik7Ci0J ZG93bl9yZWFkKCZhcmdzLm1wLT5tX3BlcmFnbG9jayk7Ci0JYXJncy5tcC0+ bV9wZXJhZ1tJTlRfR0VUKGFnaS0+YWdpX3NlcW5vLCBBUkNIX0NPTlZFUlQp XS5wYWdpX2ZyZWVjb3VudCArPSBuZXdsZW47Ci0JdXBfcmVhZCgmYXJncy5t cC0+bV9wZXJhZ2xvY2spOworCWFyZ3MubXAtPm1fcGVyYWdbSU5UX0dFVChh Z2ktPmFnaV9zZXFubywgQVJDSF9DT05WRVJUKV0tPnBhZ2lfZnJlZWNvdW50 ICs9IG5ld2xlbjsKIAlJTlRfU0VUKGFnaS0+YWdpX25ld2lubywgQVJDSF9D T05WRVJULCBuZXdpbm8pOwogCS8qCiAJICogSW5zZXJ0IHJlY29yZHMgZGVz Y3JpYmluZyB0aGUgbmV3IGlub2RlIGNodW5rIGludG8gdGhlIGJ0cmVlLgpA QCAtMzk3LDkgKzM5NSw4IEBAIHhmc19pYWxsb2NfYWdfc2VsZWN0KAogCSAq LwogCWFnbm8gPSBwYWdubzsKIAlmbGFncyA9IFhGU19BTExPQ19GTEFHX1RS WUxPQ0s7Ci0JZG93bl9yZWFkKCZtcC0+bV9wZXJhZ2xvY2spOwogCWZvciAo OzspIHsKLQkJcGFnID0gJm1wLT5tX3BlcmFnW2Fnbm9dOworCQlwYWcgPSBt cC0+bV9wZXJhZ1thZ25vXTsKIAkJaWYgKCFwYWctPnBhZ2lfaW5pdCkgewog CQkJaWYgKHhmc19pYWxsb2NfcmVhZF9hZ2kobXAsIHRwLCBhZ25vLCAmYWdi cCkpIHsKIAkJCQlhZ2JwID0gTlVMTDsKQEAgLTQzOCw3ICs0MzUsNiBAQCB4 ZnNfaWFsbG9jX2FnX3NlbGVjdCgKIAkJCQkJYWdicCA9IE5VTEw7CiAJCQkJ CWdvdG8gbmV4dGFnOwogCQkJCX0KLQkJCQl1cF9yZWFkKCZtcC0+bV9wZXJh Z2xvY2spOwogCQkJCXJldHVybiBhZ2JwOwogCQkJfQogCQl9CkBAIC00NTEs NyArNDQ3LDYgQEAgbmV4dGFnOgogCQkgKiBkb3duLgogCQkgKi8KIAkJaWYg KFhGU19GT1JDRURfU0hVVERPV04obXApKSB7Ci0JCQl1cF9yZWFkKCZtcC0+ bV9wZXJhZ2xvY2spOwogCQkJcmV0dXJuICh4ZnNfYnVmX3QgKikwOwogCQl9 CiAJCWFnbm8rKzsKQEAgLTQ1OSw3ICs0NTQsNiBAQCBuZXh0YWc6CiAJCQlh Z25vID0gMDsKIAkJaWYgKGFnbm8gPT0gcGFnbm8pIHsKIAkJCWlmIChmbGFn cyA9PSAwKSB7Ci0JCQkJdXBfcmVhZCgmbXAtPm1fcGVyYWdsb2NrKTsKIAkJ CQlyZXR1cm4gKHhmc19idWZfdCAqKTA7CiAJCQl9CiAJCQlmbGFncyA9IDA7 CkBAIC02MjYsMTMgKzYyMCwxMCBAQCBuZXh0YWc6CiAJCQkqaW5vcCA9IE5V TExGU0lOTzsKIAkJCXJldHVybiBub3Jvb20gPyBFTk9TUEMgOiAwOwogCQl9 Ci0JCWRvd25fcmVhZCgmbXAtPm1fcGVyYWdsb2NrKTsKLQkJaWYgKG1wLT5t X3BlcmFnW3RhZ25vXS5wYWdpX2lub2Rlb2sgPT0gMCkgewotCQkJdXBfcmVh ZCgmbXAtPm1fcGVyYWdsb2NrKTsKKwkJaWYgKG1wLT5tX3BlcmFnW3RhZ25v XS0+cGFnaV9pbm9kZW9rID09IDApIHsKIAkJCWdvdG8gbmV4dGFnOwogCQl9 CiAJCWVycm9yID0geGZzX2lhbGxvY19yZWFkX2FnaShtcCwgdHAsIHRhZ25v LCAmYWdicCk7Ci0JCXVwX3JlYWQoJm1wLT5tX3BlcmFnbG9jayk7CiAJCWlm IChlcnJvcikKIAkJCWdvdG8gbmV4dGFnOwogCQlhZ2kgPSBYRlNfQlVGX1RP X0FHSShhZ2JwKTsKQEAgLTg4MCw5ICs4NzEsNyBAQCBuZXh0YWc6CiAJCWdv dG8gZXJyb3IwOwogCUlOVF9NT0QoYWdpLT5hZ2lfZnJlZWNvdW50LCBBUkNI X0NPTlZFUlQsIC0xKTsKIAl4ZnNfaWFsbG9jX2xvZ19hZ2kodHAsIGFnYnAs IFhGU19BR0lfRlJFRUNPVU5UKTsKLQlkb3duX3JlYWQoJm1wLT5tX3BlcmFn bG9jayk7Ci0JbXAtPm1fcGVyYWdbdGFnbm9dLnBhZ2lfZnJlZWNvdW50LS07 Ci0JdXBfcmVhZCgmbXAtPm1fcGVyYWdsb2NrKTsKKwltcC0+bV9wZXJhZ1t0 YWdub10tPnBhZ2lfZnJlZWNvdW50LS07CiAjaWZkZWYgREVCVUcKIAlpZiAo Y3VyLT5iY19ubGV2ZWxzID09IDEpIHsKIAkJaW50CWZyZWVjb3VudCA9IDA7 CkBAIC05NzMsOSArOTYyLDcgQEAgeGZzX2RpZnJlZSgKIAkvKgogCSAqIEdl dCB0aGUgYWxsb2NhdGlvbiBncm91cCBoZWFkZXIuCiAJICovCi0JZG93bl9y ZWFkKCZtcC0+bV9wZXJhZ2xvY2spOwogCWVycm9yID0geGZzX2lhbGxvY19y ZWFkX2FnaShtcCwgdHAsIGFnbm8sICZhZ2JwKTsKLQl1cF9yZWFkKCZtcC0+ bV9wZXJhZ2xvY2spOwogCWlmIChlcnJvcikgewogCQljbW5fZXJyKENFX1dB Uk4sCiAJCQkieGZzX2RpZnJlZTogeGZzX2lhbGxvY19yZWFkX2FnaSgpIHJl dHVybmVkIGFuIGVycm9yICVkIG9uICVzLiAgUmV0dXJuaW5nIGVycm9yLiIs CkBAIC0xMDU4LDkgKzEwNDUsNyBAQCB4ZnNfZGlmcmVlKAogCQlJTlRfTU9E KGFnaS0+YWdpX2NvdW50LCBBUkNIX0NPTlZFUlQsIC1pbGVuKTsKIAkJSU5U X01PRChhZ2ktPmFnaV9mcmVlY291bnQsIEFSQ0hfQ09OVkVSVCwgLShpbGVu IC0gMSkpOwogCQl4ZnNfaWFsbG9jX2xvZ19hZ2kodHAsIGFnYnAsIFhGU19B R0lfQ09VTlQgfCBYRlNfQUdJX0ZSRUVDT1VOVCk7Ci0JCWRvd25fcmVhZCgm bXAtPm1fcGVyYWdsb2NrKTsKLQkJbXAtPm1fcGVyYWdbYWdub10ucGFnaV9m cmVlY291bnQgLT0gaWxlbiAtIDE7Ci0JCXVwX3JlYWQoJm1wLT5tX3BlcmFn bG9jayk7CisJCW1wLT5tX3BlcmFnW2Fnbm9dLT5wYWdpX2ZyZWVjb3VudCAt PSBpbGVuIC0gMTsKIAkJeGZzX3RyYW5zX21vZF9zYih0cCwgWEZTX1RSQU5T X1NCX0lDT1VOVCwgLWlsZW4pOwogCQl4ZnNfdHJhbnNfbW9kX3NiKHRwLCBY RlNfVFJBTlNfU0JfSUZSRUUsIC0oaWxlbiAtIDEpKTsKIApAQCAtMTA4Nyw5 ICsxMDcyLDcgQEAgeGZzX2RpZnJlZSgKIAkJICovCiAJCUlOVF9NT0QoYWdp LT5hZ2lfZnJlZWNvdW50LCBBUkNIX0NPTlZFUlQsIDEpOwogCQl4ZnNfaWFs bG9jX2xvZ19hZ2kodHAsIGFnYnAsIFhGU19BR0lfRlJFRUNPVU5UKTsKLQkJ ZG93bl9yZWFkKCZtcC0+bV9wZXJhZ2xvY2spOwotCQltcC0+bV9wZXJhZ1th Z25vXS5wYWdpX2ZyZWVjb3VudCsrOwotCQl1cF9yZWFkKCZtcC0+bV9wZXJh Z2xvY2spOworCQltcC0+bV9wZXJhZ1thZ25vXS0+cGFnaV9mcmVlY291bnQr KzsKIAkJeGZzX3RyYW5zX21vZF9zYih0cCwgWEZTX1RSQU5TX1NCX0lGUkVF LCAxKTsKIAl9CiAKQEAgLTEyMTAsOSArMTE5Myw3IEBAIHhmc19kaWxvY2F0 ZSgKIAkJb2Zmc2V0X2FnYm5vID0gYWdibm8gJiBtcC0+bV9pbm9hbGlnbl9t YXNrOwogCQljaHVua19hZ2JubyA9IGFnYm5vIC0gb2Zmc2V0X2FnYm5vOwog CX0gZWxzZSB7Ci0JCWRvd25fcmVhZCgmbXAtPm1fcGVyYWdsb2NrKTsKIAkJ ZXJyb3IgPSB4ZnNfaWFsbG9jX3JlYWRfYWdpKG1wLCB0cCwgYWdubywgJmFn YnApOwotCQl1cF9yZWFkKCZtcC0+bV9wZXJhZ2xvY2spOwogCQlpZiAoZXJy b3IpIHsKICNpZmRlZiBERUJVRwogCQkJeGZzX2ZzX2Ntbl9lcnIoQ0VfQUxF UlQsIG1wLCAieGZzX2RpbG9jYXRlOiAiCkBAIC0xMzczLDcgKzEzNTQsNyBA QCB4ZnNfaWFsbG9jX3JlYWRfYWdpKAogCQl4ZnNfdHJhbnNfYnJlbHNlKHRw LCBicCk7CiAJCXJldHVybiBYRlNfRVJST1IoRUZTQ09SUlVQVEVEKTsKIAl9 Ci0JcGFnID0gJm1wLT5tX3BlcmFnW2Fnbm9dOworCXBhZyA9IG1wLT5tX3Bl cmFnW2Fnbm9dOwogCWlmICghcGFnLT5wYWdpX2luaXQpIHsKIAkJcGFnLT5w YWdpX2ZyZWVjb3VudCA9IElOVF9HRVQoYWdpLT5hZ2lfZnJlZWNvdW50LCBB UkNIX0NPTlZFUlQpOwogCQlwYWctPnBhZ2lfaW5pdCA9IDE7Ci0tLSBsaW51 eC0yLjQuMjUvZnMveGZzL3hmc19pdGFibGUuYy5vcmcJMjAwNC0wOC0yNyAy MTo0ODoxOS4wMDAwMDAwMDAgKzA5MDAKKysrIGxpbnV4LTIuNC4yNS9mcy94 ZnMveGZzX2l0YWJsZS5jCTIwMDQtMDgtMjcgMjE6NTA6MDAuMDAwMDAwMDAw ICswOTAwCkBAIC0zMzIsOSArMzMyLDcgQEAgeGZzX2J1bGtzdGF0KAogCXJ2 YWwgPSAwOwogCXdoaWxlICh1YmxlZnQgPj0gc3RhdHN0cnVjdF9zaXplICYm IGFnbm8gPCBtcC0+bV9zYi5zYl9hZ2NvdW50KSB7CiAJCWJwID0gTlVMTDsK LQkJZG93bl9yZWFkKCZtcC0+bV9wZXJhZ2xvY2spOwogCQllcnJvciA9IHhm c19pYWxsb2NfcmVhZF9hZ2kobXAsIHRwLCBhZ25vLCAmYWdicCk7Ci0JCXVw X3JlYWQoJm1wLT5tX3BlcmFnbG9jayk7CiAJCWlmIChlcnJvcikgewogCQkJ LyoKIAkJCSAqIFNraXAgdGhpcyBhbGxvY2F0aW9uIGdyb3VwIGFuZCBnbyB0 byB0aGUgbmV4dCBvbmUuCkBAIC03MzEsOSArNzI5LDcgQEAgeGZzX2ludW1i ZXJzKAogCWFnYnAgPSBOVUxMOwogCXdoaWxlIChsZWZ0ID4gMCAmJiBhZ25v IDwgbXAtPm1fc2Iuc2JfYWdjb3VudCkgewogCQlpZiAoYWdicCA9PSBOVUxM KSB7Ci0JCQlkb3duX3JlYWQoJm1wLT5tX3BlcmFnbG9jayk7CiAJCQllcnJv ciA9IHhmc19pYWxsb2NfcmVhZF9hZ2kobXAsIHRwLCBhZ25vLCAmYWdicCk7 Ci0JCQl1cF9yZWFkKCZtcC0+bV9wZXJhZ2xvY2spOwogCQkJaWYgKGVycm9y KSB7CiAJCQkJLyoKIAkJCQkgKiBJZiB3ZSBjYW4ndCByZWFkIHRoZSBBR0kg b2YgdGhpcyBhZywKLS0tIGxpbnV4LTIuNC4yNS9mcy94ZnMveGZzX21vdW50 LmMub3JnCTIwMDQtMDgtMjcgMjE6NDg6MjUuMDAwMDAwMDAwICswOTAwCisr KyBsaW51eC0yLjQuMjUvZnMveGZzL3hmc19tb3VudC5jCTIwMDQtMDgtMjcg MjE6NTA6MTAuMDAwMDAwMDAwICswOTAwCkBAIC0xNjUsMTMgKzE2NSwyMSBA QCB4ZnNfbW91bnRfZnJlZSgKIAlpZiAobXAtPm1fcGVyYWcpIHsKIAkJaW50 CWFnbm87CiAKLQkJZm9yIChhZ25vID0gMDsgYWdubyA8IG1wLT5tX21heGFn aTsgYWdubysrKQotCQkJaWYgKG1wLT5tX3BlcmFnW2Fnbm9dLnBhZ2JfbGlz dCkKLQkJCQlrbWVtX2ZyZWUobXAtPm1fcGVyYWdbYWdub10ucGFnYl9saXN0 LAotCQkJCQkJc2l6ZW9mKHhmc19wZXJhZ19idXN5X3QpICoKLQkJCQkJCQlY RlNfUEFHQl9OVU1fU0xPVFMpOwotCQlrbWVtX2ZyZWUobXAtPm1fcGVyYWcs Ci0JCQkgIHNpemVvZih4ZnNfcGVyYWdfdCkgKiBtcC0+bV9zYi5zYl9hZ2Nv dW50KTsKKwkJZm9yIChhZ25vID0gMDsgYWdubyA8IG1wLT5tX21heGFnaTsg YWdubysrKSB7CisJCQl4ZnNfcGVyYWdfdCAqcGFnID0gbXAtPm1fcGVyYWdb YWdub107CisJCQlpZiAocGFnKSB7CisJCQkJaWYgKHBhZy0+cGFnYl9saXN0 KSB7CisJCQkJCWttZW1fZnJlZShwYWctPnBhZ2JfbGlzdCwKKwkJCQkJCQlz aXplb2YoeGZzX3BlcmFnX2J1c3lfdCkgKgorCQkJCQkJCQlYRlNfUEFHQl9O VU1fU0xPVFMpOworCQkJCQlwYWctPnBhZ2JfbGlzdCA9IE5VTEw7CisJCQkJ fQorCQkJCWttZW1fZnJlZShwYWcsIHNpemVvZih4ZnNfcGVyYWdfdCkpOwor CQkJCW1wLT5tX3BlcmFnW2Fnbm9dID0gTlVMTDsKKwkJCX0KKwkJfQorCQlr bWVtX2ZyZWUobXAtPm1fcGVyYWcsIG1wLT5tX21heGFnaSAqIHNpemVvZih4 ZnNfcGVyYWdfdCAqKSk7CisJCW1wLT5tX3BlcmFnID0gTlVMTDsKIAl9CiAK IAlBSUxfTE9DS19ERVNUUk9ZKCZtcC0+bV9haWxfbG9jayk7CkBAIC0zNjQs NyArMzcyLDcgQEAgeGZzX2luaXRpYWxpemVfcGVyYWcoeGZzX21vdW50X3Qg Km1wLCBpbgogCQkJfQogCiAJCQkvKiBUaGlzIGFnIGlzIHByZWZlcmVkIGZv ciBpbm9kZXMgKi8KLQkJCXBhZyA9ICZtcC0+bV9wZXJhZ1tpbmRleF07CisJ CQlwYWcgPSBtcC0+bV9wZXJhZ1tpbmRleF07CiAJCQlwYWctPnBhZ2lfaW5v ZGVvayA9IDE7CiAJCQlpZiAoaW5kZXggPCBtYXhfbWV0YWRhdGEpCiAJCQkJ cGFnLT5wYWdmX21ldGFkYXRhID0gMTsKQEAgLTM3Miw3ICszODAsNyBAQCB4 ZnNfaW5pdGlhbGl6ZV9wZXJhZyh4ZnNfbW91bnRfdCAqbXAsIGluCiAJfSBl bHNlIHsKIAkJLyogU2V0dXAgZGVmYXVsdCBiZWhhdmlvciBmb3Igc21hbGxl ciBmaWxlc3lzdGVtcyAqLwogCQlmb3IgKGluZGV4ID0gMDsgaW5kZXggPCBh Z2NvdW50OyBpbmRleCsrKSB7Ci0JCQlwYWcgPSAmbXAtPm1fcGVyYWdbaW5k ZXhdOworCQkJcGFnID0gbXAtPm1fcGVyYWdbaW5kZXhdOwogCQkJcGFnLT5w YWdpX2lub2Rlb2sgPSAxOwogCQl9CiAJfQpAQCAtOTM5LDkgKzk0NywxMCBA QCB4ZnNfbW91bnRmcygKIAkvKgogCSAqIEFsbG9jYXRlIGFuZCBpbml0aWFs aXplIHRoZSBwZXItYWcgZGF0YS4KIAkgKi8KLQlpbml0X3J3c2VtKCZtcC0+ bV9wZXJhZ2xvY2spOwotCW1wLT5tX3BlcmFnID0KLQkJa21lbV96YWxsb2Mo c2JwLT5zYl9hZ2NvdW50ICogc2l6ZW9mKHhmc19wZXJhZ190KSwgS01fU0xF RVApOworCW1wLT5tX3BlcmFnID0ga21lbV96YWxsb2Moc2JwLT5zYl9hZ2Nv dW50ICogc2l6ZW9mKHhmc19wZXJhZ190ICopLCBLTV9TTEVFUCk7CisJZm9y IChhZ25vID0gMDsgYWdubyA8IHNicC0+c2JfYWdjb3VudDsgYWdubysrKSB7 CisJCW1wLT5tX3BlcmFnW2Fnbm9dID0ga21lbV96YWxsb2Moc2l6ZW9mKHhm c19wZXJhZ190KSwgS01fU0xFRVApOworCX0KIAogCW1wLT5tX21heGFnaSA9 IHhmc19pbml0aWFsaXplX3BlcmFnKG1wLCBzYnAtPnNiX2FnY291bnQpOwog CkBAIC0xMDQ1LDExICsxMDU0LDE4IEBAIHhmc19tb3VudGZzKAogIGVycm9y MjoKIAl4ZnNfaWhhc2hfZnJlZShtcCk7CiAJeGZzX2NoYXNoX2ZyZWUobXAp OwotCWZvciAoYWdubyA9IDA7IGFnbm8gPCBzYnAtPnNiX2FnY291bnQ7IGFn bm8rKykKLQkJaWYgKG1wLT5tX3BlcmFnW2Fnbm9dLnBhZ2JfbGlzdCkKLQkJ CWttZW1fZnJlZShtcC0+bV9wZXJhZ1thZ25vXS5wYWdiX2xpc3QsCi0JCQkg IHNpemVvZih4ZnNfcGVyYWdfYnVzeV90KSAqIFhGU19QQUdCX05VTV9TTE9U Uyk7Ci0Ja21lbV9mcmVlKG1wLT5tX3BlcmFnLCBzYnAtPnNiX2FnY291bnQg KiBzaXplb2YoeGZzX3BlcmFnX3QpKTsKKwlmb3IgKGFnbm8gPSAwOyBhZ25v IDwgc2JwLT5zYl9hZ2NvdW50OyBhZ25vKyspIHsKKwkJeGZzX3BlcmFnX3Qg KnBhZyA9IG1wLT5tX3BlcmFnW2Fnbm9dOworCQlpZiAocGFnKSB7CisJCQlp ZiAocGFnLT5wYWdiX2xpc3QpIHsKKwkJCQlrbWVtX2ZyZWUocGFnLT5wYWdi X2xpc3QsIHNpemVvZih4ZnNfcGVyYWdfYnVzeV90KSAqIFhGU19QQUdCX05V TV9TTE9UUyk7CisJCQkJcGFnLT5wYWdiX2xpc3QgPSBOVUxMOworCQkJfQor CQkJa21lbV9mcmVlKHBhZywgc2l6ZW9mKHhmc19wZXJhZ190KSk7CisJCQlt cC0+bV9wZXJhZ1thZ25vXSA9IE5VTEw7CisJCX0KKwl9CisJa21lbV9mcmVl KG1wLT5tX3BlcmFnLCBzYnAtPnNiX2FnY291bnQgKiBzaXplb2YoeGZzX3Bl cmFnX3QgKikpOwogCW1wLT5tX3BlcmFnID0gTlVMTDsKIAkvKiBGQUxMVEhS T1VHSCAqLwogIGVycm9yMToKLS0tIGxpbnV4LTIuNC4yNS9mcy94ZnMveGZz X21vdW50Lmgub3JnCTIwMDQtMDgtMjcgMjE6NDg6MzEuMDAwMDAwMDAwICsw OTAwCisrKyBsaW51eC0yLjQuMjUvZnMveGZzL3hmc19tb3VudC5oCTIwMDQt MDgtMjcgMjE6NTA6MzQuMDAwMDAwMDAwICswOTAwCkBAIC0zMzUsOCArMzM1 LDcgQEAgdHlwZWRlZiBzdHJ1Y3QgeGZzX21vdW50IHsKIAl1aW50CQkJbV9h Z19tYXhsZXZlbHM7CS8qIFhGU19BR19NQVhMRVZFTFMgKi8KIAl1aW50CQkJ bV9ibV9tYXhsZXZlbHNbMl07IC8qIFhGU19CTV9NQVhMRVZFTFMgKi8KIAl1 aW50CQkJbV9pbl9tYXhsZXZlbHM7CS8qIFhGU19JTl9NQVhMRVZFTFMgKi8K LQlzdHJ1Y3QgeGZzX3BlcmFnCSptX3BlcmFnOwkvKiBwZXItYWcgYWNjb3Vu dGluZyBpbmZvICovCi0Jc3RydWN0IHJ3X3NlbWFwaG9yZQltX3BlcmFnbG9j azsJLyogbG9jayBmb3IgbV9wZXJhZyAocG9pbnRlcikgKi8KKwlzdHJ1Y3Qg eGZzX3BlcmFnCSoqbV9wZXJhZzsJLyogcGVyLWFnIGFjY291bnRpbmcgaW5m byAqLwogCXNlbWFfdAkJCW1fZ3Jvd2xvY2s7CS8qIGdyb3dmcyBtdXRleCAq LwogCWludAkJCW1fZml4ZWRmc2lkWzJdOwkvKiB1bmNoYW5nZWQgZm9yIGxp ZmUgb2YgRlMgKi8KIAl1aW50CQkJbV9kbWV2bWFzazsJLyogRE1JIGV2ZW50 cyBmb3IgdGhpcyBGUyAqLwotLS0gbGludXgtMi40LjI1L2ZzL3hmcy94ZnNf ZnNvcHMuYy5vcmcJMjAwNC0wOC0yNyAyMTo0ODowMy4wMDAwMDAwMDAgKzA5 MDAKKysrIGxpbnV4LTIuNC4yNS9mcy94ZnMveGZzX2Zzb3BzLmMJMjAwNC0w OS0wMyAxMzo1MzoyOC4wMDAwMDAwMDAgKzA5MDAKQEAgLTE1MCw2ICsxNTAs OCBAQCB4ZnNfZ3Jvd2ZzX2RhdGFfcHJpdmF0ZSgKIAl4ZnNfc2JfdAkJKnNi cDsKIAl4ZnNfdHJhbnNfdAkJKnRwOwogCWludAkJCWluZGV4ID0gMDsKKwl4 ZnNfcGVyYWdfdAkJKipucGVyYWcgPSBOVUxMOworCXhmc19wZXJhZ190CQkq Km9wZXJhZyA9IG1wLT5tX3BlcmFnOwogCiAJbmIgPSBpbi0+bmV3YmxvY2tz OwogCXBjdCA9IGluLT5pbWF4cGN0OwpAQCAtMTc2LDE2ICsxNzgsMTQgQEAg eGZzX2dyb3dmc19kYXRhX3ByaXZhdGUoCiAJbmV3ID0gbmIgLSBtcC0+bV9z Yi5zYl9kYmxvY2tzOwogCW9hZ2NvdW50ID0gbXAtPm1fc2Iuc2JfYWdjb3Vu dDsKIAlpZiAobmFnY291bnQgPiBvYWdjb3VudCkgewotCQlkb3duX3dyaXRl KCZtcC0+bV9wZXJhZ2xvY2spOwotCQltcC0+bV9wZXJhZyA9IGttZW1fcmVh bGxvYyhtcC0+bV9wZXJhZywKLQkJCXNpemVvZih4ZnNfcGVyYWdfdCkgKiBu YWdjb3VudCwKLQkJCXNpemVvZih4ZnNfcGVyYWdfdCkgKiBvYWdjb3VudCwK LQkJCUtNX1NMRUVQKTsKLQkJbWVtc2V0KCZtcC0+bV9wZXJhZ1tvYWdjb3Vu dF0sIDAsCi0JCQkobmFnY291bnQgLSBvYWdjb3VudCkgKiBzaXplb2YoeGZz X3BlcmFnX3QpKTsKKwkJbnBlcmFnID0ga21lbV9hbGxvYyhzaXplb2YoeGZz X3BlcmFnX3QgKikgKiBuYWdjb3VudCwgS01fU0xFRVApOworCQltZW1jcHko bnBlcmFnLCBtcC0+bV9wZXJhZywgc2l6ZW9mKHhmc19wZXJhZ190ICopKm9h Z2NvdW50KTsKKwkJZm9yIChhZ25vID0gb2FnY291bnQ7IGFnbm8gPCBuYWdj b3VudDsgYWdubysrKSB7CisJCQlucGVyYWdbYWdub10gPSBrbWVtX3phbGxv YyhzaXplb2YoeGZzX3BlcmFnX3QpLCBLTV9TTEVFUCk7CisJCX0KKwkJbXAt Pm1fcGVyYWcgPSBucGVyYWc7CiAJCW1wLT5tX2ZsYWdzIHw9IFhGU19NT1VO VF8zMkJJVElOT0RFUzsKIAkJaW5kZXggPSB4ZnNfaW5pdGlhbGl6ZV9wZXJh ZyhtcCwgbmFnY291bnQpOwotCQl1cF93cml0ZSgmbXAtPm1fcGVyYWdsb2Nr KTsKIAl9CiAJdHAgPSB4ZnNfdHJhbnNfYWxsb2MobXAsIFhGU19UUkFOU19H Uk9XRlMpOwogCWlmICgoZXJyb3IgPSB4ZnNfdHJhbnNfcmVzZXJ2ZSh0cCwg WEZTX0dST1dGU19TUEFDRV9SRVMobXApLApAQCAtMzc0LDggKzM3NCwxMCBA QCB4ZnNfZ3Jvd2ZzX2RhdGFfcHJpdmF0ZSgKIAkJcmV0dXJuIGVycm9yOwog CX0KIAkvKiBpbml0aWFsaXplIGNvbXBsZXRlZCwgdXBkYXRlIG1heGFnaSAq LwotCWlmIChpbmRleCkKKwlpZiAoaW5kZXgpIHsKKwkJa21lbV9mcmVlKG9w ZXJhZywgc2l6ZW9mKHhmc19wZXJhZ190ICopKm9hZ2NvdW50KTsKIAkJbXAt Pm1fbWF4YWdpID0gaW5kZXg7CisJfQogCWlmIChtcC0+bV9zYi5zYl9pbWF4 X3BjdCkgewogCQlfX3VpbnQ2NF90IGljb3VudCA9IG1wLT5tX3NiLnNiX2Ri bG9ja3MgKiBtcC0+bV9zYi5zYl9pbWF4X3BjdDsKIAkJZG9fZGl2KGljb3Vu dCwgMTAwKTsK --Boundary-bJSx4WX8uyVvfWdP65HLB-- From owner-linux-xfs Mon Oct 4 08:27:01 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 04 Oct 2004 08:27:03 -0700 (PDT) Received: from hauptpostamt.charite.de (hauptpostamt.charite.de [193.175.66.220]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i94FR0Or012760 for ; Mon, 4 Oct 2004 08:27:01 -0700 Received: from postamt1.charite.de (postamt1.charite.de [193.175.66.246]) by hauptpostamt.charite.de (Postfix) with ESMTP id 4534815C025; Mon, 4 Oct 2004 17:26:38 +0200 (CEST) Received: by postamt1.charite.de (Postfix, from userid 7945) id 3AF9A633AD; Mon, 4 Oct 2004 17:26:38 +0200 (CEST) Date: Mon, 4 Oct 2004 17:26:38 +0200 From: Ralf Hildebrandt To: linux-xfs@oss.sgi.com Cc: Udo Wolter Subject: duplicate uuid on mount Message-ID: <20041004152638.GY32356@charite.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new at charite.de X-archive-position: 4209 X-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 We duplicated a fs by using xfsdump and xfsrestore; now we get XFS: Filesystem sdc5 has duplicate UUID - can't mount XFS: Filesystem sdc5 has duplicate UUID - can't mount # xfs_db -r -c "sb 0" -c "p uuid" /dev/sdb5 uuid = f921a9a5-ec6a-45a2-a383-7011b4dfffbc # xfs_db -r -c "sb 0" -c "p uuid" /dev/sdc5 uuid = f921a9a5-ec6a-45a2-a383-7011b4dfffbc So, how can we make the uuid unique again? -- _________________________________________________ Charité - Universitätsmedizin Berlin _________________________________________________ Ralf Hildebrandt i.A. des IT-Zentrum | Netzwerkdienste Stabsstelle des Klinikumsvorstandes Campus Benjamin Franklin Hindenburgdamm 30 | Berlin Tel. +49 30 450 570155 | Fax +49 30 8445-4447 Ralf.Hildebrandt@charite.de http://www.charite.de ----- End forwarded message ----- -- Ralf Hildebrandt (i.A. des IT-Zentrum) 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-8445-4447 IT-Zentrum Standort CBF AIM. ralfpostfix From owner-linux-xfs Mon Oct 4 11:34:04 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 04 Oct 2004 11:34:08 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i94IY3n7017454 for ; Mon, 4 Oct 2004 11:34:03 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i94Jiu79025371 for ; Mon, 4 Oct 2004 12:44:57 -0700 Received: from [128.162.233.24] (fsgi275.americas.sgi.com [128.162.233.24]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i94IWbOV48682657; Mon, 4 Oct 2004 13:32:37 -0500 (CDT) Message-ID: <41619745.4070602@sgi.com> Date: Mon, 04 Oct 2004 13:32:37 -0500 From: Bill Kendall User-Agent: Mozilla Thunderbird 0.8 (X11/20040918) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ralf Hildebrandt CC: linux-xfs@oss.sgi.com, Udo Wolter Subject: Re: duplicate uuid on mount References: <20041004152638.GY32356@charite.de> In-Reply-To: <20041004152638.GY32356@charite.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4210 X-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 Ralf Hildebrandt wrote: > We duplicated a fs by using xfsdump and xfsrestore; now we get > > XFS: Filesystem sdc5 has duplicate UUID - can't mount > XFS: Filesystem sdc5 has duplicate UUID - can't mount > > # xfs_db -r -c "sb 0" -c "p uuid" /dev/sdb5 > uuid = f921a9a5-ec6a-45a2-a383-7011b4dfffbc > # xfs_db -r -c "sb 0" -c "p uuid" /dev/sdc5 > uuid = f921a9a5-ec6a-45a2-a383-7011b4dfffbc > > So, how can we make the uuid unique again? > I'm not sure how xfsrestore would get you in this situation as it does not restore the UUID, but this should do the trick: xfs_db -x -c "uuid generate" /dev/sdc5 -- Bill From owner-linux-xfs Mon Oct 4 14:38:47 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 04 Oct 2004 14:38:49 -0700 (PDT) Received: from mail-h12-02.cc.ksu.edu (mail-h12-02.cc.ksu.edu [129.130.12.151]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i94Lckbh032691 for ; Mon, 4 Oct 2004 14:38:47 -0700 Received: from unix2.cc.ksu.edu (unix2.cc.ksu.edu [129.130.12.4]) by mail-h12-02.cc.ksu.edu (8.12.9/8.12.9) with ESMTP id i94LcQgE007137; Mon, 4 Oct 2004 16:38:26 -0500 (CDT) Received: from localhost (matts@localhost) by unix2.cc.ksu.edu (8.11.6+Sun/8.11.6) with ESMTP id i94LcPf24923; Mon, 4 Oct 2004 16:38:25 -0500 (CDT) X-Authentication-Warning: unix2.cc.ksu.edu: matts owned process doing -bs Date: Mon, 4 Oct 2004 16:38:23 -0500 (CDT) From: Matt Stegman X-X-Sender: matts@unix2.cc.ksu.edu To: Ralf Hildebrandt cc: linux-xfs@oss.sgi.com, Udo Wolter Subject: Re: duplicate uuid on mount In-Reply-To: <20041004152638.GY32356@charite.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: clamd / ClamAV version 0.71, clamav-milter version 0.71 X-Virus-Status: Clean X-archive-position: 4211 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: matts@ksu.edu Precedence: bulk X-list: linux-xfs There is also the "nouuid" option to mount: mount -t xfs -o nouuid /dev/sdc5 /mnt/tmp This tells the kernel to ignore duplicate UUID. -- Matt Stegman On Mon, 4 Oct 2004, Ralf Hildebrandt wrote: > We duplicated a fs by using xfsdump and xfsrestore; now we get > > XFS: Filesystem sdc5 has duplicate UUID - can't mount > XFS: Filesystem sdc5 has duplicate UUID - can't mount > > # xfs_db -r -c "sb 0" -c "p uuid" /dev/sdb5 > uuid = f921a9a5-ec6a-45a2-a383-7011b4dfffbc > # xfs_db -r -c "sb 0" -c "p uuid" /dev/sdc5 > uuid = f921a9a5-ec6a-45a2-a383-7011b4dfffbc > > So, how can we make the uuid unique again? > > From owner-linux-xfs Mon Oct 4 14:41:21 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 04 Oct 2004 14:41:22 -0700 (PDT) Received: from moving-picture.com (mpc-26.sohonet.co.uk [193.203.82.251]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i94LfKQv000666 for ; Mon, 4 Oct 2004 14:41:21 -0700 Received: from [192.168.101.18] (helo=[192.168.101.18]) by moving-picture.com with esmtp (Exim 4.24) id 1CEaZt-00018K-OE; Mon, 04 Oct 2004 22:41:05 +0100 Message-ID: <4161C42B.1010105@moving-picture.com> Date: Mon, 04 Oct 2004 22:44:11 +0100 From: James Pearson User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: duplicate uuid on mount Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Disclaimer: This email and any attachments are confidential, may be legally X-Disclaimer: privileged and intended solely for the use of addressee. If you X-Disclaimer: are not the intended recipient of this message, any disclosure, X-Disclaimer: copying, distribution or any action taken in reliance on it is X-Disclaimer: strictly prohibited and may be unlawful. If you have received X-Disclaimer: this message in error, please notify the sender and delete all X-Disclaimer: copies from your system. X-Disclaimer: X-Disclaimer: Email may be susceptible to data corruption, interception and X-Disclaimer: unauthorised amendment, and we do not accept liability for any X-Disclaimer: such corruption, interception or amendment or the consequences X-Disclaimer: thereof. X-archive-position: 4212 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: james-p@moving-picture.com Precedence: bulk X-list: linux-xfs >> We duplicated a fs by using xfsdump and xfsrestore; now we get >> >> XFS: Filesystem sdc5 has duplicate UUID - can't mount >> XFS: Filesystem sdc5 has duplicate UUID - can't mount >> >> # xfs_db -r -c "sb 0" -c "p uuid" /dev/sdb5 >> uuid = f921a9a5-ec6a-45a2-a383-7011b4dfffbc >> # xfs_db -r -c "sb 0" -c "p uuid" /dev/sdc5 >> uuid = f921a9a5-ec6a-45a2-a383-7011b4dfffbc >> >> So, how can we make the uuid unique again? >> > > I'm not sure how xfsrestore would get you in this situation as > it does not restore the UUID, but this should do the trick: > > xfs_db -x -c "uuid generate" /dev/sdc5 Easier to use: xfs_admin -U generate /dev/sdc5 James Pearson From owner-linux-xfs Mon Oct 4 23:57:32 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 04 Oct 2004 23:57:35 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i956vUV4030719 for ; Mon, 4 Oct 2004 23:57:31 -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 QAA00573; Tue, 5 Oct 2004 16:57:08 +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 i956v6ln4736804; Tue, 5 Oct 2004 16:57:07 +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 i956uDvc005236; Tue, 5 Oct 2004 16:56:13 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i956u82B005234; Tue, 5 Oct 2004 16:56:08 +1000 Date: Tue, 5 Oct 2004 16:56:07 +1000 From: Nathan Scott To: ASANO Masahiro , "Tatsuko Yasugahira(Ohata)" Cc: linux-xfs@oss.sgi.com Subject: Re: a deadlock at xfs_growfs Message-ID: <20041005065607.GA4845@frodo> References: <20040825.182131.466644752.masano@tnes.nec.co.jp> <82C4A9B682002Ftatsu@tnes.nec.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <82C4A9B682002Ftatsu@tnes.nec.co.jp> User-Agent: Mutt/1.5.3i X-archive-position: 4213 X-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 On Mon, Oct 04, 2004 at 11:04:40AM +0900, Tatsuko Yasugahira(Ohata) wrote: > > Hi SGI guys, Hi there NEC guys! > >I'll do it later. > > This deadlock problem were reproduced in the environment of > 2.4.25+maxagi.patch and 2.4.27+maxagi.patch. > I made the test tool which can reproduce the problem. > growfs.sh > subgrowfs.sh > > Please, try them. Thanks! Will do. > growfs.patch > > This patch changed the allocation method of m_perag and deleted > the lock of m_peraglock. > When applying this patch, the deadlock problem seems to be fixed. > But, when the error has occurred, the memory leak problem happens. > What do you think of this patch? I haven't had a chance to look in detail yet - I'm a bit snowed under; I should be able to come up for air toward the end of this week - I'll get back to you then if noone else has by that time. Thanks for looking into this. cheers. -- Nathan From owner-linux-xfs Tue Oct 5 00:27:46 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 05 Oct 2004 00:27:52 -0700 (PDT) Received: from hauptpostamt.charite.de (hauptpostamt.charite.de [193.175.66.220]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i957Rjkh002547 for ; Tue, 5 Oct 2004 00:27:45 -0700 Received: from postamt1.charite.de (postamt1.charite.de [193.175.66.246]) by hauptpostamt.charite.de (Postfix) with ESMTP id 1362A15C02C; Tue, 5 Oct 2004 09:27:32 +0200 (CEST) Received: by postamt1.charite.de (Postfix, from userid 7945) id 0AE3B633A8; Tue, 5 Oct 2004 09:27:32 +0200 (CEST) Date: Tue, 5 Oct 2004 09:27:31 +0200 From: Ralf Hildebrandt To: Bill Kendall Cc: Ralf Hildebrandt , linux-xfs@oss.sgi.com, Udo Wolter Subject: Re: duplicate uuid on mount Message-ID: <20041005072731.GD23416@charite.de> References: <20041004152638.GY32356@charite.de> <41619745.4070602@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <41619745.4070602@sgi.com> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new at charite.de X-archive-position: 4214 X-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 > I'm not sure how xfsrestore would get you in this situation as maybe it was dd... > it does not restore the UUID, but this should do the trick: > > xfs_db -x -c "uuid generate" /dev/sdc5 Yes, thanks a lot. -- _________________________________________________ Charité - Universitätsmedizin Berlin _________________________________________________ Ralf Hildebrandt i.A. des IT-Zentrum | Netzwerkdienste Stabsstelle des Klinikumsvorstandes Campus Benjamin Franklin Hindenburgdamm 30 | Berlin Tel. +49 30 450 570155 | Fax +49 30 8445-4447 Ralf.Hildebrandt@charite.de http://www.charite.de From owner-linux-xfs Tue Oct 5 03:10:34 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 05 Oct 2004 03:10:38 -0700 (PDT) Received: from hauptpostamt.charite.de (hauptpostamt.charite.de [193.175.66.220]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i95AAXsR011485 for ; Tue, 5 Oct 2004 03:10:34 -0700 Received: from postamt1.charite.de (postamt1.charite.de [193.175.66.246]) by hauptpostamt.charite.de (Postfix) with ESMTP id A0F6F15C038 for ; Tue, 5 Oct 2004 12:10:19 +0200 (CEST) Received: by postamt1.charite.de (Postfix, from userid 7945) id 974BD633A8; Tue, 5 Oct 2004 12:10:19 +0200 (CEST) Date: Tue, 5 Oct 2004 12:10:19 +0200 From: Ralf Hildebrandt To: linux-xfs@oss.sgi.com Subject: Special, optimized mount options for a squid cache directory? Message-ID: <20041005101019.GM23416@charite.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new at charite.de X-archive-position: 4215 X-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 Is there a set of recommended (recommended meaning: optimizing the performance) mount options for a squid cache directory residing on an XFS filesystem? -- Ralf Hildebrandt (i.A. des IT-Zentrum) 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-8445-4447 IT-Zentrum Standort CBF AIM. ralfpostfix From owner-linux-xfs Tue Oct 5 06:46:55 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 05 Oct 2004 06:47:04 -0700 (PDT) Received: from mproxy.gmail.com (mproxy.gmail.com [216.239.56.248]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i95Dks2u020468 for ; Tue, 5 Oct 2004 06:46:55 -0700 Received: by mproxy.gmail.com with SMTP id q44so417699cwc for ; Tue, 05 Oct 2004 06:46:34 -0700 (PDT) Received: by 10.11.118.55 with SMTP id q55mr411160cwc; Tue, 05 Oct 2004 06:46:33 -0700 (PDT) Received: by 10.11.116.76 with HTTP; Tue, 5 Oct 2004 06:46:33 -0700 (PDT) Message-ID: Date: Tue, 5 Oct 2004 19:16:33 +0530 From: Ash Reply-To: Ash To: Mike Burger Subject: Re: XFS known issues ? Cc: linux-xfs@oss.sgi.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: X-archive-position: 4216 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ashrat@gmail.com Precedence: bulk X-list: linux-xfs Thanks. Is there anything that lists the planned features/tasks/current bug fixing activities ? Something like the "Work items" link on the XFS homepage. That does not seem to be updated recently. Thanks again Ash On Wed, 29 Sep 2004 07:22:02 -0500 (EST), Mike Burger wrote: > I'm sorry...I meant Bugzilla. > > > > On Wed, 29 Sep 2004, Mike Burger wrote: > > > Bugtraq? > > > > On Wed, 29 Sep 2004, Ash wrote: > > > > > Hi > > > > > > Is there any document/reference for known issues, documented > > > limitations and open bugs > > > against XFS ? > > > I checked the FAQ on the XFS home, but didn't find any related > > > information there. > > > > > > It would be helpful if someone can point me to some docs related to > > > known and documented > > > limitations. > > > > > > Thanks > > > Ash > > > > > > > > > > > > -- > Mike Burger > http://www.bubbanfriends.org > > Visit the Dog Pound II BBS > telnet://dogpound2.citadel.org or http://dogpound2.citadel.org > > To be notified of updates to the web site, visit > http://www.bubbanfriends.org/mailman/listinfo/site-update, or send a > message to: > > site-update-request@bubbanfriends.org > > with a message of: > > subscribe > From owner-linux-xfs Tue Oct 5 14:00:01 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 05 Oct 2004 14:00:06 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i95L00KH020071 for ; Tue, 5 Oct 2004 14:00:00 -0700 Received: (qmail 19857 invoked by uid 65534); 5 Oct 2004 20:59:41 -0000 Received: from G0fd2.g.pppool.de (EHLO [192.168.1.11]) (80.185.15.210) by mail.gmx.net (mp006) with SMTP; 05 Oct 2004 22:59:41 +0200 X-Authenticated: #2986359 Message-ID: <41630B3C.1020904@gmx.net> Date: Tue, 05 Oct 2004 22:59:40 +0200 From: evilninja User-Agent: Mozilla Thunderbird 0.8 (X11/20040926) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ralf Hildebrandt CC: linux-xfs@oss.sgi.com Subject: Re: Special, optimized mount options for a squid cache directory? References: <20041005101019.GM23416@charite.de> In-Reply-To: <20041005101019.GM23416@charite.de> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-archive-position: 4217 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: evilninja@gmx.net Precedence: bulk X-list: linux-xfs -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ralf Hildebrandt wrote: > Is there a set of recommended (recommended meaning: optimizing the > performance) mount options for a squid cache directory residing on an > XFS filesystem? - -o noatime would probably make sense for a cache/spool dir. but it's not bound to xfs really. Christian. PS: hm, some googling revealed http://eyck.forumakad.pl/~eyck/log/2004/03/ bad news for xfs in this report, but no real benchmarks shown, just unproven statements ;) - -- BOFH excuse #372: Forced to support NT servers; sysadmins quit. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBYws8C/PVm5+NVoYRAmfIAJwPDwlvLOe7brqeWnRdrzi2Gh+hEQCgr7H0 rOaZgvB3D/3ssm1AG/HVcGk= =Rw2o -----END PGP SIGNATURE----- From owner-linux-xfs Tue Oct 5 14:11:11 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 05 Oct 2004 14:11:15 -0700 (PDT) Received: from hauptpostamt.charite.de (hauptpostamt.charite.de [193.175.66.220]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i95LBAqC021436 for ; Tue, 5 Oct 2004 14:11:11 -0700 Received: from postamt1.charite.de (postamt1.charite.de [193.175.66.246]) by hauptpostamt.charite.de (Postfix) with ESMTP id 98F0615C00C for ; Tue, 5 Oct 2004 23:10:47 +0200 (CEST) Received: by postamt1.charite.de (Postfix, from userid 7945) id 8C748633B3; Tue, 5 Oct 2004 23:10:47 +0200 (CEST) Date: Tue, 5 Oct 2004 23:10:47 +0200 From: Ralf Hildebrandt To: linux-xfs@oss.sgi.com Subject: Re: Special, optimized mount options for a squid cache directory? Message-ID: <20041005211047.GK8661@charite.de> References: <20041005101019.GM23416@charite.de> <41630B3C.1020904@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <41630B3C.1020904@gmx.net> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new at charite.de X-archive-position: 4218 X-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 * evilninja : > -o noatime would probably make sense for a cache/spool dir. but it's not > bound to xfs really. D'oh. Whoever set this machine up forgot to use noatime. Fixed. > PS: hm, some googling revealed http://eyck.forumakad.pl/~eyck/log/2004/03/ > bad news for xfs in this report, but no real benchmarks shown, just > unproven statements ;) ReiserFS is for people who don't need their data. -- _________________________________________________ Charité - Universitätsmedizin Berlin _________________________________________________ Ralf Hildebrandt i.A. des IT-Zentrum | Netzwerkdienste Stabsstelle des Klinikumsvorstandes Campus Benjamin Franklin Hindenburgdamm 30 | Berlin Tel. +49 30 450 570155 | Fax +49 30 8445-4447 Ralf.Hildebrandt@charite.de http://www.charite.de From owner-linux-xfs Tue Oct 5 20:50:36 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 05 Oct 2004 20:50:37 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i963oY9f014642 for ; Tue, 5 Oct 2004 20:50:35 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA26960; Wed, 6 Oct 2004 13:50:14 +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 i963oCln4743159; Wed, 6 Oct 2004 13:50:12 +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 i963nIvc008521; Wed, 6 Oct 2004 13:49:18 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i963nGRf008519; Wed, 6 Oct 2004 13:49:16 +1000 Date: Wed, 6 Oct 2004 13:49:16 +1000 From: Nathan Scott To: Ash Cc: linux-xfs@oss.sgi.com Subject: Re: XFS known issues ? Message-ID: <20041006034916.GB8393@frodo> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i X-archive-position: 4219 X-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 On Tue, Oct 05, 2004 at 07:16:33PM +0530, Ash wrote: > Is there anything that lists the planned features/tasks/current bug > fixing activities ? Not really, its mostly in the developers heads I'm afraid (other than the things written down in the various bug tracking systems, of course). > Something like the "Work items" link on the XFS homepage. That does > not seem to be updated recently. Yeah, thats years out of date now. It should just be removed. cheers. -- Nathan From owner-linux-xfs Wed Oct 6 05:59:46 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 06 Oct 2004 05:59:50 -0700 (PDT) Received: from unthought.net (unthought.net [212.97.129.88]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i96CxjHe021474 for ; Wed, 6 Oct 2004 05:59:45 -0700 Received: by unthought.net (Postfix, from userid 1000) id 8A4DBADD8; Wed, 6 Oct 2004 14:59:31 +0200 (CEST) Date: Wed, 6 Oct 2004 14:59:31 +0200 From: Jakob Oestergaard To: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: NFS+SMP+XFS problems, Take II Message-ID: <20041006125931.GU18307@unthought.net> Mail-Followup-To: Jakob Oestergaard , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="3MwIy2ne0vdjdPXF" Content-Disposition: inline User-Agent: Mutt/1.3.28i X-archive-position: 4220 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jakob@unthought.net Precedence: bulk X-list: linux-xfs --3MwIy2ne0vdjdPXF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Dear all, The dcache patch (originally from Neil Brown, adapted for 2.6.8.1 by me) has been included in the current 2.6.9 RC. It *seemed* that this patch solved the XFS+NFS+SMP problem completely, and that it would then be possible to finally run an NFS server with XFS on an SMP machine. Well, close, but not close enough. Today, my "small" system (described in the earlier XFS problems thread - this is a dual athlon MP serving a ~150G XFS file system via. NFS) hosed itself. It is running 2.6.8.1 with the dcache patch (http://lkml.org/lkml/2004/9/17/92). Today I got the error: ---------------------------- Oct 6 12:44:53 phoenix kernel: xfs_iget_core: ambiguous vns: vp/0xf5c73de0, invp/0xf5c6be00 Oct 6 12:44:53 phoenix kernel: ------------[ cut here ]------------ Oct 6 12:44:53 phoenix kernel: kernel BUG at fs/xfs/support/debug.c:106! Oct 6 12:44:53 phoenix kernel: invalid operand: 0000 [#1] Oct 6 12:44:53 phoenix kernel: SMP Oct 6 12:44:53 phoenix kernel: CPU: 1 Oct 6 12:44:53 phoenix kernel: EIP: 0060:[dev_change_name+279/496] Not tainted Oct 6 12:44:53 phoenix kernel: EFLAGS: 00010246 (2.6.8.1) Oct 6 12:44:53 phoenix kernel: EIP is at cmn_err+0x97/0xb0 Oct 6 12:44:53 phoenix kernel: eax: 00000040 ebx: 00000293 ecx: c036fa24 edx: c036fa24 Oct 6 12:44:53 phoenix kernel: esi: c033c1a7 edi: c0437c1e ebp: 00000000 esp: f6553a94 Oct 6 12:44:53 phoenix kernel: ds: 007b es: 007b ss: 0068 Oct 6 12:44:53 phoenix kernel: Process nfsd (pid: 303, threadinfo=f6552000 task=f709b790) Oct 6 12:44:53 phoenix kernel: Stack: c04208e0 f60799d4 f6552000 f7348d28 f5c6be20 c01f7fb2 000000 00 c0337040 Oct 6 12:44:53 phoenix kernel: f5c73de0 f5c6be00 f5c6be20 f5c6be00 f6552000 00000008 f60799 d8 f60818d0 Oct 6 12:44:53 phoenix kernel: c01f83cc f5c6be00 f7348c00 00000000 1c15be1b 00000000 000000 08 f6553b44 Oct 6 12:44:53 phoenix kernel: Call Trace: Oct 6 12:44:53 phoenix kernel: [e100_clean_cbs+98/240] xfs_iget_core+0x182/0x510 ... ---------------------------- There exists another small patch for XFS which was a work-around for some of this - that patch has, as far as I know, never made it into a kernel, and, again as far as I know, there are some good reasons for this (known to the XFS people I guess). That patch is attached to this mail (ireclaim.diff) - I tried patching my dcache-patched 2.6.8.1 kernel, but the patch had no effect on this problem. The server would BUG again, after starting up the knfsd processes (it seems that an NFS client on the network had a queued request which would consistently trigger this bug whenever the server came back up). The *only* way in which I got this server back up and running, was to boot it with "noapic noacpi nosmp" - booting it in uniprocessor mode. It is now running that way, with a plain 2.6.8.1 and the dcache patch (no XFS patches). So, it seems that there is still a problem left, even after the dcache patch. The "window of opportunity" for whatever bug this is, has shrunk considerably after the dcache patch got applied - the server now ran for several weeks before hosing itself. In other words; it seems the dcache patch was a move in the right direction, but it also seems that there's something left. Ideas, anyone? -- / jakob --3MwIy2ne0vdjdPXF Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ireclaim.diff" --- 1.53/fs/xfs/xfs_vnodeops.c Tue Mar 2 06:35:29 2004 +++ edited/fs/xfs/xfs_vnodeops.c Thu Mar 4 14:03:06 2004 @@ -3974,21 +3974,9 @@ * avoids flushing the inode to disk during the delete operation * itself. */ - if (!ip->i_update_core && (ip->i_itemp == NULL)) { - xfs_ilock(ip, XFS_ILOCK_EXCL); - xfs_iflock(ip); - return xfs_finish_reclaim(ip, 1, XFS_IFLUSH_DELWRI_ELSE_SYNC); - } else { - xfs_mount_t *mp = ip->i_mount; - - /* Protect sync from us */ - XFS_MOUNT_ILOCK(mp); - vn_bhv_remove(VN_BHV_HEAD(vp), XFS_ITOBHV(ip)); - list_add_tail(&ip->i_reclaim, &mp->m_del_inodes); - ip->i_flags |= XFS_IRECLAIMABLE; - XFS_MOUNT_IUNLOCK(mp); - } - return 0; + xfs_ilock(ip, XFS_ILOCK_EXCL); + xfs_iflock(ip); + return xfs_finish_reclaim(ip, 1, XFS_IFLUSH_DELWRI_ELSE_SYNC); } int --- 1.20/fs/xfs/xfs_iget.c Fri Jan 9 07:20:13 2004 +++ edited/fs/xfs/xfs_iget.c Thu Mar 4 15:54:35 2004 @@ -578,7 +548,7 @@ /* We shouldn't get here without this being true, but just in case */ if (inode->i_state & I_NEW) { - make_bad_inode(inode); + remove_inode_hash(inode); unlock_new_inode(inode); } if (lock_flags) --3MwIy2ne0vdjdPXF-- From owner-linux-xfs Wed Oct 6 06:26:28 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 06 Oct 2004 06:26:29 -0700 (PDT) Received: from phoenix.infradead.org (imladris.demon.co.uk [193.237.130.41]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i96DQQVo022544 for ; Wed, 6 Oct 2004 06:26:27 -0700 Received: from hch by phoenix.infradead.org with local (Exim 4.42 #2 (Red Hat Linux)) id 1CFBo3-00082J-24; Wed, 06 Oct 2004 14:26:11 +0100 Date: Wed, 6 Oct 2004 14:26:10 +0100 From: Christoph Hellwig To: Jakob Oestergaard , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: NFS+SMP+XFS problems, Take II Message-ID: <20041006142610.A30867@infradead.org> Mail-Followup-To: Christoph Hellwig , Jakob Oestergaard , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com References: <20041006125931.GU18307@unthought.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20041006125931.GU18307@unthought.net>; from jakob@unthought.net on Wed, Oct 06, 2004 at 02:59:31PM +0200 X-SRS-Rewrite: SMTP reverse-path rewritten from by phoenix.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 4221 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs On Wed, Oct 06, 2004 at 02:59:31PM +0200, Jakob Oestergaard wrote: > > Dear all, > > The dcache patch (originally from Neil Brown, adapted for 2.6.8.1 by me) > has been included in the current 2.6.9 RC. It *seemed* that this patch > solved the XFS+NFS+SMP problem completely, and that it would then be > possible to finally run an NFS server with XFS on an SMP machine. > > Well, close, but not close enough. As I told in the thread it's not enough. I checked in two more XFS fixes, they're all in 2.6.9-rc3. From owner-linux-xfs Wed Oct 6 06:49:09 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 06 Oct 2004 06:49:11 -0700 (PDT) Received: from unthought.net (unthought.net [212.97.129.88]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i96Dn8Gs023243 for ; Wed, 6 Oct 2004 06:49:09 -0700 Received: by unthought.net (Postfix, from userid 1000) id BF824ADD8; Wed, 6 Oct 2004 15:48:55 +0200 (CEST) Date: Wed, 6 Oct 2004 15:48:55 +0200 From: Jakob Oestergaard To: Christoph Hellwig , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: NFS+SMP+XFS problems, Take II Message-ID: <20041006134855.GV18307@unthought.net> Mail-Followup-To: Jakob Oestergaard , Christoph Hellwig , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com References: <20041006125931.GU18307@unthought.net> <20041006142610.A30867@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041006142610.A30867@infradead.org> User-Agent: Mutt/1.3.28i X-archive-position: 4222 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jakob@unthought.net Precedence: bulk X-list: linux-xfs On Wed, Oct 06, 2004 at 02:26:10PM +0100, Christoph Hellwig wrote: > On Wed, Oct 06, 2004 at 02:59:31PM +0200, Jakob Oestergaard wrote: > > > > Dear all, > > > > The dcache patch (originally from Neil Brown, adapted for 2.6.8.1 by me) > > has been included in the current 2.6.9 RC. It *seemed* that this patch > > solved the XFS+NFS+SMP problem completely, and that it would then be > > possible to finally run an NFS server with XFS on an SMP machine. > > > > Well, close, but not close enough. > > As I told in the thread it's not enough. I checked in two more XFS fixes, > they're all in 2.6.9-rc3. Thanks! I'll patch the kernel this evening, and we'll see if it can stay up then. I'll report back to the lists by the end of the week if the box doesn't hose itself sooner. -- / jakob From owner-linux-xfs Wed Oct 6 07:40:15 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 06 Oct 2004 07:40:19 -0700 (PDT) Received: from cliff.advisen.com (user110.rcgllc.com [208.255.119.110] (may be forged)) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i96EeC6v026236 for ; Wed, 6 Oct 2004 07:40:14 -0700 Received: from jupiter by cliff; 06 Oct 2004 10:32:14 -0400 Subject: XFS internal error From: Dave Seff Reply-To: dseff@advisen.com To: linux-xfs@oss.sgi.com Cc: Dave Seff Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Advisen Ltd. Message-Id: <1097073134.18322.37.camel@jupiter> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 06 Oct 2004 10:32:14 -0400 X-archive-position: 4223 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dseff@advisen.com Precedence: bulk X-list: linux-xfs I just wanted to know if this was a critical error. This occured on /var on one of my systems: XFS mounting filesystem hda6 Starting XFS recovery on filesystem: hda6 (dev: hda6) XFS internal error XFS_WANT_CORRUPTED_GOTO at line 1583 of file fs/xfs/xfs_alloc.c. Caller 0xc01ada6b [] xfs_error_report+0x3a/0x3c [] xfs_free_ag_extent+0x55b/0x620 [] xfs_free_extent+0xb7/0xe0 [] xfs_free_extent+0xb7/0xe0 [] xfs_efd_init+0xf2/0x158 [] xlog_recover_process_efi+0x136/0x170 [] xlog_recover_process_efis+0x3a/0x6c [] xlog_recover_finish+0x18/0x95 [] xfs_mountfs+0xab4/0xd3c [] xfs_log_mount_finish+0x1e/0x28 [] xfs_mountfs+0xc02/0xd3c [] default_wake_function+0x0/0x1c [] xfs_setsize_buftarg+0x32/0x60 [] xfs_ioinit+0x24/0x2c [] xfs_mount+0x305/0x388 [] vfs_mount+0x27/0x2c [] linvfs_fill_super+0x7b/0x1fc [] snprintf+0x1a/0x20 [] disk_name+0x67/0x70 [] sb_set_blocksize+0x17/0x40 [] get_sb_bdev+0xe3/0x128 [] linvfs_get_sb+0x1f/0x28 [] linvfs_fill_super+0x0/0x1fc [] do_kern_mount+0x4a/0xb8 [] do_add_mount+0x69/0x154 [] do_mount+0x15e/0x178 [] copy_mount_options+0x50/0xa0 [] sys_mount+0xb3/0x118 [] syscall_call+0x7/0xb Ending XFS recovery on filesystem: hda6 (dev: hda6) -- Dave Seff Advisen Ltd. From owner-linux-xfs Wed Oct 6 08:08:04 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 06 Oct 2004 08:08:09 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i96F84Z0027331 for ; Wed, 6 Oct 2004 08:08:04 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i96GJELR009463 for ; Wed, 6 Oct 2004 09:19:14 -0700 Received: from [128.162.232.50] (stout.americas.sgi.com [128.162.232.50]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i96F7pOV48790219; Wed, 6 Oct 2004 10:07:51 -0500 (CDT) Message-ID: <41640A46.10007@sgi.com> Date: Wed, 06 Oct 2004 10:07:50 -0500 From: Eric Sandeen User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dseff@advisen.com CC: linux-xfs@oss.sgi.com Subject: Re: XFS internal error References: <1097073134.18322.37.camel@jupiter> In-Reply-To: <1097073134.18322.37.camel@jupiter> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4224 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Well, it's an error during log recovery; /* * If this failure happens the request to free this * space was invalid, it's (partly) already free. * Very bad. */ XFS_WANT_CORRUPTED_GOTO(ltbno + ltlen <= bno, error0); I think that this is not a problem in your log, but rather a problem in the data portion of your filesystem which the log replay is trying to modify. The two options now are probably to either start doing some debugging by using xfs_logprint and xfs_db to figure out what's wrong, or to zero out the log (thus throwing away any metadata changes in the log; possibly not such a good thing for your files in /var) and then running xfs_repair. -Eric Dave Seff wrote: > I just wanted to know if this was a critical error. This occured on /var > on one of my systems: > > XFS mounting filesystem hda6 > Starting XFS recovery on filesystem: hda6 (dev: hda6) > XFS internal error XFS_WANT_CORRUPTED_GOTO at line 1583 of file > fs/xfs/xfs_alloc.c. Caller 0xc01ada6b > [] xfs_error_report+0x3a/0x3c > [] xfs_free_ag_extent+0x55b/0x620 > [] xfs_free_extent+0xb7/0xe0 > [] xfs_free_extent+0xb7/0xe0 > [] xfs_efd_init+0xf2/0x158 > [] xlog_recover_process_efi+0x136/0x170 > [] xlog_recover_process_efis+0x3a/0x6c > [] xlog_recover_finish+0x18/0x95 > [] xfs_mountfs+0xab4/0xd3c > [] xfs_log_mount_finish+0x1e/0x28 > [] xfs_mountfs+0xc02/0xd3c > [] default_wake_function+0x0/0x1c > [] xfs_setsize_buftarg+0x32/0x60 > [] xfs_ioinit+0x24/0x2c > [] xfs_mount+0x305/0x388 > [] vfs_mount+0x27/0x2c > [] linvfs_fill_super+0x7b/0x1fc > [] snprintf+0x1a/0x20 > [] disk_name+0x67/0x70 > [] sb_set_blocksize+0x17/0x40 > [] get_sb_bdev+0xe3/0x128 > [] linvfs_get_sb+0x1f/0x28 > [] linvfs_fill_super+0x0/0x1fc > [] do_kern_mount+0x4a/0xb8 > [] do_add_mount+0x69/0x154 > [] do_mount+0x15e/0x178 > [] copy_mount_options+0x50/0xa0 > [] sys_mount+0xb3/0x118 > [] syscall_call+0x7/0xb > > Ending XFS recovery on filesystem: hda6 (dev: hda6) > From owner-linux-xfs Wed Oct 6 10:30:46 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 06 Oct 2004 10:30:49 -0700 (PDT) Received: from mail00hq.adic.com ([63.81.117.10]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i96HUkCf028518 for ; Wed, 6 Oct 2004 10:30:46 -0700 Received: from mail02hq.adic.com ([172.16.9.18]) by mail00hq.adic.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 6 Oct 2004 10:30:27 -0700 Received: from [172.16.82.67] ([172.16.82.67]) by mail02hq.adic.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 6 Oct 2004 10:30:27 -0700 Message-ID: <41642B04.5020901@xfs.org> Date: Wed, 06 Oct 2004 12:27:32 -0500 From: Steve Lord User-Agent: Mozilla Thunderbird 0.7.1 (X11/20040626) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Sandeen CC: dseff@advisen.com, linux-xfs@oss.sgi.com Subject: Re: XFS internal error References: <1097073134.18322.37.camel@jupiter> <41640A46.10007@sgi.com> In-Reply-To: <41640A46.10007@sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Oct 2004 17:30:27.0245 (UTC) FILETIME=[2B5C9DD0:01C4ABCA] X-archive-position: 4225 X-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 Eric Sandeen wrote: > Well, it's an error during log recovery; > > /* > * If this failure happens the request to free this > * space was invalid, it's (partly) already free. > * Very bad. > */ > XFS_WANT_CORRUPTED_GOTO(ltbno + ltlen <= bno, error0); > > I think that this is not a problem in your log, but rather a problem in > the data portion of your filesystem which the log replay is trying to > modify. > > The two options now are probably to either start doing some debugging by > using xfs_logprint and xfs_db to figure out what's wrong, or to zero out > the log (thus throwing away any metadata changes in the log; possibly > not such a good thing for your files in /var) and then running xfs_repair. > > -Eric > Hi Eric, Most of the replay has actually happened at this point, so most of the updates should already be in the metadata. This is just cleaning up the freed space. xfs_repair -L is probably the best bet to get the fs back. Steve From owner-linux-xfs Thu Oct 7 02:17:46 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Oct 2004 02:18:02 -0700 (PDT) Received: from mail.vcc.de (mail.vcc.de [217.111.2.122]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i979HiCb025628 for ; Thu, 7 Oct 2004 02:17:45 -0700 Received: from localhost (localhost [127.0.0.1]) by mail.vcc.de (Postfix) with ESMTP id E7F38162148 for ; Thu, 7 Oct 2004 11:17:28 +0200 (CEST) Received: from mail.vcc.de ([127.0.0.1]) by localhost (mail.vcc.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27440-05 for ; Thu, 7 Oct 2004 11:17:05 +0200 (CEST) Received: from [192.9.209.64] (wolverine.vcc.de [217.111.2.200]) by mail.vcc.de (Postfix) with ESMTP id 5EAED162187 for ; Thu, 7 Oct 2004 11:17:05 +0200 (CEST) Message-ID: <41650982.1090900@opticalart.de> Date: Thu, 07 Oct 2004 11:16:50 +0200 From: Frank Hellmann Organization: Optical Art Film- und Special-Effects GmbH User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: XFS List Subject: xfs_repair problem in FS root Content-Type: multipart/mixed; boundary="------------050706080401010402040400" X-Virus-Scanned: by amavisd-new at vcc.de X-archive-position: 4226 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: frank@opticalart.de Precedence: bulk X-list: linux-xfs This is a multi-part message in MIME format. --------------050706080401010402040400 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Guys! After a hard reset our scratch disk (md device /dev/md0 raid 0 with 2,7TB size) could not be mounted: > Starting XFS recovery on filesystem: md0 (dev: md0) > XFS: log mount/recovery failed > XFS: log mount failed All data resides in the root of that filesystem (about 700.000 files with about of 4Mb size each). If I start xfs_repair -L /dev/md0 it gets terminated in phase 6 after finding problems in directory inode 256. It eats up all aviable memory+swap and gets killed/terminated due to memory consumption (see attached output). I tried to add some temporary swapspace (extra 2GB), but it didn't not help this issue. Using the latest from the Web-CVS also didn't help. Is there a sane way of getting that issue resolved. Will it help if all the files are in a subdirectory (I remember issues repairing the root of the filesystems a while back)? Or do we have to split our files into multiple subdirectories (and what is the limit)? There is currently no time pressure, as all this data is just temporary cached stuff, but I think it would be nice to get it back instead of formatting it over... :-) Cheers, Frank... System specs: Vanilla Linux 2.6.6 SMP Kernel Dual Xeon 3,06GHz 2GB Memory + 1GB Swap 8TB Disk space via FibreChannel Nvidia FX2000 + 6111 drivers xfs_repair 2.6.2 + latest Web-CVS 2.6.13 -- -------------------------------------------------------------------------- Frank Hellmann Optical Art GmbH Waterloohain 7a DI Supervisor http://www.opticalart.de 22769 Hamburg frank@opticalart.de Tel: ++49 40 5111051 Fax: ++49 40 43169199 --------------050706080401010402040400 Content-Type: text/plain; name="xfs_dmesg.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="xfs_dmesg.txt" Starting XFS recovery on filesystem: md0 (dev: md0) XFS: log mount/recovery failed XFS: log mount failed Out of Memory: Killed process 9552 (xfs_repair). --------------050706080401010402040400 Content-Type: text/plain; name="xfs_repair.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="xfs_repair.txt" Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... zero_log: head block 512 tail block 512 - 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 entry "/00792f7-991275c7.cache" at block 4866 offset 1856 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 1856... entry at block 4866 offset 1856 in directory inode 256 has illegal name "/00792f7-991275c7.cache": entry "/0079302-dc5bf225.cache" at block 4866 offset 2296 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 2296... entry at block 4866 offset 2296 in directory inode 256 has illegal name "/0079302-dc5bf225.cache": entry "/0079303-a3276b5b.cache" at block 4866 offset 2336 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 2336... entry at block 4866 offset 2336 in directory inode 256 has illegal name "/0079303-a3276b5b.cache": entry "/0079304-ee655b22.cache" at block 4866 offset 2376 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 2376... entry at block 4866 offset 2376 in directory inode 256 has illegal name "/0079304-ee655b22.cache": entry "/0079305-3a481ef4.cache" at block 4866 offset 2416 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 2416... entry at block 4866 offset 2416 in directory inode 256 has illegal name "/0079305-3a481ef4.cache": entry "/0079306-109c69de.cache" at block 4866 offset 2456 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 2456... entry at block 4866 offset 2456 in directory inode 256 has illegal name "/0079306-109c69de.cache": entry "/0079307-6fe0f0a0.cache" at block 4866 offset 2496 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 2496... entry at block 4866 offset 2496 in directory inode 256 has illegal name "/0079307-6fe0f0a0.cache": entry "/0079308-4534878a.cache" at block 4866 offset 2536 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 2536... entry at block 4866 offset 2536 in directory inode 256 has illegal name "/0079308-4534878a.cache": entry "/0079309-c411d27d.cache" at block 4866 offset 2576 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 2576... entry at block 4866 offset 2576 in directory inode 256 has illegal name "/0079309-c411d27d.cache": entry "/007930a-eec5a557.cache" at block 4866 offset 2616 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 2616... entry at block 4866 offset 2616 in directory inode 256 has illegal name "/007930a-eec5a557.cache": entry "/007930b-925270cd.cache" at block 4866 offset 2656 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 2656... entry at block 4866 offset 2656 in directory inode 256 has illegal name "/007930b-925270cd.cache": entry "/007930c-b88607e7.cache" at block 4866 offset 2696 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 2696... entry at block 4866 offset 2696 in directory inode 256 has illegal name "/007930c-b88607e7.cache": entry "/007930d-75e46988.cache" at block 4866 offset 2736 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 2736... entry at block 4866 offset 2736 in directory inode 256 has illegal name "/007930d-75e46988.cache": entry "/007930e-5f301ea2.cache" at block 4866 offset 2776 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 2776... entry at block 4866 offset 2776 in directory inode 256 has illegal name "/007930e-5f301ea2.cache": entry "/007930f-8b1d5b74.cache" at block 4866 offset 2816 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 2816... entry at block 4866 offset 2816 in directory inode 256 has illegal name "/007930f-8b1d5b74.cache": entry "/0079310-a1c92c5e.cache" at block 4866 offset 2856 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 2856... entry at block 4866 offset 2856 in directory inode 256 has illegal name "/0079310-a1c92c5e.cache": entry "/0079311-066f1a10.cache" at block 4866 offset 2896 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 2896... entry at block 4866 offset 2896 in directory inode 256 has illegal name "/0079311-066f1a10.cache": entry "/0079312-2cbb6d3a.cache" at block 4866 offset 2936 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 2936... entry at block 4866 offset 2936 in directory inode 256 has illegal name "/0079312-2cbb6d3a.cache": entry "/0079313-754497fd.cache" at block 4866 offset 2976 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 2976... entry at block 4866 offset 2976 in directory inode 256 has illegal name "/0079313-754497fd.cache": entry "/0079314-5f90e0d7.cache" at block 4866 offset 3016 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 3016... entry at block 4866 offset 3016 in directory inode 256 has illegal name "/0079314-5f90e0d7.cache": entry "/0079315-e830c563.cache" at block 4866 offset 3056 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 3056... entry at block 4866 offset 3056 in directory inode 256 has illegal name "/0079315-e830c563.cache": entry "/0079316-d51293df.cache" at block 4866 offset 3096 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 3096... entry at block 4866 offset 3096 in directory inode 256 has illegal name "/0079316-d51293df.cache": entry "/0079317-aa6e0aa1.cache" at block 4866 offset 3136 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 3136... entry at block 4866 offset 3136 in directory inode 256 has illegal name "/0079317-aa6e0aa1.cache": entry "/0079318-80ba7d8b.cache" at block 4866 offset 3176 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 3176... entry at block 4866 offset 3176 in directory inode 256 has illegal name "/0079318-80ba7d8b.cache": entry "/0079319-5497385d.cache" at block 4866 offset 3216 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 3216... entry at block 4866 offset 3216 in directory inode 256 has illegal name "/0079319-5497385d.cache": entry "/007931a-a699e047.cache" at block 4866 offset 3256 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 3256... entry at block 4866 offset 3256 in directory inode 256 has illegal name "/007931a-a699e047.cache": entry "/007931b-d9e57939.cache" at block 4866 offset 3296 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 3296... entry at block 4866 offset 3296 in directory inode 256 has illegal name "/007931b-d9e57939.cache": entry "/007931c-f3310e13.cache" at block 4866 offset 3336 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 3336... entry at block 4866 offset 3336 in directory inode 256 has illegal name "/007931c-f3310e13.cache": entry "/007931d-aacef4d4.cache" at block 4866 offset 3376 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 3376... entry at block 4866 offset 3376 in directory inode 256 has illegal name "/007931d-aacef4d4.cache": entry "/007931e-801a83fe.cache" at block 4866 offset 3416 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 3416... entry at block 4866 offset 3416 in directory inode 256 has illegal name "/007931e-801a83fe.cache": entry "/007931f-72367592.cache" at block 4866 offset 3456 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 3456... entry at block 4866 offset 3456 in directory inode 256 has illegal name "/007931f-72367592.cache": entry "/0079320-58e202b8.cache" at block 4866 offset 3496 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 3496... entry at block 4866 offset 3496 in directory inode 256 has illegal name "/0079320-58e202b8.cache": entry "/0079321-279e9bc6.cache" at block 4866 offset 3536 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 3536... entry at block 4866 offset 3536 in directory inode 256 has illegal name "/0079321-279e9bc6.cache": entry "/0079322-0d4aecec.cache" at block 4866 offset 3576 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 3576... entry at block 4866 offset 3576 in directory inode 256 has illegal name "/0079322-0d4aecec.cache": entry "/0079323-01bd060a.cache" at block 4866 offset 3616 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 3616... entry at block 4866 offset 3616 in directory inode 256 has illegal name "/0079323-01bd060a.cache": entry "/0079324-2b697120.cache" at block 4866 offset 3656 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 3656... entry at block 4866 offset 3656 in directory inode 256 has illegal name "/0079324-2b697120.cache": entry "/0079325-5415e85e.cache" at block 4866 offset 3696 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 3696... entry at block 4866 offset 3696 in directory inode 256 has illegal name "/0079325-5415e85e.cache": entry "/0079326-7ec19f74.cache" at block 4866 offset 3736 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 3736... entry at block 4866 offset 3736 in directory inode 256 has illegal name "/0079326-7ec19f74.cache": entry "/0079327-952092a2.cache" at block 4866 offset 3776 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 3776... entry at block 4866 offset 3776 in directory inode 256 has illegal name "/0079327-952092a2.cache": entry "/0079328-bff4e588.cache" at block 4866 offset 3816 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 3816... entry at block 4866 offset 3816 in directory inode 256 has illegal name "/0079328-bff4e588.cache": entry "/0079329-af300d11.cache" at block 4866 offset 3856 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 3856... entry at block 4866 offset 3856 in directory inode 256 has illegal name "/0079329-af300d11.cache": entry "/007932a-85e47a3b.cache" at block 4866 offset 3896 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 3896... entry at block 4866 offset 3896 in directory inode 256 has illegal name "/007932a-85e47a3b.cache": entry "/007932b-fa98e345.cache" at block 4866 offset 3936 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 3936... entry at block 4866 offset 3936 in directory inode 256 has illegal name "/007932b-fa98e345.cache": entry "/007932c-08963b5f.cache" at block 4866 offset 3976 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 3976... entry at block 4866 offset 3976 in directory inode 256 has illegal name "/007932c-08963b5f.cache": entry "/007932d-dcbb7e89.cache" at block 4866 offset 4016 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 4016... entry at block 4866 offset 4016 in directory inode 256 has illegal name "/007932d-dcbb7e89.cache": entry "/007932e-f66f09a3.cache" at block 4866 offset 4056 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 4056... entry at block 4866 offset 4056 in directory inode 256 has illegal name "/007932e-f66f09a3.cache": entry "/007932f-891390dd.cache" at block 4867 offset 16 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 16... entry at block 4867 offset 16 in directory inode 256 has illegal name "/007932f-891390dd.cache": entry "/0079330-c451a0a4.cache" at block 4867 offset 56 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 56... entry at block 4867 offset 56 in directory inode 256 has illegal name "/0079330-c451a0a4.cache": entry "/0079331-9dae5a63.cache" at block 4867 offset 96 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 96... entry at block 4867 offset 96 in directory inode 256 has illegal name "/0079331-9dae5a63.cache": entry "/0079332-b77a2d49.cache" at block 4867 offset 136 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 136... entry at block 4867 offset 136 in directory inode 256 has illegal name "/0079332-b77a2d49.cache": entry "/0079333-cbedf8d3.cache" at block 4867 offset 176 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 176... entry at block 4867 offset 176 in directory inode 256 has illegal name "/0079333-cbedf8d3.cache": entry "/0079334-39e320c9.cache" at block 4867 offset 216 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 216... entry at block 4867 offset 216 in directory inode 256 has illegal name "/0079334-39e320c9.cache": entry "/0079335-469fb9b7.cache" at block 4867 offset 256 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 256... entry at block 4867 offset 256 in directory inode 256 has illegal name "/0079335-469fb9b7.cache": entry "/0079336-6c4bce9d.cache" at block 4867 offset 296 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 296... entry at block 4867 offset 296 in directory inode 256 has illegal name "/0079336-6c4bce9d.cache": entry "/0079337-b8668b4b.cache" at block 4867 offset 336 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 336... entry at block 4867 offset 336 in directory inode 256 has illegal name "/0079337-b8668b4b.cache": entry "/0079338-92b2fc61.cache" at block 4867 offset 376 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 376... entry at block 4867 offset 376 in directory inode 256 has illegal name "/0079338-92b2fc61.cache": entry "/0079339-5fd0920e.cache" at block 4867 offset 416 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 416... entry at block 4867 offset 416 in directory inode 256 has illegal name "/0079339-5fd0920e.cache": entry "/007933a-7504e524.cache" at block 4867 offset 456 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 456... entry at block 4867 offset 456 in directory inode 256 has illegal name "/007933a-7504e524.cache": entry "/007933b-2cfb1fe3.cache" at block 4867 offset 496 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 496... entry at block 4867 offset 496 in directory inode 256 has illegal name "/007933b-2cfb1fe3.cache": entry "/007933c-062f68c9.cache" at block 4867 offset 536 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 536... entry at block 4867 offset 536 in directory inode 256 has illegal name "/007933c-062f68c9.cache": entry "/007933d-16975566.cache" at block 4867 offset 576 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 576... entry at block 4867 offset 576 in directory inode 256 has illegal name "/007933d-16975566.cache": entry "/007933e-3c43224c.cache" at block 4867 offset 616 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 616... entry at block 4867 offset 616 in directory inode 256 has illegal name "/007933e-3c43224c.cache": entry "/007933f-433fbb32.cache" at block 4867 offset 656 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 656... entry at block 4867 offset 656 in directory inode 256 has illegal name "/007933f-433fbb32.cache": entry "/0079340-69ebcc18.cache" at block 4867 offset 696 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 696... entry at block 4867 offset 696 in directory inode 256 has illegal name "/0079340-69ebcc18.cache": entry "/0079341-bdc689ce.cache" at block 4867 offset 736 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 736... entry at block 4867 offset 736 in directory inode 256 has illegal name "/0079341-bdc689ce.cache": entry "/0079342-80e4df72.cache" at block 4867 offset 776 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 776... entry at block 4867 offset 776 in directory inode 256 has illegal name "/0079342-80e4df72.cache": entry "/0079343-ff98460c.cache" at block 4867 offset 816 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 816... entry at block 4867 offset 816 in directory inode 256 has illegal name "/0079343-ff98460c.cache": entry "/0079344-d54c3126.cache" at block 4867 offset 856 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 856... entry at block 4867 offset 856 in directory inode 256 has illegal name "/0079344-d54c3126.cache": entry "/0079345-8cb3cbe1.cache" at block 4867 offset 896 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 896... entry at block 4867 offset 896 in directory inode 256 has illegal name "/0079345-8cb3cbe1.cache": entry "/0079346-7ebd13fb.cache" at block 4867 offset 936 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 936... entry at block 4867 offset 936 in directory inode 256 has illegal name "/0079346-7ebd13fb.cache": entry "/0079347-022ac661.cache" at block 4867 offset 976 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 976... entry at block 4867 offset 976 in directory inode 256 has illegal name "/0079347-022ac661.cache": entry "/0079348-28feb14b.cache" at block 4867 offset 1016 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 1016... entry at block 4867 offset 1016 in directory inode 256 has illegal name "/0079348-28feb14b.cache": entry "/0079349-57822835.cache" at block 4867 offset 1056 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 1056... entry at block 4867 offset 1056 in directory inode 256 has illegal name "/0079349-57822835.cache": entry "/007934a-bfeea8ef.cache" at block 4867 offset 1096 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 1096... entry at block 4867 offset 1096 in directory inode 256 has illegal name "/007934a-bfeea8ef.cache": entry "/007934b-6bc3ed39.cache" at block 4867 offset 1136 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 1136... entry at block 4867 offset 1136 in directory inode 256 has illegal name "/007934b-6bc3ed39.cache": entry "/007934c-41179a13.cache" at block 4867 offset 1176 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 1176... entry at block 4867 offset 1176 in directory inode 256 has illegal name "/007934c-41179a13.cache": entry "/007934d-3e6b036d.cache" at block 4867 offset 1216 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 1216... entry at block 4867 offset 1216 in directory inode 256 has illegal name "/007934d-3e6b036d.cache": entry "/007934e-14bf7447.cache" at block 4867 offset 1256 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 1256... entry at block 4867 offset 1256 in directory inode 256 has illegal name "/007934e-14bf7447.cache": entry "/007934f-959a21b0.cache" at block 4867 offset 1296 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 1296... entry at block 4867 offset 1296 in directory inode 256 has illegal name "/007934f-959a21b0.cache": entry "/0079350-bf4e569a.cache" at block 4867 offset 1336 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 1336... entry at block 4867 offset 1336 in directory inode 256 has illegal name "/0079350-bf4e569a.cache": entry "/0079351-af8abe03.cache" at block 4867 offset 1376 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 1376... entry at block 4867 offset 1376 in directory inode 256 has illegal name "/0079351-af8abe03.cache": entry "/0079352-855ec929.cache" at block 4867 offset 1416 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 1416... entry at block 4867 offset 1416 in directory inode 256 has illegal name "/0079352-855ec929.cache": entry "/0079353-483ca746.cache" at block 4867 offset 1456 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 1456... entry at block 4867 offset 1456 in directory inode 256 has illegal name "/0079353-483ca746.cache": entry "/0079354-62e8d06c.cache" at block 4867 offset 1496 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 1496... entry at block 4867 offset 1496 in directory inode 256 has illegal name "/0079354-62e8d06c.cache": entry "/0079355-b6c595ba.cache" at block 4867 offset 1536 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 1536... entry at block 4867 offset 1536 in directory inode 256 has illegal name "/0079355-b6c595ba.cache": entry "/0079356-9c11e290.cache" at block 4867 offset 1576 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 1576... entry at block 4867 offset 1576 in directory inode 256 has illegal name "/0079356-9c11e290.cache": entry "/0079357-3bb7d4de.cache" at block 4867 offset 1616 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 1616... entry at block 4867 offset 1616 in directory inode 256 has illegal name "/0079357-3bb7d4de.cache": entry "/0079358-1163a3f4.cache" at block 4867 offset 1656 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 1656... entry at block 4867 offset 1656 in directory inode 256 has illegal name "/0079358-1163a3f4.cache": entry "/0079359-489c5933.cache" at block 4867 offset 1696 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 1696... entry at block 4867 offset 1696 in directory inode 256 has illegal name "/0079359-489c5933.cache": entry "/007935a-4e39b291.cache" at block 4867 offset 1736 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 1736... entry at block 4867 offset 1736 in directory inode 256 has illegal name "/007935a-4e39b291.cache": entry "/007935b-1c396841.cache" at block 4867 offset 1776 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 1776... entry at block 4867 offset 1776 in directory inode 256 has illegal name "/007935b-1c396841.cache": entry "/007935c-73397b5a.cache" at block 4867 offset 1816 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 1816... entry at block 4867 offset 1816 in directory inode 256 has illegal name "/007935c-73397b5a.cache": entry "/007935d-6baa9000.cache" at block 4867 offset 1856 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 1856... entry at block 4867 offset 1856 in directory inode 256 has illegal name "/007935d-6baa9000.cache": entry "/007935e-04aa831b.cache" at block 4867 offset 1896 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 1896... entry at block 4867 offset 1896 in directory inode 256 has illegal name "/007935e-04aa831b.cache": entry "/007935f-c3d4230b.cache" at block 4867 offset 1936 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 1936... entry at block 4867 offset 1936 in directory inode 256 has illegal name "/007935f-c3d4230b.cache": entry "/0079360-acd43010.cache" at block 4867 offset 1976 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 1976... entry at block 4867 offset 1976 in directory inode 256 has illegal name "/0079360-acd43010.cache": entry "/0079361-1dd4053d.cache" at block 4867 offset 2016 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 2016... entry at block 4867 offset 2016 in directory inode 256 has illegal name "/0079361-1dd4053d.cache": entry "/0079362-72d41626.cache" at block 4867 offset 2056 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 2056... entry at block 4867 offset 2056 in directory inode 256 has illegal name "/0079362-72d41626.cache": entry "/0079363-a4a56926.cache" at block 4867 offset 2096 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 2096... entry at block 4867 offset 2096 in directory inode 256 has illegal name "/0079363-a4a56926.cache": entry "/0079364-1fc2e0e6.cache" at block 4867 offset 2136 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 2136... entry at block 4867 offset 2136 in directory inode 256 has illegal name "/0079364-1fc2e0e6.cache": entry "/0079365-aec2d5cb.cache" at block 4867 offset 2176 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 2176... entry at block 4867 offset 2176 in directory inode 256 has illegal name "/0079365-aec2d5cb.cache": entry "/0079366-c1c2c6d0.cache" at block 4867 offset 2216 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 2216... entry at block 4867 offset 2216 in directory inode 256 has illegal name "/0079366-c1c2c6d0.cache": entry "/0079367-d9512d8a.cache" at block 4867 offset 2256 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 2256... entry at block 4867 offset 2256 in directory inode 256 has illegal name "/0079367-d9512d8a.cache": entry "/0079368-5ac7d03f.cache" at block 4867 offset 2296 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 2296... entry at block 4867 offset 2296 in directory inode 256 has illegal name "/0079368-5ac7d03f.cache": entry "/0079369-be4b0b3e.cache" at block 4867 offset 2336 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 2336... entry at block 4867 offset 2336 in directory inode 256 has illegal name "/0079369-be4b0b3e.cache": entry "/007936a-d14b1825.cache" at block 4867 offset 2376 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 2376... entry at block 4867 offset 2376 in directory inode 256 has illegal name "/007936a-d14b1825.cache": entry "/007936b-604b2d08.cache" at block 4867 offset 2416 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 2416... entry at block 4867 offset 2416 in directory inode 256 has illegal name "/007936b-604b2d08.cache": entry "/007936c-e1810ba0.cache" at block 4867 offset 2456 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 2456... entry at block 4867 offset 2456 in directory inode 256 has illegal name "/007936c-e1810ba0.cache": entry "/007936d-37f074a0.cache" at block 4867 offset 2496 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 2496... entry at block 4867 offset 2496 in directory inode 256 has illegal name "/007936d-37f074a0.cache": entry "/007936e-58f067bb.cache" at block 4867 offset 2536 in directory inode 256 references invalid inode 18374686479671623679 clearing inode number in entry at offset 2536... entry at block 4867 offset 2536 in directory inode 256 has illegal name "/007936e-58f067bb.cache": - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 - agno = 16 - agno = 17 - agno = 18 - agno = 19 - agno = 20 - agno = 21 - agno = 22 - agno = 23 - agno = 24 - agno = 25 - agno = 26 - agno = 27 - agno = 28 - agno = 29 - agno = 30 - agno = 31 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - clear lost+found (if it exists) ... could not map block 2209 could not map block 2210 could not map block 2211 could not map block 2212 could not map block 2213 could not map block 2214 could not map block 2215 could not map block 2216 could not map block 2217 could not map block 2218 could not map block 2219 could not map block 2220 could not map block 2221 could not map block 2222 could not map block 2223 could not map block 2224 could not map block 2225 could not map block 2226 could not map block 2227 could not map block 2228 could not map block 2229 could not map block 2230 could not map block 2231 could not map block 2232 could not map block 2233 could not map block 2234 could not map block 2235 could not map block 2236 could not map block 2237 could not map block 2238 could not map block 2239 could not map block 2240 could not map block 2241 could not map block 2242 could not map block 2243 could not map block 2244 could not map block 2245 could not map block 2246 could not map block 2247 could not map block 2248 could not map block 2249 could not map block 2250 could not map block 2251 could not map block 2252 could not map block 2253 could not map block 2254 could not map block 2255 could not map block 2256 could not map block 2257 could not map block 2258 could not map block 2259 could not map block 2260 could not map block 2261 could not map block 2262 could not map block 2263 could not map block 2264 could not map block 2265 could not map block 2266 could not map block 2267 could not map block 2268 could not map block 2269 could not map block 2270 could not map block 2271 could not map block 2272 could not map block 2273 could not map block 2274 could not map block 2275 could not map block 2276 could not map block 2277 could not map block 2278 could not map block 2279 could not map block 2280 could not map block 2281 could not map block 2282 could not map block 2283 could not map block 2284 could not map block 2285 could not map block 2286 could not map block 2287 could not map block 2288 could not map block 2289 could not map block 2290 could not map block 2291 could not map block 2292 could not map block 2293 could not map block 2294 could not map block 2295 could not map block 2296 could not map block 2297 could not map block 2298 could not map block 2299 could not map block 2300 could not map block 2301 could not map block 2302 could not map block 2303 could not map block 2304 could not map block 2305 could not map block 2306 could not map block 2307 could not map block 2308 could not map block 2309 could not map block 2310 could not map block 2311 could not map block 2312 could not map block 2313 could not map block 2314 could not map block 2315 could not map block 2316 could not map block 2317 could not map block 2318 could not map block 2319 could not map block 2320 could not map block 2321 could not map block 2322 could not map block 2323 could not map block 2324 could not map block 2325 could not map block 2326 could not map block 2327 could not map block 2328 could not map block 2329 could not map block 2330 could not map block 2331 could not map block 2332 could not map block 2333 could not map block 2334 could not map block 2335 could not map block 2336 could not map block 2337 could not map block 2338 could not map block 2339 could not map block 2340 could not map block 2341 could not map block 2342 could not map block 2343 could not map block 2344 could not map block 2345 could not map block 2346 could not map block 2347 could not map block 2348 could not map block 2349 could not map block 2350 could not map block 2351 could not map block 2352 could not map block 2353 could not map block 2354 could not map block 2355 could not map block 2356 could not map block 2357 could not map block 2358 could not map block 2359 could not map block 2360 could not map block 2361 could not map block 2362 could not map block 2363 could not map block 2364 could not map block 2365 could not map block 2366 could not map block 2367 could not map block 2368 could not map block 2369 could not map block 2370 could not map block 2371 could not map block 2372 could not map block 2373 could not map block 2374 could not map block 2375 could not map block 2376 could not map block 2377 could not map block 2378 could not map block 2379 could not map block 2380 could not map block 2381 could not map block 2382 could not map block 2383 could not map block 2384 could not map block 2385 could not map block 2386 could not map block 2387 could not map block 2388 could not map block 2389 could not map block 2390 could not map block 2391 could not map block 2392 could not map block 2393 could not map block 2394 could not map block 2395 could not map block 2396 could not map block 2397 could not map block 2398 could not map block 2399 could not map block 2400 could not map block 2401 could not map block 2402 could not map block 2403 could not map block 2404 could not map block 2405 could not map block 2406 could not map block 2407 could not map block 2408 could not map block 2409 could not map block 2410 could not map block 2411 could not map block 2412 could not map block 2413 could not map block 2414 could not map block 2415 could not map block 2416 could not map block 2417 could not map block 2418 could not map block 2419 could not map block 2420 could not map block 2421 could not map block 2422 could not map block 2423 could not map block 2424 could not map block 2425 could not map block 2426 could not map block 2427 could not map block 2428 could not map block 2429 could not map block 2430 could not map block 2431 could not map block 2432 could not map block 2433 could not map block 2434 could not map block 2435 could not map block 2436 could not map block 2437 could not map block 2438 could not map block 2439 could not map block 2440 could not map block 2441 could not map block 2442 could not map block 2443 could not map block 2444 could not map block 2445 could not map block 2446 could not map block 2447 could not map block 2448 could not map block 2449 could not map block 2450 could not map block 2451 could not map block 2452 could not map block 2453 could not map block 2454 could not map block 2455 could not map block 2456 could not map block 2457 could not map block 2458 could not map block 2459 could not map block 2460 could not map block 2461 could not map block 2462 could not map block 2463 could not map block 2464 could not map block 2465 could not map block 2466 could not map block 2467 could not map block 2468 could not map block 2469 could not map block 2470 could not map block 2471 could not map block 2472 could not map block 2473 could not map block 2474 could not map block 2475 could not map block 2476 could not map block 2477 could not map block 2478 could not map block 2479 could not map block 2480 could not map block 2481 could not map block 2482 could not map block 2483 could not map block 2484 could not map block 2485 could not map block 2486 could not map block 2487 could not map block 2488 could not map block 2489 could not map block 2490 could not map block 2491 could not map block 2492 could not map block 2493 could not map block 2494 could not map block 2495 could not map block 2496 could not map block 2497 could not map block 2498 could not map block 2499 could not map block 2500 could not map block 2501 could not map block 2502 could not map block 2503 could not map block 2504 could not map block 2505 could not map block 2506 could not map block 2507 could not map block 2508 could not map block 2509 could not map block 2510 could not map block 2511 could not map block 2512 could not map block 2513 could not map block 2514 could not map block 2515 could not map block 2516 could not map block 2517 could not map block 2518 could not map block 2519 could not map block 2520 could not map block 2521 could not map block 2522 could not map block 2523 could not map block 2524 could not map block 2525 could not map block 2526 could not map block 2527 could not map block 2528 could not map block 2529 could not map block 2530 could not map block 2531 could not map block 2532 could not map block 2533 could not map block 2534 could not map block 2535 could not map block 2536 could not map block 2537 could not map block 2538 could not map block 2539 could not map block 2540 could not map block 2541 could not map block 2542 could not map block 2543 could not map block 2544 could not map block 2545 could not map block 2546 could not map block 2547 could not map block 2548 could not map block 2549 could not map block 2550 could not map block 2551 could not map block 2552 could not map block 2553 could not map block 2554 could not map block 2555 could not map block 2556 could not map block 2557 could not map block 2558 could not map block 2559 could not map block 2560 could not map block 2561 could not map block 2562 could not map block 2563 could not map block 2564 could not map block 2565 could not map block 2566 could not map block 2567 could not map block 2568 could not map block 2569 could not map block 2570 could not map block 2571 could not map block 2572 could not map block 2573 could not map block 2574 could not map block 2575 could not map block 2576 could not map block 2577 could not map block 2578 could not map block 2579 could not map block 2580 could not map block 2581 could not map block 2582 could not map block 2583 could not map block 2584 could not map block 2585 could not map block 2586 could not map block 2587 could not map block 2588 could not map block 2589 could not map block 2590 could not map block 2591 could not map block 2592 could not map block 2593 could not map block 2594 could not map block 2595 could not map block 2596 could not map block 2597 could not map block 2598 could not map block 2599 could not map block 2600 could not map block 2601 could not map block 2602 could not map block 2603 could not map block 2604 could not map block 2605 could not map block 2606 could not map block 2607 could not map block 2608 could not map block 2609 could not map block 2610 could not map block 2611 could not map block 2612 could not map block 2613 could not map block 2614 could not map block 2615 could not map block 2616 could not map block 2617 could not map block 2618 could not map block 2619 could not map block 2620 could not map block 2621 could not map block 2622 could not map block 2623 could not map block 2624 could not map block 2625 could not map block 2626 could not map block 2627 could not map block 2628 could not map block 2629 could not map block 2630 could not map block 2631 could not map block 2632 could not map block 2633 could not map block 2634 could not map block 2635 could not map block 2636 could not map block 2637 could not map block 2638 could not map block 2639 could not map block 2640 could not map block 2641 could not map block 2642 could not map block 2643 could not map block 2644 could not map block 2645 could not map block 2646 could not map block 2647 could not map block 2648 could not map block 2649 could not map block 2650 could not map block 2651 could not map block 2652 could not map block 2653 could not map block 2654 could not map block 2655 could not map block 2656 could not map block 2657 could not map block 2658 could not map block 2659 could not map block 2660 could not map block 2661 could not map block 2662 could not map block 2663 could not map block 2664 could not map block 2665 could not map block 2666 could not map block 2667 could not map block 2668 could not map block 2669 could not map block 2670 could not map block 2671 could not map block 2672 could not map block 2673 could not map block 2674 could not map block 2675 could not map block 2676 could not map block 2677 could not map block 2678 could not map block 2679 could not map block 2680 could not map block 2681 could not map block 2682 could not map block 2683 could not map block 2684 could not map block 2685 could not map block 2686 could not map block 2687 could not map block 2688 could not map block 2689 could not map block 2690 could not map block 2691 could not map block 2692 could not map block 2693 could not map block 2694 could not map block 2695 could not map block 2696 could not map block 2697 could not map block 2698 could not map block 2699 could not map block 2700 could not map block 2701 could not map block 2702 could not map block 2703 could not map block 2704 could not map block 2705 could not map block 2706 could not map block 2707 could not map block 2708 could not map block 2709 could not map block 2710 could not map block 2711 could not map block 2712 could not map block 2713 could not map block 2714 could not map block 2715 could not map block 2716 could not map block 2717 could not map block 2718 could not map block 2719 could not map block 2720 could not map block 2721 could not map block 2722 could not map block 2723 could not map block 2724 could not map block 2725 could not map block 2726 could not map block 2727 could not map block 2728 could not map block 2729 could not map block 2730 could not map block 2731 could not map block 2732 could not map block 2733 could not map block 2734 could not map block 2735 could not map block 2736 could not map block 2737 could not map block 2738 could not map block 2739 could not map block 2740 could not map block 2741 could not map block 2742 could not map block 2743 could not map block 2744 could not map block 2745 could not map block 2746 could not map block 2747 could not map block 2748 could not map block 2749 could not map block 2750 could not map block 2751 could not map block 2752 could not map block 2753 could not map block 2754 could not map block 2755 could not map block 2756 could not map block 2757 could not map block 2758 could not map block 2759 could not map block 2760 could not map block 2761 could not map block 2762 could not map block 2763 could not map block 2764 could not map block 2765 could not map block 2766 could not map block 2767 could not map block 2768 could not map block 2769 could not map block 2770 could not map block 2771 could not map block 2772 could not map block 2773 could not map block 2774 could not map block 2775 could not map block 2776 could not map block 2777 could not map block 2778 could not map block 2779 could not map block 2780 could not map block 2781 could not map block 2782 could not map block 2783 could not map block 2784 could not map block 2785 could not map block 2786 could not map block 2787 could not map block 2788 could not map block 2789 could not map block 2790 could not map block 2791 could not map block 2792 could not map block 2793 could not map block 2794 could not map block 2795 could not map block 2796 could not map block 2797 could not map block 2798 could not map block 2799 could not map block 2800 could not map block 2801 could not map block 2802 could not map block 2803 could not map block 2804 could not map block 2805 could not map block 2806 could not map block 2807 could not map block 2808 could not map block 2809 could not map block 2810 could not map block 2811 could not map block 2812 could not map block 2813 could not map block 2814 could not map block 2815 could not map block 2816 could not map block 2817 could not map block 2818 could not map block 2819 could not map block 2820 could not map block 2821 could not map block 2822 could not map block 2823 could not map block 2824 could not map block 2825 could not map block 2826 could not map block 2827 could not map block 2828 could not map block 2829 could not map block 2830 could not map block 2831 could not map block 2832 could not map block 2833 could not map block 2834 could not map block 2835 could not map block 2836 could not map block 2837 could not map block 2838 could not map block 2839 could not map block 2840 could not map block 2841 could not map block 2842 could not map block 2843 could not map block 2844 could not map block 2845 could not map block 2846 could not map block 2847 could not map block 2848 could not map block 2849 could not map block 2850 could not map block 2851 could not map block 2852 could not map block 2853 could not map block 2854 could not map block 2855 could not map block 2856 could not map block 2857 could not map block 2858 could not map block 2859 could not map block 2860 could not map block 2861 could not map block 2862 could not map block 2863 could not map block 2864 could not map block 2865 could not map block 2866 could not map block 2867 could not map block 2868 could not map block 2869 could not map block 2870 could not map block 2871 could not map block 2872 could not map block 2873 could not map block 2874 could not map block 2875 could not map block 2876 could not map block 2877 could not map block 2878 could not map block 2879 could not map block 2880 could not map block 2881 could not map block 2882 could not map block 2883 could not map block 2884 could not map block 2885 could not map block 2886 could not map block 2887 could not map block 2888 could not map block 2889 could not map block 2890 could not map block 2891 could not map block 2892 could not map block 2893 could not map block 2894 could not map block 2895 could not map block 2896 could not map block 2897 could not map block 2898 could not map block 2899 could not map block 2900 could not map block 2901 could not map block 2902 could not map block 2903 could not map block 2904 could not map block 2905 could not map block 2906 could not map block 2907 could not map block 2908 could not map block 2909 could not map block 2910 could not map block 2911 could not map block 2912 could not map block 2913 could not map block 2914 could not map block 2915 could not map block 2916 could not map block 2917 could not map block 2918 could not map block 2919 could not map block 2920 could not map block 2921 could not map block 2922 could not map block 2923 could not map block 2924 could not map block 2925 could not map block 2926 could not map block 2927 could not map block 2928 could not map block 2929 could not map block 2930 could not map block 2931 could not map block 2932 could not map block 2933 could not map block 2934 could not map block 2935 could not map block 2936 could not map block 2937 could not map block 2938 could not map block 2939 could not map block 2940 could not map block 2941 could not map block 2942 could not map block 2943 could not map block 2944 could not map block 2945 could not map block 2946 could not map block 2947 could not map block 2948 could not map block 2949 could not map block 2950 could not map block 2951 could not map block 2952 could not map block 2953 could not map block 2954 could not map block 2955 could not map block 2956 could not map block 2957 could not map block 2958 could not map block 2959 could not map block 2960 could not map block 2961 could not map block 2962 could not map block 2963 could not map block 2964 could not map block 2965 could not map block 2966 could not map block 2967 could not map block 2968 could not map block 2969 could not map block 2970 could not map block 2971 could not map block 2972 could not map block 2973 could not map block 2974 could not map block 2975 could not map block 2976 could not map block 2977 could not map block 2978 could not map block 2979 could not map block 2980 could not map block 2981 could not map block 2982 could not map block 2983 could not map block 2984 could not map block 2985 could not map block 2986 could not map block 2987 could not map block 2988 could not map block 2989 could not map block 2990 could not map block 2991 could not map block 2992 could not map block 2993 could not map block 2994 could not map block 2995 could not map block 2996 could not map block 2997 could not map block 2998 could not map block 2999 could not map block 3000 could not map block 3001 could not map block 3002 could not map block 3003 could not map block 3004 could not map block 3005 could not map block 3006 could not map block 3007 could not map block 3008 could not map block 3009 could not map block 3010 could not map block 3011 could not map block 3012 could not map block 3013 could not map block 3014 could not map block 3015 could not map block 3016 could not map block 3017 could not map block 3018 could not map block 3019 could not map block 3020 could not map block 3021 could not map block 3022 could not map block 3023 could not map block 3024 could not map block 3025 could not map block 3026 could not map block 3027 could not map block 3028 could not map block 3029 could not map block 3030 could not map block 3031 could not map block 3032 could not map block 3033 could not map block 3034 could not map block 3035 could not map block 3036 could not map block 3037 could not map block 3038 could not map block 3039 could not map block 3040 could not map block 3041 could not map block 3042 could not map block 3043 could not map block 3044 could not map block 3045 could not map block 3046 could not map block 3047 could not map block 3048 could not map block 3049 could not map block 3050 could not map block 3051 could not map block 3052 could not map block 3053 could not map block 3054 could not map block 3055 could not map block 3056 could not map block 3057 could not map block 3058 could not map block 3059 could not map block 3060 could not map block 3061 could not map block 3062 could not map block 3063 could not map block 3064 could not map block 3065 could not map block 3066 could not map block 3067 could not map block 3068 could not map block 3069 could not map block 3070 could not map block 3071 could not map block 3072 could not map block 3073 could not map block 3074 could not map block 3075 could not map block 3076 could not map block 3077 could not map block 3078 could not map block 3079 could not map block 3080 could not map block 3081 could not map block 3082 could not map block 3083 could not map block 3084 could not map block 3085 could not map block 3086 could not map block 3087 could not map block 3088 could not map block 3089 could not map block 3090 could not map block 3091 could not map block 3092 could not map block 3093 could not map block 3094 could not map block 3095 could not map block 3096 could not map block 3097 could not map block 3098 could not map block 3099 could not map block 3100 could not map block 3101 could not map block 3102 could not map block 3103 could not map block 3104 could not map block 3105 could not map block 3106 could not map block 3107 could not map block 3108 could not map block 3109 could not map block 3110 could not map block 3111 could not map block 3112 could not map block 3113 could not map block 3114 could not map block 3115 could not map block 3116 could not map block 3117 could not map block 3118 could not map block 3119 could not map block 3120 could not map block 3121 could not map block 3122 could not map block 3123 could not map block 3124 could not map block 3125 could not map block 3126 could not map block 3127 could not map block 3128 could not map block 3129 could not map block 3130 could not map block 3131 could not map block 3132 could not map block 3133 could not map block 3134 could not map block 3135 could not map block 3136 could not map block 3137 could not map block 3138 could not map block 3139 could not map block 3140 could not map block 3141 could not map block 3142 could not map block 3143 could not map block 3144 could not map block 3145 could not map block 3146 could not map block 3147 could not map block 3148 could not map block 3149 could not map block 3150 could not map block 3151 could not map block 3152 could not map block 3153 could not map block 3154 could not map block 3155 could not map block 3156 could not map block 3157 could not map block 3158 could not map block 3159 could not map block 3160 could not map block 3161 could not map block 3162 could not map block 3163 could not map block 3164 could not map block 3165 could not map block 3166 could not map block 3167 could not map block 3168 could not map block 3169 could not map block 3170 could not map block 3171 could not map block 3172 could not map block 3173 could not map block 3174 could not map block 3175 could not map block 3176 could not map block 3177 could not map block 3178 could not map block 3179 could not map block 3180 could not map block 3181 could not map block 3182 could not map block 3183 could not map block 3184 could not map block 3185 could not map block 3186 could not map block 3187 could not map block 3188 could not map block 3189 could not map block 3190 could not map block 3191 could not map block 3192 could not map block 3193 could not map block 3194 could not map block 3195 could not map block 3196 could not map block 3197 could not map block 3198 could not map block 3199 could not map block 3200 could not map block 3201 could not map block 3202 could not map block 3203 could not map block 3204 could not map block 3205 could not map block 3206 could not map block 3207 could not map block 3208 could not map block 3209 could not map block 3210 could not map block 3211 could not map block 3212 could not map block 3213 could not map block 3214 could not map block 3215 could not map block 3216 could not map block 3217 could not map block 3218 could not map block 3219 could not map block 3220 could not map block 3221 could not map block 3222 could not map block 3223 could not map block 3224 could not map block 3225 could not map block 3226 could not map block 3227 could not map block 3228 could not map block 3229 could not map block 3230 could not map block 3231 could not map block 3232 could not map block 3233 could not map block 3234 could not map block 3235 could not map block 3236 could not map block 3237 could not map block 3238 could not map block 3239 could not map block 3240 could not map block 3241 could not map block 3242 could not map block 3243 could not map block 3244 could not map block 3245 could not map block 3246 could not map block 3247 could not map block 3248 could not map block 3249 could not map block 3250 could not map block 3251 could not map block 3252 could not map block 3253 could not map block 3254 could not map block 3255 could not map block 3256 could not map block 3257 could not map block 3258 could not map block 3259 could not map block 3260 could not map block 3261 could not map block 3262 could not map block 3263 could not map block 3264 could not map block 3265 could not map block 3266 could not map block 3267 could not map block 3268 could not map block 3269 could not map block 3270 could not map block 3271 could not map block 3272 could not map block 3273 could not map block 3274 could not map block 3275 could not map block 3276 could not map block 3277 could not map block 3278 could not map block 3279 could not map block 3280 could not map block 3281 could not map block 3282 could not map block 3283 could not map block 3284 could not map block 3285 could not map block 3286 could not map block 3287 could not map block 3288 could not map block 3289 could not map block 3290 could not map block 3291 could not map block 3292 could not map block 3293 could not map block 3294 could not map block 3295 could not map block 3296 could not map block 3297 could not map block 3298 could not map block 3299 could not map block 3300 could not map block 3301 could not map block 3302 could not map block 3303 could not map block 3304 could not map block 3305 could not map block 3306 could not map block 3307 could not map block 3308 could not map block 3309 could not map block 3310 could not map block 3311 could not map block 3312 could not map block 3313 could not map block 3314 could not map block 3315 could not map block 3316 could not map block 3317 could not map block 3318 could not map block 3319 could not map block 3320 could not map block 3321 could not map block 3322 could not map block 3323 could not map block 3324 could not map block 3325 could not map block 3326 could not map block 3327 could not map block 3328 could not map block 3329 could not map block 3330 could not map block 3331 could not map block 3332 could not map block 3333 could not map block 3334 could not map block 3335 could not map block 3336 could not map block 3337 could not map block 3338 could not map block 3339 could not map block 3340 could not map block 3341 could not map block 3342 could not map block 3343 could not map block 3344 could not map block 3345 could not map block 3346 could not map block 3347 could not map block 3348 could not map block 3349 could not map block 3350 could not map block 3351 could not map block 3352 could not map block 3353 could not map block 3354 could not map block 3355 could not map block 3356 could not map block 3357 could not map block 3358 could not map block 3359 could not map block 3360 could not map block 3361 could not map block 3362 could not map block 3363 could not map block 3364 could not map block 3365 could not map block 3366 could not map block 3367 could not map block 3368 could not map block 3369 could not map block 3370 could not map block 3371 could not map block 3372 could not map block 3373 could not map block 3374 could not map block 3375 could not map block 3376 could not map block 3377 could not map block 3378 could not map block 3379 could not map block 3380 could not map block 3381 could not map block 3382 could not map block 3383 could not map block 3384 could not map block 3385 could not map block 3386 could not map block 3387 could not map block 3388 could not map block 3389 could not map block 3390 could not map block 3391 could not map block 3392 could not map block 3393 could not map block 3394 could not map block 3395 could not map block 3396 could not map block 3397 could not map block 3398 could not map block 3399 could not map block 3400 could not map block 3401 could not map block 3402 could not map block 3403 could not map block 3404 could not map block 3405 could not map block 3406 could not map block 3407 could not map block 3408 could not map block 3409 could not map block 3410 could not map block 3411 could not map block 3412 could not map block 3413 could not map block 3414 could not map block 3415 could not map block 3416 could not map block 3417 could not map block 3418 could not map block 3419 could not map block 3420 could not map block 3421 could not map block 3422 could not map block 3423 could not map block 3424 could not map block 3425 could not map block 3426 could not map block 3427 could not map block 3428 could not map block 3429 could not map block 3430 could not map block 3431 could not map block 3432 could not map block 3433 could not map block 3434 could not map block 3435 could not map block 3436 could not map block 3437 could not map block 3438 could not map block 3439 could not map block 3440 could not map block 3441 could not map block 3442 could not map block 3443 could not map block 3444 could not map block 3445 could not map block 3446 could not map block 3447 could not map block 3448 could not map block 3449 could not map block 3450 could not map block 3451 could not map block 3452 could not map block 3453 could not map block 3454 could not map block 3455 could not map block 3456 could not map block 3457 could not map block 3458 could not map block 3459 could not map block 3460 could not map block 3461 could not map block 3462 could not map block 3463 could not map block 3464 could not map block 3465 could not map block 3466 could not map block 3467 could not map block 3468 could not map block 3469 could not map block 3470 could not map block 3471 could not map block 3472 could not map block 3473 could not map block 3474 could not map block 3475 could not map block 3476 could not map block 3477 could not map block 3478 could not map block 3479 could not map block 3480 could not map block 3481 could not map block 3482 could not map block 3483 could not map block 3484 could not map block 3485 could not map block 3486 could not map block 3487 could not map block 3488 could not map block 3489 could not map block 3490 could not map block 3491 could not map block 3492 could not map block 3493 could not map block 3494 could not map block 3495 could not map block 3496 could not map block 3497 could not map block 3498 could not map block 3499 could not map block 3500 could not map block 3501 could not map block 3502 could not map block 3503 could not map block 3504 could not map block 3505 could not map block 3506 could not map block 3507 could not map block 3508 could not map block 3509 could not map block 3510 could not map block 3511 could not map block 3512 could not map block 3513 could not map block 3514 could not map block 3515 could not map block 3516 could not map block 3517 could not map block 3518 could not map block 3519 could not map block 3520 could not map block 3521 could not map block 3522 could not map block 3523 could not map block 3524 could not map block 3525 could not map block 3526 could not map block 3527 could not map block 3528 could not map block 3529 could not map block 3530 could not map block 3531 could not map block 3532 could not map block 3533 could not map block 3534 could not map block 3535 could not map block 3536 could not map block 3537 could not map block 3538 could not map block 3539 could not map block 3540 could not map block 3541 could not map block 3542 could not map block 3543 could not map block 3544 could not map block 3545 could not map block 3546 could not map block 3547 could not map block 3548 could not map block 3549 could not map block 3550 could not map block 3551 could not map block 3552 could not map block 3553 could not map block 3554 could not map block 3555 could not map block 3556 could not map block 3557 could not map block 3558 could not map block 3559 could not map block 3560 could not map block 3561 could not map block 3562 could not map block 3563 could not map block 3564 could not map block 3565 could not map block 3566 could not map block 3567 could not map block 3568 could not map block 3569 could not map block 3570 could not map block 3571 could not map block 3572 could not map block 3573 could not map block 3574 could not map block 3575 could not map block 3576 could not map block 3577 could not map block 3578 could not map block 3579 could not map block 3580 could not map block 3581 could not map block 3582 could not map block 3583 could not map block 3584 could not map block 3585 could not map block 3586 could not map block 3587 could not map block 3588 could not map block 3589 could not map block 3590 could not map block 3591 could not map block 3592 could not map block 3593 could not map block 3594 could not map block 3595 could not map block 3596 could not map block 3597 could not map block 3598 could not map block 3599 could not map block 3600 could not map block 3601 could not map block 3602 could not map block 3603 could not map block 3604 could not map block 3605 could not map block 3606 could not map block 3607 could not map block 3608 could not map block 3609 could not map block 3610 could not map block 3611 could not map block 3612 could not map block 3613 could not map block 3614 could not map block 3615 could not map block 3616 could not map block 3617 could not map block 3618 could not map block 3619 could not map block 3620 could not map block 3621 could not map block 3622 could not map block 3623 could not map block 3624 could not map block 3625 could not map block 3626 could not map block 3627 could not map block 3628 could not map block 3629 could not map block 3630 could not map block 3631 could not map block 3632 could not map block 3633 could not map block 3634 could not map block 3635 could not map block 3636 could not map block 3637 could not map block 3638 could not map block 3639 could not map block 3640 could not map block 3641 could not map block 3642 could not map block 3643 could not map block 3644 could not map block 3645 could not map block 3646 could not map block 3647 could not map block 3648 could not map block 3649 could not map block 3650 could not map block 3651 could not map block 3652 could not map block 3653 could not map block 3654 could not map block 3655 could not map block 3656 could not map block 3657 could not map block 3658 could not map block 3659 could not map block 3660 could not map block 3661 could not map block 3662 could not map block 3663 could not map block 3664 could not map block 3665 could not map block 3666 could not map block 3667 could not map block 3668 could not map block 3669 could not map block 3670 could not map block 3671 could not map block 3672 could not map block 3673 could not map block 3674 could not map block 3675 could not map block 3676 could not map block 3677 could not map block 3678 could not map block 3679 could not map block 3680 could not map block 3681 could not map block 3682 could not map block 3683 could not map block 3684 could not map block 3685 could not map block 3686 could not map block 3687 could not map block 3688 could not map block 3689 could not map block 3690 could not map block 3691 could not map block 3692 could not map block 3693 could not map block 3694 could not map block 3695 could not map block 3696 could not map block 3697 could not map block 3698 could not map block 3699 could not map block 3700 could not map block 3701 could not map block 3702 could not map block 3703 could not map block 3704 could not map block 3705 could not map block 3706 could not map block 3707 could not map block 3708 could not map block 3709 could not map block 3710 could not map block 3711 could not map block 3712 could not map block 3713 could not map block 3714 could not map block 3715 could not map block 3716 could not map block 3717 could not map block 3718 could not map block 3719 could not map block 3720 could not map block 3721 could not map block 3722 could not map block 3723 could not map block 3724 could not map block 3725 could not map block 3726 could not map block 3727 could not map block 3728 could not map block 3729 could not map block 3730 could not map block 3731 could not map block 3732 could not map block 3733 could not map block 3734 could not map block 3735 could not map block 3736 could not map block 3737 could not map block 3738 could not map block 3739 could not map block 3740 could not map block 3741 could not map block 3742 could not map block 3743 could not map block 3744 could not map block 3745 could not map block 3746 could not map block 3747 could not map block 3748 could not map block 3749 could not map block 3750 could not map block 3751 could not map block 3752 could not map block 3753 could not map block 3754 could not map block 3755 could not map block 3756 could not map block 3757 could not map block 3758 could not map block 3759 could not map block 3760 could not map block 3761 could not map block 3762 could not map block 3763 could not map block 3764 could not map block 3765 could not map block 3766 could not map block 3767 could not map block 3768 could not map block 3769 could not map block 3770 could not map block 3771 could not map block 3772 could not map block 3773 could not map block 3774 could not map block 3775 could not map block 3776 could not map block 3777 could not map block 3778 could not map block 3779 could not map block 3780 could not map block 3781 could not map block 3782 could not map block 3783 could not map block 3784 could not map block 3785 could not map block 3786 could not map block 3787 could not map block 3788 could not map block 3789 could not map block 3790 could not map block 3791 could not map block 3792 could not map block 3793 could not map block 3794 could not map block 3795 could not map block 3796 could not map block 3797 could not map block 3798 could not map block 3799 could not map block 3800 could not map block 3801 could not map block 3802 could not map block 3803 could not map block 3804 could not map block 3805 could not map block 3806 could not map block 3807 could not map block 3808 could not map block 3809 could not map block 3810 could not map block 3811 could not map block 3812 could not map block 3813 could not map block 3814 could not map block 3815 could not map block 3816 could not map block 3817 could not map block 3818 could not map block 3819 could not map block 3820 could not map block 3821 could not map block 3822 could not map block 3823 could not map block 3824 could not map block 3825 could not map block 3826 could not map block 3827 could not map block 3828 could not map block 3829 could not map block 3830 could not map block 3831 could not map block 3832 could not map block 3833 could not map block 3834 could not map block 3835 could not map block 3836 could not map block 3837 could not map block 3838 could not map block 3839 could not map block 3840 could not map block 3841 could not map block 3842 could not map block 3843 could not map block 3844 could not map block 3845 could not map block 3846 could not map block 3847 could not map block 3848 could not map block 3849 could not map block 3850 could not map block 3851 could not map block 3852 could not map block 3853 could not map block 3854 could not map block 3855 could not map block 3856 could not map block 3857 could not map block 3858 could not map block 3859 could not map block 3860 could not map block 3861 could not map block 3862 could not map block 3863 could not map block 3864 could not map block 3865 could not map block 3866 could not map block 3867 could not map block 3868 could not map block 3869 could not map block 3870 could not map block 3871 could not map block 3872 could not map block 3873 could not map block 3874 could not map block 3875 could not map block 3876 could not map block 3877 could not map block 3878 could not map block 3879 could not map block 3880 could not map block 3881 could not map block 3882 could not map block 3883 could not map block 3884 could not map block 3885 could not map block 3886 could not map block 3887 could not map block 3888 could not map block 3889 could not map block 3890 could not map block 3891 could not map block 3892 could not map block 3893 could not map block 3894 could not map block 3895 could not map block 3896 could not map block 3897 could not map block 3898 could not map block 3899 could not map block 3900 could not map block 3901 could not map block 3902 could not map block 3903 could not map block 3904 could not map block 3905 could not map block 3906 could not map block 3907 could not map block 3908 could not map block 3909 could not map block 3910 could not map block 3911 could not map block 3912 could not map block 3913 could not map block 3914 could not map block 3915 could not map block 3916 could not map block 3917 could not map block 3918 could not map block 3919 could not map block 3920 could not map block 3921 could not map block 3922 could not map block 3923 could not map block 3924 could not map block 3925 could not map block 3926 could not map block 3927 could not map block 3928 could not map block 3929 could not map block 3930 could not map block 3931 could not map block 3932 could not map block 3933 could not map block 3934 could not map block 3935 could not map block 3936 could not map block 3937 could not map block 3938 could not map block 3939 could not map block 3940 could not map block 3941 could not map block 3942 could not map block 3943 could not map block 3944 could not map block 3945 could not map block 3946 could not map block 3947 could not map block 3948 could not map block 3949 could not map block 3950 could not map block 3951 could not map block 3952 could not map block 3953 could not map block 3954 could not map block 3955 could not map block 3956 could not map block 3957 could not map block 3958 could not map block 3959 could not map block 3960 could not map block 3961 could not map block 3962 could not map block 3963 could not map block 3964 could not map block 3965 could not map block 3966 could not map block 3967 could not map block 3968 could not map block 3969 could not map block 3970 could not map block 3971 could not map block 3972 could not map block 3973 could not map block 3974 could not map block 3975 could not map block 3976 could not map block 3977 could not map block 3978 could not map block 3979 could not map block 3980 could not map block 3981 could not map block 3982 could not map block 3983 could not map block 3984 could not map block 3985 could not map block 3986 could not map block 3987 could not map block 3988 could not map block 3989 could not map block 3990 could not map block 3991 could not map block 3992 could not map block 3993 could not map block 3994 could not map block 3995 could not map block 3996 could not map block 3997 could not map block 3998 could not map block 3999 could not map block 4000 could not map block 4001 could not map block 4002 could not map block 4003 could not map block 4004 could not map block 4005 could not map block 4006 could not map block 4007 could not map block 4008 could not map block 4009 could not map block 4010 could not map block 4011 could not map block 4012 could not map block 4013 could not map block 4014 could not map block 4015 could not map block 4016 could not map block 4017 could not map block 4018 could not map block 4019 could not map block 4020 could not map block 4021 could not map block 4022 could not map block 4023 could not map block 4024 could not map block 4025 could not map block 4026 could not map block 4027 could not map block 4028 could not map block 4029 could not map block 4030 could not map block 4031 could not map block 4032 could not map block 4033 could not map block 4034 could not map block 4035 could not map block 4036 could not map block 4037 could not map block 4038 could not map block 4039 could not map block 4040 could not map block 4041 could not map block 4042 could not map block 4043 could not map block 4044 could not map block 4045 could not map block 4046 could not map block 4047 could not map block 4048 could not map block 4049 could not map block 4050 could not map block 4051 could not map block 4052 could not map block 4053 could not map block 4054 could not map block 4055 could not map block 4056 could not map block 4057 could not map block 4058 could not map block 4059 could not map block 4060 could not map block 4061 could not map block 4062 could not map block 4063 could not map block 4064 could not map block 4065 could not map block 4066 could not map block 4067 could not map block 4068 could not map block 4069 could not map block 4070 could not map block 4071 could not map block 4072 could not map block 4073 could not map block 4074 could not map block 4075 could not map block 4076 could not map block 4077 could not map block 4078 could not map block 4079 could not map block 4080 could not map block 4081 could not map block 4082 could not map block 4083 could not map block 4084 could not map block 4085 could not map block 4086 could not map block 4087 could not map block 4088 could not map block 4089 could not map block 4090 could not map block 4091 could not map block 4092 could not map block 4093 could not map block 4094 could not map block 4095 could not map block 4096 could not map block 4097 could not map block 4098 could not map block 4099 could not map block 4100 could not map block 4101 could not map block 4102 could not map block 4103 could not map block 4104 could not map block 4105 could not map block 4106 could not map block 4107 could not map block 4108 could not map block 4109 could not map block 4110 could not map block 4111 could not map block 4112 could not map block 4113 could not map block 4114 could not map block 4115 could not map block 4116 could not map block 4117 could not map block 4118 could not map block 4119 could not map block 4120 could not map block 4121 could not map block 4122 could not map block 4123 could not map block 4124 could not map block 4125 could not map block 4126 could not map block 4127 could not map block 4128 could not map block 4129 could not map block 4130 could not map block 4131 could not map block 4132 could not map block 4133 could not map block 4134 could not map block 4135 could not map block 4136 could not map block 4137 could not map block 4138 could not map block 4139 could not map block 4140 could not map block 4141 could not map block 4142 could not map block 4143 could not map block 4144 could not map block 4145 could not map block 4146 could not map block 4147 could not map block 4148 could not map block 4149 could not map block 4150 could not map block 4151 could not map block 4152 could not map block 4153 could not map block 4154 could not map block 4155 could not map block 4156 could not map block 4157 could not map block 4158 could not map block 4159 could not map block 4160 could not map block 4161 could not map block 4162 could not map block 4163 could not map block 4164 could not map block 4165 could not map block 4166 could not map block 4167 could not map block 4168 could not map block 4169 could not map block 4170 could not map block 4171 could not map block 4172 could not map block 4173 could not map block 4174 could not map block 4175 could not map block 4176 could not map block 4177 could not map block 4178 could not map block 4179 could not map block 4180 could not map block 4181 could not map block 4182 could not map block 4183 could not map block 4184 could not map block 4185 could not map block 4186 could not map block 4187 could not map block 4188 could not map block 4189 could not map block 4190 could not map block 4191 could not map block 4192 could not map block 4193 could not map block 4194 could not map block 4195 could not map block 4196 could not map block 4197 could not map block 4198 could not map block 4199 could not map block 4200 could not map block 4201 could not map block 4202 could not map block 4203 could not map block 4204 could not map block 4205 could not map block 4206 could not map block 4207 could not map block 4208 could not map block 4209 could not map block 4210 could not map block 4211 could not map block 4212 could not map block 4213 could not map block 4214 could not map block 4215 could not map block 4216 could not map block 4217 could not map block 4218 could not map block 4219 could not map block 4220 could not map block 4221 could not map block 4222 could not map block 4223 could not map block 4224 could not map block 4225 could not map block 4226 could not map block 4227 could not map block 4228 could not map block 4229 could not map block 4230 could not map block 4231 could not map block 4232 could not map block 4233 could not map block 4234 could not map block 4235 could not map block 4236 could not map block 4237 could not map block 4238 could not map block 4239 could not map block 4240 could not map block 4241 could not map block 4242 could not map block 4243 could not map block 4244 could not map block 4245 could not map block 4246 could not map block 4247 could not map block 4248 could not map block 4249 could not map block 4250 could not map block 4251 could not map block 4252 could not map block 4253 could not map block 4254 could not map block 4255 could not map block 4256 could not map block 4257 could not map block 4258 could not map block 4259 could not map block 4260 could not map block 4261 could not map block 4262 could not map block 4263 could not map block 4264 could not map block 4265 could not map block 4266 could not map block 4267 could not map block 4268 could not map block 4269 could not map block 4270 could not map block 4271 could not map block 4272 could not map block 4273 could not map block 4274 could not map block 4275 could not map block 4276 could not map block 4277 could not map block 4278 could not map block 4279 could not map block 4280 could not map block 4281 could not map block 4282 could not map block 4283 could not map block 4284 could not map block 4285 could not map block 4286 could not map block 4287 could not map block 4288 could not map block 4289 could not map block 4290 could not map block 4291 could not map block 4292 could not map block 4293 could not map block 4294 could not map block 4295 could not map block 4296 could not map block 4297 could not map block 4298 could not map block 4299 could not map block 4300 could not map block 4301 could not map block 4302 could not map block 4303 could not map block 4304 could not map block 4305 could not map block 4306 could not map block 4307 could not map block 4308 could not map block 4309 could not map block 4310 could not map block 4311 could not map block 4312 could not map block 4313 could not map block 4314 could not map block 4315 could not map block 4316 could not map block 4317 could not map block 4318 could not map block 4319 could not map block 4320 could not map block 4321 could not map block 4322 could not map block 4323 could not map block 4324 could not map block 4325 could not map block 4326 could not map block 4327 could not map block 4328 could not map block 4329 could not map block 4330 could not map block 4331 could not map block 4332 could not map block 4333 could not map block 4334 could not map block 4335 could not map block 4336 could not map block 4337 could not map block 4338 could not map block 4339 could not map block 4340 could not map block 4341 could not map block 4342 could not map block 4343 could not map block 4344 could not map block 4345 could not map block 4346 could not map block 4347 could not map block 4348 could not map block 4349 could not map block 4350 could not map block 4351 could not map block 4352 could not map block 4353 could not map block 4354 could not map block 4355 could not map block 4356 could not map block 4357 could not map block 4358 could not map block 4359 could not map block 4360 could not map block 4361 could not map block 4362 could not map block 4363 could not map block 4364 could not map block 4365 could not map block 4366 could not map block 4367 could not map block 4368 could not map block 4369 could not map block 4370 could not map block 4371 could not map block 4372 could not map block 4373 could not map block 4374 could not map block 4375 could not map block 4376 could not map block 4377 could not map block 4378 could not map block 4379 could not map block 4380 could not map block 4381 could not map block 4382 could not map block 4383 could not map block 4384 could not map block 4385 could not map block 4386 could not map block 4387 could not map block 4388 could not map block 4389 could not map block 4390 could not map block 4391 could not map block 4392 could not map block 4393 could not map block 4394 could not map block 4395 could not map block 4396 could not map block 4397 could not map block 4398 could not map block 4399 could not map block 4400 could not map block 4401 could not map block 4402 could not map block 4403 could not map block 4404 could not map block 4405 could not map block 4406 could not map block 4407 could not map block 4408 could not map block 4409 could not map block 4410 could not map block 4411 could not map block 4412 could not map block 4413 could not map block 4414 could not map block 4415 could not map block 4416 could not map block 4417 could not map block 4418 could not map block 4419 could not map block 4420 could not map block 4421 could not map block 4422 could not map block 4423 could not map block 4424 could not map block 4425 could not map block 4426 could not map block 4427 could not map block 4428 could not map block 4429 could not map block 4430 could not map block 4431 could not map block 4432 could not map block 4433 could not map block 4434 could not map block 4435 could not map block 4436 could not map block 4437 could not map block 4438 could not map block 4439 could not map block 4440 could not map block 4441 could not map block 4442 could not map block 4443 could not map block 4444 could not map block 4445 could not map block 4446 could not map block 4447 could not map block 4448 could not map block 4449 could not map block 4450 could not map block 4451 could not map block 4452 could not map block 4453 could not map block 4454 could not map block 4455 could not map block 4456 could not map block 4457 could not map block 4458 could not map block 4459 could not map block 4460 could not map block 4461 could not map block 4462 could not map block 4463 could not map block 4464 could not map block 4465 could not map block 4466 could not map block 4467 could not map block 4468 could not map block 4469 could not map block 4470 could not map block 4471 could not map block 4472 could not map block 4473 could not map block 4474 could not map block 4475 could not map block 4476 could not map block 4477 could not map block 4478 could not map block 4479 could not map block 4480 could not map block 4481 could not map block 4482 could not map block 4483 could not map block 4484 could not map block 4485 could not map block 4486 could not map block 4487 could not map block 4488 could not map block 4489 could not map block 4490 could not map block 4491 could not map block 4492 could not map block 4493 could not map block 4494 could not map block 4495 could not map block 4496 could not map block 4497 could not map block 4498 could not map block 4499 could not map block 4500 could not map block 4501 could not map block 4502 could not map block 4503 could not map block 4504 could not map block 4505 could not map block 4506 could not map block 4507 could not map block 4508 could not map block 4509 could not map block 4510 could not map block 4511 could not map block 4512 could not map block 4513 could not map block 4514 could not map block 4515 could not map block 4516 could not map block 4517 could not map block 4518 could not map block 4519 could not map block 4520 could not map block 4521 could not map block 4522 could not map block 4523 could not map block 4524 could not map block 4525 could not map block 4526 could not map block 4527 could not map block 4528 could not map block 4529 could not map block 4530 could not map block 4531 could not map block 4532 could not map block 4533 could not map block 4534 could not map block 4535 could not map block 4536 could not map block 4537 could not map block 4538 could not map block 4539 could not map block 4540 could not map block 4541 could not map block 4542 could not map block 4543 could not map block 4544 could not map block 4545 could not map block 4546 could not map block 4547 could not map block 4548 could not map block 4549 could not map block 4550 could not map block 4551 could not map block 4552 could not map block 4553 could not map block 4554 could not map block 4555 could not map block 4556 could not map block 4557 could not map block 4558 could not map block 4559 could not map block 4560 could not map block 4561 could not map block 4562 could not map block 4563 could not map block 4564 could not map block 4565 could not map block 4566 could not map block 4567 could not map block 4568 could not map block 4569 could not map block 4570 could not map block 4571 could not map block 4572 could not map block 4573 could not map block 4574 could not map block 4575 could not map block 4576 could not map block 4577 could not map block 4578 could not map block 4579 could not map block 4580 could not map block 4581 could not map block 4582 could not map block 4583 could not map block 4584 could not map block 4585 could not map block 4586 could not map block 4587 could not map block 4588 could not map block 4589 could not map block 4590 could not map block 4591 could not map block 4592 could not map block 4593 could not map block 4594 could not map block 4595 could not map block 4596 could not map block 4597 could not map block 4598 could not map block 4599 could not map block 4600 could not map block 4601 could not map block 4602 could not map block 4603 could not map block 4604 could not map block 4605 could not map block 4606 could not map block 4607 could not map block 4608 could not map block 4609 could not map block 4610 could not map block 4611 could not map block 4612 could not map block 4613 could not map block 4614 could not map block 4615 could not map block 4616 could not map block 4617 could not map block 4618 could not map block 4619 could not map block 4620 could not map block 4621 could not map block 4622 could not map block 4623 could not map block 4624 could not map block 4625 could not map block 4626 could not map block 4627 could not map block 4628 could not map block 4629 could not map block 4630 could not map block 4631 could not map block 4632 could not map block 4633 could not map block 4634 could not map block 4635 could not map block 4636 could not map block 4637 could not map block 4638 could not map block 4639 could not map block 4640 could not map block 4641 could not map block 4642 could not map block 4643 could not map block 4644 could not map block 4645 could not map block 4646 could not map block 4647 could not map block 4648 could not map block 4649 could not map block 4650 could not map block 4651 could not map block 4652 could not map block 4653 could not map block 4654 could not map block 4655 could not map block 4656 could not map block 4657 could not map block 4658 could not map block 4659 could not map block 4660 could not map block 4661 could not map block 4662 could not map block 4663 could not map block 4664 could not map block 4665 could not map block 4666 could not map block 4667 could not map block 4668 could not map block 4669 could not map block 4670 could not map block 4671 could not map block 4672 could not map block 4673 could not map block 4674 could not map block 4675 could not map block 4676 could not map block 4677 could not map block 4678 could not map block 4679 could not map block 4680 could not map block 4681 could not map block 4682 could not map block 4683 could not map block 4684 could not map block 4685 could not map block 4686 could not map block 4687 could not map block 4688 could not map block 4689 could not map block 4690 could not map block 4691 could not map block 4692 could not map block 4693 could not map block 4694 could not map block 4695 could not map block 4696 could not map block 4697 could not map block 4698 could not map block 4699 could not map block 4700 could not map block 4701 could not map block 4702 could not map block 4703 could not map block 4704 could not map block 4705 could not map block 4706 could not map block 4707 could not map block 4708 could not map block 4709 could not map block 4710 could not map block 4711 could not map block 4712 could not map block 4713 could not map block 4714 could not map block 4715 could not map block 4716 could not map block 4717 could not map block 4718 could not map block 4719 could not map block 4720 could not map block 4721 could not map block 4722 could not map block 4723 could not map block 4724 could not map block 4725 could not map block 4726 could not map block 4727 could not map block 4728 could not map block 4729 could not map block 4730 could not map block 4731 could not map block 4732 could not map block 4733 could not map block 4734 could not map block 4735 could not map block 4736 could not map block 4737 could not map block 4738 could not map block 4739 could not map block 4740 could not map block 4741 could not map block 4742 could not map block 4743 could not map block 4744 could not map block 4745 could not map block 4746 could not map block 4747 could not map block 4748 could not map block 4749 could not map block 4750 could not map block 4751 could not map block 4752 could not map block 4753 could not map block 4754 could not map block 4755 could not map block 4756 could not map block 4757 could not map block 4758 could not map block 4759 could not map block 4760 could not map block 4761 could not map block 4762 could not map block 4763 could not map block 4764 could not map block 4765 could not map block 4766 could not map block 4767 could not map block 4768 could not map block 4769 could not map block 4770 could not map block 4771 could not map block 4772 could not map block 4773 could not map block 4774 could not map block 4775 could not map block 4776 could not map block 4777 could not map block 4778 could not map block 4779 could not map block 4780 could not map block 4781 could not map block 4782 could not map block 4783 could not map block 4784 could not map block 4785 could not map block 4786 could not map block 4787 could not map block 4788 could not map block 4789 could not map block 4790 could not map block 4791 could not map block 4792 could not map block 4793 could not map block 4794 could not map block 4795 could not map block 4796 could not map block 4797 could not map block 4798 could not map block 4799 could not map block 4800 could not map block 4801 could not map block 4802 could not map block 4803 could not map block 4804 could not map block 4805 could not map block 4806 could not map block 4807 could not map block 4808 could not map block 4809 could not map block 4810 could not map block 4811 could not map block 4812 could not map block 4813 could not map block 4814 could not map block 4815 could not map block 4816 could not map block 4817 could not map block 4818 could not map block 4819 could not map block 4820 could not map block 4821 could not map block 4822 could not map block 4823 could not map block 4824 could not map block 4825 could not map block 4826 could not map block 4827 could not map block 4828 could not map block 4829 could not map block 4830 could not map block 4831 could not map block 4832 could not map block 4833 could not map block 4834 could not map block 4835 could not map block 4836 could not map block 4837 could not map block 4838 could not map block 4839 could not map block 4840 could not map block 4841 could not map block 4842 could not map block 4843 could not map block 4844 could not map block 4845 could not map block 4846 could not map block 4847 could not map block 4848 could not map block 4849 could not map block 4850 could not map block 4851 could not map block 4852 could not map block 4853 could not map block 4854 could not map block 4855 could not map block 4856 - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 - agno = 16 - agno = 17 - agno = 18 - agno = 19 - agno = 20 - agno = 21 - agno = 22 - agno = 23 - agno = 24 - agno = 25 - agno = 26 - agno = 27 - agno = 28 - agno = 29 - agno = 30 - agno = 31 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 / ... bad hash table for directory inode 256 (no leaf entry): rebuilding rebuilding directory inode 256 --------------050706080401010402040400-- From owner-linux-xfs Thu Oct 7 02:40:18 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Oct 2004 02:40:20 -0700 (PDT) Received: from ns.itam.nsc.ru (ns.itam.nsc.ru [194.226.179.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i979eEGY029718 for ; Thu, 7 Oct 2004 02:40:17 -0700 Received: from site.lan (itut.itam.nsc.ru [194.226.179.2]) by ns.itam.nsc.ru (8.12.8/8.12.8) with ESMTP id i979dsMh032714 for ; Thu, 7 Oct 2004 16:39:54 +0700 Received: from [192.168.7.215] ([192.168.7.215]) (authenticated bits=0) by site.lan (8.12.11/8.12.11) with ESMTP id i979dnwj003786 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 7 Oct 2004 16:39:49 +0700 Subject: 2.4.21-20.EL undefined references in modules From: Stas Nikiforov Reply-To: stas@itam.nsc.ru To: linux-xfs@oss.sgi.com Content-Type: text/plain Organization: ITAM Message-Id: <1097141989.2726.168.camel@whirl.lab7.lan> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Thu, 07 Oct 2004 16:39:49 +0700 Content-Transfer-Encoding: 7bit X-archive-position: 4227 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: stas@itam.nsc.ru Precedence: bulk X-list: linux-xfs Hi, I've tried to compile xfs modules for RHEL 2.4.21-20.ELsmp kernel and got some errors. Compilation was successful, but I'm unable to insert modules due to unresolved dependencies. These are: I think that the problem is in wrong definition of kernel version in file linux/xfs_lrw.c lines 325-335. This code below suppose that the kernel version is less then 2.4.22, but some features were backported by RedHat to 2.4.21-20. Is it possible to define somewhere KERNEL_HAS_NEW_O_DIRECT and safely recompile xfs modules for updated RHEL kernel? Best regards Stas. #if LINUX_VERSION_CODE >= KERNEL_VERSION(2,4,22) || defined (KERNEL_HAS_NEW_O_DIRECT) if (unlikely(ioflags & IO_ISDIRECT)) { ret = do_generic_direct_read(file, buf, size, offset); UPDATE_ATIME(file->f_dentry->d_inode); } else { ret = generic_file_read(file, buf, size, offset); } #else ret = generic_file_read(file, buf, size, offset); #endif -- Mr. Nikiforov Stanislav Intsitute of Theoretical and Applied Mechanics 4/1, Institutskaya str., Novosibirsk, 930090, Russia Voice: +7 3832 343163 E-mail: stas@itam.nsc.ru From owner-linux-xfs Thu Oct 7 07:10:37 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Oct 2004 07:10:42 -0700 (PDT) Received: from mproxy.gmail.com (mproxy.gmail.com [216.239.56.251]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i97EAbcd000861 for ; Thu, 7 Oct 2004 07:10:37 -0700 Received: by mproxy.gmail.com with SMTP id w41so497760cwb for ; Thu, 07 Oct 2004 07:10:16 -0700 (PDT) Received: by 10.11.116.68 with SMTP id o68mr543791cwc; Thu, 07 Oct 2004 07:10:16 -0700 (PDT) Received: by 10.11.116.76 with HTTP; Thu, 7 Oct 2004 07:10:16 -0700 (PDT) Message-ID: Date: Thu, 7 Oct 2004 19:40:16 +0530 From: Ash Reply-To: Ash To: linux-xfs@oss.sgi.com Subject: Disk placement Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4228 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ashrat@gmail.com Precedence: bulk X-list: linux-xfs Hi Does XFS provide any control for the placement of files on disk ? Something like policy modules for disk placement ? clustering of files for example ? Thanks From owner-linux-xfs Thu Oct 7 07:39:43 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Oct 2004 07:39:48 -0700 (PDT) Received: from mail00hq.adic.com (mail00hq.adic.com [63.81.117.10]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i97Edg4V002066 for ; Thu, 7 Oct 2004 07:39:43 -0700 Received: from mail02hq.adic.com ([172.16.9.18]) by mail00hq.adic.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 7 Oct 2004 07:39:25 -0700 Received: from [172.16.82.67] ([172.16.82.67]) by mail02hq.adic.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 7 Oct 2004 07:39:24 -0700 Message-ID: <4165546A.9050804@xfs.org> Date: Thu, 07 Oct 2004 09:36:26 -0500 From: Steve Lord User-Agent: Mozilla Thunderbird 0.7.1 (X11/20040626) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ash CC: XFS Linux Subject: Re: Disk placement References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Oct 2004 14:39:24.0795 (UTC) FILETIME=[70E0C4B0:01C4AC7B] X-archive-position: 4229 X-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 Ash wrote: > Hi > > Does XFS provide any control for the placement of files on disk ? > Something like policy modules for disk placement ? clustering > of files for example ? > > Thanks > Not explicitly, there are some useful facts about how xfs lays things out which you can use to get limited placement control. XFS divides a filesystem into allocation groups, read the mkfs_xfs man page. You can specify the size of allocation groups, and you can get allocation groups to start on stripe boundaries in a raid setup. The simple rules of placement are: XFS will attempt to place a new directory in a different allocation group than its parent inode. XFS will attempt to place a new file inode in the same allocation group as its parent inode. Blocks in a file (directory blocks in a directory) will prefer the same allocation group as the inode - in fact the same allocation group as the previous chunk in the file. It will also first look for a chunk of free space close to the previous one. If an allocation group is too full, or another cpu is currently allocating space from it, then the allocator will move on to another allocation group. xfs_bmap can tell you all sorts of things about where the blocks of a file are on the disk. There has been talk in the past about allowing more explicit placement and being able to map more directly onto the actual LUNs. I do not know if there is work in progress to do this. Steve From owner-linux-xfs Thu Oct 7 10:40:19 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Oct 2004 10:40:21 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i97HeID4011445 for ; Thu, 7 Oct 2004 10:40:18 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i97IpbGu027410 for ; Thu, 7 Oct 2004 11:51:37 -0700 Received: from [128.162.232.50] (stout.americas.sgi.com [128.162.232.50]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i97He3OV48885728; Thu, 7 Oct 2004 12:40:04 -0500 (CDT) Message-ID: <41657F73.2070900@sgi.com> Date: Thu, 07 Oct 2004 12:40:03 -0500 From: Eric Sandeen User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: stas@itam.nsc.ru CC: linux-xfs@oss.sgi.com Subject: Re: 2.4.21-20.EL undefined references in modules References: <1097141989.2726.168.camel@whirl.lab7.lan> In-Reply-To: <1097141989.2726.168.camel@whirl.lab7.lan> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4230 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Stas - Please take a look at the various kernel patches in ftp://oss.sgi.com/projects/xfs/testing/release-1.3.3-pre2/kernels/RHEL/SRPMS/kernel-2.4.21-15.EL.sgi3.src.rpm -that might offer a clue. You're right that the #ifdef is handling a backport; in our kernels we put this alongside KERNEL_HAS_O_DIRECT in linux/include/linux/fs.h: --- linux/include/linux/fs.h.orig 2003-12-30 14:47:13.000000000 -0600 +++ linux/include/linux/fs.h 2003-12-30 14:47:45.000000000 -0600 @@ -418,6 +418,7 @@ int (*flushpage) (struct page *, unsigned long); int (*releasepage) (struct page *, int); #define KERNEL_HAS_O_DIRECT /* this is for modules out of the kernel */ +#define KERNEL_HAS_NEW_O_DIRECT /* O_DIRECT rework from 2.4.22 */ int (*direct_IO)(int, struct file *, struct kiobuf *, unsigned long, int); int (*direct_sector_IO)(int, struct file *, struct kiobuf *, unsigned long, int, int, int); void (*removepage)(struct page *); /* called when page gets removed from the inode */ Stas Nikiforov wrote: > Hi, > I've tried to compile xfs modules for > RHEL 2.4.21-20.ELsmp kernel and got some errors. > > Compilation was successful, but I'm unable to insert > modules due to unresolved dependencies. > > These are: > > I think that the problem is in wrong definition > of kernel version in file linux/xfs_lrw.c > lines 325-335. This code below suppose that > the kernel version is less then 2.4.22, but > some features were backported by RedHat to > 2.4.21-20. > > Is it possible to define somewhere > KERNEL_HAS_NEW_O_DIRECT and safely recompile xfs modules > for updated RHEL kernel? > > Best regards > Stas. > > #if LINUX_VERSION_CODE >= KERNEL_VERSION(2,4,22) || defined > (KERNEL_HAS_NEW_O_DIRECT) > if (unlikely(ioflags & IO_ISDIRECT)) { > ret = do_generic_direct_read(file, buf, size, offset); > UPDATE_ATIME(file->f_dentry->d_inode); > } else { > ret = generic_file_read(file, buf, size, offset); > } > #else > ret = generic_file_read(file, buf, size, offset); > #endif > From owner-linux-xfs Thu Oct 7 13:00:47 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Oct 2004 13:00:50 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i97K0lxp021101 for ; Thu, 7 Oct 2004 13:00:47 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i97K0loh021100 for linux-xfs@oss.sgi.com; Thu, 7 Oct 2004 13:00:47 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i97K0j2C021084 for ; Thu, 7 Oct 2004 13:00:45 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i97JmnfU020780; Thu, 7 Oct 2004 12:48:49 -0700 Date: Thu, 7 Oct 2004 12:48:49 -0700 Message-Id: <200410071948.i97JmnfU020780@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 365] New: Truncating a file over NFS+DMAPI hangs client X-Bugzilla-Reason: AssignedTo X-archive-position: 4231 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=365 Summary: Truncating a file over NFS+DMAPI hangs client Product: Linux XFS Version: Current Platform: IA32 OS/Version: Linux Status: NEW Severity: normal Priority: Medium Component: dmapi AssignedTo: xfs-master@oss.sgi.com ReportedBy: mmontour@bycast.com Summary: The problem occurs on a server running the current linux-2.4-xfs CVS kernel from oss.sgi.com, with a DMAPI-enabled filesystem exported over NFS. Most operations work as expected for an NFS client, but truncating a file hangs the client and also does something to the server that later prevents the server from un-exporting the NFS filesystem. Detailed steps to reproduce are shown below. --- On the server, Create an XFS filesystem: mkfs.xfs -f -i size=2048,maxpct=0 /dev/sdb1 Mount it on /test dev-fsg-40:~# mount /dev/sdb1 /test -o dmapi,mtpt=/test Export it over NFS, using /etc/exports line: /test 192.168.1.0/24(rw,no_root_squash) Set up DMAPI handling: dm_create_session -i TestSession ret=0 newsid=1 set_disp -s 1 /test DM_EVENT_TRUNCATE --- On the client (here SuSE 9.0, kernel 2.4.21-243-athlon, although this has been observed on other clients including Solaris 8): Mount the NFS directory: mount 192.168.1.2:/test /mnt -o nfsvers=3,udp,hard,intr Create a file: echo "12345" > /mnt/file1 --- On the server, set TRUNCATE events: set_region -o 0 -l 0 -s 1 /test/file1 DM_REGION_TRUNCATE exactflag is True --- On the client, try to truncate the file: > /mnt/file1 The client hangs at this point, which is expected. --- On the server, get the event and respond with "Continue": get_events 1 rlenp is 72 truncate: token=1 sequence=1 file handle ab3011b1efcf4b2d0e000000000000001300000000000000 offset 0 length 0 respond_event 1 1 1 0 --- On the client, the "> /mnt/file1" operation should have completed. However it is still hung and cannot be interrupted with ctrl-C. --- On the server, the file still shows its original length: ls -l /test total 4 -rw-r--r-- 1 root root 6 Oct 7 18:34 file1 --- On the client, forcibly unmount the filesystem: umount -f /mnt umount2: Device or resource busy umount: /mnt: Illegal seek umount -f /mnt The second "umount -f" completes without error, and /proc/mounts confirms that the filesystem is unmounted. --- On the server, try to shut down the NFS server: /etc/init.d/nfs-kernel-server stop Stopping NFS kernel daemon: mountd nfsd. Unexporting directories for NFS kernel daemon... The init.d script hangs at this point. "cat /proc/fs/nfs/exports" also hangs now. I have to do a "/sbin/reboot -f" to restart the server. ----------- Partial kernel configuration for the server is shown below. egrep -i "NFS|XFS|DMAPI" .config CONFIG_DMAPI=y CONFIG_DMAPI_DEBUG=y # CONFIG_VXFS_FS is not set CONFIG_XFS_FS=y # CONFIG_XFS_POSIX_ACL is not set # CONFIG_XFS_QUOTA is not set CONFIG_XFS_DMAPI=y # CONFIG_XFS_RT is not set # CONFIG_XFS_TRACE is not set CONFIG_XFS_DEBUG=y CONFIG_DMAPI=y CONFIG_NFS_FS=m CONFIG_NFS_V3=y # CONFIG_NFS_DIRECTIO is not set # CONFIG_ROOT_NFS is not set CONFIG_NFSD=m CONFIG_NFSD_V3=y # CONFIG_NFSD_TCP is not set # CONFIG_NCPFS_NFS_NS is not set Additional debugging information is available on request. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Thu Oct 7 14:43:19 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Oct 2004 14:43:21 -0700 (PDT) Received: from coredumps.de (coredumps.de [217.160.213.75]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i97LhJKf025027 for ; Thu, 7 Oct 2004 14:43:19 -0700 Received: from port-212-202-52-150.dynamic.qsc.de ([212.202.52.150] helo=ente.berdmann.de) by coredumps.de with esmtpsa (TLSv1:DES-CBC3-SHA:168) (Exim 4.42) id 1CFg2T-0001BT-PG for linux-xfs@oss.sgi.com; Thu, 07 Oct 2004 23:43:05 +0200 Received: from apollo.berdmann.de ([192.168.1.2]) by ente.berdmann.de with esmtp (Exim 3.36 #1) id 1CFg2T-0004Uw-00 for linux-xfs@oss.sgi.com; Thu, 07 Oct 2004 23:43:05 +0200 Message-ID: <4165B869.3020001@berdmann.de> Date: Thu, 07 Oct 2004 23:43:05 +0200 From: Bernhard Erdmann User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040930 X-Accept-Language: de, en, fr MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: building xfsprogs (CVS): fadvise.c:71: `POSIX_FADV_NORMAL' undeclared (first use in this function) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4232 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: be@berdmann.de Precedence: bulk X-list: linux-xfs Hi, I'm trying to build the current version of xfsprogs (2.6.24) on a RHL 6.2 box. "make" fails. xfsprogs 2.6.19 or 2.6.21 (don't know anymore) was compiled cleanly. gcc -O1 -g -DDEBUG -funsigned-char -fno-strict-aliasing -Wall -DVERSION=\"2.6.24\" -DLOCALEDIR=\"/usr/share/locale\" -DPACKAGE=\"xfsprogs\" -I../include -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -DHAVE_FADVISE -DHAVE_MINCORE -DHAVE_INJECT -DHAVE_RESBLKS -DHAVE_SHUTDOWN -c -o fadvise.o fadvise.c fadvise.c: In function `fadvise_f': fadvise.c:71: `POSIX_FADV_NORMAL' undeclared (first use in this function) fadvise.c:71: (Each undeclared identifier is reported only once fadvise.c:71: for each function it appears in.) fadvise.c:76: `POSIX_FADV_DONTNEED' undeclared (first use in this function) fadvise.c:80: `POSIX_FADV_NOREUSE' undeclared (first use in this function) fadvise.c:84: `POSIX_FADV_RANDOM' undeclared (first use in this function) fadvise.c:88: `POSIX_FADV_SEQUENTIAL' undeclared (first use in this function) fadvise.c:92: `POSIX_FADV_WILLNEED' undeclared (first use in this function) fadvise.c:122: warning: implicit declaration of function `posix_fadvise64' gmake[1]: *** [fadvise.o] Error 1 make: *** [default] Error 2 From owner-linux-xfs Thu Oct 7 16:11:46 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Oct 2004 16:11:48 -0700 (PDT) Received: from snort.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i97NBi6r029841 for ; Thu, 7 Oct 2004 16:11:45 -0700 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i97NBPxu8788345 for ; Fri, 8 Oct 2004 09:11:25 +1000 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i97NBO1731664220 for linux-xfs@oss.sgi.com; Fri, 8 Oct 2004 09:11:24 +1000 (EST) Date: Fri, 8 Oct 2004 09:11:24 +1000 (EST) From: Nathan Scott Message-Id: <200410072311.i97NBO1731664220@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE 907752 - fix older glibc builds X-archive-position: 4233 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Be more strict when checking presence of fadvise, fixes build for old glibc versions. Date: Thu Oct 7 16:09:23 PDT 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/us-xfs-cmds Inspected by: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:180547a xfsprogs/VERSION - 1.119 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/VERSION.diff?r1=text&tr1=1.119&r2=text&tr2=1.118&f=h xfsprogs/doc/CHANGES - 1.163 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/doc/CHANGES.diff?r1=text&tr1=1.163&r2=text&tr2=1.162&f=h xfsprogs/debian/changelog - 1.109 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/debian/changelog.diff?r1=text&tr1=1.109&r2=text&tr2=1.108&f=h xfsprogs/aclocal.m4 - 1.13 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/aclocal.m4.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h xfsprogs/m4/package_libcdev.m4 - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/m4/package_libcdev.m4.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h From owner-linux-xfs Thu Oct 7 16:20:11 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Oct 2004 16:20:12 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i97NK93P001059 for ; Thu, 7 Oct 2004 16:20:09 -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 JAA21548; Fri, 8 Oct 2004 09:19:47 +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 i97NJiln4855145; Fri, 8 Oct 2004 09:19:45 +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 i97NIkfO000917; Fri, 8 Oct 2004 09:18:46 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i97NIisb000915; Fri, 8 Oct 2004 09:18:44 +1000 Date: Fri, 8 Oct 2004 09:18:44 +1000 From: Nathan Scott To: Bernhard Erdmann Cc: linux-xfs@oss.sgi.com Subject: Re: building xfsprogs (CVS): fadvise.c:71: `POSIX_FADV_NORMAL' undeclared (first use in this function) Message-ID: <20041007231844.GB824@frodo> References: <4165B869.3020001@berdmann.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4165B869.3020001@berdmann.de> User-Agent: Mutt/1.5.3i X-archive-position: 4234 X-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 On Thu, Oct 07, 2004 at 11:43:05PM +0200, Bernhard Erdmann wrote: > Hi, > > I'm trying to build the current version of xfsprogs (2.6.24) on a RHL > 6.2 box. "make" fails. xfsprogs 2.6.19 or 2.6.21 (don't know anymore) > was compiled cleanly. Ugh. *grumblegrumble*old glibc*grumblegrumble*. Try CVS in an hour, it should work after a "make distclean" in current xfsprogs (2.6.25). cheers. -- Nathan From owner-linux-xfs Thu Oct 7 16:24:09 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Oct 2004 16:24:11 -0700 (PDT) Received: from coredumps.de (coredumps.de [217.160.213.75]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i97NO8Pe001476 for ; Thu, 7 Oct 2004 16:24:09 -0700 Received: from port-212-202-52-150.dynamic.qsc.de ([212.202.52.150] helo=ente.berdmann.de) by coredumps.de with esmtpsa (TLSv1:DES-CBC3-SHA:168) (Exim 4.42) id 1CFhc3-0001ja-Ht for linux-xfs@oss.sgi.com; Fri, 08 Oct 2004 01:23:55 +0200 Received: from apollo.berdmann.de ([192.168.1.2]) by ente.berdmann.de with esmtp (Exim 3.36 #1) id 1CFhc3-0001sH-00 for linux-xfs@oss.sgi.com; Fri, 08 Oct 2004 01:23:55 +0200 Message-ID: <4165D00A.8020306@berdmann.de> Date: Fri, 08 Oct 2004 01:23:54 +0200 From: Bernhard Erdmann User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040930 X-Accept-Language: de, en, fr MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: xfs_fsr for directories? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4235 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: be@berdmann.de Precedence: bulk X-list: linux-xfs Hi, I've noticed on old and heavily used XFS filesystems (Newsspool oder Cyrus IMAP storage) even a "ls" command can take a very long time when there have been 10,000 to 50,000 files in a directory. "ls" spits out the remaining 5,000 filenames but then it sits and waits for several seconds (5-20 sec). # xfs_db -r -c "frag -d" /dev/vg1/news actual 4644, ideal 1891, fragmentation factor 59.28% # xfs_db -r -c "frag -d" /dev/vg1/imap actual 2299, ideal 424, fragmentation factor 81.56% xfs_fsr cleans up the files, but who cares about directories? How does XFS handle directories when files are deleted? Do they shrink as well? From owner-linux-xfs Thu Oct 7 16:26:39 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Oct 2004 16:26:40 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i97NQbE0001822 for ; Thu, 7 Oct 2004 16:26:38 -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 JAA21668; Fri, 8 Oct 2004 09:26:17 +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 i97NQGln4666399; Fri, 8 Oct 2004 09:26:16 +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 i97NPGfO000955; Fri, 8 Oct 2004 09:25:17 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i97NPFqO000953; Fri, 8 Oct 2004 09:25:15 +1000 Date: Fri, 8 Oct 2004 09:25:15 +1000 From: Nathan Scott To: Frank Hellmann Cc: XFS List Subject: Re: xfs_repair problem in FS root Message-ID: <20041007232515.GC824@frodo> References: <41650982.1090900@opticalart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41650982.1090900@opticalart.de> User-Agent: Mutt/1.5.3i X-archive-position: 4236 X-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 On Thu, Oct 07, 2004 at 11:16:50AM +0200, Frank Hellmann wrote: > ... > with about of 4Mb size each). If I start xfs_repair -L /dev/md0 it gets > terminated in phase 6 after finding problems in directory inode 256. It > eats up all aviable memory+swap and gets killed/terminated due to memory > consumption (see attached output). Try adding still more swap or get more memory... :( > 2GB Memory + 1GB Swap > 8TB Disk space via FibreChannel Yes, handling this kind of mismatch is something we know we need to work on for the check/repair tools. cheers. -- Nathan From owner-linux-xfs Thu Oct 7 17:31:19 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Oct 2004 17:31:21 -0700 (PDT) Received: from pimout1-ext.prodigy.net (pimout1-ext.prodigy.net [207.115.63.77]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i980VJIO009214 for ; Thu, 7 Oct 2004 17:31:19 -0700 Received: from taniwha.stupidest.org (adsl-68-120-154-49.dsl.snfc21.pacbell.net [68.120.154.49]) by pimout1-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id i980TbWC363102; Thu, 7 Oct 2004 20:29:38 -0400 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id B4462115C861; Thu, 7 Oct 2004 17:29:36 -0700 (PDT) Date: Thu, 7 Oct 2004 17:29:36 -0700 From: Chris Wedgwood To: Bernhard Erdmann Cc: linux-xfs@oss.sgi.com Subject: Re: xfs_fsr for directories? Message-ID: <20041008002936.GA12054@taniwha.stupidest.org> References: <4165D00A.8020306@berdmann.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4165D00A.8020306@berdmann.de> X-archive-position: 4237 X-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 On Fri, Oct 08, 2004 at 01:23:54AM +0200, Bernhard Erdmann wrote: > xfs_fsr cleans up the files, but who cares about directories? plenty of people > How does XFS handle directories when files are deleted? Do they > shrink as well? yes to *try* to make a directory better if not don't mind the inode changing do somehting like (can't be done whilst it's being accessed though) cd parent/of/said/dir mv dir old-dir mkdir dir mv old-dir/* dir rmdir old-dir which will create a new directory and move all entries over, with some luck this will help create the directory in fewer fragments (compared to having it grow slowly over time) From owner-linux-xfs Thu Oct 7 18:00:47 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Oct 2004 18:00:59 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9810lA8013192 for ; Thu, 7 Oct 2004 18:00:47 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i9810lfG013191 for linux-xfs@oss.sgi.com; Thu, 7 Oct 2004 18:00:47 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9810kXb013177 for ; Thu, 7 Oct 2004 18:00:46 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i980MjoU008309; Thu, 7 Oct 2004 17:22:45 -0700 Date: Thu, 7 Oct 2004 17:22:45 -0700 Message-Id: <200410080022.i980MjoU008309@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 366] New: configure script is missing basic macro X-Bugzilla-Reason: AssignedTo X-archive-position: 4238 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=366 Summary: configure script is missing basic macro Product: Linux XFS Version: Current Platform: All URL: http://bugs.gentoo.org/show_bug.cgi?id=65735 OS/Version: Linux Status: NEW Severity: minor Priority: Medium Component: xfsprogs AssignedTo: xfs-master@oss.sgi.com ReportedBy: vapier@gentoo.org the configure.in is missing a call to AC_PROG_CC which results in bad (but not fatal) detection of header files and type sizes $ ./configure [...] checking for sys/types.h... no [...] checking size of long... 0 [...] ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Thu Oct 7 19:00:48 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Oct 2004 19:00:50 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9820m23018063 for ; Thu, 7 Oct 2004 19:00:48 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i9820mQx018060 for linux-xfs@oss.sgi.com; Thu, 7 Oct 2004 19:00:48 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9820kBF018036 for ; Thu, 7 Oct 2004 19:00:46 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i981nVS0017723; Thu, 7 Oct 2004 18:49:31 -0700 Date: Thu, 7 Oct 2004 18:49:31 -0700 Message-Id: <200410080149.i981nVS0017723@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 366] configure script is missing basic macro X-Bugzilla-Reason: AssignedTo X-archive-position: 4239 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=366 ------- Additional Comments From vapier@gentoo.org 2004-07-10 17:23 PDT ------- Created an attachment (id=140) --> (http://oss.sgi.com/bugzilla/attachment.cgi?id=140&action=view) 2.6.13-configure.patch patch written by Marc Bevand ------- Additional Comments From vapier@gentoo.org 2004-07-10 17:23 PDT ------- Created an attachment (id=141) --> (http://oss.sgi.com/bugzilla/attachment.cgi?id=141&action=view) 2.6.13-configure.patch patch written by Marc Bevand ------- Additional Comments From nathans@sgi.com 2004-07-10 18:49 PDT ------- Hi there, Hmm, AC_PROG_CC is called via AC_PACKAGE_UTILITIES, before any of those failed checks you've listed there. The problem must be somewhere else.. probably a Gentoo-specific thing, since noone else has reported this and its known to work correctly on Redhat, SuSE and Debian. Can you add the full configure output please? (gentoo bug system doesnt have that either). And maybe your generated configure script too? thanks. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Thu Oct 7 20:00:47 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Oct 2004 20:00:49 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9830liU020082 for ; Thu, 7 Oct 2004 20:00:47 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i9830lWb020080 for linux-xfs@oss.sgi.com; Thu, 7 Oct 2004 20:00:47 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9830kka020056 for ; Thu, 7 Oct 2004 20:00:46 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i982LHC5019111; Thu, 7 Oct 2004 19:21:17 -0700 Date: Thu, 7 Oct 2004 19:21:17 -0700 Message-Id: <200410080221.i982LHC5019111@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 366] configure script is missing basic macro X-Bugzilla-Reason: AssignedTo X-archive-position: 4240 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=366 ------- Additional Comments From vapier@gentoo.org 2004-07-10 19:21 PDT ------- ok, the problem is this little bit of code: if test -z "$CC"; then AC_PROG_CC fi on Gentoo, we have a habit of setting $CC in the environment (unrelated topic as to why we do that ...) not quite sure what kind of assumption that code is working under, but the side effect is that $OBJEXT is never defined and thus all the compilation configure tests will fail since they look for 'conftest.$OBJEXT' which would normally resolve to 'conftest.o' but for us Gentoo peeps, we get 'conftest.' ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Thu Oct 7 20:00:47 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Oct 2004 20:00:58 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9830lk2020081 for ; Thu, 7 Oct 2004 20:00:47 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i9830lIf020079 for linux-xfs@oss.sgi.com; Thu, 7 Oct 2004 20:00:47 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9830kkc020056 for ; Thu, 7 Oct 2004 20:00:46 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i982Mckc019138; Thu, 7 Oct 2004 19:22:38 -0700 Date: Thu, 7 Oct 2004 19:22:38 -0700 Message-Id: <200410080222.i982Mckc019138@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 366] configure script is missing basic macro X-Bugzilla-Reason: AssignedTo X-archive-position: 4241 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=366 ------- Additional Comments From vapier@gentoo.org 2004-07-10 19:22 PDT ------- test case: vapier@vapier 0 xfsprogs-2.6.13 # env -uCC ./configure checking for gcc... gcc checking for C compiler default output... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for make... /usr/bin/make checking for libtool... /usr/bin/libtool checking for tar... /bin/tar checking for gzip... /bin/gzip checking for makedepend... /usr/X11R6/bin/makedepend checking for awk... /bin/awk checking for sed... /bin/sed checking for echo... /bin/echo checking for sort... /bin/sort checking whether ln -s works... yes checking for msgfmt... /usr/bin/msgfmt checking for msgmerge... /usr/bin/msgmerge checking for rpm... /usr/bin/rpm checking for rpmbuild... /usr/bin/rpmbuild checking how to run the C preprocessor... gcc -E checking for egrep... grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking uuid.h usability... no checking uuid.h presence... no checking for uuid.h... no checking uuid/uuid.h usability... yes checking uuid/uuid.h presence... yes checking for uuid/uuid.h... yes checking for uuid_compare... no checking for uuid_compare in -luuid... yes checking pthread.h usability... yes checking pthread.h presence... yes checking for pthread.h... yes checking for pthread_mutex_init in -lpthread... yes checking for __psint_t ... no checking for __psunsigned_t ... no checking for long... yes checking size of long... 4 checking for char *... yes checking size of char *... 4 configure: creating ./config.status config.status: creating include/builddefs config.status: creating include/platform_defs.h vapier@vapier 0 xfsprogs-2.6.13 # env CC=gcc ./configure checking for make... /usr/bin/make checking for libtool... /usr/bin/libtool checking for tar... /bin/tar checking for gzip... /bin/gzip checking for makedepend... /usr/X11R6/bin/makedepend checking for awk... /bin/awk checking for sed... /bin/sed checking for echo... /bin/echo checking for sort... /bin/sort checking whether ln -s works... yes checking for msgfmt... /usr/bin/msgfmt checking for msgmerge... /usr/bin/msgmerge checking for rpm... /usr/bin/rpm checking for rpmbuild... /usr/bin/rpmbuild checking how to run the C preprocessor... gcc -E checking for egrep... grep -E checking for ANSI C header files... no checking for sys/types.h... no checking for sys/stat.h... no checking for stdlib.h... no checking for string.h... no checking for memory.h... no checking for strings.h... no checking for inttypes.h... no checking for stdint.h... no checking for unistd.h... no checking uuid.h usability... no checking uuid.h presence... no checking for uuid.h... no checking uuid/uuid.h usability... no checking uuid/uuid.h presence... yes configure: WARNING: uuid/uuid.h: present but cannot be compiled configure: WARNING: uuid/uuid.h: check for missing prerequisite headers? configure: WARNING: uuid/uuid.h: proceeding with the preprocessor's result configure: WARNING: ## ------------------------------------ ## configure: WARNING: ## Report this to bug-autoconf@gnu.org. ## configure: WARNING: ## ------------------------------------ ## checking for uuid/uuid.h... yes checking for uuid_compare... no checking for uuid_compare in -luuid... yes checking pthread.h usability... no checking pthread.h presence... yes configure: WARNING: pthread.h: present but cannot be compiled configure: WARNING: pthread.h: check for missing prerequisite headers? configure: WARNING: pthread.h: proceeding with the preprocessor's result configure: WARNING: ## ------------------------------------ ## configure: WARNING: ## Report this to bug-autoconf@gnu.org. ## configure: WARNING: ## ------------------------------------ ## checking for pthread.h... yes checking for pthread_mutex_init in -lpthread... yes checking for __psint_t ... no checking for __psunsigned_t ... no checking for long... no checking size of long... 0 checking for char *... no checking size of char *... 0 configure: creating ./config.status config.status: creating include/builddefs config.status: creating include/platform_defs.h ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Thu Oct 7 21:00:48 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Oct 2004 21:00:51 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9840muf025510 for ; Thu, 7 Oct 2004 21:00:48 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i9840mPA025509 for linux-xfs@oss.sgi.com; Thu, 7 Oct 2004 21:00:48 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9840k8T025495 for ; Thu, 7 Oct 2004 21:00:46 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i983BxOQ020928; Thu, 7 Oct 2004 20:11:59 -0700 Date: Thu, 7 Oct 2004 20:11:59 -0700 Message-Id: <200410080311.i983BxOQ020928@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 366] configure script is missing basic macro X-Bugzilla-Reason: AssignedTo X-archive-position: 4242 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=366 nathans@sgi.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From nathans@sgi.com 2004-07-10 20:11 PDT ------- > on Gentoo, we have a habit of setting $CC in the environment > (unrelated topic as to why we do that ...) Ah, this is easily resolved then - if you guys get current xfsprogs, that check is no longer there. xfsprogs-2.6.25 is current in cvs. I suspect you will also want current versions of xfsdump, dmapi, acl and attr packages too (if you guys have those in gentoo) - they will all have the same issue. cheers. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Thu Oct 7 22:00:48 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Oct 2004 22:00:51 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9850mSr031734 for ; Thu, 7 Oct 2004 22:00:48 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i9850mGU031733 for linux-xfs@oss.sgi.com; Thu, 7 Oct 2004 22:00:48 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9850kv5031718 for ; Thu, 7 Oct 2004 22:00:46 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i9848aTE026100; Thu, 7 Oct 2004 21:08:36 -0700 Date: Thu, 7 Oct 2004 21:08:36 -0700 Message-Id: <200410080408.i9848aTE026100@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 366] configure script is missing basic macro X-Bugzilla-Reason: AssignedTo X-archive-position: 4243 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=366 ------- Additional Comments From vapier@gentoo.org 2004-07-10 21:08 PDT ------- ah, very true, the other xfs apps hadnt caught my mind thanks for the heads up, i'll update the Gentoo packages :) ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Thu Oct 7 23:39:02 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 07 Oct 2004 23:39:05 -0700 (PDT) Received: from coredumps.de (coredumps.de [217.160.213.75]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i986d1pU001526 for ; Thu, 7 Oct 2004 23:39:02 -0700 Received: from port-212-202-52-150.dynamic.qsc.de ([212.202.52.150] helo=ente.berdmann.de) by coredumps.de with esmtpsa (TLSv1:DES-CBC3-SHA:168) (Exim 4.42) id 1CFoOu-0001bC-Fb; Fri, 08 Oct 2004 08:38:48 +0200 Received: from apollo.berdmann.de ([192.168.1.2]) by ente.berdmann.de with esmtp (Exim 3.36 #1) id 1CFoOt-0002vg-00; Fri, 08 Oct 2004 08:38:47 +0200 Message-ID: <416635F7.7090607@berdmann.de> Date: Fri, 08 Oct 2004 08:38:47 +0200 From: Bernhard Erdmann User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040930 X-Accept-Language: de, en, fr MIME-Version: 1.0 To: Nathan Scott CC: linux-xfs@oss.sgi.com Subject: Re: building xfsprogs (CVS): fadvise.c:71: `POSIX_FADV_NORMAL' undeclared (first use in this function) References: <4165B869.3020001@berdmann.de> <20041007231844.GB824@frodo> In-Reply-To: <20041007231844.GB824@frodo> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4244 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: be@berdmann.de Precedence: bulk X-list: linux-xfs > Try CVS in an hour, it should work after a "make distclean" in > current xfsprogs (2.6.25). Thanks. xfsprogs 2.6.25 does compile. From owner-linux-xfs Fri Oct 8 07:00:50 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 08 Oct 2004 07:00:52 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i98E0owS004509 for ; Fri, 8 Oct 2004 07:00:50 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i98E0omA004507 for linux-xfs@oss.sgi.com; Fri, 8 Oct 2004 07:00:50 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i98E0m3t004482 for ; Fri, 8 Oct 2004 07:00:48 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i98DqSUJ004215; Fri, 8 Oct 2004 06:52:28 -0700 Date: Fri, 8 Oct 2004 06:52:28 -0700 Message-Id: <200410081352.i98DqSUJ004215@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 368] New: xfsdump doesnt support DESTDIR for make install target X-Bugzilla-Reason: AssignedTo X-archive-position: 4245 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=368 Summary: xfsdump doesnt support DESTDIR for make install target Product: Linux XFS Version: Current Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: High Component: xfsdump AssignedTo: xfs-master@oss.sgi.com ReportedBy: vapier@gentoo.org another patch we had laying around in Gentoo adds `make install DESTDIR=/some/place` support also removes forcing of -O1 on the user ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Fri Oct 8 07:00:50 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 08 Oct 2004 07:00:54 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i98E0onl004508 for ; Fri, 8 Oct 2004 07:00:50 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i98E0o6f004506 for linux-xfs@oss.sgi.com; Fri, 8 Oct 2004 07:00:50 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i98E0m3r004482 for ; Fri, 8 Oct 2004 07:00:48 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i98DCwGo002071; Fri, 8 Oct 2004 06:12:58 -0700 Date: Fri, 8 Oct 2004 06:12:58 -0700 Message-Id: <200410081312.i98DCwGo002071@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 367] New: dmapi doesnt support DESTDIR for install target X-Bugzilla-Reason: AssignedTo X-archive-position: 4246 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=367 Summary: dmapi doesnt support DESTDIR for install target Product: Linux XFS Version: Current Platform: All OS/Version: Linux Status: NEW Severity: enhancement Priority: High Component: dmapi AssignedTo: xfs-master@oss.sgi.com ReportedBy: vapier@gentoo.org find attached a patch that we've been using at Gentoo for sometime ... guess no one thought to send it to you guys ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Fri Oct 8 13:00:51 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 08 Oct 2004 13:00:53 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i98K0p3U029608 for ; Fri, 8 Oct 2004 13:00:51 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i98K0p9e029607 for linux-xfs@oss.sgi.com; Fri, 8 Oct 2004 13:00:51 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i98K0ock029591 for ; Fri, 8 Oct 2004 13:00:50 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i98JAnEm021192; Fri, 8 Oct 2004 12:10:49 -0700 Date: Fri, 8 Oct 2004 12:10:49 -0700 Message-Id: <200410081910.i98JAnEm021192@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 365] Truncating a file over NFS+DMAPI hangs client X-Bugzilla-Reason: AssignedTo X-archive-position: 4247 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=365 ------- Additional Comments From mmontour@bycast.com 2004-08-10 12:10 PDT ------- Further investigation indicates that the problem occurs in fs/xfs/xfs_dmapi.c, xfs_dm_send_data_event(), in this code (line 183): #ifdef DM_FLAGS_IALLOCSEM_WR if (flags & DM_FLAGS_IALLOCSEM_WR) down_write(&inode->i_alloc_sem); #endif The down_write() hangs (shown by adding printk's before and after this statement). ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Fri Oct 8 16:00:52 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 08 Oct 2004 16:00:54 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i98N0qWN009583 for ; Fri, 8 Oct 2004 16:00:52 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i98N0qLb009582 for linux-xfs@oss.sgi.com; Fri, 8 Oct 2004 16:00:52 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i98N0oOr009568 for ; Fri, 8 Oct 2004 16:00:50 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i98MHHpU008247; Fri, 8 Oct 2004 15:17:17 -0700 Date: Fri, 8 Oct 2004 15:17:17 -0700 Message-Id: <200410082217.i98MHHpU008247@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 365] Truncating a file over NFS+DMAPI hangs client X-Bugzilla-Reason: AssignedTo X-archive-position: 4248 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=365 ------- Additional Comments From roehrich@sgi.com 2004-08-10 15:17 PDT ------- It's been a while since the locking was evaluated, to see if it's keeping up with the kernel. I'll try to get to this next week. At first glance it appears that xfs_dm_send_data_event has the locking out of order after it comes back from dm_send_data_event. I think the down(i_sem) should happen after any down*(i_alloc_sem). ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Fri Oct 8 17:00:52 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 08 Oct 2004 17:02:03 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9900qU1017872 for ; Fri, 8 Oct 2004 17:00:52 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i9900qTB017871 for linux-xfs@oss.sgi.com; Fri, 8 Oct 2004 17:00:52 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9900oSF017855 for ; Fri, 8 Oct 2004 17:00:50 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i98NHvNe010350; Fri, 8 Oct 2004 16:17:57 -0700 Date: Fri, 8 Oct 2004 16:17:57 -0700 Message-Id: <200410082317.i98NHvNe010350@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 365] Truncating a file over NFS+DMAPI hangs client X-Bugzilla-Reason: AssignedTo X-archive-position: 4249 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=365 ------- Additional Comments From mmontour@bycast.com 2004-08-10 16:17 PDT ------- I've done more investigation and it looks like i_alloc_sem isn't actually held at the time of the dm_send_data_event, if the truncate operation comes from NFS. NFS nfsd_setattr calls notify_change which calls linvfs_setattr, but i_alloc_sem is not set on this path (in fact, "grep" shows that nothing in fs/nfs mentions i_alloc_sem). Local truncate operations go through do_truncate() in fs/open.c, which downs i_alloc_sem before calling notify_change. My temporary workaround is to call "down_write_trylock(&inode->i_alloc_sem)" before the "up_write(&inode->i_alloc_sem)", and to skip the later down_write if the down_write_trylock() indicates no contention. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Fri Oct 8 17:18:55 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 08 Oct 2004 17:18:57 -0700 (PDT) Received: from pimout3-ext.prodigy.net (pimout3-ext.prodigy.net [207.115.63.102]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i990IsZI020147 for ; Fri, 8 Oct 2004 17:18:55 -0700 Received: from taniwha.stupidest.org (adsl-68-120-154-49.dsl.snfc21.pacbell.net [68.120.154.49]) by pimout3-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id i990IHSX162428; Fri, 8 Oct 2004 20:18:18 -0400 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id 16B52115C86F; Fri, 8 Oct 2004 17:18:17 -0700 (PDT) Date: Fri, 8 Oct 2004 17:18:17 -0700 From: Chris Wedgwood To: Bernhard Erdmann Cc: linux-xfs@oss.sgi.com Subject: Re: xfs_fsr for directories? Message-ID: <20041009001817.GA23108@taniwha.stupidest.org> References: <4165D00A.8020306@berdmann.de> <20041008002936.GA12054@taniwha.stupidest.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041008002936.GA12054@taniwha.stupidest.org> X-archive-position: 4250 X-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 On Thu, Oct 07, 2004 at 05:29:36PM -0700, Chris Wedgwood wrote: > to *try* to make a directory better if not don't mind the inode > changing do somehting like (can't be done whilst it's being accessed > though) actually: mkdir temp mv dir/* temp mv temp/* dir rmdir temp will preserve the inode number and is probably as good, ctime/mtime change though From owner-linux-xfs Sat Oct 9 17:00:56 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 09 Oct 2004 17:01:06 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9A00uwJ014734 for ; Sat, 9 Oct 2004 17:00:56 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i9A00u8A014732 for linux-xfs@oss.sgi.com; Sat, 9 Oct 2004 17:00:56 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9A00tN9014708 for ; Sat, 9 Oct 2004 17:00:55 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i99NndoP014409; Sat, 9 Oct 2004 16:49:39 -0700 Date: Sat, 9 Oct 2004 16:49:39 -0700 Message-Id: <200410092349.i99NndoP014409@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 370] New: xfsprogs doesnt support DESTDIR for make install target X-Bugzilla-Reason: AssignedTo X-archive-position: 4251 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=370 Summary: xfsprogs doesnt support DESTDIR for make install target Product: Linux XFS Version: Current Platform: All OS/Version: Linux Status: NEW Severity: enhancement Priority: High Component: xfsprogs AssignedTo: xfs-master@oss.sgi.com ReportedBy: vapier@gentoo.org another patch we had laying around in Gentoo adds `make install DESTDIR=/some/place` support also removes forcing of -O1 on the user ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Sat Oct 9 17:00:56 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 09 Oct 2004 17:01:06 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9A00uUV014733 for ; Sat, 9 Oct 2004 17:00:56 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i9A00u12014731 for linux-xfs@oss.sgi.com; Sat, 9 Oct 2004 17:00:56 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9A00tN7014708 for ; Sat, 9 Oct 2004 17:00:55 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i99NnIVS014393; Sat, 9 Oct 2004 16:49:18 -0700 Date: Sat, 9 Oct 2004 16:49:18 -0700 Message-Id: <200410092349.i99NnIVS014393@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 368] xfsdump doesnt support DESTDIR for make install target X-Bugzilla-Reason: AssignedTo X-archive-position: 4252 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=368 vapier@gentoo.org changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |enhancement ------- Additional Comments From vapier@gentoo.org 2004-08-10 06:53 PDT ------- Created an attachment (id=143) --> (http://oss.sgi.com/bugzilla/attachment.cgi?id=143&action=view) xfsdump-destdir.patch ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Sat Oct 9 18:00:56 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 09 Oct 2004 18:01:03 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9A10uvu016459 for ; Sat, 9 Oct 2004 18:00:56 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i9A10ueJ016457 for linux-xfs@oss.sgi.com; Sat, 9 Oct 2004 18:00:56 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9A10tta016422 for ; Sat, 9 Oct 2004 18:00:55 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i9A0Yr3Q015916; Sat, 9 Oct 2004 17:34:53 -0700 Date: Sat, 9 Oct 2004 17:34:53 -0700 Message-Id: <200410100034.i9A0Yr3Q015916@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 372] New: attr doesnt support DESTDIR for make install target X-Bugzilla-Reason: AssignedTo X-archive-position: 4255 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=372 Summary: attr doesnt support DESTDIR for make install target Product: Linux XFS Version: Current Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: High Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: vapier@gentoo.org another patch we had laying around in Gentoo adds `make install DESTDIR=/some/place` support ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Sat Oct 9 18:00:56 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 09 Oct 2004 18:01:01 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9A10uxF016455 for ; Sat, 9 Oct 2004 18:00:56 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i9A10ucF016454 for linux-xfs@oss.sgi.com; Sat, 9 Oct 2004 18:00:56 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9A10ttY016422 for ; Sat, 9 Oct 2004 18:00:55 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i9A0Z1uB015925; Sat, 9 Oct 2004 17:35:01 -0700 Date: Sat, 9 Oct 2004 17:35:01 -0700 Message-Id: <200410100035.i9A0Z1uB015925@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 372] attr doesnt support DESTDIR for make install target X-Bugzilla-Reason: AssignedTo X-archive-position: 4253 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=372 vapier@gentoo.org changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |enhancement ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Sat Oct 9 18:00:56 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 09 Oct 2004 18:01:01 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9A10u3X016463 for ; Sat, 9 Oct 2004 18:00:56 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i9A10uRH016461 for linux-xfs@oss.sgi.com; Sat, 9 Oct 2004 18:00:56 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9A10ttc016422 for ; Sat, 9 Oct 2004 18:00:55 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i9A09c9H015504; Sat, 9 Oct 2004 17:09:38 -0700 Date: Sat, 9 Oct 2004 17:09:38 -0700 Message-Id: <200410100009.i9A09c9H015504@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 371] New: acl doesnt support DESTDIR for make install target X-Bugzilla-Reason: AssignedTo X-archive-position: 4254 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=371 Summary: acl doesnt support DESTDIR for make install target Product: Linux XFS Version: Current Platform: All OS/Version: Linux Status: NEW Severity: enhancement Priority: High Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: vapier@gentoo.org another patch we had laying around in Gentoo adds `make install DESTDIR=/some/place` support also removes forcing of -O1 on the user ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Sat Oct 9 22:41:23 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 09 Oct 2004 22:41:24 -0700 (PDT) Received: from mail.cs.umn.edu (postfix@mail.cs.umn.edu [128.101.35.202]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9A5fMAG027126 for ; Sat, 9 Oct 2004 22:41:23 -0700 Received: from localhost (localhost [127.0.0.1]) by augustus.cs.umn.edu (Postfix) with ESMTP id 0087E5C391 for ; Sun, 10 Oct 2004 00:41:08 -0500 (CDT) Received: from mail.cs.umn.edu ([127.0.0.1]) by localhost (augustus [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 05398-01-8 for ; Sun, 10 Oct 2004 00:41:07 -0500 (CDT) Received: from mega.cs.umn.edu (mega.cs.umn.edu [128.101.35.167]) by mail.cs.umn.edu (Postfix) with ESMTP id CAFD85C38E for ; Sun, 10 Oct 2004 00:41:07 -0500 (CDT) Received: from localhost (geeta@localhost) by mega.cs.umn.edu (8.9.3/8.9.0) with ESMTP id AAA20526 for ; Sun, 10 Oct 2004 00:41:07 -0500 (CDT) X-Authentication-Warning: mega.cs.umn.edu: geeta owned process doing -bs Date: Sun, 10 Oct 2004 00:41:07 -0500 (CDT) From: Geeta Gharpure To: linux-xfs@oss.sgi.com Subject: mkfs on floppy Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at cs.umn.edu X-archive-position: 4256 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: geeta@cs.umn.edu Precedence: bulk X-list: linux-xfs Hello Has anyone tried mkfs.xfs on a floppy device? I am constantly getting - [root@localhost root]# mkfs.xfs /dev/fd0 mkfs.xfs: cannot open /dev/fd0: Device or resource busy message. I am able to make ext2 on the same device. I have made the required kernel configuration and installed - xfsprogs-2.6.25-1 Please help. Thanks and regards, geeta From owner-linux-xfs Sun Oct 10 00:06:11 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 10 Oct 2004 00:06:13 -0700 (PDT) Received: from pimout1-ext.prodigy.net (pimout1-ext.prodigy.net [207.115.63.77]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9A76A9U031589 for ; Sun, 10 Oct 2004 00:06:11 -0700 Received: from taniwha.stupidest.org (adsl-68-120-154-49.dsl.snfc21.pacbell.net [68.120.154.49]) by pimout1-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id i9A75tWC153360; Sun, 10 Oct 2004 03:05:55 -0400 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id D024A115C874; Sun, 10 Oct 2004 00:05:54 -0700 (PDT) Date: Sun, 10 Oct 2004 00:05:54 -0700 From: Chris Wedgwood To: Geeta Gharpure Cc: linux-xfs@oss.sgi.com Subject: Re: mkfs on floppy Message-ID: <20041010070554.GA31586@taniwha.stupidest.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-archive-position: 4257 X-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 On Sun, Oct 10, 2004 at 12:41:07AM -0500, Geeta Gharpure wrote: > Has anyone tried mkfs.xfs on a floppy device? it's not useful and won't work, there is a lower limit that's much larger than a typical floppy (16MB?) an ls120/240 should work > I am constantly getting - > [root@localhost root]# mkfs.xfs /dev/fd0 > mkfs.xfs: cannot open /dev/fd0: Device or resource busy > message. dont do that xfs isn't useful or desirable on a floppy --cw From owner-linux-xfs Sun Oct 10 04:00:14 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 10 Oct 2004 04:00:16 -0700 (PDT) Received: from mail.drzeus.cx (daemon@a26.t1.student.liu.se [130.236.221.26]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9AB0DpL022077 for ; Sun, 10 Oct 2004 04:00:14 -0700 Received: from [10.8.0.168] ([::ffff:10.8.0.168]) (AUTH: PLAIN drzeus, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.drzeus.cx with esmtp; Sun, 10 Oct 2004 13:00:30 +0200 id 0048EBBB.4169164E.000041AF Message-ID: <41691639.8080002@drzeus.cx> Date: Sun, 10 Oct 2004 13:00:09 +0200 From: Pierre Ossman User-Agent: Mozilla Thunderbird 0.8 (X11/20040919) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Unable to mount root when using 'quiet' X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4258 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: drzeus-list@drzeus.cx Precedence: bulk X-list: linux-xfs I've encountered a really strange bug that appeared in 2.6.9-rc3 (I previously had 2.6.9-rc2). I'm running FC2. When booting the machine with the kernel parameter 'quiet' the kernel is unable to mount the root XFS partition. It just gives error 19, says something about trying to kill init, then panics. Since 'quiet' is used I do not get any decent output. Removing the parameter makes the problem go away. Without debug output I don't really know how to determine what's wrong. Perhaps someone who knows what has been changed recently can have some ideas? Rgds Pierre Ossman PS. I'm not subscribed so please cc me. From owner-linux-xfs Sun Oct 10 17:01:01 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 10 Oct 2004 17:01:04 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9B011vS029894 for ; Sun, 10 Oct 2004 17:01:01 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i9B011E9029893 for linux-xfs@oss.sgi.com; Sun, 10 Oct 2004 17:01:01 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9B00x3v029875 for ; Sun, 10 Oct 2004 17:00:59 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i9B00ADZ029860; Sun, 10 Oct 2004 17:00:10 -0700 Date: Sun, 10 Oct 2004 17:00:10 -0700 Message-Id: <200410110000.i9B00ADZ029860@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 370] xfsprogs doesnt support DESTDIR for make install target X-Bugzilla-Reason: AssignedTo X-archive-position: 4259 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=370 nathans@sgi.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID ------- Additional Comments From vapier@gentoo.org 2004-09-10 16:49 PDT ------- Created an attachment (id=144) --> (http://oss.sgi.com/bugzilla/attachment.cgi?id=144&action=view) xfsprogs-destdir.patch ------- Additional Comments From nathans@sgi.com 2004-10-10 17:00 PDT ------- These things are already possible - see the use of DIST_ROOT inside build/Makefile for example, and the optimisation level can also be overriden via CFLAGS (it is forced to -01 due to old compiler bugs) being set in the environment. cheers. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Sun Oct 10 18:01:02 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 10 Oct 2004 18:01:07 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9B112OK031350 for ; Sun, 10 Oct 2004 18:01:02 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i9B112aS031346 for linux-xfs@oss.sgi.com; Sun, 10 Oct 2004 18:01:02 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9B10x2b031290 for ; Sun, 10 Oct 2004 18:01:00 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i9B02rJ0030182; Sun, 10 Oct 2004 17:02:53 -0700 Date: Sun, 10 Oct 2004 17:02:53 -0700 Message-Id: <200410110002.i9B02rJ0030182@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 371] acl doesnt support DESTDIR for make install target X-Bugzilla-Reason: AssignedTo X-archive-position: 4262 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=371 nathans@sgi.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID ------- Additional Comments From vapier@gentoo.org 2004-09-10 17:25 PDT ------- Created an attachment (id=145) --> (http://oss.sgi.com/bugzilla/attachment.cgi?id=145&action=view) acl-destdir.patch ------- Additional Comments From nathans@sgi.com 2004-10-10 17:02 PDT ------- This is already possible - see use of DIST_ROOT in build/Makefile for example. cheers. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Sun Oct 10 18:01:02 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 10 Oct 2004 18:01:05 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9B112it031348 for ; Sun, 10 Oct 2004 18:01:02 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i9B1123i031343 for linux-xfs@oss.sgi.com; Sun, 10 Oct 2004 18:01:02 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9B10x2V031290 for ; Sun, 10 Oct 2004 18:01:00 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i9B010mV029890; Sun, 10 Oct 2004 17:01:00 -0700 Date: Sun, 10 Oct 2004 17:01:00 -0700 Message-Id: <200410110001.i9B010mV029890@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 368] xfsdump doesnt support DESTDIR for make install target X-Bugzilla-Reason: AssignedTo X-archive-position: 4260 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=368 nathans@sgi.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID ------- Additional Comments From nathans@sgi.com 2004-10-10 17:00 PDT ------- These things are already possible - see the use of DIST_ROOT inside build/Makefile for example, and the optimisation level can also be overriden via CFLAGS (it is forced to -01 due to old compiler bugs) being set in the environment. cheers. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Sun Oct 10 18:01:02 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 10 Oct 2004 18:01:06 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9B112HR031349 for ; Sun, 10 Oct 2004 18:01:02 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i9B112bh031345 for linux-xfs@oss.sgi.com; Sun, 10 Oct 2004 18:01:02 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9B10x2R031290 for ; Sun, 10 Oct 2004 18:00:59 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i9B0XBSc030718; Sun, 10 Oct 2004 17:33:11 -0700 Date: Sun, 10 Oct 2004 17:33:11 -0700 Message-Id: <200410110033.i9B0XBSc030718@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 370] xfsprogs doesnt support DESTDIR for make install target X-Bugzilla-Reason: AssignedTo X-archive-position: 4261 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=370 ------- Additional Comments From vapier@gentoo.org 2004-10-10 17:33 PDT ------- any reason you just dont rename DIST_ROOT DESTDIR ? DESTDIR is a lot more common in the OSS world than DIST_ROOT ... ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Sun Oct 10 18:01:02 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 10 Oct 2004 18:01:08 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9B112L6031347 for ; Sun, 10 Oct 2004 18:01:02 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i9B1126j031344 for linux-xfs@oss.sgi.com; Sun, 10 Oct 2004 18:01:02 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9B10x2d031290 for ; Sun, 10 Oct 2004 18:01:00 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i9B027t2030065; Sun, 10 Oct 2004 17:02:07 -0700 Date: Sun, 10 Oct 2004 17:02:07 -0700 Message-Id: <200410110002.i9B027t2030065@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 372] attr doesnt support DESTDIR for make install target X-Bugzilla-Reason: AssignedTo X-archive-position: 4263 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=372 nathans@sgi.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID ------- Additional Comments From vapier@gentoo.org 2004-09-10 17:35 PDT ------- Created an attachment (id=146) --> (http://oss.sgi.com/bugzilla/attachment.cgi?id=146&action=view) attr-destdir.patch ------- Additional Comments From nathans@sgi.com 2004-10-10 17:02 PDT ------- This is already possible - see use of DIST_ROOT in build/Makefile for example. cheers. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Sun Oct 10 19:01:01 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 10 Oct 2004 19:01:02 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9B211Xq001772 for ; Sun, 10 Oct 2004 19:01:01 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i9B211T0001771 for linux-xfs@oss.sgi.com; Sun, 10 Oct 2004 19:01:01 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9B210lJ001755 for ; Sun, 10 Oct 2004 19:01:00 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i9B1qQq5001522; Sun, 10 Oct 2004 18:52:26 -0700 Date: Sun, 10 Oct 2004 18:52:26 -0700 Message-Id: <200410110152.i9B1qQq5001522@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 370] xfsprogs doesnt support DESTDIR for make install target X-Bugzilla-Reason: AssignedTo X-archive-position: 4264 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=370 ------- Additional Comments From nathans@sgi.com 2004-10-10 18:52 PDT ------- Several years too late to do a rename like that - people will be relying on being able to set the current variable name.. you can just set DIST_ROOT=$DESTDIR before you do your build though, no? cheers. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Sun Oct 10 20:01:01 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 10 Oct 2004 20:01:03 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9B311t9003193 for ; Sun, 10 Oct 2004 20:01:01 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i9B311j1003192 for linux-xfs@oss.sgi.com; Sun, 10 Oct 2004 20:01:01 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9B310nR003178 for ; Sun, 10 Oct 2004 20:01:00 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i9B2BaSU002264; Sun, 10 Oct 2004 19:11:36 -0700 Date: Sun, 10 Oct 2004 19:11:36 -0700 Message-Id: <200410110211.i9B2BaSU002264@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 370] xfsprogs doesnt support DESTDIR for make install target X-Bugzilla-Reason: AssignedTo X-archive-position: 4265 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=370 ------- Additional Comments From vapier@gentoo.org 2004-10-10 19:11 PDT ------- it's not problem working around it, i just thought it might be better to have these things fixed upstream rather than just in Gentoo ;) ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Sun Oct 10 21:01:01 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 10 Oct 2004 21:01:03 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9B411oi008332 for ; Sun, 10 Oct 2004 21:01:01 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i9B411l5008331 for linux-xfs@oss.sgi.com; Sun, 10 Oct 2004 21:01:01 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9B4100A008315 for ; Sun, 10 Oct 2004 21:01:00 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i9B3Bao7003751; Sun, 10 Oct 2004 20:11:36 -0700 Date: Sun, 10 Oct 2004 20:11:36 -0700 Message-Id: <200410110311.i9B3Bao7003751@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 367] dmapi doesnt support DESTDIR for install target X-Bugzilla-Reason: AssignedTo X-archive-position: 4266 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=367 nathans@sgi.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID ------- Additional Comments From vapier@gentoo.org 2004-08-10 06:13 PDT ------- Created an attachment (id=142) --> (http://oss.sgi.com/bugzilla/attachment.cgi?id=142&action=view) dmapi-destdir.patch now you can `make install DESTDIR=/some/random/place` ------- Additional Comments From nathans@sgi.com 2004-10-10 20:11 PDT ------- DIST_ROOT provides this functionality already. cheers. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Mon Oct 11 02:01:03 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 11 Oct 2004 02:01:05 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9B912kw010584 for ; Mon, 11 Oct 2004 02:01:02 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i9B912uh010583 for linux-xfs@oss.sgi.com; Mon, 11 Oct 2004 02:01:02 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9B911lv010567 for ; Mon, 11 Oct 2004 02:01:01 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i9B8mZSh002207; Mon, 11 Oct 2004 01:48:35 -0700 Date: Mon, 11 Oct 2004 01:48:35 -0700 Message-Id: <200410110848.i9B8mZSh002207@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 373] New: samba msoffice xfs interaction problem X-Bugzilla-Reason: AssignedTo X-archive-position: 4267 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=373 Summary: samba msoffice xfs interaction problem Product: Linux XFS Version: Current Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: Medium Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: x@axxel.net os: gentoo linux xfs-kernel 2.4.24-xfs-r5 samba: 3.0.7 problem: occurs when a user who was not the creator of the file saves a msoffice document on a samba share using the xfs file system. msoffice creates a new file during the save process. the result is that the saving user is added to the acl with only ro rights (default rights are set to rwx) to this file. these only ro rights affect also the creator of the file, although he is listed in the acl with full rwx rights. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Mon Oct 11 04:55:21 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 11 Oct 2004 04:55:23 -0700 (PDT) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9BBtJur030329 for ; Mon, 11 Oct 2004 04:55:21 -0700 Received: from web1.messagingengine.com (web1.internal [10.202.2.210]) by frontend1.messagingengine.com (Postfix) with ESMTP id 6711FC30600 for ; Mon, 11 Oct 2004 07:55:05 -0400 (EDT) Received: by web1.messagingengine.com (Postfix, from userid 99) id C4AE03738; Mon, 11 Oct 2004 07:55:05 -0400 (EDT) Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="ISO-8859-1" MIME-Version: 1.0 X-Mailer: MIME::Lite 1.5 (F2.73; T1.001; A1.64; B3.05; Q3.03) To: linux-xfs@oss.sgi.com Date: Mon, 11 Oct 2004 13:55:05 +0200 From: milos_p@fastmail.fm X-Sasl-Enc: 6hGntcw15NDXnYatyp63Fg 1097495705 Message-Id: <1097495705.27061.206199044@webmail.messagingengine.com> X-archive-position: 4268 Subject: (no subject) X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: milos_p@fastmail.fm Precedence: bulk X-list: linux-xfs From owner-linux-xfs Mon Oct 11 05:28:15 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 11 Oct 2004 05:28:20 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i9BCSEwu032145 for ; Mon, 11 Oct 2004 05:28:15 -0700 Received: (qmail 12148 invoked by uid 65534); 11 Oct 2004 12:27:55 -0000 Received: from G12be.g.pppool.de (EHLO [192.168.1.11]) (80.185.18.190) by mail.gmx.net (mp018) with SMTP; 11 Oct 2004 14:27:55 +0200 X-Authenticated: #2986359 Message-ID: <416A7C48.9040609@gmx.net> Date: Mon, 11 Oct 2004 14:27:52 +0200 From: evilninja User-Agent: Mozilla Thunderbird 0.8 (X11/20040926) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com CC: Geeta Gharpure Subject: Re: mkfs on floppy References: <20041010070554.GA31586@taniwha.stupidest.org> In-Reply-To: <20041010070554.GA31586@taniwha.stupidest.org> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-archive-position: 4269 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: evilninja@gmx.net Precedence: bulk X-list: linux-xfs -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chris Wedgwood wrote: > > it's not useful and won't work, there is a lower limit that's much > larger than a typical floppy (16MB?) at least with JFS there is a limit too: evil@prinz:~$ /sbin/mkfs.jfs /dev/fd0 /sbin/mkfs.jfs version 1.1.6, 28-Apr-2004 Partition must be at least 16 megabytes. and reiserfs says: Guessing about desired format.. Kernel 2.6.9-rc2 is running. reiserfs_create_journal: cannot create a journal of 8193 blocks with 18 offset on 352 blocks ext2/ext3 mkfs is working, but mounting fails (?). Christian. - -- BOFH excuse #383: Your processor has taken a ride to Heaven's Gate on the UFO behind Hale-Bopp's comet. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBanxIC/PVm5+NVoYRAhaOAJ0XVIBnLrEsoS5Q9vHxOw3M8tCpugCfRuuG gL2s2/k457F0Y/nl86or6tY= =/+ol -----END PGP SIGNATURE----- From owner-linux-xfs Mon Oct 11 06:13:35 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 11 Oct 2004 06:13:37 -0700 (PDT) Received: from mail.drzeus.cx (daemon@a26.t1.student.liu.se [130.236.221.26]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9BDDYqg003296 for ; Mon, 11 Oct 2004 06:13:35 -0700 Received: from [10.8.0.5] (apollo.drzeus.cx [::ffff:10.8.0.5]) (AUTH: PLAIN drzeus, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by mail.drzeus.cx with esmtp; Mon, 11 Oct 2004 15:13:51 +0200 id 00291831.416A870F.00005D13 Message-ID: <416A86ED.6010808@drzeus.cx> Date: Mon, 11 Oct 2004 15:13:17 +0200 From: Pierre Ossman User-Agent: Mozilla Thunderbird 0.8 (X11/20040919) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: Unable to mount root when using 'quiet' References: <41691639.8080002@drzeus.cx> In-Reply-To: <41691639.8080002@drzeus.cx> X-Enigmail-Version: 0.84.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4270 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: drzeus-list@drzeus.cx Precedence: bulk X-list: linux-xfs Seems it wasn't that easy. When I removed the battery (it's a laptop) I got the panic even without 'quiet'. Might be a timing issue? If I compile xfs into the kernel instead of having it as a module the system boots every time. Pierre Ossman wrote: > I've encountered a really strange bug that appeared in 2.6.9-rc3 (I > previously had 2.6.9-rc2). I'm running FC2. > > When booting the machine with the kernel parameter 'quiet' the kernel is > unable to mount the root XFS partition. It just gives error 19, says > something about trying to kill init, then panics. > > Since 'quiet' is used I do not get any decent output. Removing the > parameter makes the problem go away. > > Without debug output I don't really know how to determine what's wrong. > Perhaps someone who knows what has been changed recently can have some > ideas? > > Rgds > Pierre Ossman > > PS. I'm not subscribed so please cc me. > From owner-linux-xfs Mon Oct 11 09:16:32 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 11 Oct 2004 09:16:37 -0700 (PDT) Received: from gateway2.geodev.com (IDENT:+Z8AZ88ODKsqV/tg39loJFaNW+Hzovk2@gateway2.geodev.com [64.45.165.170]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9BGGV1U013280 for ; Mon, 11 Oct 2004 09:16:32 -0700 Received: from [192.168.201.127] (fiste.geodev.com [192.168.201.127]) (authenticated) by gateway2.geodev.com (8.11.6/8.11.6) with ESMTP id i9BGFwM22186; Mon, 11 Oct 2004 11:15:58 -0500 Message-ID: <416AB1C1.30108@geodev.com> Date: Mon, 11 Oct 2004 11:16:01 -0500 From: Chris Evert User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nathan Scott CC: linux-xfs@oss.sgi.com Subject: Re: possible deadlock in kmem_alloc (mode:0x50) References: <4159FFCC.9000708@geodev.com> <20040929111143.G4413387@wobbly.melbourne.sgi.com> In-Reply-To: <20040929111143.G4413387@wobbly.melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4271 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: chris@geodev.com Precedence: bulk X-list: linux-xfs Nathan Scott wrote: > On Tue, Sep 28, 2004 at 07:20:28PM -0500, Chris Evert wrote: > >>Hello, >> >>I'm getting a bunch of these messages: >> >>Sep 28 19:04:48 hod kernel: possible deadlock in kmem_alloc (mode:0x50) >>Sep 28 19:05:18 hod last message repeated 349087 times >>Sep 28 19:06:20 hod last message repeated 688880 times >>Sep 28 19:07:21 hod last message repeated 681742 times >>Sep 28 19:08:22 hod last message repeated 686647 times >>Sep 28 19:09:23 hod last message repeated 679838 times >> >>I'm using kernel 2.6.8-1.521 (Fedora Core 2) and sharing the file system >>via NFS. I'm getting no oopses, just slow to no response to NFS requests. >> >>Any clues? > > > /proc/slabinfo will hold some clues, send it over this way. > Also, try bumping up the value of /proc/sys/vm/vfs_cache_pressure. > > cheers. > Thanks. I bumped /proc/sys/vm/vfs_cache_pressure to 150 and that seemed to work til this weekend. This time, the messages were being repeated merely 3000 times a second, but the log seems to be writing over itself: Oct 10 23:31:00 hod kernel: possible deadlock in kmem_alloc (mo deadlock in kmem_alloc (mode:0x50) Oct 10 23:31:00 hod kernel: possible deadlock in kmem_alloc (mode:0x50) Oct 10 23:31:00 hod last message repeated 85 times Oct 10 23:31:00 hod kernel: possible deadl deadlock in kmem_alloc (mode:0x50) Oct 10 23:31:00 hod kernel: poss deadlock in kmem_alloc (mode:0x50) Oct 10 23:31:00 hod kernel: possible deadlock in kmem_alloc (mode:0x50) Oct 10 23:31:00 hod last message repeated 84 times A snapshot of /proc/slabinfo during this time: slabinfo - version: 2.0 # name : tunables : slabdata nfs_write_data 36 42 512 7 1 : tunables 54 27 8 : slabdata 6 6 0 nfs_read_data 32 35 512 7 1 : tunables 54 27 8 : slabdata 5 5 0 nfs_inode_cache 19 30 640 6 1 : tunables 54 27 8 : slabdata 5 5 0 nfs_page 0 0 128 31 1 : tunables 120 60 8 : slabdata 0 0 0 xfrm6_tunnel_spi 0 0 64 61 1 : tunables 120 60 8 : slabdata 0 0 0 fib6_nodes 5 119 32 119 1 : tunables 120 60 8 : slabdata 1 1 0 ip6_dst_cache 11 30 256 15 1 : tunables 120 60 8 : slabdata 2 2 0 ndisc_cache 1 15 256 15 1 : tunables 120 60 8 : slabdata 1 1 0 raw6_sock 0 0 768 5 1 : tunables 54 27 8 : slabdata 0 0 0 udp6_sock 0 0 768 5 1 : tunables 54 27 8 : slabdata 0 0 0 tcp6_sock 11 12 1280 3 1 : tunables 24 12 8 : slabdata 4 4 0 bt_sock 3 14 512 7 1 : tunables 54 27 8 : slabdata 2 2 0 rpc_buffers 8 8 2048 2 1 : tunables 24 12 8 : slabdata 4 4 0 rpc_tasks 8 15 256 15 1 : tunables 120 60 8 : slabdata 1 1 0 rpc_inode_cache 8 14 512 7 1 : tunables 54 27 8 : slabdata 2 2 0 ip_fib_hash 25 226 16 226 1 : tunables 120 60 8 : slabdata 1 1 0 xfs_acl 0 0 304 13 1 : tunables 54 27 8 : slabdata 0 0 0 xfs_chashlist 17 185 20 185 1 : tunables 120 60 8 : slabdata 1 1 0 xfs_ili 133 196 140 28 1 : tunables 120 60 8 : slabdata 7 7 0 xfs_ifork 0 0 56 70 1 : tunables 120 60 8 : slabdata 0 0 0 xfs_efi_item 0 0 260 15 1 : tunables 54 27 8 : slabdata 0 0 0 xfs_efd_item 0 0 260 15 1 : tunables 54 27 8 : slabdata 0 0 0 xfs_buf_item 0 0 148 27 1 : tunables 120 60 8 : slabdata 0 0 0 xfs_dabuf 0 0 16 226 1 : tunables 120 60 8 : slabdata 0 0 0 xfs_da_state 0 0 336 12 1 : tunables 54 27 8 : slabdata 0 0 0 xfs_trans 0 0 600 6 1 : tunables 54 27 8 : slabdata 0 0 0 xfs_inode 212 240 384 10 1 : tunables 54 27 8 : slabdata 24 24 0 xfs_btree_cur 0 0 140 28 1 : tunables 120 60 8 : slabdata 0 0 0 xfs_bmap_free_item 0 0 16 226 1 : tunables 120 60 8 : slabdata 0 0 0 xfs_buf_t 20 120 256 15 1 : tunables 120 60 8 : slabdata 8 8 0 linvfs_icache 212 240 384 10 1 : tunables 54 27 8 : slabdata 24 24 0 dm_tio 0 0 16 226 1 : tunables 120 60 8 : slabdata 0 0 0 dm_io 0 0 16 226 1 : tunables 120 60 8 : slabdata 0 0 0 uhci_urb_priv 0 0 44 88 1 : tunables 120 60 8 : slabdata 0 0 0 ext3_inode_cache 6898 17840 512 8 1 : tunables 54 27 8 : slabdata 2230 2230 0 ext3_xattr 0 0 48 81 1 : tunables 120 60 8 : slabdata 0 0 0 journal_handle 34 135 28 135 1 : tunables 120 60 8 : slabdata 1 1 0 journal_head 138 243 48 81 1 : tunables 120 60 8 : slabdata 3 3 0 revoke_table 4 290 12 290 1 : tunables 120 60 8 : slabdata 1 1 0 revoke_record 0 0 16 226 1 : tunables 120 60 8 : slabdata 0 0 0 scsi_cmd_cache 2 10 384 10 1 : tunables 54 27 8 : slabdata 1 1 0 qla2xxx_srbs 256 310 128 31 1 : tunables 120 60 8 : slabdata 10 10 0 sgpool-128 32 33 2560 3 2 : tunables 24 12 8 : slabdata 11 11 0 sgpool-64 32 33 1280 3 1 : tunables 24 12 8 : slabdata 11 11 0 sgpool-32 32 36 640 6 1 : tunables 54 27 8 : slabdata 6 6 0 sgpool-16 32 40 384 10 1 : tunables 54 27 8 : slabdata 4 4 0 sgpool-8 32 45 256 15 1 : tunables 120 60 8 : slabdata 3 3 0 unix_sock 24 63 512 7 1 : tunables 54 27 8 : slabdata 9 9 0 ip_mrt_cache 0 0 128 31 1 : tunables 120 60 8 : slabdata 0 0 0 tcp_tw_bucket 0 0 128 31 1 : tunables 120 60 8 : slabdata 0 0 0 tcp_bind_bucket 19 226 16 226 1 : tunables 120 60 8 : slabdata 1 1 0 tcp_open_request 0 0 128 31 1 : tunables 120 60 8 : slabdata 0 0 0 inet_peer_cache 1 61 64 61 1 : tunables 120 60 8 : slabdata 1 1 0 secpath_cache 0 0 128 31 1 : tunables 120 60 8 : slabdata 0 0 0 xfrm_dst_cache 0 0 256 15 1 : tunables 120 60 8 : slabdata 0 0 0 ip_dst_cache 44 105 256 15 1 : tunables 120 60 8 : slabdata 7 7 0 arp_cache 7 15 256 15 1 : tunables 120 60 8 : slabdata 1 1 0 raw4_sock 0 0 640 6 1 : tunables 54 27 8 : slabdata 0 0 0 udp_sock 10 24 640 6 1 : tunables 54 27 8 : slabdata 4 4 0 tcp_sock 46 70 1152 7 2 : tunables 24 12 8 : slabdata 10 10 0 flow_cache 0 0 128 31 1 : tunables 120 60 8 : slabdata 0 0 0 mqueue_inode_cache 1 6 640 6 1 : tunables 54 27 8 : slabdata 1 1 0 isofs_inode_cache 0 0 384 10 1 : tunables 54 27 8 : slabdata 0 0 0 hugetlbfs_inode_cache 1 11 348 11 1 : tunables 54 27 8 : slabdata 1 1 0 ext2_inode_cache 0 0 512 7 1 : tunables 54 27 8 : slabdata 0 0 0 ext2_xattr 0 0 48 81 1 : tunables 120 60 8 : slabdata 0 0 0 dquot 0 0 144 27 1 : tunables 120 60 8 : slabdata 0 0 0 eventpoll_pwq 0 0 36 107 1 : tunables 120 60 8 : slabdata 0 0 0 eventpoll_epi 0 0 128 31 1 : tunables 120 60 8 : slabdata 0 0 0 kioctx 0 0 256 15 1 : tunables 120 60 8 : slabdata 0 0 0 kiocb 0 0 128 31 1 : tunables 120 60 8 : slabdata 0 0 0 dnotify_cache 2 185 20 185 1 : tunables 120 60 8 : slabdata 1 1 0 file_lock_cache 3 78 100 39 1 : tunables 120 60 8 : slabdata 2 2 0 fasync_cache 0 0 16 226 1 : tunables 120 60 8 : slabdata 0 0 0 shmem_inode_cache 6 14 512 7 1 : tunables 54 27 8 : slabdata 2 2 0 posix_timers_cache 0 0 112 35 1 : tunables 120 60 8 : slabdata 0 0 0 uid_cache 12 61 64 61 1 : tunables 120 60 8 : slabdata 1 1 0 cfq_pool 101 119 32 119 1 : tunables 120 60 8 : slabdata 1 1 0 crq_pool 54 480 40 96 1 : tunables 120 60 8 : slabdata 5 5 0 deadline_drq 0 0 52 75 1 : tunables 120 60 8 : slabdata 0 0 0 as_arq 0 0 64 61 1 : tunables 120 60 8 : slabdata 0 0 0 blkdev_ioc 176 370 20 185 1 : tunables 120 60 8 : slabdata 2 2 0 blkdev_queue 22 24 480 8 1 : tunables 54 27 8 : slabdata 3 3 0 blkdev_requests 54 125 160 25 1 : tunables 120 60 8 : slabdata 5 5 0 biovec-(256) 256 256 3072 2 2 : tunables 24 12 8 : slabdata 128 128 0 biovec-128 256 260 1536 5 2 : tunables 24 12 8 : slabdata 52 52 0 biovec-64 256 260 768 5 1 : tunables 54 27 8 : slabdata 52 52 0 biovec-16 256 270 256 15 1 : tunables 120 60 8 : slabdata 18 18 0 biovec-4 256 305 64 61 1 : tunables 120 60 8 : slabdata 5 5 0 biovec-1 371 678 16 226 1 : tunables 120 60 8 : slabdata 3 3 0 bio 385 434 128 31 1 : tunables 120 60 8 : slabdata 14 14 0 sock_inode_cache 101 133 512 7 1 : tunables 54 27 8 : slabdata 19 19 0 skbuff_head_cache 949 1380 256 15 1 : tunables 120 60 8 : slabdata 92 92 60 sock 5 10 384 10 1 : tunables 54 27 8 : slabdata 1 1 0 proc_inode_cache 2690 2690 384 10 1 : tunables 54 27 8 : slabdata 269 269 0 sigqueue 6 27 148 27 1 : tunables 120 60 8 : slabdata 1 1 0 radix_tree_node 35085 46284 276 14 1 : tunables 54 27 8 : slabdata 3306 3306 0 bdev_cache 10 21 512 7 1 : tunables 54 27 8 : slabdata 3 3 0 mnt_cache 35 62 128 31 1 : tunables 120 60 8 : slabdata 2 2 0 inode_cache 2054 2080 384 10 1 : tunables 54 27 8 : slabdata 208 208 0 dentry_cache 10215 26468 152 26 1 : tunables 120 60 8 : slabdata 1018 1018 0 filp 703 885 256 15 1 : tunables 120 60 8 : slabdata 59 59 0 names_cache 5 5 4096 1 1 : tunables 24 12 8 : slabdata 5 5 0 idr_layer_cache 74 116 136 29 1 : tunables 120 60 8 : slabdata 4 4 0 buffer_head 486022 486525 52 75 1 : tunables 120 60 8 : slabdata 6487 6487 0 mm_struct 74 115 768 5 1 : tunables 54 27 8 : slabdata 23 23 0 vm_area_struct 1812 2565 88 45 1 : tunables 120 60 8 : slabdata 57 57 0 fs_cache 191 366 64 61 1 : tunables 120 60 8 : slabdata 6 6 0 files_cache 76 133 512 7 1 : tunables 54 27 8 : slabdata 19 19 0 signal_cache 239 372 128 31 1 : tunables 120 60 8 : slabdata 12 12 0 sighand_cache 244 255 1408 5 2 : tunables 24 12 8 : slabdata 51 51 0 task_struct 545 545 1472 5 2 : tunables 24 12 8 : slabdata 109 109 0 anon_vma 757 1808 16 226 1 : tunables 120 60 8 : slabdata 8 8 0 pgd 77 357 32 119 1 : tunables 120 60 8 : slabdata 3 3 0 kpmd 58 58 4096 1 1 : tunables 24 12 8 : slabdata 58 58 0 pmd 174 174 4096 1 1 : tunables 24 12 8 : slabdata 174 174 0 size-131072(DMA) 0 0 131072 1 32 : tunables 8 4 0 : slabdata 0 0 0 size-131072 1 1 131072 1 32 : tunables 8 4 0 : slabdata 1 1 0 size-65536(DMA) 0 0 65536 1 16 : tunables 8 4 0 : slabdata 0 0 0 size-65536 20 20 65536 1 16 : tunables 8 4 0 : slabdata 20 20 0 size-32768(DMA) 0 0 32768 1 8 : tunables 8 4 0 : slabdata 0 0 0 size-32768 26 26 32768 1 8 : tunables 8 4 0 : slabdata 26 26 0 size-16384(DMA) 0 0 16384 1 4 : tunables 8 4 0 : slabdata 0 0 0 size-16384 6 6 16384 1 4 : tunables 8 4 0 : slabdata 6 6 0 size-8192(DMA) 0 0 8192 1 2 : tunables 8 4 0 : slabdata 0 0 0 size-8192 16 16 8192 1 2 : tunables 8 4 0 : slabdata 16 16 0 size-4096(DMA) 0 0 4096 1 1 : tunables 24 12 8 : slabdata 0 0 0 size-4096 1318 1318 4096 1 1 : tunables 24 12 8 : slabdata 1318 1318 0 size-2048(DMA) 0 0 2048 2 1 : tunables 24 12 8 : slabdata 0 0 0 size-2048 368 384 2048 2 1 : tunables 24 12 8 : slabdata 192 192 0 size-1620(DMA) 0 0 1664 4 2 : tunables 24 12 8 : slabdata 0 0 0 size-1620 28 32 1664 4 2 : tunables 24 12 8 : slabdata 8 8 0 size-1024(DMA) 0 0 1024 4 1 : tunables 54 27 8 : slabdata 0 0 0 size-1024 256 256 1024 4 1 : tunables 54 27 8 : slabdata 64 64 0 size-512(DMA) 0 0 512 8 1 : tunables 54 27 8 : slabdata 0 0 0 size-512 718 2536 512 8 1 : tunables 54 27 8 : slabdata 317 317 27 size-256(DMA) 0 0 256 15 1 : tunables 120 60 8 : slabdata 0 0 0 size-256 769 2400 256 15 1 : tunables 120 60 8 : slabdata 160 160 0 size-128(DMA) 0 0 128 31 1 : tunables 120 60 8 : slabdata 0 0 0 size-128 2465 4960 128 31 1 : tunables 120 60 8 : slabdata 160 160 0 size-64(DMA) 0 0 64 61 1 : tunables 120 60 8 : slabdata 0 0 0 size-64 5975 25498 64 61 1 : tunables 120 60 8 : slabdata 418 418 0 size-32(DMA) 0 0 32 119 1 : tunables 120 60 8 : slabdata 0 0 0 size-32 4052 5474 32 119 1 : tunables 120 60 8 : slabdata 46 46 0 kmem_cache 165 165 256 15 1 : tunables 120 60 8 : slabdata 11 11 0 Thanks for any insight. Chris -- Chris Evert chris@geodev.com Geophysical Development Corporation Houston, TX From owner-linux-xfs Mon Oct 11 10:31:39 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 11 Oct 2004 10:31:41 -0700 (PDT) Received: from tempgw.ciprico.com (hqntws.ciprico.com [208.252.143.8] (may be forged)) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9BHVa6M017903 for ; Mon, 11 Oct 2004 10:31:38 -0700 Received: from Unknown [172.20.0.8] by tempgw.ciprico.com - SurfControl E-mail Filter (4.7); Mon, 11 Oct 2004 12:31:16 -0500 Received: by hqntex1.ciprico.com with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Oct 2004 12:31:15 -0500 Message-ID: From: Joe Eiler To: "'linux-xfs@oss.sgi.com'" Date: Mon, 11 Oct 2004 12:31:05 -0500 Subject: xfs_repair failing MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Mailer: Internet Mail Service (5.5.2653.19) X-archive-position: 4272 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jeiler@ciprico.com Precedence: bulk X-list: linux-xfs When running xfs_repair I get a "ran out of disk space!!" error. I realize this is because there isn't enough space on the disk to do the repair. I did a quick search of the archives and I found someone else with this problem but they were told it was "expected" behavior. My question is "Is there any way around this?" Can xfs_repair move the lost+found to a different disk? Are there any steps to free up some space by copying files off that are already determined to be good? Thanks, Joe Oh, this is on a production system running kernel 2.4.21 running xfsprogs 2.4.10-0 From owner-linux-xfs Mon Oct 11 16:54:34 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 11 Oct 2004 16:54:45 -0700 (PDT) Received: from chook.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9BNsVqw005288 for ; Mon, 11 Oct 2004 16:54:32 -0700 Received: (from nathans@localhost) by chook.melbourne.sgi.com (8.11.6/8.11.6) id i9BNsCC26346 for linux-xfs@oss.sgi.com; Tue, 12 Oct 2004 09:54:12 +1000 Date: Tue, 12 Oct 2004 09:54:12 +1000 From: Nathan Scott Message-Id: <200410112354.i9BNsCC26346@chook.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE 904196 - Merge up to 2.6.9-rc4 X-archive-position: 4273 X-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@chook.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Date: Tue Oct 12 09:52:30 AEST 2004 Workarea: chook.melbourne.sgi.com:/build/nathans/2.6.x-xfs Inspected by: torvalds@osdl.org The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: 2.6.x-xfs-melb:linux:19727a Documentation/ManagementStyle - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/Documentation/ManagementStyle include/linux/gen_stats.h - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/gen_stats.h Documentation/arm/Samsung-S3C24XX/GPIO.txt - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/Documentation/arm/Samsung-S3C24XX/GPIO.txt include/asm-arm/arch-s3c2410/usb-control.h - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-arm/arch-s3c2410/usb-control.h include/asm-arm/arch-h720x/dma.h - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-arm/arch-h720x/dma.h arch/ia64/kernel/mca_drv.c - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/kernel/mca_drv.c include/asm-arm/arch-h720x/uncompress.h - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-arm/arch-h720x/uncompress.h arch/ia64/kernel/mca_drv.h - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/kernel/mca_drv.h Documentation/networking/gen_stats.txt - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/Documentation/networking/gen_stats.txt include/asm-arm/arch-s3c2410/regs-spi.h - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-arm/arch-s3c2410/regs-spi.h arch/ia64/kernel/mca_drv_asm.S - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/kernel/mca_drv_asm.S arch/ia64/configs/bigsur_defconfig - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/configs/bigsur_defconfig include/asm-arm/arch-s3c2410/regs-mem.h - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-arm/arch-s3c2410/regs-mem.h arch/ppc/boot/simple/pibs.c - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ppc/boot/simple/pibs.c net/core/gen_estimator.c - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/core/gen_estimator.c include/asm-arm/arch-h720x/hardware.h - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-arm/arch-h720x/hardware.h net/core/gen_stats.c - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/core/gen_stats.c drivers/char/drm/drm_core.h - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/char/drm/drm_core.h drivers/ide/arm/bast-ide.c - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/ide/arm/bast-ide.c include/net/gen_stats.h - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/net/gen_stats.h include/asm-arm/arch-h720x/io.h - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-arm/arch-h720x/io.h include/asm-arm/arch-h720x/boards.h - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-arm/arch-h720x/boards.h arch/arm/configs/h7201_defconfig - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/configs/h7201_defconfig arch/arm/configs/h7202_defconfig - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/configs/h7202_defconfig include/asm-arm/arch-h720x/h7202-regs.h - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-arm/arch-h720x/h7202-regs.h include/asm-arm/arch-h720x/h7201-regs.h - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-arm/arch-h720x/h7201-regs.h include/asm-arm/arch-h720x/serial.h - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-arm/arch-h720x/serial.h include/asm-arm/arch-h720x/irq.h - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-arm/arch-h720x/irq.h include/asm-arm/arch-h720x/irqs.h - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-arm/arch-h720x/irqs.h arch/arm/mach-s3c2410/usb-simtec.h - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/mach-s3c2410/usb-simtec.h arch/arm/mach-s3c2410/usb-simtec.c - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/mach-s3c2410/usb-simtec.c arch/arm/mach-h720x/Kconfig - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/mach-h720x/Kconfig arch/arm/mach-h720x/Makefile - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/mach-h720x/Makefile arch/arm/mach-h720x/common.c - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/mach-h720x/common.c arch/arm/mach-h720x/cpu-h7201.c - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/mach-h720x/cpu-h7201.c arch/arm/mach-h720x/cpu-h7202.c - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/mach-h720x/cpu-h7202.c arch/arm/mach-h720x/h7201-eval.c - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/mach-h720x/h7201-eval.c arch/arm/mach-h720x/h7202-eval.c - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/mach-h720x/h7202-eval.c include/asm-arm/arch-s3c2410/regs-iic.h - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-arm/arch-s3c2410/regs-iic.h include/asm-arm/arch-h720x/vmalloc.h - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-arm/arch-h720x/vmalloc.h include/asm-arm/arch-h720x/memory.h - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-arm/arch-h720x/memory.h include/asm-arm/arch-h720x/timex.h - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-arm/arch-h720x/timex.h include/asm-arm/arch-h720x/param.h - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-arm/arch-h720x/param.h include/asm-arm/arch-h720x/system.h - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-arm/arch-h720x/system.h Documentation/filesystems/ntfs.txt - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/Documentation/filesystems/ntfs.txt.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h Documentation/firmware_class/hotplug-script - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/Documentation/firmware_class/hotplug-script.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h Documentation/ioctl-number.txt - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/Documentation/ioctl-number.txt.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h Documentation/kernel-parameters.txt - 1.11 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/Documentation/kernel-parameters.txt.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h Documentation/scsi/scsi_mid_low_api.txt - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/Documentation/scsi/scsi_mid_low_api.txt.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h Documentation/sysctl/vm.txt - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/Documentation/sysctl/vm.txt.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h Documentation/vm/overcommit-accounting - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/Documentation/vm/overcommit-accounting.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h MAINTAINERS - 1.12 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/MAINTAINERS.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h Makefile - 1.24 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/Makefile.diff?r1=text&tr1=1.24&r2=text&tr2=1.23&f=h arch/alpha/Makefile - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/alpha/Makefile.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/alpha/kernel/sys_dp264.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/alpha/kernel/sys_dp264.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/arm/Kconfig - 1.9 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/Kconfig.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h arch/arm/Makefile - 1.9 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/Makefile.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h arch/arm/boot/Makefile - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/boot/Makefile.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h arch/arm/boot/compressed/head.S - 1.8 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/boot/compressed/head.S.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h arch/arm/kernel/calls.S - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/kernel/calls.S.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/arm/kernel/debug.S - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/kernel/debug.S.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h arch/arm/kernel/ecard.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/kernel/ecard.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/arm/kernel/entry-armv.S - 1.8 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/kernel/entry-armv.S.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h arch/arm/kernel/irq.c - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/kernel/irq.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h arch/arm/kernel/signal.c - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/kernel/signal.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h arch/arm/kernel/time.c - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/kernel/time.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h arch/arm/mach-pxa/pm.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/mach-pxa/pm.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/arm/mach-pxa/sleep.S - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/mach-pxa/sleep.S.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/arm/mach-sa1100/pm.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/mach-sa1100/pm.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/arm/mm/Kconfig - 1.9 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/mm/Kconfig.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h arch/arm/mm/abort-ev5tj.S - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/mm/abort-ev5tj.S.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/arm/mm/consistent.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/mm/consistent.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/arm/mm/init.c - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/mm/init.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h arch/arm/tools/mach-types - 1.8 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/tools/mach-types.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h arch/arm26/mm/init.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm26/mm/init.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/i386/Makefile - 1.11 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/i386/Makefile.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h arch/i386/kernel/acpi/boot.c - 1.13 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/i386/kernel/acpi/boot.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h arch/i386/kernel/apic.c - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/i386/kernel/apic.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h arch/i386/kernel/dmi_scan.c - 1.9 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/i386/kernel/dmi_scan.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h arch/i386/kernel/io_apic.c - 1.16 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/i386/kernel/io_apic.c.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h arch/i386/kernel/traps.c - 1.13 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/i386/kernel/traps.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h arch/i386/mm/fault.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/i386/mm/fault.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/i386/mm/init.c - 1.8 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/i386/mm/init.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h arch/i386/pci/i386.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/i386/pci/i386.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/ia64/Kconfig - 1.11 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/Kconfig.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h arch/ia64/Makefile - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/Makefile.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h arch/ia64/hp/common/sba_iommu.c - 1.9 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/hp/common/sba_iommu.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h arch/ia64/ia32/elfcore32.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/ia32/elfcore32.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/ia64/ia32/ia32_entry.S - 1.8 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/ia32/ia32_entry.S.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h arch/ia64/ia32/ia32_ldt.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/ia32/ia32_ldt.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/ia64/ia32/ia32_signal.c - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/ia32/ia32_signal.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h arch/ia64/ia32/ia32_support.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/ia32/ia32_support.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/ia64/ia32/ia32priv.h - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/ia32/ia32priv.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h arch/ia64/ia32/sys_ia32.c - 1.10 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/ia32/sys_ia32.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h arch/ia64/kernel/Makefile - 1.8 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/kernel/Makefile.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h arch/ia64/kernel/acpi-ext.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/kernel/acpi-ext.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/ia64/kernel/acpi.c - 1.13 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/kernel/acpi.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h arch/ia64/kernel/asm-offsets.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/kernel/asm-offsets.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/ia64/kernel/efi.c - 1.9 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/kernel/efi.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h arch/ia64/kernel/iosapic.c - 1.10 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/kernel/iosapic.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h arch/ia64/kernel/irq.c - 1.9 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/kernel/irq.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h arch/ia64/kernel/irq_ia64.c - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/kernel/irq_ia64.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h arch/ia64/kernel/mca.c - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/kernel/mca.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h arch/ia64/kernel/module.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/kernel/module.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/ia64/kernel/palinfo.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/kernel/palinfo.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/ia64/kernel/patch.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/kernel/patch.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/ia64/kernel/perfmon.c - 1.9 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/kernel/perfmon.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h arch/ia64/kernel/process.c - 1.9 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/kernel/process.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h arch/ia64/kernel/ptrace.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/kernel/ptrace.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/ia64/kernel/salinfo.c - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/kernel/salinfo.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h arch/ia64/kernel/setup.c - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/kernel/setup.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h arch/ia64/kernel/sigframe.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/kernel/sigframe.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/ia64/kernel/signal.c - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/kernel/signal.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h arch/ia64/kernel/smp.c - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/kernel/smp.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h arch/ia64/kernel/sys_ia64.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/kernel/sys_ia64.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/ia64/kernel/time.c - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/kernel/time.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h arch/ia64/kernel/traps.c - 1.8 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/kernel/traps.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h arch/ia64/kernel/unaligned.c - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/kernel/unaligned.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h arch/ia64/kernel/unwind.c - 1.9 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/kernel/unwind.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h arch/ia64/lib/csum_partial_copy.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/lib/csum_partial_copy.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/ia64/lib/io.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/lib/io.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/ia64/mm/contig.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/mm/contig.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/ia64/mm/extable.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/mm/extable.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/ia64/mm/fault.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/mm/fault.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/ia64/mm/init.c - 1.10 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/mm/init.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h arch/ia64/mm/tlb.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/mm/tlb.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/ia64/sn/kernel/sn2/prominfo_proc.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/sn/kernel/sn2/prominfo_proc.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/m68k/Makefile - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/m68k/Makefile.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h arch/mips/vr41xx/common/icu.c - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/vr41xx/common/icu.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h arch/mips/vr41xx/common/vrc4173.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/vr41xx/common/vrc4173.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/ppc/Makefile - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ppc/Makefile.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/ppc/boot/common/util.S - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ppc/boot/common/util.S.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/ppc/boot/openfirmware/misc.S - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ppc/boot/openfirmware/misc.S.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/ppc/boot/simple/Makefile - 1.8 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ppc/boot/simple/Makefile.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h arch/ppc/boot/simple/misc.c - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ppc/boot/simple/misc.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h arch/ppc/boot/simple/relocate.S - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ppc/boot/simple/relocate.S.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/ppc/configs/mvme5100_defconfig - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ppc/configs/mvme5100_defconfig.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/ppc/kernel/cpu_setup_6xx.S - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ppc/kernel/cpu_setup_6xx.S.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/ppc/kernel/cputable.c - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ppc/kernel/cputable.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h arch/ppc/kernel/entry.S - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ppc/kernel/entry.S.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h arch/ppc/kernel/head.S - 1.9 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ppc/kernel/head.S.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h arch/ppc/kernel/idle_6xx.S - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ppc/kernel/idle_6xx.S.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/ppc/kernel/idle_power4.S - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ppc/kernel/idle_power4.S.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/ppc/kernel/misc.S - 1.10 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ppc/kernel/misc.S.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h arch/ppc/kernel/ppc_ksyms.c - 1.8 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ppc/kernel/ppc_ksyms.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h arch/ppc/kernel/signal.c - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ppc/kernel/signal.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h arch/ppc/lib/checksum.S - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ppc/lib/checksum.S.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/ppc/mm/44x_mmu.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ppc/mm/44x_mmu.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/ppc/platforms/4xx/ebony.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ppc/platforms/4xx/ebony.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/ppc/platforms/4xx/ocotea.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ppc/platforms/4xx/ocotea.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/ppc/platforms/4xx/ocotea.h - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ppc/platforms/4xx/ocotea.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/ppc/platforms/pmac_pci.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ppc/platforms/pmac_pci.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/ppc/syslib/ibm44x_common.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ppc/syslib/ibm44x_common.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/ppc/syslib/ppc4xx_pic.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ppc/syslib/ppc4xx_pic.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/ppc/syslib/todc_time.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ppc/syslib/todc_time.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/ppc64/Kconfig - 1.11 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ppc64/Kconfig.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h arch/ppc64/Makefile - 1.8 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ppc64/Makefile.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h arch/ppc64/boot/Makefile - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ppc64/boot/Makefile.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/ppc64/kernel/ItLpQueue.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ppc64/kernel/ItLpQueue.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/ppc64/kernel/entry.S - 1.8 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ppc64/kernel/entry.S.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h arch/ppc64/kernel/head.S - 1.12 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ppc64/kernel/head.S.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h arch/ppc64/kernel/misc.S - 1.10 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ppc64/kernel/misc.S.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h arch/ppc64/kernel/pSeries_lpar.c - 1.10 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ppc64/kernel/pSeries_lpar.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h arch/ppc64/kernel/ppc_ksyms.c - 1.10 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ppc64/kernel/ppc_ksyms.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h arch/ppc64/kernel/process.c - 1.11 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ppc64/kernel/process.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h arch/ppc64/kernel/rtas-proc.c - 1.9 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ppc64/kernel/rtas-proc.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h arch/ppc64/kernel/setup.c - 1.12 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ppc64/kernel/setup.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h arch/ppc64/kernel/sys_ppc32.c - 1.11 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ppc64/kernel/sys_ppc32.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h arch/ppc64/lib/checksum.S - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ppc64/lib/checksum.S.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/s390/defconfig - 1.10 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/s390/defconfig.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h arch/s390/kernel/compat_signal.c - 1.8 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/s390/kernel/compat_signal.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h arch/s390/kernel/s390_ksyms.c - 1.8 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/s390/kernel/s390_ksyms.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h arch/s390/kernel/setup.c - 1.9 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/s390/kernel/setup.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h arch/sparc/Makefile - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/sparc/Makefile.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h arch/sparc/kernel/init_task.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/sparc/kernel/init_task.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/sparc64/Makefile - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/sparc64/Makefile.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/sparc64/defconfig - 1.11 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/sparc64/defconfig.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h arch/sparc64/kernel/binfmt_elf32.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/sparc64/kernel/binfmt_elf32.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/sparc64/kernel/chmc.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/sparc64/kernel/chmc.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/sparc64/kernel/power.c - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/sparc64/kernel/power.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h arch/sparc64/kernel/signal32.c - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/sparc64/kernel/signal32.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h arch/sparc64/kernel/sys_sparc32.c - 1.9 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/sparc64/kernel/sys_sparc32.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h arch/sparc64/kernel/traps.c - 1.8 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/sparc64/kernel/traps.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h arch/sparc64/mm/fault.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/sparc64/mm/fault.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/sparc64/solaris/misc.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/sparc64/solaris/misc.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/um/kernel/Makefile - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/um/kernel/Makefile.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/um/kernel/ptrace.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/um/kernel/ptrace.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/um/kernel/sys_call_table.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/um/kernel/sys_call_table.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/x86_64/Kconfig - 1.9 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/x86_64/Kconfig.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h arch/x86_64/Makefile - 1.8 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/x86_64/Makefile.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h arch/x86_64/ia32/syscall32.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/x86_64/ia32/syscall32.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/x86_64/kernel/io_apic.c - 1.10 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/x86_64/kernel/io_apic.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h arch/x86_64/kernel/nmi.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/x86_64/kernel/nmi.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/x86_64/kernel/setup.c - 1.10 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/x86_64/kernel/setup.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h arch/x86_64/kernel/setup64.c - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/x86_64/kernel/setup64.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h arch/x86_64/kernel/smp.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/x86_64/kernel/smp.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/x86_64/kernel/smpboot.c - 1.8 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/x86_64/kernel/smpboot.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h arch/x86_64/kernel/time.c - 1.8 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/x86_64/kernel/time.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h arch/x86_64/kernel/traps.c - 1.10 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/x86_64/kernel/traps.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h arch/x86_64/mm/init.c - 1.9 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/x86_64/mm/init.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h arch/x86_64/mm/ioremap.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/x86_64/mm/ioremap.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h crypto/aes.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/crypto/aes.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/acpi/Kconfig - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/acpi/Kconfig.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h drivers/acpi/asus_acpi.c - 1.8 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/acpi/asus_acpi.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h drivers/acpi/blacklist.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/acpi/blacklist.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/acpi/bus.c - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/acpi/bus.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h drivers/acpi/debug.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/acpi/debug.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/acpi/dispatcher/dsmethod.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/acpi/dispatcher/dsmethod.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/acpi/dispatcher/dsutils.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/acpi/dispatcher/dsutils.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/acpi/events/evgpe.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/acpi/events/evgpe.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/acpi/events/evmisc.c - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/acpi/events/evmisc.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/acpi/events/evregion.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/acpi/events/evregion.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/acpi/events/evrgnini.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/acpi/events/evrgnini.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/acpi/events/evxface.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/acpi/events/evxface.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/acpi/executer/exfldio.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/acpi/executer/exfldio.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/acpi/hardware/hwgpe.c - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/acpi/hardware/hwgpe.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/acpi/hardware/hwregs.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/acpi/hardware/hwregs.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/acpi/hardware/hwtimer.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/acpi/hardware/hwtimer.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/acpi/numa.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/acpi/numa.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/acpi/osl.c - 1.9 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/acpi/osl.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h drivers/acpi/pci_link.c - 1.10 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/acpi/pci_link.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h drivers/acpi/tables.c - 1.8 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/acpi/tables.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h drivers/acpi/thermal.c - 1.8 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/acpi/thermal.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h drivers/acpi/utilities/utglobal.c - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/acpi/utilities/utglobal.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/block/DAC960.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/block/DAC960.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/block/DAC960.h - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/block/DAC960.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/block/cciss.c - 1.9 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/block/cciss.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h drivers/block/cciss.h - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/block/cciss.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/block/cpqarray.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/block/cpqarray.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/block/cpqarray.h - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/block/cpqarray.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/block/ioctl.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/block/ioctl.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/block/umem.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/block/umem.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/cdrom/cdrom.c - 1.10 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/cdrom/cdrom.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h drivers/char/agp/amd-k7-agp.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/char/agp/amd-k7-agp.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/char/agp/amd64-agp.c - 1.8 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/char/agp/amd64-agp.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h drivers/char/agp/ati-agp.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/char/agp/ati-agp.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/char/agp/generic.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/char/agp/generic.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/char/agp/hp-agp.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/char/agp/hp-agp.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/char/agp/intel-agp.c - 1.8 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/char/agp/intel-agp.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h drivers/char/agp/nvidia-agp.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/char/agp/nvidia-agp.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/char/agp/sworks-agp.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/char/agp/sworks-agp.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/char/agp/via-agp.c - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/char/agp/via-agp.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h drivers/char/cyclades.c - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/char/cyclades.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h drivers/char/drm/Kconfig - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/char/drm/Kconfig.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/char/drm/drmP.h - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/char/drm/drmP.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/char/drm/ffb_drv.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/char/drm/ffb_drv.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/char/drm/i810_drv.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/char/drm/i810_drv.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/char/drm/i830_drv.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/char/drm/i830_drv.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/char/drm/mga_drv.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/char/drm/mga_drv.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/char/drm/r128_drv.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/char/drm/r128_drv.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/char/drm/radeon_drv.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/char/drm/radeon_drv.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/char/drm/sis_drv.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/char/drm/sis_drv.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/char/drm/tdfx_drv.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/char/drm/tdfx_drv.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/char/efirtc.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/char/efirtc.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/char/generic_serial.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/char/generic_serial.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/char/moxa.c - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/char/moxa.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h drivers/char/random.c - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/char/random.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h drivers/char/tty_io.c - 1.11 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/char/tty_io.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h drivers/char/tty_ioctl.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/char/tty_ioctl.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/char/watchdog/sa1100_wdt.c - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/char/watchdog/sa1100_wdt.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h drivers/ide/Kconfig - 1.11 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/ide/Kconfig.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h drivers/ide/arm/Makefile - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/ide/arm/Makefile.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/ide/ide-dma.c - 1.10 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/ide/ide-dma.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h drivers/ide/ide-probe.c - 1.8 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/ide/ide-probe.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h drivers/ide/ide-proc.c - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/ide/ide-proc.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h drivers/ide/ide-taskfile.c - 1.9 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/ide/ide-taskfile.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h drivers/ide/legacy/ide-cs.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/ide/legacy/ide-cs.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/ide/pci/aec62xx.c - 1.8 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/ide/pci/aec62xx.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h drivers/ide/pci/aec62xx.h - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/ide/pci/aec62xx.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/ide/pci/cmd640.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/ide/pci/cmd640.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/ide/pci/cmd64x.c - 1.9 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/ide/pci/cmd64x.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h drivers/ide/pci/cmd64x.h - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/ide/pci/cmd64x.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/ide/pci/pdc202xx_old.c - 1.10 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/ide/pci/pdc202xx_old.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h drivers/ide/pci/pdc202xx_old.h - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/ide/pci/pdc202xx_old.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/ide/pci/piix.c - 1.10 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/ide/pci/piix.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h drivers/ide/pci/triflex.c - 1.8 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/ide/pci/triflex.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h drivers/ieee1394/eth1394.c - 1.10 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/ieee1394/eth1394.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h drivers/ieee1394/eth1394.h - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/ieee1394/eth1394.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/input/mouse/pc110pad.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/input/mouse/pc110pad.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/isdn/capi/capi.c - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/isdn/capi/capi.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h drivers/isdn/i4l/isdn_net.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/isdn/i4l/isdn_net.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/isdn/i4l/isdn_tty.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/isdn/i4l/isdn_tty.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/macintosh/ans-lcd.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/macintosh/ans-lcd.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/media/dvb/dvb-core/dvb_net.c - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/dvb/dvb-core/dvb_net.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/media/dvb/frontends/stv0299.c - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/dvb/frontends/stv0299.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h drivers/media/video/dpc7146.c - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/video/dpc7146.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/message/i2o/i2o_config.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/message/i2o/i2o_config.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/mtd/chips/jedec_probe.c - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/mtd/chips/jedec_probe.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/net/3c59x.c - 1.8 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/3c59x.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h drivers/net/arcnet/arc-rimi.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/arcnet/arc-rimi.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/net/arcnet/com90xx.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/arcnet/com90xx.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/net/bonding/bond_alb.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/bonding/bond_alb.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/net/defxx.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/defxx.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/net/hamradio/bpqether.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/hamradio/bpqether.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/net/ioc3-eth.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/ioc3-eth.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/net/myri_sbus.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/myri_sbus.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/net/natsemi.c - 1.8 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/natsemi.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h drivers/net/plip.c - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/plip.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/net/pppoe.c - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/pppoe.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h drivers/net/skfp/skfddi.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/skfp/skfddi.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/net/sungem.c - 1.8 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/sungem.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h drivers/net/tokenring/Kconfig - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/tokenring/Kconfig.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/net/tokenring/olympic.c - 1.9 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/tokenring/olympic.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h drivers/net/wan/pc300_tty.c - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/wan/pc300_tty.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/net/wireless/ray_cs.c - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/wireless/ray_cs.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/net/wireless/ray_cs.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/wireless/ray_cs.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/pcmcia/cardbus.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/pcmcia/cardbus.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/pcmcia/cistpl.c - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/pcmcia/cistpl.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h drivers/pcmcia/cs.c - 1.9 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/pcmcia/cs.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h drivers/pcmcia/ds.c - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/pcmcia/ds.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h drivers/pcmcia/i82365.c - 1.8 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/pcmcia/i82365.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h drivers/pcmcia/rsrc_mgr.c - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/pcmcia/rsrc_mgr.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/pcmcia/sa1100_h3600.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/pcmcia/sa1100_h3600.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/pcmcia/yenta_socket.h - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/pcmcia/yenta_socket.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/pnp/system.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/pnp/system.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/s390/block/dasd_diag.c - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/s390/block/dasd_diag.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/s390/block/dasd_eckd.c - 1.9 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/s390/block/dasd_eckd.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h drivers/s390/char/sclp_tty.c - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/s390/char/sclp_tty.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h drivers/s390/char/sclp_vt220.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/s390/char/sclp_vt220.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/s390/cio/blacklist.c - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/s390/cio/blacklist.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/s390/cio/ccwgroup.c - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/s390/cio/ccwgroup.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h drivers/s390/cio/cio.c - 1.8 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/s390/cio/cio.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h drivers/s390/cio/css.c - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/s390/cio/css.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h drivers/s390/cio/device.c - 1.8 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/s390/cio/device.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h drivers/s390/cio/device_fsm.c - 1.8 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/s390/cio/device_fsm.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h drivers/s390/cio/device_id.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/s390/cio/device_id.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/scsi/3w-xxxx.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/3w-xxxx.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/scsi/NCR53C9x.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/NCR53C9x.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/scsi/atp870u.c - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/atp870u.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/scsi/dc395x.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/dc395x.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/scsi/gdth.c - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/gdth.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h drivers/scsi/gdth.h - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/gdth.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/scsi/ips.c - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/ips.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/scsi/mca_53c9x.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/mca_53c9x.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/scsi/pcmcia/nsp_cs.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/pcmcia/nsp_cs.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/scsi/scsiiom.c - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/scsiiom.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h drivers/scsi/tmscsim.c - 1.8 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/tmscsim.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h drivers/serial/serial_core.c - 1.11 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/serial/serial_core.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h drivers/usb/class/bluetty.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/class/bluetty.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/usb/class/cdc-acm.c - 1.9 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/class/cdc-acm.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h drivers/usb/class/usblp.c - 1.8 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/class/usblp.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h drivers/usb/core/hcd.c - 1.10 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/core/hcd.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h drivers/usb/core/hub.h - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/core/hub.h.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h drivers/usb/host/ehci-dbg.c - 1.8 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/host/ehci-dbg.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h drivers/usb/host/ehci-hub.c - 1.8 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/host/ehci-hub.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h drivers/usb/host/ehci-mem.c - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/host/ehci-mem.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h drivers/usb/host/ehci-q.c - 1.8 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/host/ehci-q.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h drivers/usb/host/ehci-sched.c - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/host/ehci-sched.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h drivers/usb/host/ehci.h - 1.8 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/host/ehci.h.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h drivers/usb/host/ohci-dbg.c - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/host/ohci-dbg.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h drivers/usb/host/ohci-hub.c - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/host/ohci-hub.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/usb/host/ohci-q.c - 1.9 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/host/ohci-q.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h drivers/usb/host/ohci.h - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/host/ohci.h.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h drivers/usb/host/uhci-hcd.c - 1.11 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/host/uhci-hcd.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h drivers/usb/host/uhci-hcd.h - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/host/uhci-hcd.h.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h drivers/usb/host/uhci-hub.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/host/uhci-hub.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/usb/input/aiptek.c - 1.8 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/input/aiptek.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h drivers/usb/input/hid-core.c - 1.9 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/input/hid-core.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h drivers/usb/input/kbtab.c - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/input/kbtab.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h drivers/usb/input/wacom.c - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/input/wacom.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/usb/media/ov511.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/media/ov511.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/usb/misc/auerswald.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/misc/auerswald.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/usb/net/catc.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/net/catc.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/usb/net/kaweth.c - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/net/kaweth.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/usb/net/pegasus.c - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/net/pegasus.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/usb/net/rtl8150.c - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/net/rtl8150.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h drivers/usb/net/usbnet.c - 1.11 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/net/usbnet.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h drivers/usb/serial/empeg.c - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/serial/empeg.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/usb/serial/io_edgeport.c - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/serial/io_edgeport.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/usb/serial/io_edgeport.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/serial/io_edgeport.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/usb/serial/io_ti.c - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/serial/io_ti.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/usb/serial/io_usbvend.h - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/serial/io_usbvend.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/usb/storage/datafab.c - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/storage/datafab.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h drivers/usb/storage/freecom.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/storage/freecom.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/usb/storage/isd200.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/storage/isd200.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/usb/storage/jumpshot.c - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/storage/jumpshot.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h drivers/usb/storage/protocol.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/storage/protocol.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/usb/storage/sddr09.c - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/storage/sddr09.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h drivers/usb/storage/sddr55.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/storage/sddr55.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/usb/storage/transport.h - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/storage/transport.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/video/Kconfig - 1.13 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/video/Kconfig.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h drivers/video/radeonfb.c - 1.9 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/video/radeonfb.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h drivers/video/sis/sis.h - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/video/sis/sis.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/video/sis/sis_main.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/video/sis/sis_main.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/video/sis/sis_main.h - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/video/sis/sis_main.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/video/tridentfb.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/video/tridentfb.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h fs/eventpoll.c - 1.8 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/eventpoll.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h fs/hfs/bfind.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/hfs/bfind.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h fs/hfs/bitmap.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/hfs/bitmap.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h fs/hfs/bnode.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/hfs/bnode.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h fs/hfs/brec.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/hfs/brec.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h fs/hfs/btree.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/hfs/btree.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h fs/hfs/catalog.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/hfs/catalog.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h fs/hfs/extent.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/hfs/extent.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h fs/hfs/hfs.h - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/hfs/hfs.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h fs/hfs/inode.c - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/hfs/inode.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h fs/hfs/mdb.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/hfs/mdb.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h fs/hfs/part_tbl.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/hfs/part_tbl.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h fs/hfs/super.c - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/hfs/super.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h fs/hugetlbfs/inode.c - 1.9 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/hugetlbfs/inode.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h fs/isofs/compress.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/isofs/compress.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h fs/jffs2/super.c - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/jffs2/super.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h fs/locks.c - 1.9 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/locks.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h fs/namei.c - 1.10 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/namei.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h fs/ncpfs/dir.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/ncpfs/dir.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h fs/ncpfs/inode.c - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/ncpfs/inode.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h fs/ncpfs/ioctl.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/ncpfs/ioctl.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h fs/ncpfs/ncplib_kernel.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/ncpfs/ncplib_kernel.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h fs/ncpfs/ncplib_kernel.h - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/ncpfs/ncplib_kernel.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h fs/ncpfs/sock.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/ncpfs/sock.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h fs/ncpfs/symlink.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/ncpfs/symlink.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h fs/ntfs/ChangeLog - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/ntfs/ChangeLog.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h fs/ntfs/Makefile - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/ntfs/Makefile.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h fs/ntfs/attrib.c - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/ntfs/attrib.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h fs/partitions/acorn.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/partitions/acorn.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h fs/partitions/amiga.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/partitions/amiga.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h fs/partitions/atari.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/partitions/atari.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h fs/partitions/efi.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/partitions/efi.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h fs/partitions/ldm.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/partitions/ldm.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h fs/partitions/ldm.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/partitions/ldm.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h fs/partitions/mac.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/partitions/mac.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h fs/partitions/osf.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/partitions/osf.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h fs/partitions/sgi.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/partitions/sgi.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h fs/partitions/sun.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/partitions/sun.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h fs/quota_v1.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/quota_v1.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h fs/quota_v2.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/quota_v2.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h fs/romfs/inode.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/romfs/inode.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h fs/udf/balloc.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/udf/balloc.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h fs/ufs/balloc.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/ufs/balloc.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h fs/ufs/inode.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/ufs/inode.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h fs/ufs/super.c - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/ufs/super.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h fs/ufs/swab.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/ufs/swab.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h fs/ufs/truncate.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/ufs/truncate.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h fs/ufs/util.h - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/ufs/util.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h include/acpi/acconfig.h - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/acpi/acconfig.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h include/acpi/acexcep.h - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/acpi/acexcep.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/acpi/acglobal.h - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/acpi/acglobal.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h include/acpi/acmacros.h - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/acpi/acmacros.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h include/acpi/acpi_drivers.h - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/acpi/acpi_drivers.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h include/asm-arm/arch-pxa/serial.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-arm/arch-pxa/serial.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/asm-arm/arch-rpc/uncompress.h - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-arm/arch-rpc/uncompress.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-arm/bitops.h - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-arm/bitops.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h include/asm-arm/page.h - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-arm/page.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h include/asm-arm/system.h - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-arm/system.h.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h include/asm-arm/unistd.h - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-arm/unistd.h.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h include/asm-ia64/compat.h - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-ia64/compat.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h include/asm-ia64/elf.h - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-ia64/elf.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h include/asm-ia64/gcc_intrin.h - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-ia64/gcc_intrin.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h include/asm-ia64/hardirq.h - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-ia64/hardirq.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-ia64/hw_irq.h - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-ia64/hw_irq.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h include/asm-ia64/ia32.h - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-ia64/ia32.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h include/asm-ia64/io.h - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-ia64/io.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h include/asm-ia64/iosapic.h - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-ia64/iosapic.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h include/asm-ia64/mca.h - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-ia64/mca.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-ia64/mmu_context.h - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-ia64/mmu_context.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h include/asm-ia64/page.h - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-ia64/page.h.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h include/asm-ia64/pgtable.h - 1.8 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-ia64/pgtable.h.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h include/asm-ia64/processor.h - 1.10 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-ia64/processor.h.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h include/asm-ia64/siginfo.h - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-ia64/siginfo.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-ia64/signal.h - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-ia64/signal.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-ia64/smp.h - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-ia64/smp.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h include/asm-ia64/sn/sn_sal.h - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-ia64/sn/sn_sal.h.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h include/asm-ia64/spinlock.h - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-ia64/spinlock.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h include/asm-ia64/system.h - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-ia64/system.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h include/asm-ia64/thread_info.h - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-ia64/thread_info.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h include/asm-ia64/uaccess.h - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-ia64/uaccess.h.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h include/asm-ia64/unistd.h - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-ia64/unistd.h.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h include/asm-mips/vr41xx/vrc4173.h - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-mips/vr41xx/vrc4173.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-ppc/ibm44x.h - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-ppc/ibm44x.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-ppc/ppcboot.h - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-ppc/ppcboot.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h include/asm-ppc/reg_booke.h - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-ppc/reg_booke.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h include/asm-ppc64/eeh.h - 1.8 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-ppc64/eeh.h.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h include/asm-ppc64/mmu.h - 1.9 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-ppc64/mmu.h.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h include/asm-ppc64/mmu_context.h - 1.8 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-ppc64/mmu_context.h.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h include/asm-s390/page.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-s390/page.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/asm-s390/pgtable.h - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-s390/pgtable.h.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h include/asm-sparc64/checksum.h - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-sparc64/checksum.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h include/asm-sparc64/elf.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-sparc64/elf.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/asm-um/uaccess.h - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-um/uaccess.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h include/asm-x86_64/desc.h - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-x86_64/desc.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-x86_64/hw_irq.h - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-x86_64/hw_irq.h.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h include/asm-x86_64/io.h - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-x86_64/io.h.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h include/asm-x86_64/proto.h - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-x86_64/proto.h.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h include/asm-x86_64/ptrace.h - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-x86_64/ptrace.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h include/asm-x86_64/smp.h - 1.9 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-x86_64/smp.h.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h include/linux/acpi.h - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/acpi.h.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h include/linux/arcdevice.h - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/arcdevice.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h include/linux/byteorder/big_endian.h - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/byteorder/big_endian.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h include/linux/byteorder/generic.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/byteorder/generic.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/linux/byteorder/little_endian.h - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/byteorder/little_endian.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h include/linux/cyclades.h - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/cyclades.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h include/linux/genhd.h - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/genhd.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h include/linux/i2o.h - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/i2o.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h include/linux/ide.h - 1.16 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/ide.h.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h include/linux/if_ether.h - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/if_ether.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h include/linux/if_fddi.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/if_fddi.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/linux/if_tr.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/if_tr.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/linux/if_vlan.h - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/if_vlan.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h include/linux/iso_fs.h - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/iso_fs.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h include/linux/mman.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/mman.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/linux/ncp.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/ncp.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/linux/ncp_fs.h - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/ncp_fs.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h include/linux/ncp_fs_i.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/ncp_fs_i.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/linux/ncp_no.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/ncp_no.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/linux/netfilter_bridge/ebt_802_3.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/netfilter_bridge/ebt_802_3.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/linux/notifier.h - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/notifier.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h include/linux/percpu.h - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/percpu.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h include/linux/quotaio_v2.h - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/quotaio_v2.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h include/linux/romfs_fs.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/romfs_fs.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/linux/sched.h - 1.11 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/sched.h.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h include/linux/skbuff.h - 1.9 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/skbuff.h.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h include/linux/sunrpc/auth_gss.h - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/sunrpc/auth_gss.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h include/linux/sysctl.h - 1.19 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/sysctl.h.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h include/linux/time.h - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/time.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h include/linux/timex.h - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/timex.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h include/linux/tty.h - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/tty.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h include/linux/ufs_fs.h - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/ufs_fs.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h include/linux/ufs_fs_i.h - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/ufs_fs_i.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h include/linux/umem.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/umem.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/linux/usb_ch9.h - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/usb_ch9.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/net/inet_ecn.h - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/net/inet_ecn.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/net/llc_pdu.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/net/llc_pdu.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/net/pkt_sched.h - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/net/pkt_sched.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h include/net/tcp.h - 1.9 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/net/tcp.h.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h include/pcmcia/ss.h - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/pcmcia/ss.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h include/sound/asequencer.h - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/sound/asequencer.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h include/sound/pcm.h - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/sound/pcm.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h include/sound/pcm_oss.h - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/sound/pcm_oss.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/sound/seq_kernel.h - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/sound/seq_kernel.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h init/main.c - 1.19 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/init/main.c.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h kernel/cpu.c - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/kernel/cpu.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h kernel/power/console.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/kernel/power/console.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h kernel/power/swsusp.c - 1.9 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/kernel/power/swsusp.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h kernel/sched.c - 1.18 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/kernel/sched.c.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h kernel/timer.c - 1.9 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/kernel/timer.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h mm/mlock.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/mm/mlock.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h mm/mmap.c - 1.12 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/mm/mmap.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h mm/nommu.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/mm/nommu.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h mm/slab.c - 1.10 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/mm/slab.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h mm/vmscan.c - 1.10 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/mm/vmscan.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h net/8021q/vlan.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/8021q/vlan.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h net/8021q/vlan_dev.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/8021q/vlan_dev.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h net/atm/br2684.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/atm/br2684.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h net/atm/clip.c - 1.9 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/atm/clip.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h net/bridge/br_input.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/bridge/br_input.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h net/bridge/br_netfilter.c - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/bridge/br_netfilter.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h net/bridge/netfilter/ebt_802_3.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/bridge/netfilter/ebt_802_3.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h net/bridge/netfilter/ebt_among.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/bridge/netfilter/ebt_among.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h net/bridge/netfilter/ebt_arp.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/bridge/netfilter/ebt_arp.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h net/bridge/netfilter/ebt_arpreply.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/bridge/netfilter/ebt_arpreply.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h net/bridge/netfilter/ebt_dnat.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/bridge/netfilter/ebt_dnat.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h net/bridge/netfilter/ebt_ip.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/bridge/netfilter/ebt_ip.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h net/bridge/netfilter/ebt_log.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/bridge/netfilter/ebt_log.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h net/bridge/netfilter/ebt_redirect.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/bridge/netfilter/ebt_redirect.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h net/bridge/netfilter/ebt_snat.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/bridge/netfilter/ebt_snat.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h net/bridge/netfilter/ebt_vlan.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/bridge/netfilter/ebt_vlan.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h net/bridge/netfilter/ebtables.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/bridge/netfilter/ebtables.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h net/core/Makefile - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/core/Makefile.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h net/core/dv.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/core/dv.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h net/core/neighbour.c - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/core/neighbour.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h net/decnet/dn_neigh.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/decnet/dn_neigh.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h net/ethernet/eth.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ethernet/eth.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h net/ipv4/af_inet.c - 1.8 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv4/af_inet.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h net/ipv4/arp.c - 1.9 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv4/arp.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h net/ipv4/ip_gre.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv4/ip_gre.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h net/ipv4/ip_output.c - 1.9 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv4/ip_output.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h net/ipv4/ipconfig.c - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv4/ipconfig.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h net/ipv4/ipip.c - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv4/ipip.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h net/ipv4/ipvs/ip_vs_sync.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv4/ipvs/ip_vs_sync.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h net/ipv4/netfilter/ip_nat_helper.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv4/netfilter/ip_nat_helper.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h net/ipv4/netfilter/ipt_mac.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv4/netfilter/ipt_mac.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h net/ipv4/sysctl_net_ipv4.c - 1.8 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv4/sysctl_net_ipv4.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h net/ipv4/tcp.c - 1.9 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv4/tcp.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h net/ipv4/tcp_diag.c - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv4/tcp_diag.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h net/ipv4/tcp_input.c - 1.8 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv4/tcp_input.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h net/ipv4/tcp_ipv4.c - 1.8 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv4/tcp_ipv4.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h net/ipv4/tcp_output.c - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv4/tcp_output.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h net/ipv6/af_inet6.c - 1.9 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv6/af_inet6.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h net/ipv6/netfilter/ip6t_eui64.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv6/netfilter/ip6t_eui64.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h net/ipv6/netfilter/ip6t_mac.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv6/netfilter/ip6t_mac.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h net/ipv6/reassembly.c - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv6/reassembly.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h net/ipv6/route.c - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv6/route.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h net/ipv6/sit.c - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv6/sit.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h net/llc/llc_input.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/llc/llc_input.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h net/llc/llc_output.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/llc/llc_output.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h net/sched/cls_api.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/sched/cls_api.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h net/sched/cls_fw.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/sched/cls_fw.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h net/sched/cls_u32.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/sched/cls_u32.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h net/sched/estimator.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/sched/estimator.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h net/sched/sch_cbq.c - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/sched/sch_cbq.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h security/commoncap.c - 1.8 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/security/commoncap.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h security/dummy.c - 1.9 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/security/dummy.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h security/selinux/hooks.c - 1.11 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/security/selinux/hooks.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h sound/pci/intel8x0.c - 1.8 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/sound/pci/intel8x0.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h drivers/usb/misc/legousbtower.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/misc/legousbtower.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/scsi/qla2xxx/qla_init.c - 1.8 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/qla2xxx/qla_init.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h arch/ppc64/mm/hash_low.S - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ppc64/mm/hash_low.S.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h arch/ppc64/kernel/pmac_pci.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ppc64/kernel/pmac_pci.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/ppc64/kernel/pmac_feature.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ppc64/kernel/pmac_feature.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/ppc64/kernel/idle_power4.S - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ppc64/kernel/idle_power4.S.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/ppc64/configs/g5_defconfig - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ppc64/configs/g5_defconfig.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h drivers/pci/hotplug/shpchp_ctrl.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/pci/hotplug/shpchp_ctrl.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/s390/block/dcssblk.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/s390/block/dcssblk.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/s390/cio/cmf.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/s390/cio/cmf.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h fs/hfs/btree.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/hfs/btree.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h fs/hfs/hfs_fs.h - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/hfs/hfs_fs.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h fs/hfsplus/bfind.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/hfsplus/bfind.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h fs/hfsplus/bitmap.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/hfsplus/bitmap.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h fs/hfsplus/bnode.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/hfsplus/bnode.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h fs/hfsplus/brec.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/hfsplus/brec.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h fs/hfsplus/btree.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/hfsplus/btree.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h fs/hfsplus/catalog.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/hfsplus/catalog.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h fs/hfsplus/extents.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/hfsplus/extents.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h fs/hfsplus/hfsplus_raw.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/hfsplus/hfsplus_raw.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h fs/hfsplus/part_tbl.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/hfsplus/part_tbl.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h fs/hfsplus/wrapper.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/hfsplus/wrapper.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/arm/mm/proc-v6.S - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/mm/proc-v6.S.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/x86_64/kernel/mce.c - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/x86_64/kernel/mce.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h arch/s390/appldata/appldata_mem.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/s390/appldata/appldata_mem.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/i386/pci/mmconfig.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/i386/pci/mmconfig.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/net/wireless/prism54/isl_38xx.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/wireless/prism54/isl_38xx.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/net/wireless/prism54/isl_38xx.h - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/wireless/prism54/isl_38xx.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/net/wireless/prism54/islpci_dev.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/wireless/prism54/islpci_dev.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/net/wireless/prism54/islpci_dev.h - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/wireless/prism54/islpci_dev.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/macintosh/therm_adt746x.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/macintosh/therm_adt746x.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/firmware/Kconfig - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/firmware/Kconfig.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/char/agp/intel-mch-agp.c - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/char/agp/intel-mch-agp.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h net/core/netpoll.c - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/core/netpoll.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h split-patches/dmapi-enable - 1.10 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/split-patches/dmapi-enable.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h arch/arm/mach-s3c2410/Makefile - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/mach-s3c2410/Makefile.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/arm/mach-s3c2410/irq.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/mach-s3c2410/irq.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/arm/mach-s3c2410/mach-bast.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/mach-s3c2410/mach-bast.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/arm/mach-s3c2410/mach-vr1000.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/mach-s3c2410/mach-vr1000.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/media/dvb/dvb-core/dvb_ca_en50221.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/dvb/dvb-core/dvb_ca_en50221.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/net/s2io.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/s2io.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/s390/net/qeth_main.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/s390/net/qeth_main.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/serial/amba-pl011.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/serial/amba-pl011.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/serial/bast_sio.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/serial/bast_sio.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/serial/s3c2410.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/serial/s3c2410.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h include/asm-arm/arch-s3c2410/bast-irq.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-arm/arch-s3c2410/bast-irq.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/asm-arm/arch-s3c2410/hardware.h - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-arm/arch-s3c2410/hardware.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-arm/arch-s3c2410/regs-gpio.h - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-arm/arch-s3c2410/regs-gpio.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h include/asm-x86_64/msi.h - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-x86_64/msi.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/ppc/syslib/ibm44x_common.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ppc/syslib/ibm44x_common.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/char/drm/drm_irq.h - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/char/drm/drm_irq.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/mtd/maps/ixp4xx.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/mtd/maps/ixp4xx.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h fs/reiserfs/xattr_acl.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/reiserfs/xattr_acl.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h fs/reiserfs/xattr_security.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/reiserfs/xattr_security.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h fs/reiserfs/xattr_trusted.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/reiserfs/xattr_trusted.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h fs/reiserfs/xattr_user.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/reiserfs/xattr_user.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/net/via-velocity.h - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/via-velocity.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/net/via-velocity.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/via-velocity.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h Documentation/powerpc/mpc52xx.txt - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/Documentation/powerpc/mpc52xx.txt.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/usb/class/cdc-acm.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/class/cdc-acm.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/char/hpet.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/char/hpet.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/block/sx8.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/block/sx8.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h net/sched/act_api.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/sched/act_api.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/arm/mach-integrator/clock.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/mach-integrator/clock.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/arm/mach-s3c2410/gpio.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/mach-s3c2410/gpio.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h include/asm-arm/hardware/clock.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-arm/hardware/clock.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/asm-arm/mach/time.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-arm/mach/time.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/arm/mach-versatile/clock.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/mach-versatile/clock.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/asm-ppc/mpc52xx.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-ppc/mpc52xx.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/asm-ppc/mpc52xx_psc.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-ppc/mpc52xx_psc.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/ppc/syslib/mpc52xx_setup.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ppc/syslib/mpc52xx_setup.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/ppc/syslib/mpc52xx_pic.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ppc/syslib/mpc52xx_pic.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/ppc/platforms/mpc5200.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ppc/platforms/mpc5200.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/ppc/platforms/lite5200.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ppc/platforms/lite5200.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h split-patches/kdb-i386-4.4-2 - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/split-patches/kdb-i386-4.4-2.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h split-patches/kdb-common-v4.4-2 - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/split-patches/kdb-common-v4.4-2.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h Documentation/arm/Samsung-S3C24XX/EB2410ITX.txt - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/Documentation/arm/Samsung-S3C24XX/EB2410ITX.txt.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h Documentation/arm/Samsung-S3C24XX/Overview.txt - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/Documentation/arm/Samsung-S3C24XX/Overview.txt.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h kernel/kprobes.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/kernel/kprobes.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h Documentation/tty.txt - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/Documentation/tty.txt.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/asm-m32r/spinlock.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-m32r/spinlock.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/asm-m32r/semaphore.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-m32r/semaphore.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/asm-m32r/m32r_mp_fpga.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-m32r/m32r_mp_fpga.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/asm-m32r/m32r.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-m32r/m32r.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/asm-m32r/m32102.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-m32r/m32102.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/arm/mach-imx/time.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/mach-imx/time.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/asm-m32r/io.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-m32r/io.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/asm-m32r/hardirq.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-m32r/hardirq.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/arm/mach-iop3xx/iop331-pci.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/mach-iop3xx/iop331-pci.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/asm-m32r/bitops.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-m32r/bitops.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h fs/hostfs/hostfs_user.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/hostfs/hostfs_user.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h fs/hostfs/hostfs_kern.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/hostfs/hostfs_kern.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h fs/hostfs/hostfs.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/hostfs/hostfs.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/video/amba-clcd.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/video/amba-clcd.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/cpufreq/cpufreq_ondemand.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/cpufreq/cpufreq_ondemand.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/i386/kernel/kprobes.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/i386/kernel/kprobes.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/char/ipmi/ipmi_poweroff.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/char/ipmi/ipmi_poweroff.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/char/drm/i915_drv.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/char/drm/i915_drv.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/acpi/motherboard.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/acpi/motherboard.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/x86_64/Kconfig.debug - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/x86_64/Kconfig.debug.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/sparc64/kernel/kprobes.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/sparc64/kernel/kprobes.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/ppc64/mm/hash_native.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ppc64/mm/hash_native.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/m32r/mm/ioremap.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/m32r/mm/ioremap.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/m32r/mm/ioremap-nommu.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/m32r/mm/ioremap-nommu.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/m32r/m32700ut/m32r-flash.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/m32r/m32700ut/m32r-flash.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/m32r/Kconfig - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/m32r/Kconfig.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/m32r/Makefile - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/m32r/Makefile.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/m32r/drivers/Kconfig - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/m32r/drivers/Kconfig.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/m32r/drivers/Makefile - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/m32r/drivers/Makefile.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/m32r/drivers/cs_internal.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/m32r/drivers/cs_internal.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/m32r/drivers/ds1302.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/m32r/drivers/ds1302.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/m32r/drivers/m32r-pldsio.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/m32r/drivers/m32r-pldsio.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/m32r/drivers/m32r_cfc.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/m32r/drivers/m32r_cfc.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/m32r/drivers/m32r_cfc.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/m32r/drivers/m32r_cfc.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/m32r/drivers/m32r_pcc.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/m32r/drivers/m32r_pcc.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/m32r/drivers/m32r_pcc.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/m32r/drivers/m32r_pcc.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/m32r/drivers/m5.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/m32r/drivers/m5.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/m32r/drivers/m5.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/m32r/drivers/m5.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/m32r/drivers/m5drv.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/m32r/drivers/m5drv.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/m32r/kernel/entry.S - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/m32r/kernel/entry.S.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/m32r/kernel/io_m32102.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/m32r/kernel/io_m32102.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/m32r/kernel/irq.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/m32r/kernel/irq.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/m32r/kernel/setup.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/m32r/kernel/setup.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/m32r/kernel/setup_m32700ut.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/m32r/kernel/setup_m32700ut.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/m32r/kernel/setup_mappi.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/m32r/kernel/setup_mappi.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/m32r/kernel/setup_mappi2.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/m32r/kernel/setup_mappi2.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/m32r/kernel/setup_oaks32r.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/m32r/kernel/setup_oaks32r.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/m32r/kernel/setup_opsput.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/m32r/kernel/setup_opsput.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/m32r/kernel/setup_usrv.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/m32r/kernel/setup_usrv.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/m32r/kernel/signal.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/m32r/kernel/signal.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/m32r/kernel/smp.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/m32r/kernel/smp.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h From owner-linux-xfs Mon Oct 11 17:13:07 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 11 Oct 2004 17:13:09 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i9C0D5pq005868 for ; Mon, 11 Oct 2004 17:13: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 KAA01835; Tue, 12 Oct 2004 10:12:45 +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 i9C0Chln4978499; Tue, 12 Oct 2004 10:12:43 +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 i9C0BcOm004443; Tue, 12 Oct 2004 10:11:38 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i9C0Ba9D004441; Tue, 12 Oct 2004 10:11:36 +1000 Date: Tue, 12 Oct 2004 10:11:36 +1000 From: Nathan Scott To: Chris Evert Cc: linux-xfs@oss.sgi.com Subject: Re: possible deadlock in kmem_alloc (mode:0x50) Message-ID: <20041012001136.GC1826@frodo> References: <4159FFCC.9000708@geodev.com> <20040929111143.G4413387@wobbly.melbourne.sgi.com> <416AB1C1.30108@geodev.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <416AB1C1.30108@geodev.com> User-Agent: Mutt/1.5.3i X-archive-position: 4274 X-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 On Mon, Oct 11, 2004 at 11:16:01AM -0500, Chris Evert wrote: > Nathan Scott wrote: > > > >/proc/slabinfo will hold some clues, send it over this way. Oh, another useful tidbit is /proc/meminfo. > I bumped /proc/sys/vm/vfs_cache_pressure to 150 and that seemed to work > til this weekend. > > A snapshot of /proc/slabinfo during this time: Hmmm, well, these are your big slab users... > slabinfo - version: 2.0 > # name > : tunables : slabdata > > ext3_inode_cache 6898 17840 512 8 1 : tunables 54 27 > 8 : slabdata 2230 2230 0 > radix_tree_node 35085 46284 276 14 1 : tunables 54 27 > 8 : slabdata 3306 3306 0 > inode_cache 2054 2080 384 10 1 : tunables 54 27 > 8 : slabdata 208 208 0 > dentry_cache 10215 26468 152 26 1 : tunables 120 60 > 8 : slabdata 1018 1018 0 > buffer_head 486022 486525 52 75 1 : tunables 120 60 > 8 : slabdata 6487 6487 0 XFS seems to be playing ball and giving back slab cache memory when asked to do so - ext3 is holding onto a fair bit, and I can't tell who's used all those buffer heads - its the VMs responsibility to get rid of those, with help from individual filesystems. cheers. -- Nathan From owner-linux-xfs Tue Oct 12 16:45:46 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 12 Oct 2004 16:45:50 -0700 (PDT) Received: from gateway2.geodev.com (IDENT:WB082WOpVFe2YFaBYy+sWL49XIRW6jso@gateway2.geodev.com [64.45.165.170]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9CNjjxv015836 for ; Tue, 12 Oct 2004 16:45:45 -0700 Received: from [192.168.201.127] (fiste.geodev.com [192.168.201.127]) (authenticated) by gateway2.geodev.com (8.11.6/8.11.6) with ESMTP id i9CNiqM21103; Tue, 12 Oct 2004 18:44:52 -0500 Message-ID: <416C6C75.3080700@geodev.com> Date: Tue, 12 Oct 2004 18:44:53 -0500 From: Chris Evert User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nathan Scott CC: linux-xfs@oss.sgi.com Subject: Re: possible deadlock in kmem_alloc (mode:0x50) References: <4159FFCC.9000708@geodev.com> <20040929111143.G4413387@wobbly.melbourne.sgi.com> <416AB1C1.30108@geodev.com> <20041012001136.GC1826@frodo> In-Reply-To: <20041012001136.GC1826@frodo> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4275 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: chris@geodev.com Precedence: bulk X-list: linux-xfs Nathan Scott wrote: > On Mon, Oct 11, 2004 at 11:16:01AM -0500, Chris Evert wrote: > >>Nathan Scott wrote: >> >>>/proc/slabinfo will hold some clues, send it over this way. > > > Oh, another useful tidbit is /proc/meminfo. > > > XFS seems to be playing ball and giving back slab cache memory > when asked to do so - ext3 is holding onto a fair bit, and I > can't tell who's used all those buffer heads - its the VMs > responsibility to get rid of those, with help from individual > filesystems. Ironically, the only ext3 fs is /, which holds /var/log/messages, which is getting a lot of I/O... I have a second system which experienced the same problem and I grabbed meminfo as well as slabinfo: MemTotal: 4154356 kB MemFree: 18772 kB Buffers: 91232 kB Cached: 3794960 kB SwapCached: 3928 kB Active: 570212 kB Inactive: 3325868 kB HighTotal: 163776 kB HighFree: 832 kB LowTotal: 3990580 kB LowFree: 17940 kB SwapTotal: 2047744 kB SwapFree: 2011904 kB Dirty: 10448 kB Writeback: 0 kB Mapped: 12256 kB Slab: 122640 kB Committed_AS: 161152 kB PageTables: 2640 kB VmallocTotal: 106488 kB VmallocUsed: 103804 kB VmallocChunk: 128 kB HugePages_Total: 0 HugePages_Free: 0 Hugepagesize: 2048 kB slabinfo - version: 2.0 # name : tunables : slabdata nfs_write_data 36 42 512 7 1 : tunables 54 27 8 : slabdata 6 6 0 nfs_read_data 32 35 512 7 1 : tunables 54 27 8 : slabdata 5 5 0 nfs_inode_cache 20 42 640 6 1 : tunables 54 27 8 : slabdata 7 7 0 nfs_page 0 0 128 31 1 : tunables 120 60 8 : slabdata 0 0 0 xfrm6_tunnel_spi 0 0 64 61 1 : tunables 120 60 8 : slabdata 0 0 0 fib6_nodes 5 119 32 119 1 : tunables 120 60 8 : slabdata 1 1 0 ip6_dst_cache 11 30 256 15 1 : tunables 120 60 8 : slabdata 2 2 0 ndisc_cache 1 15 256 15 1 : tunables 120 60 8 : slabdata 1 1 0 raw6_sock 0 0 768 5 1 : tunables 54 27 8 : slabdata 0 0 0 udp6_sock 0 0 768 5 1 : tunables 54 27 8 : slabdata 0 0 0 tcp6_sock 11 15 1280 3 1 : tunables 24 12 8 : slabdata 5 5 0 bt_sock 3 14 512 7 1 : tunables 54 27 8 : slabdata 2 2 0 rpc_buffers 8 8 2048 2 1 : tunables 24 12 8 : slabdata 4 4 0 rpc_tasks 8 15 256 15 1 : tunables 120 60 8 : slabdata 1 1 0 rpc_inode_cache 8 14 512 7 1 : tunables 54 27 8 : slabdata 2 2 0 ip_fib_hash 24 226 16 226 1 : tunables 120 60 8 : slabdata 1 1 0 xfs_acl 0 0 304 13 1 : tunables 54 27 8 : slabdata 0 0 0 xfs_chashlist 94 185 20 185 1 : tunables 120 60 8 : slabdata 1 1 0 xfs_ili 1650 1708 140 28 1 : tunables 120 60 8 : slabdata 61 61 0 xfs_ifork 0 0 56 70 1 : tunables 120 60 8 : slabdata 0 0 0 xfs_efi_item 0 0 260 15 1 : tunables 54 27 8 : slabdata 0 0 0 xfs_efd_item 0 0 260 15 1 : tunables 54 27 8 : slabdata 0 0 0 xfs_buf_item 0 0 148 27 1 : tunables 120 60 8 : slabdata 0 0 0 xfs_dabuf 0 0 16 226 1 : tunables 120 60 8 : slabdata 0 0 0 xfs_da_state 0 0 336 12 1 : tunables 54 27 8 : slabdata 0 0 0 xfs_trans 38 150 600 6 1 : tunables 54 27 8 : slabdata 25 25 0 xfs_inode 2147 2200 384 10 1 : tunables 54 27 8 : slabdata 220 220 0 xfs_btree_cur 0 0 140 28 1 : tunables 120 60 8 : slabdata 0 0 0 xfs_bmap_free_item 0 0 16 226 1 : tunables 120 60 8 : slabdata 0 0 0 xfs_buf_t 40 135 256 15 1 : tunables 120 60 8 : slabdata 9 9 0 linvfs_icache 2147 2200 384 10 1 : tunables 54 27 8 : slabdata 220 220 0 uhci_urb_priv 0 0 44 88 1 : tunables 120 60 8 : slabdata 0 0 0 ext3_inode_cache 3839 17712 512 8 1 : tunables 54 27 8 : slabdata 2214 2214 0 ext3_xattr 0 0 48 81 1 : tunables 120 60 8 : slabdata 0 0 0 journal_handle 16 135 28 135 1 : tunables 120 60 8 : slabdata 1 1 0 journal_head 5277 45279 48 81 1 : tunables 120 60 8 : slabdata 559 559 30 revoke_table 24 290 12 290 1 : tunables 120 60 8 : slabdata 1 1 0 revoke_record 0 0 16 226 1 : tunables 120 60 8 : slabdata 0 0 0 dm_tio 2560 2712 16 226 1 : tunables 120 60 8 : slabdata 12 12 0 dm_io 2560 2712 16 226 1 : tunables 120 60 8 : slabdata 12 12 0 qla2xxx_srbs 256 310 128 31 1 : tunables 120 60 8 : slabdata 10 10 0 scsi_cmd_cache 5 20 384 10 1 : tunables 54 27 8 : slabdata 2 2 0 sgpool-128 32 33 2560 3 2 : tunables 24 12 8 : slabdata 11 11 0 sgpool-64 32 33 1280 3 1 : tunables 24 12 8 : slabdata 11 11 0 sgpool-32 32 36 640 6 1 : tunables 54 27 8 : slabdata 6 6 0 sgpool-16 32 40 384 10 1 : tunables 54 27 8 : slabdata 4 4 0 sgpool-8 32 45 256 15 1 : tunables 120 60 8 : slabdata 3 3 0 unix_sock 27 63 512 7 1 : tunables 54 27 8 : slabdata 9 9 0 ip_mrt_cache 0 0 128 31 1 : tunables 120 60 8 : slabdata 0 0 0 tcp_tw_bucket 7 31 128 31 1 : tunables 120 60 8 : slabdata 1 1 0 tcp_bind_bucket 29 226 16 226 1 : tunables 120 60 8 : slabdata 1 1 0 tcp_open_request 4 31 128 31 1 : tunables 120 60 8 : slabdata 1 1 0 inet_peer_cache 2 61 64 61 1 : tunables 120 60 8 : slabdata 1 1 0 secpath_cache 0 0 128 31 1 : tunables 120 60 8 : slabdata 0 0 0 xfrm_dst_cache 0 0 256 15 1 : tunables 120 60 8 : slabdata 0 0 0 ip_dst_cache 2092 2160 256 15 1 : tunables 120 60 8 : slabdata 144 144 0 arp_cache 6 30 256 15 1 : tunables 120 60 8 : slabdata 2 2 0 raw4_sock 0 0 640 6 1 : tunables 54 27 8 : slabdata 0 0 0 udp_sock 11 24 640 6 1 : tunables 54 27 8 : slabdata 4 4 0 tcp_sock 226 238 1152 7 2 : tunables 24 12 8 : slabdata 34 34 0 flow_cache 0 0 128 31 1 : tunables 120 60 8 : slabdata 0 0 0 mqueue_inode_cache 1 6 640 6 1 : tunables 54 27 8 : slabdata 1 1 0 isofs_inode_cache 0 0 384 10 1 : tunables 54 27 8 : slabdata 0 0 0 hugetlbfs_inode_cache 1 11 348 11 1 : tunables 54 27 8 : slabdata 1 1 0 ext2_inode_cache 0 0 512 7 1 : tunables 54 27 8 : slabdata 0 0 0 ext2_xattr 0 0 48 81 1 : tunables 120 60 8 : slabdata 0 0 0 dquot 0 0 144 27 1 : tunables 120 60 8 : slabdata 0 0 0 eventpoll_pwq 0 0 36 107 1 : tunables 120 60 8 : slabdata 0 0 0 eventpoll_epi 0 0 128 31 1 : tunables 120 60 8 : slabdata 0 0 0 kioctx 0 0 256 15 1 : tunables 120 60 8 : slabdata 0 0 0 kiocb 0 0 128 31 1 : tunables 120 60 8 : slabdata 0 0 0 dnotify_cache 2 185 20 185 1 : tunables 120 60 8 : slabdata 1 1 0 file_lock_cache 3 39 100 39 1 : tunables 120 60 8 : slabdata 1 1 0 fasync_cache 0 0 16 226 1 : tunables 120 60 8 : slabdata 0 0 0 shmem_inode_cache 6 7 512 7 1 : tunables 54 27 8 : slabdata 1 1 0 posix_timers_cache 0 0 112 35 1 : tunables 120 60 8 : slabdata 0 0 0 uid_cache 14 61 64 61 1 : tunables 120 60 8 : slabdata 1 1 0 cfq_pool 84 476 32 119 1 : tunables 120 60 8 : slabdata 4 4 0 crq_pool 43 288 40 96 1 : tunables 120 60 8 : slabdata 3 3 0 deadline_drq 0 0 52 75 1 : tunables 120 60 8 : slabdata 0 0 0 as_arq 0 0 64 61 1 : tunables 120 60 8 : slabdata 0 0 0 blkdev_ioc 136 185 20 185 1 : tunables 120 60 8 : slabdata 1 1 0 blkdev_queue 37 48 480 8 1 : tunables 54 27 8 : slabdata 6 6 0 blkdev_requests 43 175 160 25 1 : tunables 120 60 8 : slabdata 7 7 0 biovec-(256) 256 256 3072 2 2 : tunables 24 12 8 : slabdata 128 128 0 biovec-128 256 260 1536 5 2 : tunables 24 12 8 : slabdata 52 52 0 biovec-64 256 260 768 5 1 : tunables 54 27 8 : slabdata 52 52 0 biovec-16 256 270 256 15 1 : tunables 120 60 8 : slabdata 18 18 0 biovec-4 256 305 64 61 1 : tunables 120 60 8 : slabdata 5 5 0 biovec-1 324 452 16 226 1 : tunables 120 60 8 : slabdata 2 2 30 bio 347 372 128 31 1 : tunables 120 60 8 : slabdata 12 12 0 sock_inode_cache 276 308 512 7 1 : tunables 54 27 8 : slabdata 44 44 0 skbuff_head_cache 5907 5940 256 15 1 : tunables 120 60 8 : slabdata 396 396 0 sock 5 10 384 10 1 : tunables 54 27 8 : slabdata 1 1 0 proc_inode_cache 1347 1360 384 10 1 : tunables 54 27 8 : slabdata 136 136 0 sigqueue 10 54 148 27 1 : tunables 120 60 8 : slabdata 2 2 0 radix_tree_node 46441 53382 276 14 1 : tunables 54 27 8 : slabdata 3813 3813 0 bdev_cache 25 28 512 7 1 : tunables 54 27 8 : slabdata 4 4 0 mnt_cache 47 93 128 31 1 : tunables 120 60 8 : slabdata 3 3 0 inode_cache 2718 2730 384 10 1 : tunables 54 27 8 : slabdata 273 273 0 dentry_cache 10005 29484 152 26 1 : tunables 120 60 8 : slabdata 1134 1134 0 filp 886 960 256 15 1 : tunables 120 60 8 : slabdata 63 64 0 names_cache 5 5 4096 1 1 : tunables 24 12 8 : slabdata 5 5 0 idr_layer_cache 74 87 136 29 1 : tunables 120 60 8 : slabdata 3 3 0 buffer_head 523608 587025 52 75 1 : tunables 120 60 8 : slabdata 7827 7827 14 mm_struct 91 105 768 5 1 : tunables 54 27 8 : slabdata 21 21 0 vm_area_struct 2472 2565 88 45 1 : tunables 120 60 8 : slabdata 57 57 0 fs_cache 157 305 64 61 1 : tunables 120 60 8 : slabdata 5 5 0 files_cache 95 119 512 7 1 : tunables 54 27 8 : slabdata 17 17 0 signal_cache 212 279 128 31 1 : tunables 120 60 8 : slabdata 9 9 0 sighand_cache 213 215 1408 5 2 : tunables 24 12 8 : slabdata 43 43 0 task_struct 358 360 1472 5 2 : tunables 24 12 8 : slabdata 72 72 0 anon_vma 1040 1130 16 226 1 : tunables 120 60 8 : slabdata 5 5 0 pgd 89 357 32 119 1 : tunables 120 60 8 : slabdata 3 3 0 kpmd 73 73 4096 1 1 : tunables 24 12 8 : slabdata 73 73 0 pmd 227 227 4096 1 1 : tunables 24 12 8 : slabdata 227 227 0 size-131072(DMA) 0 0 131072 1 32 : tunables 8 4 0 : slabdata 0 0 0 size-131072 28 28 131072 1 32 : tunables 8 4 0 : slabdata 28 28 0 size-65536(DMA) 0 0 65536 1 16 : tunables 8 4 0 : slabdata 0 0 0 size-65536 158 158 65536 1 16 : tunables 8 4 0 : slabdata 158 158 0 size-32768(DMA) 0 0 32768 1 8 : tunables 8 4 0 : slabdata 0 0 0 size-32768 75 75 32768 1 8 : tunables 8 4 0 : slabdata 75 75 0 size-16384(DMA) 0 0 16384 1 4 : tunables 8 4 0 : slabdata 0 0 0 size-16384 45 45 16384 1 4 : tunables 8 4 0 : slabdata 45 45 0 size-8192(DMA) 0 0 8192 1 2 : tunables 8 4 0 : slabdata 0 0 0 size-8192 76 76 8192 1 2 : tunables 8 4 0 : slabdata 76 76 0 size-4096(DMA) 0 0 4096 1 1 : tunables 24 12 8 : slabdata 0 0 0 size-4096 6123 6123 4096 1 1 : tunables 24 12 8 : slabdata 6123 6123 0 size-2048(DMA) 0 0 2048 2 1 : tunables 24 12 8 : slabdata 0 0 0 size-2048 276 276 2048 2 1 : tunables 24 12 8 : slabdata 138 138 0 size-1620(DMA) 0 0 1664 4 2 : tunables 24 12 8 : slabdata 0 0 0 size-1620 54 56 1664 4 2 : tunables 24 12 8 : slabdata 14 14 0 size-1024(DMA) 0 0 1024 4 1 : tunables 54 27 8 : slabdata 0 0 0 size-1024 332 332 1024 4 1 : tunables 54 27 8 : slabdata 83 83 0 size-512(DMA) 0 0 512 8 1 : tunables 54 27 8 : slabdata 0 0 0 size-512 687 2536 512 8 1 : tunables 54 27 8 : slabdata 317 317 0 size-256(DMA) 0 0 256 15 1 : tunables 120 60 8 : slabdata 0 0 0 size-256 7305 7305 256 15 1 : tunables 120 60 8 : slabdata 487 487 0 size-128(DMA) 0 0 128 31 1 : tunables 120 60 8 : slabdata 0 0 0 size-128 3550 4960 128 31 1 : tunables 120 60 8 : slabdata 160 160 0 size-64(DMA) 0 0 64 61 1 : tunables 120 60 8 : slabdata 0 0 0 size-64 7280 18117 64 61 1 : tunables 120 60 8 : slabdata 297 297 0 size-32(DMA) 0 0 32 119 1 : tunables 120 60 8 : slabdata 0 0 0 size-32 16170 20230 32 119 1 : tunables 120 60 8 : slabdata 170 170 30 kmem_cache 165 165 256 15 1 : tunables 120 60 8 : slabdata 11 11 0 Regards, Chris From owner-linux-xfs Tue Oct 12 17:24:21 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 12 Oct 2004 17:24:23 -0700 (PDT) Received: from snort.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9D0OKG3018308 for ; Tue, 12 Oct 2004 17:24:21 -0700 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i9D0O0xu33559408 for ; Wed, 13 Oct 2004 10:24:00 +1000 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i9D0NxnT36353128 for linux-xfs@oss.sgi.com; Wed, 13 Oct 2004 10:23:59 +1000 (EST) Date: Wed, 13 Oct 2004 10:23:59 +1000 (EST) From: Nathan Scott Message-Id: <200410130023.i9D0NxnT36353128@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE 907752 - xfsdump X-archive-position: 4276 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Bump xfsdump version to deal with a mixup from a fix coming in via LBS. Date: Tue Oct 12 17:23:04 PDT 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/us-xfs-cmds Inspected by: wkendall The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:180816a xfsdump/VERSION - 1.66 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/VERSION.diff?r1=text&tr1=1.66&r2=text&tr2=1.65&f=h xfsdump/doc/CHANGES - 1.73 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/doc/CHANGES.diff?r1=text&tr1=1.73&r2=text&tr2=1.72&f=h xfsdump/debian/changelog - 1.52 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/debian/changelog.diff?r1=text&tr1=1.52&r2=text&tr2=1.51&f=h From owner-linux-xfs Tue Oct 12 19:03:30 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 12 Oct 2004 19:03:32 -0700 (PDT) Received: from snort.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9D23Tmd021067 for ; Tue, 12 Oct 2004 19:03:30 -0700 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i9D239xu36433489 for ; Wed, 13 Oct 2004 12:03:10 +1000 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i9D238GG36546293 for linux-xfs@oss.sgi.com; Wed, 13 Oct 2004 12:03:08 +1000 (EST) Date: Wed, 13 Oct 2004 12:03:08 +1000 (EST) From: Nathan Scott Message-Id: <200410130203.i9D238GG36546293@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE 918834 - fix laptop mode X-archive-position: 4277 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Fix regression when running in laptop mode, causes hangs on sync. Date: Wed Oct 13 12:02:44 AEST 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-linux Inspected by: kaos@sgi.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:19744a linux-2.6/xfs_super.c - 1.318 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_super.c.diff?r1=text&tr1=1.318&r2=text&tr2=1.317&f=h From owner-linux-xfs Tue Oct 12 22:46:42 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 12 Oct 2004 22:46:47 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i9D5keRr007659 for ; Tue, 12 Oct 2004 22:46:41 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA06776; Wed, 13 Oct 2004 15:46:16 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i9D5kCln4988549; Wed, 13 Oct 2004 15:46:12 +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 i9D5j2FD001916; Wed, 13 Oct 2004 15:45:02 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i9D5irku001914; Wed, 13 Oct 2004 15:44:53 +1000 Date: Wed, 13 Oct 2004 15:44:52 +1000 From: Nathan Scott To: Andrew Morton , Nick Piggin Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-xfs@oss.sgi.com Subject: Page cache write performance issue Message-ID: <20041013054452.GB1618@frodo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.3i X-archive-position: 4278 X-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 Hi guys, I've noticed the following performance regression from between 2.6.8.1 and 2.6.9-rc. It seems to have a very pronounced affect on both ext2 and xfs. - single thread, writing (what should be) straight into the page cache, file size 1/2 of memory size (500MB vs 1GB), writes are in 1K chunks, most of memory is free, machine was just booted; - on 2.6.8 (and earlier 2.6 releases) I can typically get ~50MB/sec on this machine doing this; (or better with larger I/O sizes, but thats not the point here) - on 2.4.28-pre (and all 2.4 releases) I can typically get ~70MB/sec, presumably writeback kicks in earlier on 2.6; OK, I guess we can live with that... probably some tradeoff is being made there in the VM; - on 2.6.9-rc I can only get _4_MB/sec (ext2 or xfs); writeback commences very quickly, CPU utilisation drops way down (from 100% to <10%)... looks like we go slower cos we're initiating I/O almost from the start. Now if I bump up /proc/sys/vm/dirty_background_ratio and /proc/sys/vm/dirty_ratio from 40 to 80, I see the expected performance again (actually, I see the 2.4 performance, so the poorer early-2.6 numbers were probably due to I/O commencing at the tail end of all the writes, due to 50% being more than 40% :). But 2.6.8 had the same default dirty writeout ratios (40) as 2.6.9-rc does, didn't it? So, any ideas what happened to 2.6.9? Whats the rationale for commencing writeout earlier in 2.6 (even when there's so much free memory available)? Any chance we can get the defaults set to something much larger in the wake of the other 2.6.9 VM changes, so we don't regress here? thanks! -- Nathan From owner-linux-xfs Tue Oct 12 23:22:12 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 12 Oct 2004 23:22:14 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9D6MAVm008645 for ; Tue, 12 Oct 2004 23:22:11 -0700 Received: from bix (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i9D6LU932499; Tue, 12 Oct 2004 23:21:30 -0700 Date: Tue, 12 Oct 2004 23:19:45 -0700 From: Andrew Morton To: Nathan Scott Cc: piggin@cyberone.com.au, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-xfs@oss.sgi.com Subject: Re: Page cache write performance issue Message-Id: <20041012231945.2aff9a00.akpm@osdl.org> In-Reply-To: <20041013054452.GB1618@frodo> References: <20041013054452.GB1618@frodo> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4279 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: linux-xfs Nathan Scott wrote: > > So, any ideas what happened to 2.6.9? Does reverting the below fix it up? > Whats the rationale for commencing writeout earlier in 2.6 > (even when there's > so much free memory available)? There wasn't much rationale behind that patch - that's why I dropped it the first three times ;) I have no problem with making it four times. It could be that small values of unmapped_ratio are making background_ratio too small. --- a/mm/page-writeback.c 10 Aug 2004 04:16:17 -0000 1.43 +++ a/mm/page-writeback.c 13 Oct 2004 06:12:03 -0000 @@ -153,9 +153,11 @@ if (dirty_ratio < 5) dirty_ratio = 5; - background_ratio = dirty_background_ratio; - if (background_ratio >= dirty_ratio) - background_ratio = dirty_ratio / 2; + /* + * Keep the ratio between dirty_ratio and background_ratio roughly + * what the sysctls are after dirty_ratio has been scaled (above). + */ + background_ratio = dirty_background_ratio * dirty_ratio/vm_dirty_ratio; background = (background_ratio * total_pages) / 100; dirty = (dirty_ratio * total_pages) / 100; From owner-linux-xfs Tue Oct 12 23:41:36 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 12 Oct 2004 23:41:38 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i9D6fYnr009198 for ; Tue, 12 Oct 2004 23:41:35 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA07831; Wed, 13 Oct 2004 16:41:12 +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 i9D6f8ln5017382; Wed, 13 Oct 2004 16:41:09 +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 i9D6dwFD004536; Wed, 13 Oct 2004 16:39:59 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i9D6dtdu004534; Wed, 13 Oct 2004 16:39:55 +1000 Date: Wed, 13 Oct 2004 16:39:55 +1000 From: Nathan Scott To: Andrew Morton Cc: piggin@cyberone.com.au, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-xfs@oss.sgi.com Subject: Re: Page cache write performance issue Message-ID: <20041013063955.GA2079@frodo> References: <20041013054452.GB1618@frodo> <20041012231945.2aff9a00.akpm@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041012231945.2aff9a00.akpm@osdl.org> User-Agent: Mutt/1.5.3i X-archive-position: 4280 X-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 Hi Andrew, On Tue, Oct 12, 2004 at 11:19:45PM -0700, Andrew Morton wrote: > Nathan Scott wrote: > > > > So, any ideas what happened to 2.6.9? > > Does reverting the below fix it up? Reverting that one improves things slightly - I move up from ~4MB/sec to ~17MB/sec; thats just under a third of the 2.6.8 numbers I was seeing though, unfortunately. cheers. -- Nathan From owner-linux-xfs Wed Oct 13 00:04:17 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 13 Oct 2004 00:04:26 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9D74Gjj012205 for ; Wed, 13 Oct 2004 00:04:16 -0700 Received: from bix (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i9D73p904733; Wed, 13 Oct 2004 00:03:51 -0700 Date: Wed, 13 Oct 2004 00:02:06 -0700 From: Andrew Morton To: Nathan Scott Cc: piggin@cyberone.com.au, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-xfs@oss.sgi.com Subject: Re: Page cache write performance issue Message-Id: <20041013000206.680132ad.akpm@osdl.org> In-Reply-To: <20041013063955.GA2079@frodo> References: <20041013054452.GB1618@frodo> <20041012231945.2aff9a00.akpm@osdl.org> <20041013063955.GA2079@frodo> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4281 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: linux-xfs Nathan Scott wrote: > > Hi Andrew, > > On Tue, Oct 12, 2004 at 11:19:45PM -0700, Andrew Morton wrote: > > Nathan Scott wrote: > > > > > > So, any ideas what happened to 2.6.9? > > > > Does reverting the below fix it up? > > Reverting that one improves things slightly - I move up from > ~4MB/sec to ~17MB/sec; thats just under a third of the 2.6.8 > numbers I was seeing though, unfortunately. > Well something else if fishy: how can you possibly achieve only 4MB/sec? Using floppy disks or something? Does the same happen on ext2? It's exactly a 500MB write on a 1000MB machine, yes? From owner-linux-xfs Wed Oct 13 00:24:23 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 13 Oct 2004 00:24:29 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i9D7OL7J016141 for ; Wed, 13 Oct 2004 00:24:22 -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 RAA08847; Wed, 13 Oct 2004 17:23: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 i9D7Nuln5019659; Wed, 13 Oct 2004 17:23:56 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i9D7NraW4975161; Wed, 13 Oct 2004 17:23:53 +1000 (EST) Date: Wed, 13 Oct 2004 17:23:53 +1000 From: Nathan Scott To: Andrew Morton Cc: piggin@cyberone.com.au, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-xfs@oss.sgi.com Subject: Re: Page cache write performance issue Message-ID: <20041013172352.B4917536@wobbly.melbourne.sgi.com> References: <20041013054452.GB1618@frodo> <20041012231945.2aff9a00.akpm@osdl.org> <20041013063955.GA2079@frodo> <20041013000206.680132ad.akpm@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20041013000206.680132ad.akpm@osdl.org>; from akpm@osdl.org on Wed, Oct 13, 2004 at 12:02:06AM -0700 X-archive-position: 4282 X-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 On Wed, Oct 13, 2004 at 12:02:06AM -0700, Andrew Morton wrote: > > Well something else if fishy: how can you possibly achieve only 4MB/sec? These are 1K writes too remember, so it feels a bit like we write 'em out one at a time, sync (though no O_SYNC, or fsync, or such involved here). This is on an i686, so 4K pages, and using 4K filesystem blocksizes (both xfs and ext2). And now that you mention, yes, this is multiple times below the direct IO numbers too (which on this box are ~30MB/sec for direct blkdev writes, IIRC, & XFS has similar numbers). > Using floppy disks or something? Heh, uh, no. (and no, not "pencils" either ;) > Does the same happen on ext2? Yes. > It's exactly a 500MB write on a 1000MB machine, yes? Thats correct. No slab/page/.. debug options enabled either - its the same .config that was performing ~10x better on 2.6.8. I also verified that it wasn't any of the XFS changes either (they wouldn't have affected ext2 anyway, of course) - the same XFS code backported to 2.6.8 performs fine also. cheers. -- Nathan From owner-linux-xfs Wed Oct 13 01:15:54 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 13 Oct 2004 01:15:57 -0700 (PDT) Received: from mail.iinet.net.au (mail-03.iinet.net.au [203.59.3.35]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i9D8FrBl017559 for ; Wed, 13 Oct 2004 01:15:54 -0700 Received: (qmail 27139 invoked from network); 13 Oct 2004 08:15:33 -0000 Received: from unknown (HELO chimp.local.net) (203.173.3.251) by mail.iinet.net.au with SMTP; 13 Oct 2004 08:15:33 -0000 Received: from didi.local.net ([192.168.0.1]) by chimp.local.net with esmtp (Exim 4.34) id 1CHeIG-0000Yn-3k; Wed, 13 Oct 2004 18:15:32 +1000 Message-ID: <416CE423.3000607@cyberone.com.au> Date: Wed, 13 Oct 2004 18:15:31 +1000 From: Nick Piggin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040820 Debian/1.7.2-4 X-Accept-Language: en MIME-Version: 1.0 To: Nathan Scott CC: Andrew Morton , linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-xfs@oss.sgi.com Subject: Re: Page cache write performance issue References: <20041013054452.GB1618@frodo> <20041012231945.2aff9a00.akpm@osdl.org> <20041013063955.GA2079@frodo> <20041013000206.680132ad.akpm@osdl.org> <20041013172352.B4917536@wobbly.melbourne.sgi.com> In-Reply-To: <20041013172352.B4917536@wobbly.melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4283 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: piggin@cyberone.com.au Precedence: bulk X-list: linux-xfs Nathan Scott wrote: >On Wed, Oct 13, 2004 at 12:02:06AM -0700, Andrew Morton wrote: > >>Well something else if fishy: how can you possibly achieve only 4MB/sec? >> > >These are 1K writes too remember, so it feels a bit like we >write 'em out one at a time, sync (though no O_SYNC, or fsync, >or such involved here). This is on an i686, so 4K pages, and >using 4K filesystem blocksizes (both xfs and ext2). > > Still shouldn't cause such a big slowdown. Seems like they might be getting written off the end of the page reclaim LRU (although in that case it is a bit odd that increasing the dirty thresholds are improving performance). I don't think we have any vmscan metrics for this... kswapd definitely has become more active in 2.6.9-rc. If you're stuck for ideas, try editing mm/vmscan.c:may_write_to_queue - comment out the if(current_is_kswapd()) check. It is a long shot though. Andrew probably has better ideas. From owner-linux-xfs Wed Oct 13 01:42:05 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 13 Oct 2004 01:42:11 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9D8g49b023006 for ; Wed, 13 Oct 2004 01:42:05 -0700 Received: from bix (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i9D8fR918948; Wed, 13 Oct 2004 01:41:27 -0700 Date: Wed, 13 Oct 2004 01:39:41 -0700 From: Andrew Morton To: Nick Piggin Cc: nathans@sgi.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-xfs@oss.sgi.com Subject: Re: Page cache write performance issue Message-Id: <20041013013941.49693816.akpm@osdl.org> In-Reply-To: <416CE423.3000607@cyberone.com.au> References: <20041013054452.GB1618@frodo> <20041012231945.2aff9a00.akpm@osdl.org> <20041013063955.GA2079@frodo> <20041013000206.680132ad.akpm@osdl.org> <20041013172352.B4917536@wobbly.melbourne.sgi.com> <416CE423.3000607@cyberone.com.au> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4284 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: linux-xfs Nick Piggin wrote: > > Andrew probably has better ideas. uh, is this an ia32 highmem box? If so, you've hit the VM sour spot. That 128M highmem zone gets 100% filled with dirty pages and we end up doing a ton of writeout off the page LRU. And we do that while `dd' is cheerfully writing to a totally different part of the disk via balance_dirty_pages(). Seekstorm ensues. Although last time I looked (a long time ago) the slowdown was only 2:1 - perhaps your disk is in writethrough mode?? Basically, *any* other config is fine. 896MB and below, 1.5GB and above. I could well understand that a minor kswapd tweak would make this bad situation worse. Making the dirty ratios really small (dirty_ratio less than the 128MB) should make it go away. If it's not ia32 then dunno. From owner-linux-xfs Wed Oct 13 04:20:47 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 13 Oct 2004 04:20:50 -0700 (PDT) Received: from ns.itam.nsc.ru (ns.itam.nsc.ru [194.226.179.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9DBKf3f011495 for ; Wed, 13 Oct 2004 04:20:44 -0700 Received: from site.lan (itut.itam.nsc.ru [194.226.179.2]) by ns.itam.nsc.ru (8.12.8/8.12.8) with ESMTP id i9DBKJa8028894 for ; Wed, 13 Oct 2004 18:20:19 +0700 Received: from [192.168.7.215] ([192.168.7.215]) (authenticated bits=0) by site.lan (8.12.11/8.12.11) with ESMTP id i9DBKEk0015900 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 13 Oct 2004 18:20:14 +0700 Subject: 2.4.21-20.EL undefined references AGAIN From: Stas Nikiforov Reply-To: stas@itam.nsc.ru To: Linux_XFS Content-Type: text/plain Organization: ITAM Message-Id: <1097666413.2726.299.camel@whirl.lab7.lan> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Wed, 13 Oct 2004 18:20:14 +0700 Content-Transfer-Encoding: 7bit X-archive-position: 4285 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: stas@itam.nsc.ru Precedence: bulk X-list: linux-xfs Hi, Thanks for your help. But the problem persists. I've defined KERNEL_HAS_NEW_O_DIRECT as it was mentioned by Eric and recompiled xfs modules for RHEL 2.4.21-20.ELsmp kernel. When I try to load xfs.o (modprobe xfs) I get the following: modprobe xfs /lib/modules/2.4.21-20.ELsmp/sgi/fs/xfs/xfs.o: unresolved symbol filemap_fdatawrite /lib/modules/2.4.21-20.ELsmp/sgi/fs/xfs/xfs.o: unresolved symbol do_generic_direct_write /lib/modules/2.4.21-20.ELsmp/sgi/fs/xfs/xfs.o: unresolved symbol __inode_init_once /lib/modules/2.4.21-20.ELsmp/sgi/fs/xfs/xfs.o: unresolved symbol do_generic_direct_read /lib/modules/2.4.21-20.ELsmp/sgi/fs/xfs/xfs.o: insmod /lib/modules/2.4.21-20.ELsmp/sgi/fs/xfs/xfs.o failed /lib/modules/2.4.21-20.ELsmp/sgi/fs/xfs/xfs.o: insmod xfs failed It seems that kernel does not export these symbols. How can I overcome this? May be is is enough to patch my kernel with 2.4.21-15.EL.sgi headers? Thanks in advance, Stas. -- Mr. Nikiforov Stanislav Intsitute of Theoretical and Applied Mechanics 4/1, Institutskaya str., Novosibirsk, 930090, Russia Voice: +7 3832 343163 E-mail: stas@itam.nsc.ru From owner-linux-xfs Wed Oct 13 08:56:30 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 13 Oct 2004 08:56:35 -0700 (PDT) Received: from mail.charite.de (mail.charite.de [160.45.207.131]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9DFuTOT026317 for ; Wed, 13 Oct 2004 08:56:30 -0700 Received: from localhost (localhost [127.0.0.1]) by mail.charite.de (Postfix) with ESMTP id D9A382208CC; Wed, 13 Oct 2004 17:56:14 +0200 (CEST) Received: from postamt1.charite.de (postamt1.charite.de [193.175.66.246]) by mail.charite.de (Postfix) with ESMTP id 4B588220881; Wed, 13 Oct 2004 17:56:13 +0200 (CEST) Received: by postamt1.charite.de (Postfix, from userid 7945) id 41812633A8; Wed, 13 Oct 2004 17:56:13 +0200 (CEST) Date: Wed, 13 Oct 2004 17:56:13 +0200 From: Ralf Hildebrandt To: Bill Kendall Cc: Ralf Hildebrandt , linux-xfs@oss.sgi.com, Udo Wolter Subject: Re: duplicate uuid on mount Message-ID: <20041013155613.GR9263@charite.de> References: <20041004152638.GY32356@charite.de> <41619745.4070602@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <41619745.4070602@sgi.com> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new at charite.de X-archive-position: 4286 X-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 * Bill Kendall : > >We duplicated a fs by using xfsdump and xfsrestore; now we get > > > >XFS: Filesystem sdc5 has duplicate UUID - can't mount > >XFS: Filesystem sdc5 has duplicate UUID - can't mount > > > ># xfs_db -r -c "sb 0" -c "p uuid" /dev/sdb5 > >uuid = f921a9a5-ec6a-45a2-a383-7011b4dfffbc > ># xfs_db -r -c "sb 0" -c "p uuid" /dev/sdc5 > >uuid = f921a9a5-ec6a-45a2-a383-7011b4dfffbc > > > >So, how can we make the uuid unique again? > > > > I'm not sure how xfsrestore would get you in this situation as > it does not restore the UUID, but this should do the trick: > > xfs_db -x -c "uuid generate" /dev/sdc5 For the recorD: The reason for our duplicate uuid problems turned out to be an old deprecated driver for our scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.36 aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs Kernel 2.6.9 comes with TWO drivers. Since I rebuilt the 2.6.x kernel using the old 2.4.x .config file, I automatically got the old driver instead of the new one. The old driver was somehow able to access the disc using TWO DIFFERENT scsi devices. -- _________________________________________________ Charité - Universitätsmedizin Berlin _________________________________________________ Ralf Hildebrandt i.A. des IT-Zentrum | Netzwerkdienste Stabsstelle des Klinikumsvorstandes Campus Benjamin Franklin Hindenburgdamm 30 | Berlin Tel. +49 30 450 570155 | Fax +49 30 8445-4447 Ralf.Hildebrandt@charite.de http://www.charite.de From owner-linux-xfs Wed Oct 13 10:23:59 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 13 Oct 2004 10:24:01 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9DHNwsn029427 for ; Wed, 13 Oct 2004 10:23:59 -0700 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [198.149.16.14]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i9DIaAKD007900 for ; Wed, 13 Oct 2004 11:36:10 -0700 Received: from [128.162.232.50] (stout.americas.sgi.com [128.162.232.50]) by ledzep.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i9DHLLn21085310; Wed, 13 Oct 2004 12:21:21 -0500 (CDT) Message-ID: <416D6411.9070806@sgi.com> Date: Wed, 13 Oct 2004 12:21:21 -0500 From: Eric Sandeen User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: stas@itam.nsc.ru CC: Linux_XFS Subject: Re: 2.4.21-20.EL undefined references AGAIN References: <1097666413.2726.299.camel@whirl.lab7.lan> In-Reply-To: <1097666413.2726.299.camel@whirl.lab7.lan> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4287 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Yes, we export those too; again, please see the src.rpm that I pointed to on oss.sgi.com, it contains patches to address these issues on RHEL. -Eric Stas Nikiforov wrote: > Hi, > Thanks for your help. > But the problem persists. > > I've defined KERNEL_HAS_NEW_O_DIRECT > as it was mentioned by Eric and recompiled xfs modules for > RHEL 2.4.21-20.ELsmp kernel. > > When I try to load xfs.o (modprobe xfs) > I get the following: > > modprobe xfs > /lib/modules/2.4.21-20.ELsmp/sgi/fs/xfs/xfs.o: unresolved symbol filemap_fdatawrite > /lib/modules/2.4.21-20.ELsmp/sgi/fs/xfs/xfs.o: unresolved symbol do_generic_direct_write > /lib/modules/2.4.21-20.ELsmp/sgi/fs/xfs/xfs.o: unresolved symbol __inode_init_once > /lib/modules/2.4.21-20.ELsmp/sgi/fs/xfs/xfs.o: unresolved symbol do_generic_direct_read > /lib/modules/2.4.21-20.ELsmp/sgi/fs/xfs/xfs.o: insmod /lib/modules/2.4.21-20.ELsmp/sgi/fs/xfs/xfs.o failed > /lib/modules/2.4.21-20.ELsmp/sgi/fs/xfs/xfs.o: insmod xfs failed > > It seems that kernel does not export these symbols. How can I overcome this? > May be is is enough to patch my kernel with 2.4.21-15.EL.sgi headers? > > Thanks in advance, > Stas. From owner-linux-xfs Wed Oct 13 14:29:24 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 13 Oct 2004 14:29:26 -0700 (PDT) Received: from poison.mail.pas.earthlink.net (poison.mail.pas.earthlink.net [207.217.120.106]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9DLTOLP020288 for ; Wed, 13 Oct 2004 14:29:24 -0700 Received: from ubergeek.sys.pas.earthlink.net ([207.217.91.233]) by poison.mail.pas.earthlink.net with esmtp (TLSv1:AES256-SHA:256) (Exim 3.36 #1) id 1CHqgI-0005Il-00 for linux-xfs@oss.sgi.com; Wed, 13 Oct 2004 14:29:10 -0700 Date: Wed, 13 Oct 2004 14:29:10 -0700 (PDT) From: Abe Lopez X-X-Sender: alop@ubergeek.sys.pas.earthlink.net To: linux-xfs@oss.sgi.com Subject: XFS and RedHat EL WS 3 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 4288 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: alop@corp.earthlink.net Precedence: bulk X-list: linux-xfs Hello, I am having difficulty building xfs module for 2.4.21-20-EL (for Redhat Enterprise Linux workstation 3) I am attempting to patch using xfs 1.3.1 patchfiles for 2.4.21. Is there a better approach? Thank in advance --Abel Lopez Unix System Administrator From owner-linux-xfs Wed Oct 13 17:54:47 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 13 Oct 2004 17:54:51 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i9E0sjaJ031529 for ; Wed, 13 Oct 2004 17:54: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 KAA29509; Thu, 14 Oct 2004 10:54:21 +1000 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i9E0sHln5036801; Thu, 14 Oct 2004 10:54:18 +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 i9E0r4qn000793; Thu, 14 Oct 2004 10:53:04 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i9E0r08r000791; Thu, 14 Oct 2004 10:53:00 +1000 Date: Thu, 14 Oct 2004 10:53:00 +1000 From: Nathan Scott To: Nick Piggin , Andrew Morton Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-xfs@oss.sgi.com Subject: Re: Page cache write performance issue Message-ID: <20041014005300.GA716@frodo> References: <20041013054452.GB1618@frodo> <20041012231945.2aff9a00.akpm@osdl.org> <20041013063955.GA2079@frodo> <20041013000206.680132ad.akpm@osdl.org> <20041013172352.B4917536@wobbly.melbourne.sgi.com> <416CE423.3000607@cyberone.com.au> <20041013013941.49693816.akpm@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041013013941.49693816.akpm@osdl.org> User-Agent: Mutt/1.5.3i Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i9E0slaJ031538 X-archive-position: 4289 X-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 On Wed, Oct 13, 2004 at 01:39:41AM -0700, Andrew Morton wrote: > Nick Piggin wrote: > > > > Andrew probably has better ideas. > > uh, is this an ia32 highmem box? Yep, it is. > If so, you've hit the VM sour spot. > ... > Basically, *any* other config is fine. 896MB and below, 1.5GB and above. I just tried switching CONFIG_HIGHMEM off, and so running the machine with 512MB; then adjusted the test to write 256M into the page cache, again in 1K sequential chunks. A similar mis- behaviour happens, though the numbers are slightly better (up from ~4 to ~6.5MB/sec). Both ext2 and xfs see this. When I drop the file size down to 128M with this kernel, I see good results again (as we'd expect). I'm being pulled onto other issues atm, but in the background I could try reverting specific changesets if you guys can suggest anything in particular that might be triggering this? thanks! -- Nathan From owner-linux-xfs Wed Oct 13 18:01:15 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 13 Oct 2004 18:01:19 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9E11F5c031961 for ; Wed, 13 Oct 2004 18:01:15 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i9E11FSK031960 for linux-xfs@oss.sgi.com; Wed, 13 Oct 2004 18:01:15 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9E11DRh031946 for ; Wed, 13 Oct 2004 18:01:13 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i9E0kTba031279; Wed, 13 Oct 2004 17:46:29 -0700 Date: Wed, 13 Oct 2004 17:46:29 -0700 Message-Id: <200410140046.i9E0kTba031279@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 374] New: dm_{read,write}_invis leaks file handles in the kernel X-Bugzilla-Reason: AssignedTo X-archive-position: 4290 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=374 Summary: dm_{read,write}_invis leaks file handles in the kernel Product: Linux XFS Version: Current Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: High Component: dmapi AssignedTo: xfs-master@oss.sgi.com ReportedBy: mmontour@bycast.com With the linux-2.4-xfs CVS tree from oss.sgi.com, each call to dm_read_invis or dm_write_invis will leak 1 file handle within the kernel. This is visible by inspecting /proc/sys/fs/file-nr. Starting point: test-40:~# cat /proc/sys/fs/file-nr 7020 9 52420 After running a loop calling dm_read_invis on a file on a DMAPI-managed filesystem: test-40:~# cat /proc/sys/fs/file-nr 15975 1 52420 The first column shows an increasing number of allocated file handles. Eventually this will reach the system maximum (3rd column), and other applications running on the server will experience ENFILE errors. The relevant code appears to be xfs_dm_rdwr() in fs/xfs/xfs_dmapi.c, which does: struct file *file; ... file = dentry_open(dentry, NULL, oflags); if (IS_ERR(file)) { /* dentry_open did the dput */ if (fmode & FMODE_WRITE) put_write_access(inode); return EINVAL; } file->f_op = &linvfs_invis_file_operations; ... if (file->f_op->release) file->f_op->release(file->f_dentry->d_inode, file); if ((fmode & FMODE_WRITE) && have_write_access) put_write_access(inode); dput(dentry); return error; } "file" itself is never released here, e.g. with "put_filp(file)". ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Wed Oct 13 20:22:59 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 13 Oct 2004 20:23:01 -0700 (PDT) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9E3MrGJ008785 for ; Wed, 13 Oct 2004 20:22:58 -0700 Received: from bix (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with SMTP id i9E3MQ902598; Wed, 13 Oct 2004 20:22:26 -0700 Date: Wed, 13 Oct 2004 20:20:41 -0700 From: Andrew Morton To: Nathan Scott Cc: piggin@cyberone.com.au, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-xfs@oss.sgi.com Subject: Re: Page cache write performance issue Message-Id: <20041013202041.2e7066af.akpm@osdl.org> In-Reply-To: <20041014005300.GA716@frodo> References: <20041013054452.GB1618@frodo> <20041012231945.2aff9a00.akpm@osdl.org> <20041013063955.GA2079@frodo> <20041013000206.680132ad.akpm@osdl.org> <20041013172352.B4917536@wobbly.melbourne.sgi.com> <416CE423.3000607@cyberone.com.au> <20041013013941.49693816.akpm@osdl.org> <20041014005300.GA716@frodo> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4291 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: linux-xfs Nathan Scott wrote: > > On Wed, Oct 13, 2004 at 01:39:41AM -0700, Andrew Morton wrote: > > Nick Piggin wrote: > > > > > > Andrew probably has better ideas. > > > > uh, is this an ia32 highmem box? > > Yep, it is. > > > If so, you've hit the VM sour spot. > > ... > > Basically, *any* other config is fine. 896MB and below, 1.5GB and above. > > I just tried switching CONFIG_HIGHMEM off, and so running the > machine with 512MB; then adjusted the test to write 256M into > the page cache, again in 1K sequential chunks. A similar mis- > behaviour happens, though the numbers are slightly better (up > from ~4 to ~6.5MB/sec). Both ext2 and xfs see this. When I > drop the file size down to 128M with this kernel, I see good > results again (as we'd expect). No such problem here, with dd if=/dev/zero of=x bs=1k count=128k on a 256MB machine. xfs and ext2. Can you exhibit this one more than one machine? Silly question: what does `grep sync' /etc/fstab say over there? ;) From owner-linux-xfs Thu Oct 14 00:18:49 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 14 Oct 2004 00:18:56 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i9E7IlXW028276 for ; Thu, 14 Oct 2004 00:18:48 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA05635; Thu, 14 Oct 2004 17:18:23 +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 i9E7IIln4983826; Thu, 14 Oct 2004 17:18:19 +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 i9E7H4qn001835; Thu, 14 Oct 2004 17:17:04 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i9E7Gxwf001831; Thu, 14 Oct 2004 17:16:59 +1000 Date: Thu, 14 Oct 2004 17:16:59 +1000 From: Nathan Scott To: Andrew Morton Cc: piggin@cyberone.com.au, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-xfs@oss.sgi.com Subject: Re: Page cache write performance issue Message-ID: <20041014071659.GB1768@frodo> References: <20041013054452.GB1618@frodo> <20041012231945.2aff9a00.akpm@osdl.org> <20041013063955.GA2079@frodo> <20041013000206.680132ad.akpm@osdl.org> <20041013172352.B4917536@wobbly.melbourne.sgi.com> <416CE423.3000607@cyberone.com.au> <20041013013941.49693816.akpm@osdl.org> <20041014005300.GA716@frodo> <20041013202041.2e7066af.akpm@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041013202041.2e7066af.akpm@osdl.org> User-Agent: Mutt/1.5.3i X-archive-position: 4292 X-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 On Wed, Oct 13, 2004 at 08:20:41PM -0700, Andrew Morton wrote: > Nathan Scott wrote: > > I just tried switching CONFIG_HIGHMEM off, and so running the > > machine with 512MB; then adjusted the test to write 256M into > > the page cache, again in 1K sequential chunks. A similar mis- > > behaviour happens, though the numbers are slightly better (up > > from ~4 to ~6.5MB/sec). Both ext2 and xfs see this. When I > > drop the file size down to 128M with this kernel, I see good > > results again (as we'd expect). > > No such problem here, with > > dd if=/dev/zero of=x bs=1k count=128k > > on a 256MB machine. xfs and ext2. Yup, rebooted with mem=128M and on my box, & that crawls. Maybe its just this old hunk 'o junk, I suppose; odd that 2.6.8 was OK with this though. > Can you exhibit this one more than one machine? I haven't got a second ia32 box atm - setting one up soon, will let you know how it goes. > Silly question: what does `grep sync' /etc/fstab say over there? ;) Same thing it said on 2.6.8. :) Nada. cheers. -- Nathan From owner-linux-xfs Thu Oct 14 00:44:51 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 14 Oct 2004 00:44:53 -0700 (PDT) Received: from polaris.ximphony.org (ximphony.demon.co.uk [80.177.209.69]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9E7inFS032323 for ; Thu, 14 Oct 2004 00:44:50 -0700 Received: from eab109 by polaris.ximphony.org with local (Exim 3.36 #1) id 1CI0CV-0000Q4-00 for linux-xfs@oss.sgi.com; Thu, 14 Oct 2004 08:39:03 +0100 Date: Thu, 14 Oct 2004 08:39:03 +0100 To: linux-xfs@oss.sgi.com Subject: xfs_force_shutdown repeatable crash Message-ID: <20041014073903.GA1591@polaris.ximphony.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Mailer: Sent using Mutt (see http://www.mutt.org/) User-Agent: Mutt/1.5.6+20040722i From: "Edwin Beasant,,," X-archive-position: 4293 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: eab109@ximphony.org Precedence: bulk X-list: linux-xfs On you FAQ you were asking if this could be repeated, and I have a case, 100% reliable way of repeating this on my server. Polaris is a HP Netserver LH3 with a Highpoint 4-channel IDE controller running software raid 5 over 4 channels. Its root disk is a pair of 9.1 gig scsi drives as a hardware raid using the onboard AMI Megaraid controller. uname -a output: Linux polaris 2.6.8 #2 SMP Sat Oct 9 16:04:48 BST 2004 i686 GNU/Linux The fault is 100% reliable after 1.5 hours doing a considerable dump of many 2-6 meg files over a samba connection. It does not matter if this is a server push or pull. This is the sysylog output: Prior to this: The system had no unusual logs They are available if you require. Oct 13 19:57:08 polaris kernel: XFS internal error XFS_WANT_CORRUPTED_RETURN at line 310 of file fs/xfs/xfs_alloc.c. Caller 0xc0245a7d Oct 13 19:57:08 polaris kernel: [xfs_alloc_fixup_trees+525/880] xfs_alloc_fixup_trees+0x20d/0x370 Oct 13 19:57:08 polaris kernel: [xfs_alloc_ag_vextent_near+2861/3120] xfs_alloc_ag_vextent_near+0xb2d/0xc30 Oct 13 19:57:08 polaris kernel: [xfs_alloc_ag_vextent_near+2861/3120] xfs_alloc_ag_v extent_near+0xb2d/0xc30 Oct 13 19:57:08 polaris kernel: [xfs_alloc_ag_vextent+315/320] xfs_alloc_ag_vextent+0x13b/0x140 Oct 13 19:57:08 polaris kernel: [xfs_alloc_vextent+763/928] xfs_alloc_vextent+0x2fb/0x3a0 Oct 13 19:57:08 polaris kernel: [xfs_bmap_alloc+2184/5024] xfs_bmap_alloc+0x888/0x13a0 Oct 13 19:57:08 polaris kernel: [dma_timer_expiry+0/128] dma_timer_expiry+0x0/0x80 Oct 13 19:57:08 polaris kernel: [hpt370_clear_engine+61/96] hpt370_clear_engine+0x3d /0x60 Oct 13 19:57:08 polaris kernel: [xfs_bmapi+1368/5248] xfs_bmapi+0x558/0x1480 Oct 13 19:57:08 polaris kernel: [kmem_zone_alloc+76/160] kmem_zone_alloc+0x4c/0xa0 Oct 13 19:57:08 polaris kernel: [xfs_itobp+276/608] xfs_itobp+0x114/0x260 Oct 13 19:57:08 polaris kernel: [ide_dma_intr+0/176] ide_dma_intr+0x0/0xb0 Oct 13 19:57:08 polaris kernel: [dma_timer_expiry+0/128] dma_timer_expiry+0x0/0x80 Oct 13 19:57:08 polaris kernel: [xfs_dir2_grow_inode+259/1072] xfs_dir2_grow_inode+0 x103/0x430 Oct 13 19:57:08 polaris kernel: [xfs_iget_core+941/1728] xfs_iget_core+0x3ad/0x6c0 Oct 13 19:57:08 polaris kernel: [xfs_idata_realloc+78/384] xfs_idata_realloc+0x4e/0x 180 Oct 13 19:57:08 polaris kernel: [kmem_alloc+89/192] kmem_alloc+0x59/0xc0 Oct 13 19:57:08 polaris kernel: [xfs_trans_log_inode+45/96] xfs_trans_log_inode+0x2d /0x60 Oct 13 19:57:08 polaris kernel: [xfs_dir2_sf_to_block+211/1728] xfs_dir2_sf_to_block +0xd3/0x6c0 Oct 13 19:57:08 polaris kernel: [kmem_zone_zalloc+53/96] kmem_zone_zalloc+0x35/0x60 Oct 13 19:57:08 polaris kernel: [xfs_ichgtime+106/283] xfs_ichgtime+0x6a/0x11b Oct 13 19:57:08 polaris kernel: [wake_up_inode+19/80] wake_up_inode+0x13/0x50 Oct 13 19:57:08 polaris kernel: [vfs_init_vnode+75/80] vfs_init_vnode+0x4b/0x50 Oct 13 19:57:08 polaris kernel: [xfs_dir2_sf_addname+170/320] xfs_dir2_sf_addname+0x aa/0x140 Oct 13 19:57:08 polaris kernel: [xfs_dir2_createname+396/416] xfs_dir2_createname+0x 18c/0x1a0 Oct 13 19:57:08 polaris kernel: [kmem_zone_alloc+76/160] kmem_zone_alloc+0x4c/0xa0 Oct 13 19:57:08 polaris kernel: [xfs_trans_ijoin+53/144] xfs_trans_ijoin+0x35/0x90 Oct 13 19:57:08 polaris kernel: [xfs_create+1115/1888] xfs_create+0x45b/0x760 Oct 13 19:57:08 polaris kernel: [linvfs_mknod+824/1056] linvfs_mknod+0x338/0x420 Oct 13 19:57:08 polaris kernel: [d_splice_alias+73/320] d_splice_alias+0x49/0x140 Oct 13 19:57:08 polaris kernel: [in_group_p+67/128] in_group_p+0x43/0x80 Oct 13 19:57:08 polaris kernel: [xfs_iaccess+202/480] xfs_iaccess+0xca/0x1e0 Oct 13 19:57:08 polaris kernel: [in_group_p+67/128] in_group_p+0x43/0x80 Oct 13 19:57:08 polaris kernel: [xfs_iaccess+202/480] xfs_iaccess+0xca/0x1e0 Oct 13 19:57:08 polaris kernel: [xfs_access+79/96] xfs_access+0x4f/0x60 Oct 13 19:57:08 polaris kernel: [permission+73/80] permission+0x49/0x50 Oct 13 19:57:08 polaris kernel: [vfs_create+161/304] vfs_create+0xa1/0x130 Oct 13 19:57:08 polaris kernel: [open_namei+1522/1616] open_namei+0x5f2/0x650 Oct 13 19:57:08 polaris kernel: [filp_open+62/112] filp_open+0x3e/0x70 Oct 13 19:57:08 polaris kernel: [get_unused_fd+73/256] get_unused_fd+0x49/0x100 Oct 13 19:57:08 polaris kernel: [sys_open+91/144] sys_open+0x5b/0x90 Oct 13 19:57:08 polaris kernel: [syscall_call+7/11] syscall_call+0x7/0xb Oct 13 19:57:08 polaris kernel: xfs_force_shutdown(md2,0x8) called from line 1088 of file fs/xfs/xfs_trans.c. Return address = 0xc02b262b Oct 13 19:57:08 polaris kernel: Filesystem "md2": Corruption of in-memory data detect ed. Shutting down filesystem: md2 Oct 13 19:57:08 polaris kernel: Please umount the filesystem, and rectify the problem (s) Please contact me at any time to discuss! Cheers, Edwin Beasant eab109@ximphony.org -- -NeXTGenerationX "Don't fear the Penguins" GPG Fingerprint:- 4D3E 8EBD 516F CB89 9B17 8043 8896 2AC7 3636 EEA3 From owner-linux-xfs Thu Oct 14 01:01:53 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 14 Oct 2004 01:01:57 -0700 (PDT) Received: from smtp209.mail.sc5.yahoo.com (smtp209.mail.sc5.yahoo.com [216.136.130.117]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i9E81rsS000535 for ; Thu, 14 Oct 2004 01:01:53 -0700 Received: from unknown (HELO ?192.168.0.1?) (nickpiggin@203.173.3.14 with plain) by smtp209.mail.sc5.yahoo.com with SMTP; 14 Oct 2004 07:32:02 -0000 Message-ID: <416E2B6F.5040803@yahoo.com.au> Date: Thu, 14 Oct 2004 17:31:59 +1000 From: Nick Piggin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040820 Debian/1.7.2-4 X-Accept-Language: en MIME-Version: 1.0 To: Nathan Scott CC: Andrew Morton , piggin@cyberone.com.au, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-xfs@oss.sgi.com Subject: Re: Page cache write performance issue References: <20041013054452.GB1618@frodo> <20041012231945.2aff9a00.akpm@osdl.org> <20041013063955.GA2079@frodo> <20041013000206.680132ad.akpm@osdl.org> <20041013172352.B4917536@wobbly.melbourne.sgi.com> <416CE423.3000607@cyberone.com.au> <20041013013941.49693816.akpm@osdl.org> <20041014005300.GA716@frodo> <20041013202041.2e7066af.akpm@osdl.org> <20041014071659.GB1768@frodo> In-Reply-To: <20041014071659.GB1768@frodo> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4294 X-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 Nathan Scott wrote: > On Wed, Oct 13, 2004 at 08:20:41PM -0700, Andrew Morton wrote: > >>Nathan Scott wrote: >> >>> I just tried switching CONFIG_HIGHMEM off, and so running the >>> machine with 512MB; then adjusted the test to write 256M into >>> the page cache, again in 1K sequential chunks. A similar mis- >>> behaviour happens, though the numbers are slightly better (up >>> from ~4 to ~6.5MB/sec). Both ext2 and xfs see this. When I >>> drop the file size down to 128M with this kernel, I see good >>> results again (as we'd expect). >> >>No such problem here, with >> >> dd if=/dev/zero of=x bs=1k count=128k >> >>on a 256MB machine. xfs and ext2. > > > Yup, rebooted with mem=128M and on my box, & that crawls. > Maybe its just this old hunk 'o junk, I suppose; odd that > 2.6.8 was OK with this though. > Just out of interest, can you get profiles and a few lines of vmstat 1 from 2.6.8 and 2.6.9-rc, please? From owner-linux-xfs Thu Oct 14 08:01:19 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 14 Oct 2004 08:01:25 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9EF1JwT030210 for ; Thu, 14 Oct 2004 08:01:19 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i9EF1JE0030209 for linux-xfs@oss.sgi.com; Thu, 14 Oct 2004 08:01:19 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9EF1GYE030171 for ; Thu, 14 Oct 2004 08:01:17 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i9EEEYTc026432; Thu, 14 Oct 2004 07:14:34 -0700 Date: Thu, 14 Oct 2004 07:14:34 -0700 Message-Id: <200410141414.i9EEEYTc026432@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 375] New: xfs_force_shutdown in xfs_trans.c X-Bugzilla-Reason: AssignedTo X-archive-position: 4295 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=375 Summary: xfs_force_shutdown in xfs_trans.c Product: Linux XFS Version: unspecified Platform: IA32 OS/Version: Linux Status: NEW Severity: major Priority: High Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: jklaas@comcast.net System configuration: I have a knoppix/debian box that I am running kernel 2.6.8 that I built from debian package kernel-source-2.6.8. These are the compile options I picked from make menuconfig: XFS filesystem support [*] Realtime support (EXPERIMENTAL) [*] Quota support [*] Security Label support [*] POSIX ACL support I have /var mounted on it's own partition using xfs (I don't know how to figure out the version as it came with the kernel). It is on an IBM ultra-wide scsi sitting on a "LSI Logic / Symbios Logic 53c875 (rev 26)" scsi adapter. The partition is about 1GB in size. The Problem: I have a large collection of fonts that I am trying to get to use with my system. Debian has a utility called defoma to manage the fonts. One step is to use defoma-font to register the fonts with the defoma system. Every time I attempt to run this utility to register a directory full of fonts (~2000) I get the following problem with the /var partition: xfs_force_shutdown(sda6,0x8) called from line 1088 of file fs/xfs/xfs_trans.c. Return address = 0xf0c0c1bb Filesystem "sda6": Corruption of in-memory data detected. Shutting down filesys tem: sda6 Please umount the filesystem, and rectify the problem(s) xfs_force_shutdown(sda6,0x1) called from line 353 of file fs/xfs/xfs_rw.c. Retu rn address = 0xf0c0c1bb On another computer in my collection, it was obvious that this hammered the disk pretty hard. Plesae feel free to contact me for any more information and I will send you what I can. Thank you ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Thu Oct 14 11:26:42 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 14 Oct 2004 11:26:45 -0700 (PDT) Received: from smtp.cistron-office.nl (mail@10fwd.cistron-office.nl [62.216.29.197]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9EIQfMM011081 for ; Thu, 14 Oct 2004 11:26:42 -0700 Received: from subspace.cistron-office.nl ([62.216.29.200]) by smtp.cistron-office.nl with esmtp (Exim 3.35 #1 (Debian)) id 1CIAJ0-00031S-00 for ; Thu, 14 Oct 2004 20:26:26 +0200 Received: from miquels by subspace.cistron-office.nl with local (Exim 3.35 #1 (Debian)) id 1CIAJ0-0002QX-00 for ; Thu, 14 Oct 2004 20:26:26 +0200 Date: Thu, 14 Oct 2004 20:26:26 +0200 From: Miquel van Smoorenburg To: linux-xfs@oss.sgi.com Subject: shut up fs/xfs/linux-2.6/kmem.c Message-ID: <20041014182625.GA7535@cistron.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-NCC-RegID: nl.cistron User-Agent: Mutt/1.5.4i X-archive-position: 4296 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: miquels@cistron.nl Precedence: bulk X-list: linux-xfs Hello, on my machines fs/xfs/linux-2.6/kmem.c is printing a lot of garbage about failed 4th and 5th order allocations. I investigated this, and it appears that the vmalloc/kmalloc wrappers don't set __GFP_REPEAT or __GFP_NOFAIL, instead looping endlessly in the wrapper until the allocation succeeds. Because there is no delay built in (kmalloc at least calls blk_congestion_wait() if it's told to retry) it's printing lots of debug info in a very short time. This only happens for 4th and 5th order allocations, because kmalloc() itself behaves as if __GFP_REPEAT or __GFP_NOFAIL was set for < 4th order allocations if __GFP_WAIT is set. (BTW, note that mm/page_alloc.c::__alloc_pages() has either the comment or the logic wrong...) The first patch just retains the current way of doing things, but cuts down on the debug output - it also adds blk_congestion_wait() in the endless loop. With this patch applied, my system is finally peaceful and quiet again. Which is great, if you have a 9600 bd serial console - otherwise the system just stops. The second patch does the same, but simplifies things a lot by using __GFP_NOFAIL. It's cleaner, deletes code instead of adding to it, but I'm not sure if the printk's were there for some reason. Mike. == First patch, quiet down kmem.c and introduce wait: --- linux-2.6.9-rc4-tw/fs/xfs/linux-2.6/kmem.c.ORIG 2004-08-14 12:55:33.000000000 +0200 +++ linux-2.6.9-rc4-tw/fs/xfs/linux-2.6/kmem.c 2004-10-12 17:47:16.000000000 +0200 @@ -35,6 +35,7 @@ #include #include #include +#include #include "time.h" #include "kmem.h" @@ -47,18 +48,25 @@ kmem_alloc(size_t size, int flags) { int retries = 0, lflags = kmem_flags_convert(flags); + int lflagsq, warn; void *ptr; + lflagsq = lflags | (flags & (KM_MAYFAIL|KM_NOSLEEP)) ? 0 : __GFP_NOWARN; + do { + warn = (++retries % 100) == 0; if (size < MAX_SLAB_SIZE || retries > MAX_VMALLOCS) - ptr = kmalloc(size, lflags); + ptr = kmalloc(size, warn ? lflags : lflagsq); else - ptr = __vmalloc(size, lflags, PAGE_KERNEL); + ptr = __vmalloc(size, warn ? lflags : lflagsq, + PAGE_KERNEL); if (ptr || (flags & (KM_MAYFAIL|KM_NOSLEEP))) return ptr; - if (!(++retries % 100)) - printk(KERN_ERR "possible deadlock in %s (mode:0x%x)\n", + if (warn) + printk(KERN_ERR "xfs: possible memory allocation " + "deadlock in %s (mode:0x%x)\n", __FUNCTION__, lflags); + blk_congestion_wait(WRITE, HZ/50); } while (1); } @@ -103,15 +111,21 @@ kmem_zone_alloc(kmem_zone_t *zone, int flags) { int retries = 0, lflags = kmem_flags_convert(flags); + int lflagsq, warn; void *ptr; + lflagsq = lflags | (flags & (KM_MAYFAIL|KM_NOSLEEP)) ? 0 : __GFP_NOWARN; + do { - ptr = kmem_cache_alloc(zone, lflags); + warn = (++retries % 100) == 0; + ptr = kmem_cache_alloc(zone, warn ? lflags : lflagsq); if (ptr || (flags & (KM_MAYFAIL|KM_NOSLEEP))) return ptr; - if (!(++retries % 100)) - printk(KERN_ERR "possible deadlock in %s (mode:0x%x)\n", + if (warn) + printk(KERN_ERR "xfs: possible memory allocation " + "deadlock in %s (mode:0x%x)\n", __FUNCTION__, lflags); + blk_congestion_wait(WRITE, HZ/50); } while (1); } == alternative patch, simplify and use __GFP_WAIT. --- linux-2.6.9-rc4-tw/fs/xfs/linux-2.6/kmem.c.ORIG 2004-08-14 12:55:33.000000000 +0200 +++ linux-2.6.9-rc4-tw/fs/xfs/linux-2.6/kmem.c 2004-10-14 20:17:31.000000000 +0200 @@ -35,6 +35,7 @@ #include #include #include +#include #include "time.h" #include "kmem.h" @@ -46,20 +47,23 @@ void * kmem_alloc(size_t size, int flags) { - int retries = 0, lflags = kmem_flags_convert(flags); + int retries, lflags = kmem_flags_convert(flags); void *ptr; - do { - if (size < MAX_SLAB_SIZE || retries > MAX_VMALLOCS) + if (flags & (KM_MAYFAIL|KM_NOSLEEP)) + lflags |= __GFP_NOWARN; + + for (retries = 0; retries < MAX_VMALLOCS; retries++) { + if (size < MAX_SLAB_SIZE) ptr = kmalloc(size, lflags); else ptr = __vmalloc(size, lflags, PAGE_KERNEL); if (ptr || (flags & (KM_MAYFAIL|KM_NOSLEEP))) return ptr; - if (!(++retries % 100)) - printk(KERN_ERR "possible deadlock in %s (mode:0x%x)\n", - __FUNCTION__, lflags); - } while (1); + blk_congestion_wait(WRITE, HZ/50); + } + + return kmalloc(size, lflags | __GFP_NOFAIL); } void * @@ -102,17 +106,12 @@ void * kmem_zone_alloc(kmem_zone_t *zone, int flags) { - int retries = 0, lflags = kmem_flags_convert(flags); - void *ptr; + int lflags = kmem_flags_convert(flags); - do { - ptr = kmem_cache_alloc(zone, lflags); - if (ptr || (flags & (KM_MAYFAIL|KM_NOSLEEP))) - return ptr; - if (!(++retries % 100)) - printk(KERN_ERR "possible deadlock in %s (mode:0x%x)\n", - __FUNCTION__, lflags); - } while (1); + if (!(flags & (KM_MAYFAIL|KM_NOSLEEP))) + lflags |= __GFP_NOFAIL; + + return kmem_cache_alloc(zone, lflags); } void * From owner-linux-xfs Sun Oct 17 13:05:32 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 17 Oct 2004 13:05:37 -0700 (PDT) Received: from albatross.madduck.net (armagnac.ifi.unizh.ch [130.60.75.72]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9HK5Uqj027870 for ; Sun, 17 Oct 2004 13:05:31 -0700 Received: from localhost (albatross.madduck.net [127.0.0.1]) by albatross.madduck.net (postfix) with ESMTP id 6D8CD895D9D for ; Sun, 17 Oct 2004 22:05:13 +0200 (CEST) Received: from localhost (80-219-173-32.dclient.hispeed.ch [80.219.173.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cirrus.madduck.net", Issuer "madduck.net CA" (verified OK)) by albatross.madduck.net (postfix) with ESMTP id F1552895D6D for ; Sun, 17 Oct 2004 22:05:12 +0200 (CEST) Received: by localhost (Postfix, from userid 1000) id 824C822012F; Sun, 17 Oct 2004 22:05:12 +0200 (CEST) Resent-From: madduck@madduck.net Resent-Date: Sun, 17 Oct 2004 22:05:12 +0200 Resent-Message-ID: <20041017200512.GA32276@cirrus.madduck.net> Resent-To: linux-xfs@oss.sgi.com Date: Sat, 16 Oct 2004 18:50:58 +0200 From: martin f krafft To: linux kernel mailing list Subject: XFS oops on loading the module Message-ID: <20041016165058.GB32324@cirrus.madduck.net> Mail-Followup-To: linux kernel mailing list Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RYJh/3oyKhIjGcML" Content-Disposition: inline X-OS: Debian GNU/Linux 3.1 kernel 2.6.8-cirrus i686 X-Mailer: Mutt 1.5.6+20040907i (CVS) X-Motto: Keep the good times rollin' X-Subliminal-Message: debian/rules! X-Spamtrap: madduck.bogus@madduck.net User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: by albatross.madduck.net X-archive-position: 4297 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: madduck@madduck.net Precedence: bulk X-list: linux-xfs --RYJh/3oyKhIjGcML Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I just tried to mount an XFS filesystem on this AMD K6 machine, booted with the 2.6.8 kernel for FAI (http://www.informatik.uni/koeln.de/fai) (let me know if you need any information about it), and modprobe segfaults with a kernel bug. Have you seen this before? Thanks! sh-2.05b# modprobe xfs Segmentation fault ------------[ cut here ]------------ kernel BUG at kernel/module.c:264! invalid operand: 0000 [#1] SMP=20 Modules linked in: ext3 jbd mbcache sr_mod sd_mod scsi_mod ide_generic usbm= ouse usbhid ide_cd cdrom usbkbd floppy rtc via82cxxx slc90e66 sis5513 siima= ge serverworks rz1000 piix pdc202xx_old pdc202xx_new hpt366 ide_disk hpt34x= cs5530 cmd64x amd74xx alim15x3 aec62xx ide_core uhci_hcd usbcore CPU: 0 EIP: 0060:[] Not tainted EFLAGS: 00010202 (2.6.8-fai)=20 EIP is at percpu_modalloc+0xe/0xf8 eax: 0000004b ebx: e09f9400 ecx: e09f940c edx: 0000000f esi: e09f84c4 edi: 00000258 ebp: e09fa9c8 esp: d9963f0c ds: 007b es: 007b ss: 0068 Process modprobe (pid: 1272, threadinfo=3Dd9962000 task=3Ddfb50650) Stack: e09f9400 e09f84c4 00000258 e09fa9c8 c012d8be e098f000 c012d8ed 00000= 148=20 00000020 40157000 080509b8 c031f504 d9962000 c416c0a0 00000044 00000= 060=20 df0ad4e0 00000000 00000000 e09f9400 0000000f 00000000 00000000 00000= 000=20 Call Trace: [] load_module+0x3c6/0x904 [] load_module+0x3f5/0x904 [] sys_init_module+0x5d/0x200 [] syscall_call+0x7/0xb Code: 0f 0b 08 01 6f a5 2b c0 89 f6 bd a0 10 40 c0 31 f6 a1 2c 64=20 --=20 martin; (greetings from the heart of the sun.) \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck =20 invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver! spamtraps: madduck.bogus@madduck.net =20 because light travels faster than sound, some people appear to be intelligent, until you hear them speak. --RYJh/3oyKhIjGcML Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBcVFyIgvIgzMMSnURAoWNAKDOzPqdsilHlDOlTtjLetUaNXzQzQCgrc39 AHxXrnfYyDAo6mUoOA3mj3M= =iUHR -----END PGP SIGNATURE----- --RYJh/3oyKhIjGcML-- From owner-linux-xfs Sun Oct 17 22:20:40 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 17 Oct 2004 22:20:42 -0700 (PDT) Received: from ns.itam.nsc.ru (ns.itam.nsc.ru [194.226.179.15]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9I5KZCT024830 for ; Sun, 17 Oct 2004 22:20:39 -0700 Received: from site.lan (itut.itam.nsc.ru [194.226.179.2]) by ns.itam.nsc.ru (8.12.8/8.12.8) with ESMTP id i9I5KCCg027754 for ; Mon, 18 Oct 2004 12:20:13 +0700 Received: from [192.168.7.215] ([192.168.7.215]) (authenticated bits=0) by site.lan (8.12.11/8.12.11) with ESMTP id i9I5K7wJ026749 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 18 Oct 2004 12:20:07 +0700 Subject: [SOLVED] 2.4.21-20.EL undefined references From: Stas Nikiforov Reply-To: stas@itam.nsc.ru To: Linux_XFS In-Reply-To: <416D6411.9070806@sgi.com> References: <1097666413.2726.299.camel@whirl.lab7.lan> <416D6411.9070806@sgi.com> Content-Type: text/plain Organization: ITAM Message-Id: <1098076806.2726.305.camel@whirl.lab7.lan> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Mon, 18 Oct 2004 12:20:07 +0700 Content-Transfer-Encoding: 7bit X-archive-position: 4298 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: stas@itam.nsc.ru Precedence: bulk X-list: linux-xfs Hi, Thanks again for you help, Eric. I've applied xfs patches to the 2.4.21-20.EL kernel, and now I have xfs. Best regards, Stas. On Thu, 2004-10-14 at 00:21, Eric Sandeen wrote: > Yes, we export those too; again, please see the src.rpm that I pointed > to on oss.sgi.com, it contains patches to address these issues on RHEL. > > -Eric > > Stas Nikiforov wrote: > > Hi, > > Thanks for your help. > > But the problem persists. > > > > I've defined KERNEL_HAS_NEW_O_DIRECT > > as it was mentioned by Eric and recompiled xfs modules for > > RHEL 2.4.21-20.ELsmp kernel. > > > > When I try to load xfs.o (modprobe xfs) > > I get the following: > > > > modprobe xfs > > /lib/modules/2.4.21-20.ELsmp/sgi/fs/xfs/xfs.o: unresolved symbol filemap_fdatawrite > > /lib/modules/2.4.21-20.ELsmp/sgi/fs/xfs/xfs.o: unresolved symbol do_generic_direct_write > > /lib/modules/2.4.21-20.ELsmp/sgi/fs/xfs/xfs.o: unresolved symbol __inode_init_once > > /lib/modules/2.4.21-20.ELsmp/sgi/fs/xfs/xfs.o: unresolved symbol do_generic_direct_read > > /lib/modules/2.4.21-20.ELsmp/sgi/fs/xfs/xfs.o: insmod /lib/modules/2.4.21-20.ELsmp/sgi/fs/xfs/xfs.o failed > > /lib/modules/2.4.21-20.ELsmp/sgi/fs/xfs/xfs.o: insmod xfs failed > > > > It seems that kernel does not export these symbols. How can I overcome this? > > May be is is enough to patch my kernel with 2.4.21-15.EL.sgi headers? > > > > Thanks in advance, > > Stas. > From owner-linux-xfs Mon Oct 18 02:04:01 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 18 Oct 2004 02:04:07 -0700 (PDT) Received: from vsmtp4.tin.it (vsmtp4alice-fr.tin.it [212.216.176.150] (may be forged)) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9I940fN000320 for ; Mon, 18 Oct 2004 02:04:00 -0700 Received: from ims2f.cp.tin.it (192.168.70.102) by vsmtp4.tin.it (7.0.027) id 41568C9D009720E6 for linux-xfs@oss.sgi.com; Mon, 18 Oct 2004 11:03:41 +0200 Received: from [192.168.70.183] by ims2f.cp.tin.it with HTTP; Mon, 18 Oct 2004 11:03:40 +0200 Date: Mon, 18 Oct 2004 11:03:40 +0200 Message-ID: <4153628F00024FEC@ims2f.cp.tin.it> From: ecqgat@tin.it Subject: 2.4.27 with grsecurity and xfs-acl posix To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="========/4153628F00024FEC/ims2f.cp.tin.it" X-archive-position: 4299 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ecqgat@tin.it Precedence: bulk X-list: linux-xfs --========/4153628F00024FEC/ims2f.cp.tin.it Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi everyone. I was looking for a kernel patch that will let me use grsecurity and the acl posix with the xfs filesystem. I didn't find it so i made it on my own taking and modifing the acl-backport for the 2.4.27 kernel. This patch is only for 2.4.27 kernel with the 2.0.1 grsecurity patch. Now, as i am not an expert of kernel pogramming, i wonder if what i have build is correct and if the grsecurity + xfs-acl patches can work together without any problem (like filesystem corruption or security issues and so on...). Any suggestion? Thanks Marco --========/4153628F00024FEC/ims2f.cp.tin.it Content-Type: text/plain Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="2.4.27+grsec-2.0.1_xfs-acl.patch" JXBhdGNoCkluZGV4OiAyLjQuMjcvRG9jdW1lbnRhdGlvbi9Db25maWd1cmUu aGVscAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09CioqKiAyLjQuMjcvRG9jdW1l bnRhdGlvbi9Db25maWd1cmUuaGVscC5ncnNlYwlGcmkgT2N0IDE1IDIyOjEy OjM3IDIwMDQKLS0tIDIuNC4yNy9Eb2N1bWVudGF0aW9uL0NvbmZpZ3VyZS5o ZWxwCUZyaSBPY3QgMTUgMjI6MDM6MzIgMjAwNAoqKioqKioqKioqKioqKioK KioqIDE3NTkzLDE3NTk4ICoqKioKLS0tIDE3NTkzLDE3NjA4IC0tLS0KICAK ICAgIElmIHVuc3VyZSwgc2F5IE4uCiAgCisgUE9TSVggQUNMIHN1cHBvcnQK KyBDT05GSUdfWEZTX1BPU0lYX0FDTAorICAgUE9TSVggQWNjZXNzIENvbnRy b2wgTGlzdHMgKEFDTHMpIHN1cHBvcnQgcGVybWlzc2lvbnMgZm9yIHVzZXJz IGFuZAorICAgZ3JvdXBzIGJleW9uZCB0aGUgb3duZXIvZ3JvdXAvd29ybGQg c2NoZW1lLgorIAorICAgVG8gbGVhcm4gbW9yZSBhYm91dCBBY2Nlc3MgQ29u dHJvbCBMaXN0cywgdmlzaXQgdGhlIFBPU0lYIEFDTHMgZm9yCisgICBMaW51 eCB3ZWJzaXRlIDxodHRwOi8vYWNsLmJlc3RiaXRzLmF0Lz4uCisgCisgICBJ ZiB5b3UgZG9uJ3Qga25vdyB3aGF0IEFjY2VzcyBDb250cm9sIExpc3RzIGFy ZSwgc2F5IE4uCisgCiAgVHJhY2luZyBzdXBwb3J0IChFWFBFUklNRU5UQUwp CiAgQ09ORklHX1hGU19UUkFDRQogICAgU2F5IFkgaGVyZSB0byBnZXQgYW4g WEZTIGJ1aWxkIHdpdGggYWN0aXZpdHkgdHJhY2luZyBlbmFibGVkLgpJbmRl eDogMi40LjI3L2ZzL0NvbmZpZy5pbgo9PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 CioqKiAyLjQuMjcvZnMvQ29uZmlnLmluLmdyc2VjCUZyaSBPY3QgMTUgMjI6 MTI6MTggMjAwNAotLS0gMi40LjI3L2ZzL0NvbmZpZy5pbglGcmkgT2N0IDE1 IDIyOjA2OjUxIDIwMDQKKioqKioqKioqKioqKioqCioqKiAxMDIsMTA3ICoq KioKLS0tIDEwMiwxMDggLS0tLQogIGRlcF9tYm9vbCAnICBVRlMgZmlsZSBz eXN0ZW0gd3JpdGUgc3VwcG9ydCAoREFOR0VST1VTKScgQ09ORklHX1VGU19G U19XUklURSAkQ09ORklHX1VGU19GUyAkQ09ORklHX0VYUEVSSU1FTlRBTAog IAogIHRyaXN0YXRlICdYRlMgZmlsZXN5c3RlbSBzdXBwb3J0JyBDT05GSUdf WEZTX0ZTCisgZGVwX21ib29sICAgICcgIFBPU0lYIEFDTCBzdXBwb3J0JyBD T05GSUdfWEZTX1BPU0lYX0FDTCAkQ09ORklHX1hGU19GUwogIGRlcF9tYm9v bCAgICAnICBRdW90YSBzdXBwb3J0JyBDT05GSUdfWEZTX1FVT1RBICRDT05G SUdfWEZTX0ZTCiAgZGVwX21ib29sICAgICcgIFJlYWx0aW1lIHN1cHBvcnQg KEVYUEVSSU1FTlRBTCknIENPTkZJR19YRlNfUlQgJENPTkZJR19YRlNfRlMg JENPTkZJR19FWFBFUklNRU5UQUwKICBkZXBfbWJvb2wgICAgJyAgVHJhY2lu ZyBzdXBwb3J0IChFWFBFUklNRU5UQUwpJyBDT05GSUdfWEZTX1RSQUNFICRD T05GSUdfWEZTX0ZTICRDT05GSUdfRVhQRVJJTUVOVEFMCkluZGV4OiAyLjQu MjcvZnMvbmFtZWkuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09CioqKiAyLjQu MjcvZnMvbmFtZWkuYy5ncnNlYwlGcmkgT2N0IDE1IDIyOjEyOjAyIDIwMDQK LS0tIDIuNC4yNy9mcy9uYW1laS5jCUZyaSBPY3QgMTUgMjI6MDY6NTEgMjAw NAoqKioqKioqKioqKioqKioKKioqIDEwODMsMTA5MCAqKioqCiAgCQkJZ290 byBleGl0X2RwdXQ7CiAgCQl9CiAgCiEgCQllcnJvciA9IHZmc19jcmVhdGUo ZGlyLT5kX2lub2RlLCBkZW50cnksCiEgCQkJCSAgIG1vZGUgJiB+Y3VycmVu dC0+ZnMtPnVtYXNrKTsKICAJCWlmICghZXJyb3IpCiAgCQkJZ3JfaGFuZGxl X2NyZWF0ZShkZW50cnksIG5kLT5tbnQpOwogIAotLS0gMTA4MywxMDkxIC0t LS0KICAJCQlnb3RvIGV4aXRfZHB1dDsKICAJCX0KICAKISAJCWlmICghSVNf UE9TSVhBQ0woZGlyLT5kX2lub2RlKSkKISAJCQltb2RlICY9IH5jdXJyZW50 LT5mcy0+dW1hc2s7CiEgCQllcnJvciA9IHZmc19jcmVhdGUoZGlyLT5kX2lu b2RlLCBkZW50cnksIG1vZGUpOwogIAkJaWYgKCFlcnJvcikKICAJCQlncl9o YW5kbGVfY3JlYXRlKGRlbnRyeSwgbmQtPm1udCk7CiAgCioqKioqKioqKioq KioqKgoqKiogMTM0NywxMzUzICoqKioKICAJZGVudHJ5ID0gbG9va3VwX2Ny ZWF0ZSgmbmQsIDApOwogIAllcnJvciA9IFBUUl9FUlIoZGVudHJ5KTsKICAK ISAJbW9kZSAmPSB+Y3VycmVudC0+ZnMtPnVtYXNrOwogIAlpZiAoIUlTX0VS UihkZW50cnkpKSB7CiAgCQlpZiAoZ3JfaGFuZGxlX2Nocm9vdF9ta25vZChk ZW50cnksIG5kLm1udCwgbW9kZSkgfHwKICAJCSAgICBncl9oYW5kbGVfY2hy b290X2NobW9kKGRlbnRyeSwgbmQubW50LCBtb2RlKSkgewotLS0gMTM0OCwx MzU1IC0tLS0KICAJZGVudHJ5ID0gbG9va3VwX2NyZWF0ZSgmbmQsIDApOwog IAllcnJvciA9IFBUUl9FUlIoZGVudHJ5KTsKICAKISAJaWYgKCFJU19QT1NJ WEFDTChuZC5kZW50cnktPmRfaW5vZGUpKQohIAkJbW9kZSAmPSB+Y3VycmVu dC0+ZnMtPnVtYXNrOwogIAlpZiAoIUlTX0VSUihkZW50cnkpKSB7CiAgCQlp ZiAoZ3JfaGFuZGxlX2Nocm9vdF9ta25vZChkZW50cnksIG5kLm1udCwgbW9k ZSkgfHwKICAJCSAgICBncl9oYW5kbGVfY2hyb290X2NobW9kKGRlbnRyeSwg bmQubW50LCBtb2RlKSkgewoqKioqKioqKioqKioqKioKKioqIDE0MzksMTQ0 NiAqKioqCiAgCQkJCWVycm9yID0gLUVBQ0NFUzsKICAKICAJCQlpZighZXJy b3IpCiEgCQkJCWVycm9yID0gdmZzX21rZGlyKG5kLmRlbnRyeS0+ZF9pbm9k ZSwgZGVudHJ5LAohIAkJCQkJICBtb2RlICYgfmN1cnJlbnQtPmZzLT51bWFz ayk7CiAgCQkJaWYoIWVycm9yKQogIAkJCQlncl9oYW5kbGVfY3JlYXRlKGRl bnRyeSwgbmQubW50KTsKICAJCQkKLS0tIDE0NDEsMTQ0OSAtLS0tCiAgCQkJ CWVycm9yID0gLUVBQ0NFUzsKICAKICAJCQlpZighZXJyb3IpCiEgCQkJCWlm ICghSVNfUE9TSVhBQ0wobmQuZGVudHJ5LT5kX2lub2RlKSkKISAJCQkJCW1v ZGUgJj0gfmN1cnJlbnQtPmZzLT51bWFzazsKISAJCQllcnJvciA9IHZmc19t a2RpcihuZC5kZW50cnktPmRfaW5vZGUsIGRlbnRyeSwgbW9kZSk7CiAgCQkJ aWYoIWVycm9yKQogIAkJCQlncl9oYW5kbGVfY3JlYXRlKGRlbnRyeSwgbmQu bW50KTsKICAJCQkKSW5kZXg6IDIuNC4yNy9pbmNsdWRlL2xpbnV4L2ZzLmgK PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PQoqKiogMi40LjI3L2luY2x1ZGUvbGlu dXgvZnMuaC5ncnNlYwlGcmkgT2N0IDE1IDIyOjEyOjU3IDIwMDQKLS0tIDIu NC4yNy9pbmNsdWRlL2xpbnV4L2ZzLmgJRnJpIE9jdCAxNSAyMjowOTo0NyAy MDA0CioqKioqKioqKioqKioqKgoqKiogMTExLDExNiAqKioqCi0tLSAxMTEs MTE3IC0tLS0KICAjZGVmaW5lIE1TX01PVkUJCTgxOTIKICAjZGVmaW5lIE1T X1JFQwkJMTYzODQKICAjZGVmaW5lIE1TX1ZFUkJPU0UJMzI3NjgKKyAjZGVm aW5lIE1TX1BPU0lYQUNMCTY1NTM2CS8qIFZGUyBkb2VzIG5vdCBhcHBseSB0 aGUgdW1hc2sgKi8KICAjZGVmaW5lIE1TX0FDVElWRQkoMTw8MzApCiAgI2Rl ZmluZSBNU19OT1VTRVIJKDE8PDMxKQogIAoqKioqKioqKioqKioqKioKKioq IDE2MSwxNjYgKioqKgotLS0gMTYyLDE2OCAtLS0tCiAgI2RlZmluZSBJU19J TU1VVEFCTEUoaW5vZGUpCSgoaW5vZGUpLT5pX2ZsYWdzICYgU19JTU1VVEFC TEUpCiAgI2RlZmluZSBJU19OT0FUSU1FKGlub2RlKQkoX19JU19GTEcoaW5v ZGUsIE1TX05PQVRJTUUpIHx8ICgoaW5vZGUpLT5pX2ZsYWdzICYgU19OT0FU SU1FKSkKICAjZGVmaW5lIElTX05PRElSQVRJTUUoaW5vZGUpCV9fSVNfRkxH KGlub2RlLCBNU19OT0RJUkFUSU1FKQorICNkZWZpbmUgSVNfUE9TSVhBQ0wo aW5vZGUpCV9fSVNfRkxHKGlub2RlLCBNU19QT1NJWEFDTCkKICAKICAjZGVm aW5lIElTX0RFQURESVIoaW5vZGUpCSgoaW5vZGUpLT5pX2ZsYWdzICYgU19E RUFEKQogIApJbmRleDogMi40LjI3L2luY2x1ZGUvbGludXgvcG9zaXhfYWNs X3hhdHRyLmgKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gMi40LjI3L2lu Y2x1ZGUvbGludXgvcG9zaXhfYWNsX3hhdHRyLmgJVGh1IEphbiAgMSAxMDow MDowMCAxOTcwCisrKyAyLjQuMjcvaW5jbHVkZS9saW51eC9wb3NpeF9hY2xf eGF0dHIuaAlNb24gQXVnICA5IDEzOjU2OjAyIDIwMDQKQEAgLTAsMCArMSw2 NyBAQAorLyoKKyAgRmlsZTogbGludXgvcG9zaXhfYWNsX3hhdHRyLmgKKwor ICBFeHRlbmRlZCBhdHRyaWJ1dGUgc3lzdGVtIGNhbGwgcmVwcmVzZW50YXRp b24gb2YgQWNjZXNzIENvbnRyb2wgTGlzdHMuCisKKyAgQ29weXJpZ2h0IChD KSAyMDAwIGJ5IEFuZHJlYXMgR3J1ZW5iYWNoZXIgPGEuZ3J1ZW5iYWNoZXJA Y29tcHV0ZXIub3JnPgorICBDb3B5cmlnaHQgKEMpIDIwMDIgU0dJIC0gU2ls aWNvbiBHcmFwaGljcywgSW5jIDxsaW51eC14ZnNAb3NzLnNnaS5jb20+Cisg Ki8KKyNpZm5kZWYgX1BPU0lYX0FDTF9YQVRUUl9ICisjZGVmaW5lIF9QT1NJ WF9BQ0xfWEFUVFJfSAorCisvKiBFeHRlbmRlZCBhdHRyaWJ1dGUgbmFtZXMg Ki8KKyNkZWZpbmUgUE9TSVhfQUNMX1hBVFRSX0FDQ0VTUwkic3lzdGVtLnBv c2l4X2FjbF9hY2Nlc3MiCisjZGVmaW5lIFBPU0lYX0FDTF9YQVRUUl9ERUZB VUxUCSJzeXN0ZW0ucG9zaXhfYWNsX2RlZmF1bHQiCisKKy8qIFN1cHBvcnRl ZCBBQ0wgYV92ZXJzaW9uIGZpZWxkcyAqLworI2RlZmluZSBQT1NJWF9BQ0xf WEFUVFJfVkVSU0lPTgkweDAwMDIKKworCisvKiBBbiB1bmRlZmluZWQgZW50 cnkgZV9pZCB2YWx1ZSAqLworI2RlZmluZSBBQ0xfVU5ERUZJTkVEX0lECSgt MSkKKworLyogQUNMIGVudHJ5IGVfdGFnIGZpZWxkIHZhbHVlcyAqLworI2Rl ZmluZSBBQ0xfVVNFUl9PQkoJCSgweDAxKQorI2RlZmluZSBBQ0xfVVNFUgkJ KDB4MDIpCisjZGVmaW5lIEFDTF9HUk9VUF9PQkoJCSgweDA0KQorI2RlZmlu ZSBBQ0xfR1JPVVAJCSgweDA4KQorI2RlZmluZSBBQ0xfTUFTSwkJKDB4MTAp CisjZGVmaW5lIEFDTF9PVEhFUgkJKDB4MjApCisKKy8qIEFDTCBlbnRyeSBl X3Blcm0gYml0ZmllbGQgdmFsdWVzICovCisjZGVmaW5lIEFDTF9SRUFECQko MHgwNCkKKyNkZWZpbmUgQUNMX1dSSVRFCQkoMHgwMikKKyNkZWZpbmUgQUNM X0VYRUNVVEUJCSgweDAxKQorCisKK3R5cGVkZWYgc3RydWN0IHsKKwlfX3Ux NgkJCWVfdGFnOworCV9fdTE2CQkJZV9wZXJtOworCV9fdTMyCQkJZV9pZDsK K30gcG9zaXhfYWNsX3hhdHRyX2VudHJ5OworCit0eXBlZGVmIHN0cnVjdCB7 CisJX191MzIJCQlhX3ZlcnNpb247CisJcG9zaXhfYWNsX3hhdHRyX2VudHJ5 CWFfZW50cmllc1swXTsKK30gcG9zaXhfYWNsX3hhdHRyX2hlYWRlcjsKKwor CitzdGF0aWMgaW5saW5lIHNpemVfdAorcG9zaXhfYWNsX3hhdHRyX3NpemUo aW50IGNvdW50KQoreworCXJldHVybiAoc2l6ZW9mKHBvc2l4X2FjbF94YXR0 cl9oZWFkZXIpICsKKwkJKGNvdW50ICogc2l6ZW9mKHBvc2l4X2FjbF94YXR0 cl9lbnRyeSkpKTsKK30KKworc3RhdGljIGlubGluZSBpbnQKK3Bvc2l4X2Fj bF94YXR0cl9jb3VudChzaXplX3Qgc2l6ZSkKK3sKKwlpZiAoc2l6ZSA8IHNp emVvZihwb3NpeF9hY2xfeGF0dHJfaGVhZGVyKSkKKwkJcmV0dXJuIC0xOwor CXNpemUgLT0gc2l6ZW9mKHBvc2l4X2FjbF94YXR0cl9oZWFkZXIpOworCWlm IChzaXplICUgc2l6ZW9mKHBvc2l4X2FjbF94YXR0cl9lbnRyeSkpCisJCXJl dHVybiAtMTsKKwlyZXR1cm4gc2l6ZSAvIHNpemVvZihwb3NpeF9hY2xfeGF0 dHJfZW50cnkpOworfQorCisjZW5kaWYJLyogX1BPU0lYX0FDTF9YQVRUUl9I ICovCg== --========/4153628F00024FEC/ims2f.cp.tin.it-- From owner-linux-xfs Mon Oct 18 03:01:47 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 18 Oct 2004 03:01:54 -0700 (PDT) Received: from koto.vergenet.net (koto.vergenet.net [210.128.90.7]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i9IA1k5x004990 for ; Mon, 18 Oct 2004 03:01:46 -0700 Received: (qmail 8742 invoked by uid 7100); 18 Oct 2004 09:48:30 -0000 Date: Mon, 18 Oct 2004 16:25:08 +0900 From: Horms To: Jan Eringa , 274988@bugs.debian.org Cc: linux-xfs@oss.sgi.com Subject: Re: Bug#274988: XFS crash in kernel-image-2.6.8-1-686-smp Message-ID: <20041018072508.GB20121@verge.net.au> References: <200410050943.05174.jan.eringa@orbian.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="0OAP2g/MAC+5xKAE" Content-Disposition: inline In-Reply-To: <200410050943.05174.jan.eringa@orbian.com> X-Cluestick: seven User-Agent: Mutt/1.5.6+20040907i X-archive-position: 4300 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: horms@debian.org Precedence: bulk X-list: linux-xfs --0OAP2g/MAC+5xKAE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Jan, Thanks for your bug report. The only xfs patch that is applied to the Debian kernel is an ioctl patch which is pending a merge upstream, so I guess this is a bug in the XFS code as present in Linus' tree. I have CCed the linux-xfs mailing list in the hope that someone there can help you out. linux-xfs people, please feel free to either include or not include the debian bug tracking system on any resulting thread by CCing 274988@bugs.debian.org as you feel fit. I have attached the one patch that is applied to the debian 2.6.8 kernel for referance. Please let me or the bug's address know if there is a resolution as I am not on the linux-xfs list. On Tue, Oct 05, 2004 at 09:43:03AM +0100, Jan Eringa wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Package: kernel-image-2.6.8-1-686-smp > Version: 2.6.8-3 > Severity: Important > > Hardware layout > - --------------------- > Dual Xeon + Latest BIOS > 1 GB ram > 2 x 3ware SATA raid controllers + Latest Firmware > > All disks live on the 3ware 9xxx controllers > Controllers provides 3 x 1.5TB raid-5 stripes > One of which holds /, swap and /var. > > The rest of the free space I've built as a 4.5TB raid-0 stripe > for the backup volume > > This is then carved into..... > - ---------------------------------------------------------------------------------------- > backup-srv:~# df -k > Filesystem 1K-blocks Used Available Use% Mounted on > /dev/sda1 3937220 2285880 1451336 62% / > /dev/sda3 3937252 2497220 1240024 67% /var > /dev/md0 4677217408 3090281796 1586935612 67% /backups > > > - ---------------------------------------------------------------------------------------- > > > The /dev/md0 device is .... > - ---------------------------------------------------------------------------------------- > backup-srv:~# cat /proc/mdstat > md0 : active raid0 sdc1[2] sdb1[1] sda4[0] > 4677348544 blocks 64k chunks > > unused devices: > > - ---------------------------------------------------------------------------------------- > > I had to use XFS as this was the only FS that would build that large. > ext3 seems to barf at anything over 2TB > > > > Problem Description > - ------------------------- > This machine is the production backup server for all the *nix machines on > the network. cron runs rsync via ssh to grab the files from each client target > The bulk of the systems are backed up weekly and a few daily > The system seems to survive anywhere between a couple of days to no more > that 2 weeks under this sort of heavy IO & network loading before > giving up the ghost. dmesg dumps follow...... > > This problem was also exhibited by 2.6.7 and 2.6.6 > > I'm dropping back to 2.4.27 now & will let you know if pain persists > > > > - From Dmesg > - ---------------------------------------------------------------------------------------- > Unable to handle kernel paging request at virtual address 20fda90c > printing eip: > f8b26144 > *pde = 00000000 > Oops: 0000 [#1] > PREEMPT SMP > Modules linked in: af_packet ipv6 piix hw_random uhci_hcd usbcore shpchp > pciehp pci_hotplug floppy parport_pc parport pcspkr evdev e1000 xfs raid0 md > dm_mod ide_cd ide_core cdrom rtc ext3 jbd mbcache sd_mod unix 3w_9xxx > scsi_mod > CPU: 3 > EIP: 0060:[] Not tainted > EFLAGS: 00010213 (2.6.8.20040927) > EIP is at xfs_ail_insert+0x24/0xd0 [xfs] > eax: 000003e7 ebx: 00000000 ecx: 000003e7 edx: 00000000 > esi: 20fda904 edi: f7198c18 ebp: c2005168 esp: f7703dd4 > ds: 007b es: 007b ss: 0068 > Process xfslogd/3 (pid: 604, threadinfo=f7702000 task=f7cb87d0) > Stack: 0002050a 0000052a 549b2041 ed9cd202 c2005168 f7198c18 f7198c00 c0f1d30c > f8b25e5d f7198c18 c2005168 00000000 c2005168 0002050a 0000052a 00000000 > c2005168 0002050a 0000052a f8b258bc f7198c00 c2005168 0002050a 0000052a > Call Trace: > [] xfs_trans_update_ail+0x5d/0xf0 [xfs] > [] xfs_trans_chunk_committed+0x17c/0x240 [xfs] > [] xfs_trans_committed+0x4a/0x120 [xfs] > [] xlog_state_do_callback+0x2c3/0x3d0 [xfs] > [] xlog_state_done_syncing+0x80/0xc0 [xfs] > [] xlog_iodone+0x55/0xf0 [xfs] > [] pagebuf_iodone_work+0x4d/0x50 [xfs] > [] worker_thread+0x1f6/0x2e0 > [] pagebuf_iodone_work+0x0/0x50 [xfs] > [] default_wake_function+0x0/0x20 > [] default_wake_function+0x0/0x20 > [] worker_thread+0x0/0x2e0 > [] kthread+0xba/0xc0 > [] kthread+0x0/0xc0 > [] kernel_thread_helper+0x5/0x10 > Code: 8b 46 08 8b 56 0c 89 44 24 08 89 54 24 0c 8b 55 0c 8b 45 08 > <6>note: xfslogd/3[604] exited with preempt_count 1 > - ---------------------------------------------------------------------------------------- > > > Machine locks up a little while after this & after a kick in the guts gives > on next startup.... > - ---------------------------------------------------------------------------------------- > backup-srv:~# mount /backups/ > Oct 4 12:47:03 ouprci05 kernel: Filesystem "md0": XFS internal error > xlog_clear_stale_blocks(2) at line 1253 of file fs/xfs/xfs_log_recover.c. > Caller 0xf8b28876 > Oct 4 12:47:03 ouprci01 kernel: Filesystem "md0": XFS internal error > xlog_clear_stale_blocks(2) at line 1253 of file fs/xfs/xfs_log_recover.c. > Caller 0xf8b28876 > mount: Unknown error 990 > - ---------------------------------------------------------------------------------------- > > > So I try..... > - ---------------------------------------------------------------------------------------- > backup-srv:~# xfs_repair /dev/md0 > Phase 1 - find and verify superblock... > Phase 2 - using internal log > - zero log... > ERROR: The filesystem has valuable metadata changes in a log which needs to > be replayed. Mount the filesystem to replay the log, and unmount it before > re-running xfs_repair. If you are unable to mount the filesystem, then use > the -L option to destroy the log and attempt a repair. > Note that destroying the log may cause corruption -- please attempt a mount > of the filesystem before doing this. > - ---------------------------------------------------------------------------------------- > > > So I .... > - ---------------------------------------------------------------------------------------- > backup-srv:~# xfs_repair -L /dev/md0 > Phase 1 - find and verify superblock... > Phase 2 - using internal log > - zero log... > ALERT: The filesystem has valuable metadata changes in a log which is being > destroyed because the -L option was used. > - 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 > LEAFN node level is 1 inode 2820138 bno = 8388608 > > entry contains offset out of order in shortform dir 19126020 > corrected entry offsets in directory 19126020 > - agno = 1 > - agno = 2 > LEAFN node level is 1 inode 2147942164 bno = 8388608 > LEAFN node level is 1 inode 2148480815 bno = 8388608 > .... > And so on for a few hours, for the rest of the 4.5TB file system check to > complete :( > .... > > > > > ________________________________ > It is by caffeine alone I set my mind in motion, > It is by the beans of Java that thoughts acquire speed, > The hands acquire shaking, the shaking becomes a warning, > It is by caffeine alone I set my mind in motion. > (author unknown) > with thanks and apologies to Frank Herbert > ________________________________ > Jan Eringa > Unix Admin > Orbian Management Ltd > ________________________________ > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.4 (GNU/Linux) > > iD8DBQFBYl6XX4LWCZ7JjaMRAtH0AJwPIxdCA6xO88hHtJa27qo7UBlG/QCgigGI > dhtLCXAxPd1W46KbnFMdMcY= > =nuOo > -----END PGP SIGNATURE----- > -- Horms --0OAP2g/MAC+5xKAE Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="xfs-ioctl32.dpatch" #! /bin/sh -e ## .dpatch by ## ## All lines beginning with `## DP:' are a description of the patch. ## DP: Description: Add 32bit ioctl translations to XFS ## DP: Patch author: Christoph Hellwig ## DP: Upstream status: pending submission in next XFS merge . $(dirname $0)/DPATCH @DPATCH@ --- 1.31/fs/xfs/Makefile 2004-06-18 04:05:01 +02:00 +++ edited/fs/xfs/Makefile 2004-08-11 10:20:52 +02:00 @@ -71,6 +71,7 @@ xfs-$(CONFIG_XFS_POSIX_MAC) += xfs_mac.o xfs-$(CONFIG_PROC_FS) += linux-2.6/xfs_stats.o xfs-$(CONFIG_SYSCTL) += linux-2.6/xfs_sysctl.o +xfs-$(CONFIG_COMPAT) += linux-2.6/xfs_ioctl32.o xfs-y += xfs_alloc.o \ --- 1.10/fs/xfs/xfs_fs.h 2004-02-27 07:28:05 +01:00 +++ edited/fs/xfs/xfs_fs.h 2004-08-11 18:27:01 +02:00 @@ -445,6 +445,13 @@ #define XFS_FSOP_GOING_FLAGS_NOLOGFLUSH 0x2 /* don't flush log nor data */ /* + * ioctl commands that are used by Linux filesystems + */ +#define XFS_IOC_GETXFLAGS _IOR('f', 1, long) +#define XFS_IOC_SETXFLAGS _IOW('f', 2, long) +#define XFS_IOC_GETVERSION _IOR('v', 1, long) + +/* * ioctl commands that replace IRIX fcntl()'s * For 'documentation' purposed more than anything else, * the "cmd #" field reflects the IRIX fcntl number. --- 1.27/fs/xfs/linux-2.6/xfs_ioctl.c 2004-05-24 05:08:10 +02:00 +++ edited/fs/xfs/linux-2.6/xfs_ioctl.c 2004-08-11 18:26:25 +02:00 @@ -73,14 +73,6 @@ #include /* - * ioctl commands that are used by Linux filesystems - */ -#define XFS_IOC_GETXFLAGS _IOR('f', 1, long) -#define XFS_IOC_SETXFLAGS _IOW('f', 2, long) -#define XFS_IOC_GETVERSION _IOR('v', 1, long) - - -/* * xfs_find_handle maps from userspace xfs_fsop_handlereq structure to * a file or fs handle. * --- 1.84/fs/xfs/linux-2.6/xfs_super.c 2004-06-18 06:09:11 +02:00 +++ edited/fs/xfs/linux-2.6/xfs_super.c 2004-08-11 10:20:52 +02:00 @@ -66,6 +66,7 @@ #include "xfs_buf_item.h" #include "xfs_utils.h" #include "xfs_version.h" +#include "xfs_ioctl32.h" #include #include @@ -857,6 +858,10 @@ goto undo_shaker; } + error = xfs_ioctl32_init(); + if (error) + goto undo_ioctl32; + error = register_filesystem(&xfs_fs_type); if (error) goto undo_register; @@ -864,6 +869,9 @@ return 0; undo_register: + xfs_ioctl32_exit(); + +undo_ioctl32: kmem_shake_deregister(xfs_inode_shaker); undo_shaker: @@ -882,6 +890,7 @@ vfs_exitquota(); XFS_DM_EXIT(&xfs_fs_type); unregister_filesystem(&xfs_fs_type); + xfs_ioctl32_exit(); kmem_shake_deregister(xfs_inode_shaker); xfs_cleanup(); pagebuf_terminate(); --- /dev/null 2004-08-10 00:19:24.000000000 +0200 +++ a/fs/xfs/linux-2.6/xfs_ioctl32.c 2004-08-11 18:27:20.008881680 +0200 @@ -0,0 +1,162 @@ +/* + * Copyright (c) 2004 Silicon Graphics, Inc. All Rights Reserved. + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of version 2 of the GNU General Public License as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it would be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. + * + * Further, this software is distributed without any warranty that it is + * free of the rightful claim of any third person regarding infringement + * or the like. Any license provided herein, whether implied or + * otherwise, applies only to this software file. Patent licenses, if + * any, provided herein do not apply to combinations of this program with + * other software, or any other product whatsoever. + * + * You should have received a copy of the GNU General Public License along + * with this program; if not, write the Free Software Foundation, Inc., 59 + * Temple Place - Suite 330, Boston MA 02111-1307, USA. + * + * Contact information: Silicon Graphics, Inc., 1600 Amphitheatre Pkwy, + * Mountain View, CA 94043, or: + * + * http://www.sgi.com + * + * For further information regarding this notice, see: + * + * http://oss.sgi.com/projects/GenInfo/SGIGPLNoticeExplan/ + */ + +#include +#include +#include +#include +#include +#include +#include +#include + +#include "xfs_types.h" +#include "xfs_fs.h" +#include "xfs_dfrag.h" + +#if defined(CONFIG_IA64) || defined(CONFIG_X86_64) +#define BROKEN_X86_ALIGNMENT +#endif + + +typedef struct xfs_fsop_bulkreq32 { + compat_uptr_t lastip; /* last inode # pointer */ + __s32 icount; /* count of entries in buffer */ + compat_uptr_t ubuffer; /* user buffer for inode desc. */ + __s32 ocount; /* output count pointer */ +} xfs_fsop_bulkreq32_t; + +static int +xfs_ioctl32_bulkstat( + unsigned int fd, + unsigned int cmd, + unsigned long arg, + struct file * file) +{ + xfs_fsop_bulkreq32_t __user *p32 = (void __user *)arg; + xfs_fsop_bulkreq_t __user *p = compat_alloc_user_space(sizeof(*p)); + u32 addr; + + if (get_user(addr, &p32->lastip) || + put_user(compat_ptr(addr), &p->lastip) || + copy_in_user(&p->icount, &p32->icount, sizeof(s32)) || + get_user(addr, &p32->ubuffer) || + put_user(compat_ptr(addr), &p->ubuffer) || + get_user(addr, &p32->ocount) || + put_user(compat_ptr(addr), &p->ocount)) + return -EFAULT; + + return sys_ioctl(fd, cmd, (unsigned long)p); +} + +struct ioctl_trans xfs_ioctl32_trans[] = { + { XFS_IOC_DIOINFO, }, + { XFS_IOC_FSGEOMETRY_V1, }, + { XFS_IOC_FSGEOMETRY, }, + { XFS_IOC_GETVERSION, }, + { XFS_IOC_GETXFLAGS, }, + { XFS_IOC_SETXFLAGS, }, + { XFS_IOC_FSGETXATTR, }, + { XFS_IOC_FSSETXATTR, }, + { XFS_IOC_FSGETXATTRA, }, + { XFS_IOC_FSSETDM, }, + { XFS_IOC_GETBMAP, }, + { XFS_IOC_GETBMAPA, }, + { XFS_IOC_GETBMAPX, }, +/* not handled + { XFS_IOC_FD_TO_HANDLE, }, + { XFS_IOC_PATH_TO_HANDLE, }, + { XFS_IOC_PATH_TO_HANDLE, }, + { XFS_IOC_PATH_TO_FSHANDLE, }, + { XFS_IOC_OPEN_BY_HANDLE, }, + { XFS_IOC_FSSETDM_BY_HANDLE, }, + { XFS_IOC_READLINK_BY_HANDLE, }, + { XFS_IOC_ATTRLIST_BY_HANDLE, }, + { XFS_IOC_ATTRMULTI_BY_HANDLE, }, +*/ + { XFS_IOC_FSCOUNTS, NULL, }, + { XFS_IOC_SET_RESBLKS, NULL, }, + { XFS_IOC_GET_RESBLKS, NULL, }, + { XFS_IOC_FSGROWFSDATA, NULL, }, + { XFS_IOC_FSGROWFSLOG, NULL, }, + { XFS_IOC_FSGROWFSRT, NULL, }, + { XFS_IOC_FREEZE, NULL, }, + { XFS_IOC_THAW, NULL, }, + { XFS_IOC_GOINGDOWN, NULL, }, + { XFS_IOC_ERROR_INJECTION, NULL, }, + { XFS_IOC_ERROR_CLEARALL, NULL, }, +#ifndef BROKEN_X86_ALIGNMENT + /* xfs_flock_t and xfs_bstat_t have wrong u32 vs u64 alignment */ + { XFS_IOC_ALLOCSP, }, + { XFS_IOC_FREESP, }, + { XFS_IOC_RESVSP, }, + { XFS_IOC_UNRESVSP, }, + { XFS_IOC_ALLOCSP64, }, + { XFS_IOC_FREESP64, }, + { XFS_IOC_RESVSP64, }, + { XFS_IOC_UNRESVSP64, }, + { XFS_IOC_SWAPEXT, }, + { XFS_IOC_FSBULKSTAT_SINGLE, xfs_ioctl32_bulkstat }, + { XFS_IOC_FSBULKSTAT, xfs_ioctl32_bulkstat}, + { XFS_IOC_FSINUMBERS, xfs_ioctl32_bulkstat}, +#endif + { 0, }, +}; + +int __init +xfs_ioctl32_init(void) +{ + int error, i; + + for (i = 0; xfs_ioctl32_trans[i].cmd != 0; i++) { + error = register_ioctl32_conversion(xfs_ioctl32_trans[i].cmd, + xfs_ioctl32_trans[i].handler); + if (error) + goto fail; + } + + return 0; + + fail: + while (--i) + unregister_ioctl32_conversion(xfs_ioctl32_trans[i].cmd); + return error; +} + +void +xfs_ioctl32_exit(void) +{ + int i; + + for (i = 0; xfs_ioctl32_trans[i].cmd != 0; i++) + unregister_ioctl32_conversion(xfs_ioctl32_trans[i].cmd); +} --- /dev/null 2004-08-10 00:19:24.000000000 +0200 +++ a/fs/xfs/linux-2.6/xfs_ioctl32.h 2004-07-11 16:42:03.000000000 +0200 @@ -0,0 +1,41 @@ +/* + * Copyright (c) 2004 Silicon Graphics, Inc. All Rights Reserved. + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of version 2 of the GNU General Public License as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it would be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. + * + * Further, this software is distributed without any warranty that it is + * free of the rightful claim of any third person regarding infringement + * or the like. Any license provided herein, whether implied or + * otherwise, applies only to this software file. Patent licenses, if + * any, provided herein do not apply to combinations of this program with + * other software, or any other product whatsoever. + * + * You should have received a copy of the GNU General Public License along + * with this program; if not, write the Free Software Foundation, Inc., 59 + * Temple Place - Suite 330, Boston MA 02111-1307, USA. + * + * Contact information: Silicon Graphics, Inc., 1600 Amphitheatre Pkwy, + * Mountain View, CA 94043, or: + * + * http://www.sgi.com + * + * For further information regarding this notice, see: + * + * http://oss.sgi.com/projects/GenInfo/SGIGPLNoticeExplan/ + */ + +#include + +#ifdef CONFIG_COMPAT +extern int xfs_ioctl32_init(void); +extern void xfs_ioctl32_exit(void); +#else +static inline int xfs_ioctl32_init(void) { return 0; } +static inline void xfs_ioctl32_exit(void) { } +#endif --0OAP2g/MAC+5xKAE-- From owner-linux-xfs Mon Oct 18 17:56:32 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 18 Oct 2004 17:56:36 -0700 (PDT) Received: from chook.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9J0uAOn003495 for ; Mon, 18 Oct 2004 17:56:31 -0700 Received: (from nathans@localhost) by chook.melbourne.sgi.com (8.11.6/8.11.6) id i9J0tpa04832 for linux-xfs@oss.sgi.com; Tue, 19 Oct 2004 10:55:51 +1000 Date: Tue, 19 Oct 2004 10:55:51 +1000 From: Nathan Scott Message-Id: <200410190055.i9J0tpa04832@chook.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE 912624 - docs update X-archive-position: 4302 X-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@chook.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 781 Lines: 18 Update documentation for inode32 allocator rotorstep change. Date: Tue Oct 19 10:55:31 AEST 2004 Workarea: chook.melbourne.sgi.com:/build/nathans/2.6.x-xfs Inspected by: gwehrman The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: 2.6.x-xfs-melb:linux:19817a Documentation/filesystems/xfs.txt - 1.9 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/Documentation/filesystems/xfs.txt.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h split-patches/series - 1.10 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/split-patches/series.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h split-patches/docs-update - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/split-patches/docs-update.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h From owner-linux-xfs Mon Oct 18 19:37:39 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 18 Oct 2004 19:37:44 -0700 (PDT) Received: from chook.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9J2bHMi005350 for ; Mon, 18 Oct 2004 19:37:38 -0700 Received: (from nathans@localhost) by chook.melbourne.sgi.com (8.11.6/8.11.6) id i9J2ava22568 for linux-xfs@oss.sgi.com; Tue, 19 Oct 2004 12:36:57 +1000 Date: Tue, 19 Oct 2004 12:36:57 +1000 From: Nathan Scott Message-Id: <200410190236.i9J2ava22568@chook.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE 904196 - Merge up to 2.6.9 X-archive-position: 4303 X-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@chook.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 12838 Lines: 178 Date: Tue Oct 19 12:35:54 AEST 2004 Workarea: chook.melbourne.sgi.com:/build/nathans/2.6.x-xfs Inspected by: torvalds@osdl.org The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: 2.6.x-xfs-melb:linux:19821a arch/ppc64/kernel/iomap.c - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ppc64/kernel/iomap.c Documentation/scsi/ChangeLog.megaraid - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/Documentation/scsi/ChangeLog.megaraid.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h Makefile - 1.25 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/Makefile.diff?r1=text&tr1=1.25&r2=text&tr2=1.24&f=h arch/h8300/kernel/ptrace.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/h8300/kernel/ptrace.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/h8300/lib/checksum.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/h8300/lib/checksum.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/h8300/platform/h8300h/generic/timer.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/h8300/platform/h8300h/generic/timer.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/ia64/kernel/fsys.S - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/kernel/fsys.S.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h arch/ppc/Kconfig - 1.11 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ppc/Kconfig.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h arch/ppc/kernel/pci.c - 1.8 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ppc/kernel/pci.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h arch/ppc/mm/pgtable.c - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ppc/mm/pgtable.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h arch/ppc64/kernel/Makefile - 1.10 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ppc64/kernel/Makefile.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h arch/ppc64/kernel/eeh.c - 1.9 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ppc64/kernel/eeh.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h arch/ppc64/kernel/smp.c - 1.11 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ppc64/kernel/smp.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h arch/um/Kconfig - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/um/Kconfig.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/um/Kconfig_block - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/um/Kconfig_block.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/um/Kconfig_char - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/um/Kconfig_char.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/um/Kconfig_net - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/um/Kconfig_net.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/um/Makefile - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/um/Makefile.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/um/Makefile-i386 - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/um/Makefile-i386.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/um/Makefile-skas - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/um/Makefile-skas.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/um/Makefile-tt - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/um/Makefile-tt.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/um/drivers/chan_kern.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/um/drivers/chan_kern.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/um/drivers/ubd_kern.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/um/drivers/ubd_kern.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/um/include/Makefile - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/um/include/Makefile.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/um/include/sysdep-i386/checksum.h - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/um/include/sysdep-i386/checksum.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/um/kernel/Makefile - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/um/kernel/Makefile.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/um/kernel/irq.c - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/um/kernel/irq.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h arch/um/kernel/ksyms.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/um/kernel/ksyms.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/um/kernel/skas/Makefile - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/um/kernel/skas/Makefile.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/um/kernel/skas/util/Makefile - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/um/kernel/skas/util/Makefile.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/um/kernel/time_kern.c - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/um/kernel/time_kern.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/um/kernel/vmlinux.lds.S - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/um/kernel/vmlinux.lds.S.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/um/sys-i386/Makefile - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/um/sys-i386/Makefile.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/um/sys-i386/util/Makefile - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/um/sys-i386/util/Makefile.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/x86_64/kernel/suspend_asm.S - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/x86_64/kernel/suspend_asm.S.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/acpi/scan.c - 1.8 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/acpi/scan.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h drivers/base/firmware_class.c - 1.8 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/base/firmware_class.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h drivers/char/agp/intel-agp.c - 1.9 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/char/agp/intel-agp.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h drivers/input/joystick/Kconfig - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/input/joystick/Kconfig.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/input/serio/parkbd.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/input/serio/parkbd.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/mtd/chips/cfi_cmdset_0001.c - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/mtd/chips/cfi_cmdset_0001.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h drivers/mtd/maps/lubbock-flash.c - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/mtd/maps/lubbock-flash.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/pci/probe.c - 1.13 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/pci/probe.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h drivers/usb/class/usblp.c - 1.9 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/class/usblp.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h drivers/usb/gadget/net2280.c - 1.9 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/gadget/net2280.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h drivers/usb/host/ehci-hcd.c - 1.10 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/host/ehci-hcd.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h drivers/usb/host/ehci.h - 1.9 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/host/ehci.h.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h drivers/usb/input/hid-core.c - 1.10 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/input/hid-core.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h drivers/usb/media/konicawc.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/media/konicawc.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/usb/serial/digi_acceleport.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/serial/digi_acceleport.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/video/cyber2000fb.c - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/video/cyber2000fb.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h fs/ext3/inode.c - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/ext3/inode.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h fs/proc/array.c - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/proc/array.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h include/asm-generic/pgtable.h - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-generic/pgtable.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h include/asm-h8300/bitops.h - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-h8300/bitops.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h include/asm-i386/linkage.h - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-i386/linkage.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h include/asm-i386/pgtable-3level.h - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-i386/pgtable-3level.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-ppc/io.h - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-ppc/io.h.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h include/asm-um/dma-mapping.h - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-um/dma-mapping.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h include/asm-um/smp.h - 1.4 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-um/smp.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/linux/acct.h - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/acct.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h include/linux/highmem.h - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/highmem.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h include/linux/linkage.h - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/linkage.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h include/linux/sched.h - 1.12 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/sched.h.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h include/linux/times.h - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/times.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h kernel/acct.c - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/kernel/acct.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h kernel/exit.c - 1.18 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/kernel/exit.c.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h kernel/fork.c - 1.10 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/kernel/fork.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h kernel/posix-timers.c - 1.8 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/kernel/posix-timers.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h mm/oom_kill.c - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/mm/oom_kill.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h mm/page-writeback.c - 1.8 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/mm/page-writeback.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h mm/vmscan.c - 1.11 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/mm/vmscan.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h net/sunrpc/auth_gss/auth_gss.c - 1.8 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/sunrpc/auth_gss/auth_gss.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h net/sunrpc/svcauth.c - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/sunrpc/svcauth.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h security/selinux/hooks.c - 1.12 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/security/selinux/hooks.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h arch/ppc64/mm/hash_low.S - 1.8 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ppc64/mm/hash_low.S.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h drivers/pci/hotplug/rpaphp_pci.c - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/pci/hotplug/rpaphp_pci.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h drivers/scsi/megaraid/megaraid_mbox.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/megaraid/megaraid_mbox.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/asm-m32r/unistd.h - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-m32r/unistd.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/scsi/megaraid/megaraid_mbox.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/megaraid/megaraid_mbox.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/um/kernel/physmem.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/um/kernel/physmem.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/ppc64/kernel/prom_init.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ppc64/kernel/prom_init.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/m32r/kernel/entry.S - 1.3 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/m32r/kernel/entry.S.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/m32r/kernel/sys_m32r.c - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/m32r/kernel/sys_m32r.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h From owner-linux-xfs Tue Oct 19 00:01:40 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 19 Oct 2004 00:01:43 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9J71eGE014290 for ; Tue, 19 Oct 2004 00:01:40 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i9J71eUE014289 for linux-xfs@oss.sgi.com; Tue, 19 Oct 2004 00:01:40 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9J71cqZ014273 for ; Tue, 19 Oct 2004 00:01:38 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i9J6lMN2013658; Mon, 18 Oct 2004 23:47:22 -0700 Date: Mon, 18 Oct 2004 23:47:22 -0700 Message-Id: <200410190647.i9J6lMN2013658@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 373] samba msoffice xfs interaction problem X-Bugzilla-Reason: AssignedTo X-archive-position: 4304 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1178 Lines: 39 http://oss.sgi.com/bugzilla/show_bug.cgi?id=373 ------- Additional Comments From tes@sgi.com 2004-18-10 23:47 PDT ------- Hi Axel, I'm afraid I don't understand what is exactly happening for you. It would be nice to see a printout of the acl's using getfacl on each of the files. I presume: user fred owns/created the file data.txt user jack tries to save data.txt using msoffice and creates a new file data2.txt. What do you mean by "default rights"? So we have a new files data2.txt with (user:jack:r--). > > these only ro rights affect also the creator of the file, > > although he is listed in the acl with full rwx rights. What does that sentence mean? Does it mean the owner can't write to the file either even though he has rwx permissions (user::rwx) ? Hmmmm... It'd be nice to know who did what and what the resultant file was and what the resultant acls on the file was. And then what the problem was - was the resultant acls on the file not expected or the acls were right but the access checking seemed to do the wrong thing... --Tim ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Thu Oct 21 09:31:04 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 21 Oct 2004 09:31:07 -0700 (PDT) Received: from mx2.bluetie.com (mx2.bluetie.com [206.65.164.153]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9LGV3Vm027695 for ; Thu, 21 Oct 2004 09:31:03 -0700 Received: from mstore2.app.nyc1.bluetie.com (mstore2.app.nyc1.bluetie.com [10.102.1.17]) by mx2.bluetie.com (Postfix) with ESMTP id AC88CE01BC for ; Thu, 21 Oct 2004 12:30:37 -0400 (EDT) Message-ID: <20041021123038.14764@web1.app.nyc1.bluetie.com> X-Mailer: BlueTie Mailer Center Cc: To: linux-xfs@oss.sgi.com From: "Thomas Ledbetter" Subject: xfs out of diskspace issue Content-transfer-encoding: 7bit Content-Type: text/plain Date: Thu, 21 Oct 2004 12:30:37 -0400 (EDT) X-archive-position: 4307 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tledbett@bluetie.com Precedence: bulk X-list: linux-xfs Content-Length: 1517 Lines: 43 Hello. We are having some strange problems with a couple of our xfs filesystems. We have a large xfs filesystem being used to hold email data, and have encountered 'out of diskspace' error messages being generated when trying to do things like simply create a directory. However 'df' shows that there is tons of diskspace left, and tons of inodes left. The filesystem was formatted with the following parameters: - default block size of 4096 - inode size of 1024 - maxpct set to 33% In retrospect, it seems like it would of been smarter to use a blocksize of 2048 since the great majority of files are less then 4K, but I am confused as to why this would cause the 'out of diskspace' problem. Is there 'other' portions of the filesystem which could take up 33% of it? In this case there was 2.2G being reported as free by df, yet new files could not be created. Deleting existing files did allow new ones to be created. Does anyone have any ideas why this would occur or where I can turn to for more information? ____________________________________ Thomas Ledbetter Systems Administrator / Architect 585-586-2000 x1014 tledbett@bluetie.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake then delete this e-mail from your system. From owner-linux-xfs Thu Oct 21 10:48:54 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 21 Oct 2004 10:48:57 -0700 (PDT) Received: from burgers.bubbanfriends.org (IDENT:D164XXahbaQKmDjb4pQTsdQgtjRB1RP+@burgers.bubbanfriends.org [69.212.163.241]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9LHmrBd032151 for ; Thu, 21 Oct 2004 10:48:53 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 1ADC9181D91E; Thu, 21 Oct 2004 12:48:38 -0500 (EST) Received: from burgers.bubbanfriends.org ([127.0.0.1]) by localhost (burgers.bubbanfriends.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05610-08; Thu, 21 Oct 2004 12:48:37 -0500 (EST) Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id 69FA618000AD; Thu, 21 Oct 2004 12:48:37 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 66D671C1091D; Thu, 21 Oct 2004 12:48:37 -0500 (EST) Date: Thu, 21 Oct 2004 12:48:37 -0500 (EST) From: Mike Burger To: Thomas Ledbetter Cc: linux-xfs@oss.sgi.com Subject: Re: xfs out of diskspace issue In-Reply-To: <20041021123038.14764@web1.app.nyc1.bluetie.com> Message-ID: References: <20041021123038.14764@web1.app.nyc1.bluetie.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at bubbanfriends.org X-archive-position: 4308 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mburger@bubbanfriends.org Precedence: bulk X-list: linux-xfs Content-Length: 2111 Lines: 69 Could you simply be out of indoes? If so, maybe someone could clue us in on how to increase the number of inodes. On Thu, 21 Oct 2004, Thomas Ledbetter wrote: > > Hello. We are having some strange problems with a couple of our xfs filesystems. > > We have a large xfs filesystem being used to hold email data, and have > encountered 'out of diskspace' error messages being generated when trying to do > things like simply create a directory. However 'df' shows that there is tons of > diskspace left, and tons of inodes left. > > The filesystem was formatted with the following parameters: > > - default block size of 4096 > - inode size of 1024 > - maxpct set to 33% > > In retrospect, it seems like it would of been smarter to use a blocksize of > 2048 since the great majority of files are less then 4K, but I am confused as > to why this would cause the 'out of diskspace' problem. > > Is there 'other' portions of the filesystem which could take up 33% of it? > > In this case there was 2.2G being reported as free by df, yet new files could > not be created. Deleting existing files did allow new ones to be created. > > Does anyone have any ideas why this would occur or where I can turn to for > more information? > > > > ____________________________________ > Thomas Ledbetter > Systems Administrator / Architect > 585-586-2000 x1014 > tledbett@bluetie.com > > > > This message contains confidential information and is intended > only for the individual named. If you are not the named > addressee you should not disseminate, distribute or copy this > e-mail. Please notify the sender immediately by e-mail if you > have received this e-mail by mistake then delete this e-mail > from your system. > > -- Mike Burger http://www.bubbanfriends.org Visit the Dog Pound II BBS telnet://dogpound2.citadel.org or http://dogpound2.citadel.org To be notified of updates to the web site, visit http://www.bubbanfriends.org/mailman/listinfo/site-update, or send a message to: site-update-request@bubbanfriends.org with a message of: subscribe From owner-linux-xfs Thu Oct 21 11:09:20 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 21 Oct 2004 11:09:21 -0700 (PDT) Received: from mail00hq.adic.com ([63.81.117.10]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9LI9J30000871 for ; Thu, 21 Oct 2004 11:09:20 -0700 Received: from mail02hq.adic.com ([172.16.9.18]) by mail00hq.adic.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 21 Oct 2004 11:08:59 -0700 Received: from [172.16.82.67] ([172.16.82.67]) by mail02hq.adic.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 21 Oct 2004 11:08:59 -0700 Message-ID: <4177FA6C.40209@xfs.org> Date: Thu, 21 Oct 2004 13:05:32 -0500 From: Steve Lord User-Agent: Mozilla Thunderbird 0.7.1 (X11/20040626) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mike Burger CC: Thomas Ledbetter , linux-xfs@oss.sgi.com Subject: Re: xfs out of diskspace issue References: <20041021123038.14764@web1.app.nyc1.bluetie.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Oct 2004 18:08:59.0283 (UTC) FILETIME=[09A3DE30:01C4B799] X-archive-position: 4309 X-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: 302 Lines: 14 Mike Burger wrote: > Could you simply be out of indoes? > > If so, maybe someone could clue us in on how to increase the number of > inodes. > xfs_growfs can do that, use the -i option i think. Thomas did say that df reported tons of inodes free though. df -i output would be interesting. Steve From owner-linux-xfs Thu Oct 21 19:45:28 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 21 Oct 2004 19:45:30 -0700 (PDT) Received: from localhost.localdomain (CPE-144-136-105-131.nsw.bigpond.net.au [144.136.105.131]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9M2jRSf007732 for ; Thu, 21 Oct 2004 19:45:28 -0700 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.12.11/8.12.11) with ESMTP id i9M2jAX5002955 for ; Fri, 22 Oct 2004 12:45:11 +1000 Message-ID: <41787436.7090604@netscape.net> Date: Fri, 22 Oct 2004 12:45:10 +1000 From: How Wong User-Agent: Mozilla Thunderbird 0.8 (X11/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: XFS kernel 2.6 vs reiser4 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4310 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: grandsonata@netscape.net Precedence: bulk X-list: linux-xfs Content-Length: 203 Lines: 8 Hi I have been a XFS user on Fedora 2. Namesys claims Reiser4 to be faster. what would you say in terms consistency in perfomance, stability and scalability in comparison to the new Reiser4? thanks From owner-linux-xfs Fri Oct 22 00:17:12 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 22 Oct 2004 00:17:19 -0700 (PDT) Received: from mail.charite.de (mail.charite.de [160.45.207.131]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9M7HBeu026314 for ; Fri, 22 Oct 2004 00:17:12 -0700 Received: from postamt1.charite.de (postamt1.charite.de [193.175.66.246]) by mail.charite.de (Postfix) with ESMTP id 971F8220655; Fri, 22 Oct 2004 09:16:54 +0200 (CEST) Received: by postamt1.charite.de (Postfix, from userid 7945) id 8C30D633AD; Fri, 22 Oct 2004 09:16:54 +0200 (CEST) Date: Fri, 22 Oct 2004 09:16:54 +0200 From: Ralf Hildebrandt To: How Wong Cc: linux-xfs@oss.sgi.com Subject: Re: XFS kernel 2.6 vs reiser4 Message-ID: <20041022071654.GA10185@charite.de> References: <41787436.7090604@netscape.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <41787436.7090604@netscape.net> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new at charite.de X-archive-position: 4311 X-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 Content-Length: 601 Lines: 15 * How Wong : > Hi > > I have been a XFS user on Fedora 2. Namesys claims Reiser4 to be faster. > what would you say in terms consistency in perfomance, stability and > scalability in comparison to the new Reiser4? ReiseFS4 is so young, one cannot possibly tell -- Ralf Hildebrandt (i.A. des IT-Zentrum) 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 AIM. ralfpostfix From owner-linux-xfs Fri Oct 22 07:01:55 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 22 Oct 2004 07:01:58 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9ME1tTU026436 for ; Fri, 22 Oct 2004 07:01:55 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i9ME1tLD026435 for linux-xfs@oss.sgi.com; Fri, 22 Oct 2004 07:01:55 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9ME1rAC026421 for ; Fri, 22 Oct 2004 07:01:53 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i9MD67HL024511; Fri, 22 Oct 2004 06:06:07 -0700 Date: Fri, 22 Oct 2004 06:06:07 -0700 Message-Id: <200410221306.i9MD67HL024511@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 376] New: xfs_force_shutdown called from line 1088 of file fs/xfs/xfs_trans.c X-Bugzilla-Reason: AssignedTo X-archive-position: 4312 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1856 Lines: 55 http://oss.sgi.com/bugzilla/show_bug.cgi?id=376 Summary: xfs_force_shutdown called from line 1088 of file fs/xfs/xfs_trans.c Product: Linux XFS Version: unspecified Platform: IA32 OS/Version: Linux Status: NEW Severity: normal Priority: High Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: dbatchovski@technologica.com System is Debian Sarge, kernel 2.6.8.1 , xfsprogs 2.6.20-1, mdadm 1.7.0 have: xfs_force_shutdown(md2,0x8) called from line 1088 of file fs/xfs/xfs_trans.c. Return address = 0xe09f41bb When reboot follow: XFS internal error XFS_WANT_CORRUPTED_GOTO at line 866 of file fs/xfs/xfs_ialloc.c. Caller 0xe09c566c [] xfs_dialloc+0x3c5/0xb50 [xfs] [] xfs_ialloc+0x5c/0x4a0 [xfs] [] ide_build_sglist+0x3d/0xb0 [ide_core] [] xlog_grant_log_space+0x139/0x3a0 [xfs] [] xfs_ialloc+0x5c/0x4a0 [xfs] [] kmem_zone_zalloc+0x35/0x60 [xfs] [] xfs_dir_ialloc+0x91/0x2e0 [xfs] [] xfs_trans_reserve+0x84/0x1f0 [xfs] [] xfs_mkdir+0x2ad/0x740 [xfs] [] xfs_acl_vhasacl_default+0x3b/0x50 [xfs] [] linvfs_mknod+0x377/0x410 [xfs] [] do_IRQ+0xfb/0x130 [] common_interrupt+0x18/0x20 [] dput+0x31/0x220 [] in_group_p+0x42/0x80 [] xfs_iaccess+0xca/0x1b0 [xfs] [] xfs_access+0x4f/0x60 [xfs] [] linvfs_permission+0x29/0x30 [xfs] [] linvfs_mkdir+0x2a/0x30 [xfs] [] vfs_mkdir+0xb0/0x140 [] sys_mkdir+0xb8/0x100 [] syscall_call+0x7/0xb Thank you. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Fri Oct 22 12:54:28 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 22 Oct 2004 12:54:31 -0700 (PDT) Received: from mail.automatix.de (www.automatix.de [213.131.230.237]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9MJsRSu026450 for ; Fri, 22 Oct 2004 12:54:28 -0700 Received: from uucp by mail.automatix.de with local-bsmtp (Exim 3.35 #1) id 1CL5UJ-00087G-00 for linux-xfs@oss.sgi.com; Fri, 22 Oct 2004 21:54:11 +0200 Received: from pc2.s.automatix.de ([192.168.11.12] ident=jojo) by s.automatix.de with esmtp (Exim 3.36 #1) id 1CL5Nh-000689-00; Fri, 22 Oct 2004 21:47:21 +0200 From: Juergen Sauer Reply-To: juergen.sauer@automatix.de Organization: AutomatiX GmbH To: How Wong Subject: Re: XFS kernel 2.6 vs reiser4 Date: Fri, 22 Oct 2004 21:47:21 +0200 User-Agent: KMail/1.7 Cc: linux-xfs@oss.sgi.com References: <41787436.7090604@netscape.net> In-Reply-To: <41787436.7090604@netscape.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Disposition: inline Message-Id: <200410222147.21678.juergen.sauer@automatix.de> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i9MJsSSu026460 X-archive-position: 4313 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: juergen.sauer@automatix.de Precedence: bulk X-list: linux-xfs Content-Length: 844 Lines: 24 Am Freitag, 22. Oktober 2004 04:45 schrieb How Wong: > Hi > > I have been a XFS user on Fedora 2. Namesys claims Reiser4 to be > faster. what would you say in terms consistency in perfomance, > stability and scalability in comparison to the new Reiser4? Reiserfs4 is young and looks glourious in the specs and tests of the linux journals here in Germany. Within a lab for heavy duty test it may be ok, but IMHO not in productive environments. The scars from the faliures of reiserfs3 are too deep for me. I think in one or two years I will have a look. ;-> J. Sauer -- Jürgen Sauer - AutomatiX GmbH, +49-4209-4699, jojo@automatix.de ** ** Das Linux Systemhaus - Service - Support - Server - Lösungen ** ** http://www.automatix.de ICQ: #344389676 ** OpenOffice erhalten Sie hier kostenfrei http://de.openoffice.org/ From owner-linux-xfs Mon Oct 25 04:02:08 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 25 Oct 2004 04:02:11 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9PB288F018726 for ; Mon, 25 Oct 2004 04:02:08 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i9PB28KX018725 for linux-xfs@oss.sgi.com; Mon, 25 Oct 2004 04:02:08 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9PB26ec018713 for ; Mon, 25 Oct 2004 04:02:06 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i9PA2Afi016888; Mon, 25 Oct 2004 03:02:10 -0700 Date: Mon, 25 Oct 2004 03:02:10 -0700 Message-Id: <200410251002.i9PA2Afi016888@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 378] New: xfs does not set inode ctime if ATTR_CTIME flag is enabled X-Bugzilla-Reason: AssignedTo X-archive-position: 4317 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 786 Lines: 26 http://oss.sgi.com/bugzilla/show_bug.cgi?id=378 Summary: xfs does not set inode ctime if ATTR_CTIME flag is enabled Product: Linux XFS Version: Current Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: Medium Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: fsintguy@gmail.com CC: fsintguy@gmail.com xfs_setattr does not set inode ctime if ATTR_CTIME is set with attrs. xfs_setattr does not respect ATTR_CTIME, i.e, XFS_AT_CTIME unless it is coupled with ATTR_DMI flag. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Mon Oct 25 07:31:50 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 25 Oct 2004 07:31:58 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9PEVoXc029887 for ; Mon, 25 Oct 2004 07:31:50 -0700 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 25 Oct 2004 07:40:11 -0700 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i9PEVR6s013164 for ; Mon, 25 Oct 2004 07:31:28 -0700 (PDT) Received: from [64.104.13.42] (nbortnak.cisco.com [64.104.13.42]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id HAA26574 for ; Mon, 25 Oct 2004 07:31:27 -0700 (PDT) Message-ID: <417D0E3E.6030802@cisco.com> Date: Mon, 25 Oct 2004 23:31:26 +0900 From: Neil Bortnak User-Agent: Mozilla Thunderbird 0.8 (X11/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: xfs_iread_extents high order allocation failure (with fix idea) X-Enigmail-Version: 0.86.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4318 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nbortnak@cisco.com Precedence: bulk X-list: linux-xfs Content-Length: 8258 Lines: 157 Hi everyone, First off, thanks for a great filesystem. I've been using it for years without a hiccup. Currently, I have a program which does a lot of simultaneous random accesses to alot of big files on a fairly large LVM volume (1.1T). I think I have traced the problem to a number of high order (5) allocations by xfs_iread_extents. Eventually (due to memory fragmentation I guess) the system is unable to process the request. After several failed attempt the OOM killer steps in and kills the process. This appears to be the same bug as the one in June at: http://oss.sgi.com/archives/linux-xfs/2004-06/msg00079.html There is a patch included, but Nathan Scott said that Christoph wasn't entirely happy with it. I had a possible idea for a fix... Since physically contiguous pages are only strictly needed by the hardware (I understand it is a performance issue otherwise), and xfs is up a little higher than that, there shouldn't technically be a reason I couldn't use vmalloc instead of kmalloc in xfs's kmem_alloc routine, is there? More appropriately I could add a flag to the kmem_alloc routine so that it will use either one based on the preferences of the caller. Then I could use vmalloc from xfs_iread_extents, or other places where I expect a large alloc. Also, whatever is being allocated here seems to get allocated and then sticks around, so if vmalloc doesn't use the slab, the alloc/dealloc overhead still might not be too large. I am happy to write up a patch to do this and test it, but before I do anything really stupid, I thought I'd check in with you guys. Good idea? Bad idea? Neil P.S. Didn't someone recently throw in an mm patch for new/better memory defragmentation? P.P.S. Here is the stack trace that got me here and some info about my box. Also, why is there networking stuff in the trace? Pre-emption? Oct 3 20:10:11 kryten kernel: java: page allocation failure. order:5, mode:0xd0 Oct 3 20:10:12 kryten kernel: [] __alloc_pages+0x335/0x400 Oct 3 20:10:12 kryten kernel: [] __get_free_pages+0x25/0x40 Oct 3 20:10:12 kryten kernel: [] kmem_getpages+0x20/0xb0 Oct 3 20:10:12 kryten kernel: [] cache_grow+0x96/0x130 Oct 3 20:10:12 kryten kernel: [] cache_alloc_refill+0x13e/0x200 Oct 3 20:10:12 kryten kernel: [] __kmalloc+0x70/0x80 Oct 3 20:10:12 kryten kernel: [] kmem_alloc+0x59/0xc0 Oct 3 20:10:12 kryten kernel: [] xfs_iread_extents+0x4f/0x110 Oct 3 20:10:12 kryten kernel: [] ip_local_deliver_finish+0x0/0x1b0 Oct 3 20:10:12 kryten kernel: [] xfs_bmapi+0x246/0x15e0 Oct 3 20:10:12 kryten kernel: [] ip_rcv_finish+0x0/0x270 Oct 3 20:10:12 kryten kernel: [] ip_rcv_finish+0x0/0x270 Oct 3 20:10:12 kryten kernel: [] nf_hook_slow+0xc9/0x100 Oct 3 20:10:12 kryten kernel: [] ip_rcv_finish+0x0/0x270 Oct 3 20:10:12 kryten kernel: [] netif_receive_skb+0x193/0x1f0 Oct 3 20:10:12 kryten kernel: [] rtl8139_rx+0x188/0x2d0 Oct 3 20:10:12 kryten kernel: [] rtl8139_poll+0x42/0xc0 Oct 3 20:10:12 kryten kernel: [] net_rx_action+0x6a/0xf0 Oct 3 20:10:12 kryten kernel: [] xfs_iomap+0x1a6/0x550 Oct 3 20:10:12 kryten kernel: [] __alloc_pages+0x347/0x400 Oct 3 20:10:12 kryten kernel: [] linvfs_get_block_core+0xa9/0x2c0 Oct 3 20:10:12 kryten kernel: [] __get_free_pages+0x33/0x40 Oct 3 20:10:12 kryten kernel: [] cache_grow+0xde/0x130 Oct 3 20:10:12 kryten kernel: [] linvfs_get_block+0x47/0x50 Oct 3 20:10:12 kryten kernel: [] do_mpage_readpage+0x132/0x480 Oct 3 20:10:12 kryten kernel: [] unlock_page+0x1f/0x30 Oct 3 20:10:12 kryten kernel: [] radix_tree_node_alloc+0x1f/0x60 Oct 3 20:10:12 kryten kernel: [] radix_tree_insert+0xe2/0x100 Oct 3 20:10:12 kryten kernel: [] add_to_page_cache+0x52/0x70 Oct 3 20:10:12 kryten kernel: [] mpage_readpages+0x14b/0x180 Oct 3 20:10:12 kryten kernel: [] linvfs_get_block+0x0/0x50 Oct 3 20:10:12 kryten kernel: [] xfs_iformat+0x495/0x5d0 Oct 3 20:10:12 kryten kernel: [] read_pages+0x134/0x140 Oct 3 20:10:12 kryten kernel: [] linvfs_get_block+0x0/0x50 Oct 3 20:10:12 kryten kernel: [] __alloc_pages+0x347/0x400 Oct 3 20:10:12 kryten kernel: [] dm_table_any_congested+0x19/0x60 Oct 3 20:10:12 kryten kernel: [] dm_any_congested+0x30/0x60 Oct 3 20:10:12 kryten kernel: [] do_page_cache_readahead+0xcf/0x130 Oct 3 20:10:12 kryten kernel: [] page_cache_readahead+0x103/0x1f0 Oct 3 20:10:12 kryten kernel: [] do_generic_mapping_read+0xdc/0x470 Oct 3 20:10:12 kryten kernel: [] d_splice_alias+0x45/0xc0 Oct 3 20:10:12 kryten kernel: [] __generic_file_aio_read+0x1bf/0x1f0 Oct 3 20:10:12 kryten kernel: [] file_read_actor+0x0/0xf0 Oct 3 20:10:12 kryten kernel: [] xfs_read+0x155/0x270 Oct 3 20:10:12 kryten kernel: [] linvfs_read+0x8a/0xa0 Oct 3 20:10:12 kryten kernel: [] do_sync_read+0x84/0xb0 Oct 3 20:10:12 kryten kernel: [] sys_fstat64+0x37/0x40 Oct 3 20:10:12 kryten kernel: [] vfs_read+0xb8/0x130 Oct 3 20:10:12 kryten kernel: [] sys_read+0x51/0x80 Oct 3 20:10:12 kryten kernel: [] syscall_call+0x7/0xb ... more of the same ... Oct 3 20:32:00 kryten kernel: oom-killer: gfp_mask=0xd0 Oct 3 20:32:00 kryten kernel: DMA per-cpu: Oct 3 20:32:00 kryten kernel: cpu 0 hot: low 2, high 6, batch 1 Oct 3 20:32:00 kryten kernel: cpu 0 cold: low 0, high 2, batch 1 Oct 3 20:32:00 kryten kernel: Normal per-cpu: Oct 3 20:32:00 kryten kernel: cpu 0 hot: low 32, high 96, batch 16 Oct 3 20:32:00 kryten kernel: cpu 0 cold: low 0, high 32, batch 16 Oct 3 20:32:00 kryten kernel: HighMem per-cpu: Oct 3 20:32:00 kryten kernel: cpu 0 hot: low 14, high 42, batch 7 Oct 3 20:32:00 kryten kernel: cpu 0 cold: low 0, high 14, batch 7 Oct 3 20:32:00 kryten kernel: Oct 3 20:32:00 kryten kernel: Free pages: 389392kB (252kB HighMem) Oct 3 20:32:00 kryten kernel: Active:125049 inactive:4968 dirty:0 writeback:5 unstable:0 free:97348 slab:23724 mapped:124183 pagetables:813 Oct 3 20:32:01 kryten kernel: DMA free:1932kB min:16kB low:32kB high:48kB active:1512kB inactive:0kB present:16384kB Oct 3 20:32:01 kryten kernel: protections[]: 8 476 540 Oct 3 20:32:01 kryten kernel: Normal free:387208kB min:936kB low:1872kB high:2808kB active:393700kB inactive:1408kB present:901120kB Oct 3 20:32:01 kryten kernel: protections[]: 0 468 532 Oct 3 20:32:01 kryten kernel: HighMem free:252kB min:128kB low:256kB high:384kB active:104984kB inactive:18464kB present:131008kB Oct 3 20:32:01 kryten kernel: protections[]: 0 0 64 Oct 3 20:32:01 kryten kernel: DMA: 55*4kB 18*8kB 4*16kB 15*32kB 6*64kB 1*128kB 0*256kB 1*512kB 0*1024kB 0*2048kB 0*4096kB = 1932kB Oct 3 20:32:01 kryten kernel: Normal: 39944*4kB 18555*8kB 4213*16kB 336*32kB 13*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 387208kB Oct 3 20:32:01 kryten kernel: HighMem: 1*4kB 1*8kB 1*16kB 5*32kB 1*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 252kB Oct 3 20:32:01 kryten kernel: Swap cache: add 7820, delete 7788, find 1504/1705, race 0+0 Using Con Kolivas' patchset Linux kryten 2.6.8.1-ck7 #2 Tue Sep 14 23:12:49 JST 2004 i686 GNU/Linux total used free shared buffers cached Mem: 1035300 998228 37072 0 6884 329440 -/+ buffers/cache: 661904 373396 Swap: 2000080 143652 1856428 processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 10 model name : AMD Athlon(tm) stepping : 0 cpu MHz : 1111.224 cache size : 512 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow bogomips : 2187.26 From owner-linux-xfs Mon Oct 25 08:01:05 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 25 Oct 2004 08:01:07 -0700 (PDT) Received: from bulge.astrouw.edu.pl (bulge.astrouw.edu.pl [193.0.88.25]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9PF11nB031565 for ; Mon, 25 Oct 2004 08:01:04 -0700 Received: from bulge.astrouw.edu.pl (localhost [127.0.0.1]) by bulge.astrouw.edu.pl (8.12.11/8.12.11) with ESMTP id i9PF0bae004928 for ; Mon, 25 Oct 2004 17:00:37 +0200 Received: (from msz@localhost) by bulge.astrouw.edu.pl (8.12.11/8.12.11/Submit) id i9PF0bFf004925 for linux-xfs@oss.sgi.com; Mon, 25 Oct 2004 17:00:37 +0200 Date: Mon, 25 Oct 2004 17:00:37 +0200 From: Michal Szymanski To: linux-xfs@oss.sgi.com Subject: xfs_check problems on 3.6TB fs Message-ID: <20041025150037.GA4665@astrouw.edu.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-archive-position: 4319 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: msz@astrouw.edu.pl Precedence: bulk X-list: linux-xfs Content-Length: 1268 Lines: 41 Hi, I have successfully installed XFS filesystem on a software RAID0 /dev/md0 partition made of two sub-2TB pieces of a hardware RAID array. The total size is 3.6TB. The system is a Fedora Core 2, dual Xean 3.06GHz, Tyan Tiger i7501 mobo, 2.6.7-1.494.2.2smp kernel, xfsprogs-2.6.13-1. I can mount/umount, write/read to the filesystem, no problem. I am getting into a problem when trying to check the filesystem. It seems a bit confusing: >fsck /dev/md0 fsck 1.35 (28-Feb-2004) >fsck.xfs /dev/md0 (no output at all) >xfs_check /dev/md0 xfs_check: out of memory The "out of memory" message is mentioned in the xfs_check man-page, as a possible problem with a filesystem that is "very large (has many files)". Well, while in terms of total capacity my FS is indeed "very large", it is not (yet) in terms of "has many files"). At the moment there are just three directories made there and a single file (same message with no files). "xfs_repair" seems to work fine (although I only ran it on a cleanly unmounted FS). Any feedback would be appreciated. I am a bit reluctant to put my valuable data on a filesystem which can't be checked. regards, Michal. -- Michal Szymanski (msz at astrouw dot edu dot pl) Warsaw University Observatory, Warszawa, POLAND From owner-linux-xfs Mon Oct 25 12:41:34 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 25 Oct 2004 12:41:40 -0700 (PDT) Received: from mail.charite.de (mail.charite.de [160.45.207.131]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9PJfXDM016860 for ; Mon, 25 Oct 2004 12:41:34 -0700 Received: from postamt1.charite.de (postamt1.charite.de [193.175.66.246]) by mail.charite.de (Postfix) with ESMTP id 7A610220653 for ; Mon, 25 Oct 2004 21:41:15 +0200 (CEST) Received: by postamt1.charite.de (Postfix, from userid 7945) id 71DAF633A8; Mon, 25 Oct 2004 21:41:15 +0200 (CEST) Date: Mon, 25 Oct 2004 21:41:15 +0200 From: Ralf Hildebrandt To: linux-xfs@oss.sgi.com Subject: Re: SGI 320 Message-ID: <20041025194115.GS15353@charite.de> References: <33100.192.168.10.1.1098733050.squirrel@192.168.10.1> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <33100.192.168.10.1.1098733050.squirrel@192.168.10.1> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new at charite.de X-archive-position: 4321 X-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 Content-Length: 474 Lines: 12 * xlogic@binaryflux.net : > I have a sgi 320 system and I don't know if I can install linux on it . http://www.state-of-mind.de/debug.html -- Ralf Hildebrandt (i.A. des IT-Zentrum) 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 AIM. ralfpostfix From owner-linux-xfs Mon Oct 25 12:38:01 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 25 Oct 2004 12:38:03 -0700 (PDT) Received: from mail.binaryflux.net (xlogic.myftp.org [81.196.36.206] (may be forged)) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9PJc0s6016481 for ; Mon, 25 Oct 2004 12:38:01 -0700 Received: (qmail 14039 invoked by uid 1016); 25 Oct 2004 22:37:35 +0300 Received: from xlogic@binaryflux.net by Hymera by uid 1012 with qmail-scanner-1.22-st-qms ( Clear:RC:1(127.0.0.1):. Processed in 4.788331 secs); 25 Oct 2004 19:37:35 -0000 X-Antivirus-MYDOMAIN-Mail-From: xlogic@binaryflux.net via Hymera X-Antivirus-MYDOMAIN: 1.22-st-qms (Clear:RC:1(127.0.0.1):. Processed in 4.788331 secs Process 14034) Received: from localhost (HELO mail.binaryflux.net) (xlogic@binaryflux.net@127.0.0.1) by mail.binaryflux.net with SMTP; 25 Oct 2004 22:37:30 +0300 Received: from 192.168.10.1 (SquirrelMail authenticated user xlogic@binaryflux.net); by mail.binaryflux.net with HTTP; Mon, 25 Oct 2004 22:37:30 +0300 (EEST) Message-ID: <33100.192.168.10.1.1098733050.squirrel@192.168.10.1> Date: Mon, 25 Oct 2004 22:37:30 +0300 (EEST) Subject: SGI 320 From: xlogic@binaryflux.net To: linux-xfs@oss.sgi.com User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-archive-position: 4320 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: xlogic@binaryflux.net Precedence: bulk X-list: linux-xfs Content-Length: 227 Lines: 10 Hello . I have a problem and i think you can help me I have a sgi 320 system and I don't know if I can install linux on it . Please tell me if it's possible to run linux on this box and tell me what kernel to use Thank You From owner-linux-xfs Mon Oct 25 23:44:57 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 25 Oct 2004 23:45:01 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9Q6iv5l016349 for ; Mon, 25 Oct 2004 23:44:57 -0700 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 25 Oct 2004 23:53:26 -0700 Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i9Q6iRYJ020135 for ; Mon, 25 Oct 2004 23:44:27 -0700 (PDT) Received: from [64.104.13.42] (nbortnak.cisco.com [64.104.13.42]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id XAA16212; Mon, 25 Oct 2004 23:44:33 -0700 (PDT) Message-ID: <417DF250.2000803@cisco.com> Date: Tue, 26 Oct 2004 15:44:32 +0900 From: Neil Bortnak User-Agent: Mozilla Thunderbird 0.8 (X11/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Neil Bortnak CC: linux-xfs@oss.sgi.com Subject: Re: xfs_iread_extents high order allocation failure (with fix idea) References: <417D0E3E.6030802@cisco.com> In-Reply-To: <417D0E3E.6030802@cisco.com> X-Enigmail-Version: 0.86.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 4322 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nbortnak@cisco.com Precedence: bulk X-list: linux-xfs Content-Length: 2694 Lines: 67 Neil Bortnak wrote: > Hi everyone, > > First off, thanks for a great filesystem. I've been using it for years > without a > hiccup. > > Currently, I have a program which does a lot of simultaneous random > accesses to > alot of big files on a fairly large LVM volume (1.1T). I think I have > traced > the problem to a number of high order (5) allocations by xfs_iread_extents. > Eventually (due to memory fragmentation I guess) the system is unable to > process the request. After several failed attempt the OOM killer steps > in and > kills the process. > > This appears to be the same bug as the one in June at: > http://oss.sgi.com/archives/linux-xfs/2004-06/msg00079.html > There is a patch included, but Nathan Scott said that Christoph wasn't > entirely > happy with it. I had a possible idea for a fix... > > Since physically contiguous pages are only strictly needed by the > hardware (I > understand it is a performance issue otherwise), and xfs is up a little > higher > than that, there shouldn't technically be a reason I couldn't use vmalloc > instead of kmalloc in xfs's kmem_alloc routine, is there? > > More appropriately I could add a flag to the kmem_alloc routine so that > it will > use either one based on the preferences of the caller. Then I could use > vmalloc > from xfs_iread_extents, or other places where I expect a large alloc. Also, > whatever is being allocated here seems to get allocated and then sticks > around, > so if vmalloc doesn't use the slab, the alloc/dealloc overhead still > might not > be too large. > > I am happy to write up a patch to do this and test it, but before I do > anything > really stupid, I thought I'd check in with you guys. > > Good idea? Bad idea? > > Neil > Ok, I guess I was paying attention to the wrong thing when I was going through the code. I now know that I can use vmalloc in kmem_alloc because... it's already there, which is triggered by a request that is too large. Just like I wanted really. Doh! Sorry for my list-posted blunder. In any case, what I don't get is that my error is due to a failure allocating a 128k block (order 5), when the MAX_SLAB_SIZE is set to 64k (order 4). I don't understand why kmalloc would try to allocate 128k of pages for what should be a 64k slab (as that's out max size). There doesn't seem to be a mechanism for allocating extra memory just in case you need another object. It allocates just enough pages to fulfill the request. Odd... In any case I am going to apply the patch offered in the previous discussion and toy with the idea of setting MAX_SLAB_SIZE to 32k. Will there be/is there an approved fix for this coming soon? Thanks, Neil From owner-linux-xfs Tue Oct 26 02:39:46 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 26 Oct 2004 02:39:49 -0700 (PDT) Received: from mail.vcc.de (mail.vcc.de [217.111.2.122]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9Q9dkOj027146 for ; Tue, 26 Oct 2004 02:39:46 -0700 Received: from localhost (localhost [127.0.0.1]) by mail.vcc.de (Postfix) with ESMTP id CCC20161F32 for ; Tue, 26 Oct 2004 11:39:29 +0200 (CEST) Received: from mail.vcc.de ([127.0.0.1]) by localhost (mail.vcc.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06002-06 for ; Tue, 26 Oct 2004 11:39:28 +0200 (CEST) Received: from [192.9.209.64] (wolverine.vcc.de [217.111.2.200]) by mail.vcc.de (Postfix) with ESMTP id BB6D2161EC2 for ; Tue, 26 Oct 2004 11:39:28 +0200 (CEST) Message-ID: <417E1B4E.6040407@opticalart.de> Date: Tue, 26 Oct 2004 11:39:26 +0200 From: Frank Hellmann Organization: Optical Art Film- und Special-Effects GmbH User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: SGI 320 References: <33100.192.168.10.1.1098733050.squirrel@192.168.10.1> <20041025194115.GS15353@charite.de> In-Reply-To: <20041025194115.GS15353@charite.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at vcc.de X-archive-position: 4323 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: frank@opticalart.de Precedence: bulk X-list: linux-xfs Content-Length: 471 Lines: 19 Ralf Hildebrandt wrote: > * xlogic@binaryflux.net : > > > http://www.state-of-mind.de/debug.html > That link really saved my day! :-))) Cheers, Frank... -- -------------------------------------------------------------------------- Frank Hellmann Optical Art GmbH Waterloohain 7a DI Supervisor http://www.opticalart.de 22769 Hamburg frank@opticalart.de Tel: ++49 40 5111051 Fax: ++49 40 43169199 From owner-linux-xfs Tue Oct 26 03:26:53 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 26 Oct 2004 03:26:57 -0700 (PDT) Received: from mail.vcc.de (mail.vcc.de [217.111.2.122]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9QAQqXW030301 for ; Tue, 26 Oct 2004 03:26:52 -0700 Received: from localhost (localhost [127.0.0.1]) by mail.vcc.de (Postfix) with ESMTP id 69243161F32 for ; Tue, 26 Oct 2004 12:26:36 +0200 (CEST) Received: from mail.vcc.de ([127.0.0.1]) by localhost (mail.vcc.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07028-10 for ; Tue, 26 Oct 2004 12:26:35 +0200 (CEST) Received: from [192.9.209.64] (wolverine.vcc.de [217.111.2.200]) by mail.vcc.de (Postfix) with ESMTP id 17482161EC2 for ; Tue, 26 Oct 2004 12:26:35 +0200 (CEST) Message-ID: <417E2658.6060603@opticalart.de> Date: Tue, 26 Oct 2004 12:26:32 +0200 From: Frank Hellmann Organization: Optical Art Film- und Special-Effects GmbH User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: XFS List Subject: Re: xfs_check problems on 3.6TB fs References: <20041025150037.GA4665@astrouw.edu.pl> In-Reply-To: <20041025150037.GA4665@astrouw.edu.pl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at vcc.de X-archive-position: 4324 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: frank@opticalart.de Precedence: bulk X-list: linux-xfs Content-Length: 2187 Lines: 72 Hi Michael! Similar effects here. Basically we have the same setup (Hardware RAID5 with Software RAID0 striped together). I ran into some problems during a xfs_repair. See these articles: http://marc.theaimsgroup.com/?l=linux-xfs&m=109714077512194&w=2 http://marc.theaimsgroup.com/?l=linux-xfs&m=109719162327429&w=2 Not to good news, I am afraid. We are currently working on a scheme to cache our files into multiple directories instead of the filesystem root. That as far as I can tell helps to avoid this issue. So you shouldn't run into these during xfs_repair. Concering xfs_check... anyone? Cheers, Frank... Michal Szymanski wrote: > Hi, > > I have successfully installed XFS filesystem on a software RAID0 > /dev/md0 partition made of two sub-2TB pieces of a hardware RAID array. > The total size is 3.6TB. > > The system is a Fedora Core 2, dual Xean 3.06GHz, Tyan Tiger i7501 > mobo, 2.6.7-1.494.2.2smp kernel, xfsprogs-2.6.13-1. > > I can mount/umount, write/read to the filesystem, no problem. > > I am getting into a problem when trying to check the filesystem. It > seems a bit confusing: > > >>fsck /dev/md0 > > fsck 1.35 (28-Feb-2004) > > >>fsck.xfs /dev/md0 > > (no output at all) > > >>xfs_check /dev/md0 > > xfs_check: out of memory > > The "out of memory" message is mentioned in the xfs_check man-page, as a > possible problem with a filesystem that is "very large (has many files)". > Well, while in terms of total capacity my FS is indeed "very large", it > is not (yet) in terms of "has many files"). At the moment there are just > three directories made there and a single file (same message with no files). > > "xfs_repair" seems to work fine (although I only ran it on a cleanly > unmounted FS). > > Any feedback would be appreciated. I am a bit reluctant to put my > valuable data on a filesystem which can't be checked. > > regards, Michal. > -- -------------------------------------------------------------------------- Frank Hellmann Optical Art GmbH Waterloohain 7a DI Supervisor http://www.opticalart.de 22769 Hamburg frank@opticalart.de Tel: ++49 40 5111051 Fax: ++49 40 43169199 From owner-linux-xfs Tue Oct 26 15:57:55 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 26 Oct 2004 15:57:58 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9QMvtc8009087 for ; Tue, 26 Oct 2004 15:57:55 -0700 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [198.149.16.14]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i9R0C2uh003090 for ; Tue, 26 Oct 2004 17:12:03 -0700 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by ledzep.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i9QMuSk42755405; Tue, 26 Oct 2004 17:56:28 -0500 (CDT) Received: from hch by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1CMaEt-0005kH-00; Tue, 26 Oct 2004 17:56:27 -0500 To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Subject: TAKE 923607 - remove useless S_ISREG check in ->mmap and ->mprotect Message-Id: From: Christoph Hellwig Date: Tue, 26 Oct 2004 17:56:27 -0500 X-archive-position: 4325 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 703 Lines: 19 Date: Tue Oct 26 15:56:13 PDT 2004 Workarea: maine.americas.sgi.com:/home/daisy40/hch/ptools/xfs-2.4.x Inspected by: nathans, roehrich The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.4.x-xfs Modid: xfs-linux:xfs-kern:181620a fs/xfs/linux-2.6/xfs_file.c - 1.109 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_file.c.diff?r1=text&tr1=1.109&r2=text&tr2=1.108&f=h - remove check for regular files in linvfs_mmap and linvfs_mprotect fs/xfs/linux-2.4/xfs_file.c - 1.108 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_file.c.diff?r1=text&tr1=1.108&r2=text&tr2=1.107&f=h - remove check for regular files in linvfs_mmap and linvfs_mprotect From owner-linux-xfs Wed Oct 27 02:00:28 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 27 Oct 2004 02:00:31 -0700 (PDT) Received: from bulge.astrouw.edu.pl (bulge.astrouw.edu.pl [193.0.88.25]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9R90OwO008897 for ; Wed, 27 Oct 2004 02:00:27 -0700 Received: from bulge.astrouw.edu.pl (localhost [127.0.0.1]) by bulge.astrouw.edu.pl (8.12.11/8.12.11) with ESMTP id i9R901jp030354 for ; Wed, 27 Oct 2004 11:00:01 +0200 Received: (from msz@localhost) by bulge.astrouw.edu.pl (8.12.11/8.12.11/Submit) id i9R900Fp030351 for linux-xfs@oss.sgi.com; Wed, 27 Oct 2004 11:00:00 +0200 Date: Wed, 27 Oct 2004 11:00:00 +0200 From: Michal Szymanski To: linux-xfs@oss.sgi.com Subject: Re: xfs_check problems on 3.6TB fs Message-ID: <20041027090000.GA29337@astrouw.edu.pl> References: <20041025150037.GA4665@astrouw.edu.pl> <417E216A.2090503@opticalart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <417E216A.2090503@opticalart.de> User-Agent: Mutt/1.4.1i X-archive-position: 4326 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: msz@astrouw.edu.pl Precedence: bulk X-list: linux-xfs Content-Length: 2278 Lines: 53 On Tue, Oct 26, 2004 at 12:05:30PM +0200, Frank Hellmann wrote: > Similar effects here. Basically we have the same setup (Hardware RAID5 > with Software RAID0 striped together). I ran into some problems during a > xfs_repair. See these articles: > > http://marc.theaimsgroup.com/?l=linux-xfs&m=109714077512194&w=2 > > http://marc.theaimsgroup.com/?l=linux-xfs&m=109719162327429&w=2 > > Not to good news, I am afraid. We are currently working on a scheme to > cache our files into multiple directories instead of the filesystem > root. That as far as I can tell helps to avoid this issue. So you > shouldn't run into these during xfs_repair. > > Concering xfs_check... anyone? Well, I am even more confused now. I got "attracted" to XFS by reading a comparison between XFS and EXT3 which stated that EXT3 on a huge partition is a memory and time hog. Indeed, I have several hardware RAID arrays sliced into sub-2TB partitions with EXT3 FS, and it takes a few hours to complete a filesystem check after a crash. Well, but it completes. Now the XFS, advertized as a true 64-bit FS, capable of dealing with Petabytes, seems to be unable to check an almost empty partition and/or repair a partition with several hundred thousand files. On the other hand, I've read a page "Who's using XFS" with some important projects (like Sloan Digital Sky Survey) generating huge amounts of data. Do they also have partitions that they cannot check/repair? The oss.sgi.com/projects/xfs pages content suggests that actually 'fcsk' is not needed anymore on a journalling FS like XFS. So maybe we can just live without it? To resume, could someone tell me whether I can safely put my data on a 3.6TB XFS filesystem or not? The machine it is currently attached to has 4GB RAM + 2GB Swap. If this is not enough for XFS to do a check/repair, I would say it is not a solution for me. regards, Michal. PS. I've just found, on http://oss.sgi.com/projects/xfs/irix-linux.html > Linux XFS filesystems are limited to 2 Terabytes in size due to > limitations in the Linux block device I/O layers. Is it just an out-of-date page? Or, maybe, it is just the true reason of our problems? -- Michal Szymanski (msz at astrouw dot edu dot pl) Warsaw University Observatory, Warszawa, POLAND From owner-linux-xfs Wed Oct 27 02:54:56 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 27 Oct 2004 02:54:59 -0700 (PDT) Received: from bulge.astrouw.edu.pl (bulge.astrouw.edu.pl [193.0.88.25]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9R9st2Q013018 for ; Wed, 27 Oct 2004 02:54:56 -0700 Received: from bulge.astrouw.edu.pl (localhost [127.0.0.1]) by bulge.astrouw.edu.pl (8.12.11/8.12.11) with ESMTP id i9R9sY5E031602 for ; Wed, 27 Oct 2004 11:54:34 +0200 Received: (from msz@localhost) by bulge.astrouw.edu.pl (8.12.11/8.12.11/Submit) id i9R9sY8K031599 for linux-xfs@oss.sgi.com; Wed, 27 Oct 2004 11:54:34 +0200 Date: Wed, 27 Oct 2004 11:54:34 +0200 From: Michal Szymanski To: linux-xfs@oss.sgi.com Subject: Re: xfs_check problems on 3.6TB fs Message-ID: <20041027095434.GA30788@astrouw.edu.pl> References: <20041025150037.GA4665@astrouw.edu.pl> <417E216A.2090503@opticalart.de> <20041027090000.GA29337@astrouw.edu.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041027090000.GA29337@astrouw.edu.pl> User-Agent: Mutt/1.4.1i X-archive-position: 4327 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: msz@astrouw.edu.pl Precedence: bulk X-list: linux-xfs Content-Length: 1072 Lines: 27 On Wed, Oct 27, 2004 at 11:00:00AM +0200, Michal Szymanski wrote: > > To resume, could someone tell me whether I can safely put my data on a > 3.6TB XFS filesystem or not? The machine it is currently attached to > has 4GB RAM + 2GB Swap. If this is not enough for XFS to do a > check/repair, I would say it is not a solution for me. > > PS. I've just found, on http://oss.sgi.com/projects/xfs/irix-linux.html > > > Linux XFS filesystems are limited to 2 Terabytes in size due to > > limitations in the Linux block device I/O layers. > > Is it just an out-of-date page? Or, maybe, it is just the true reason of > our problems? PS2. I have made a following test: I stopped the software RAID and created two separate XFS systems on both "slices", seen by the system as /dev/sda1 and /dev/sdb1. One is just below 2TB, the other is 1.6TB. xfs_check works silently on such a (clean) filesystem. So maybe it is really the 2TB limit that makes the diffrence? Michal. -- Michal Szymanski (msz at astrouw dot edu dot pl) Warsaw University Observatory, Warszawa, POLAND From owner-linux-xfs Wed Oct 27 03:12:22 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 27 Oct 2004 03:12:24 -0700 (PDT) Received: from bulge.astrouw.edu.pl (bulge.astrouw.edu.pl [193.0.88.25]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9RACL7q013759 for ; Wed, 27 Oct 2004 03:12:22 -0700 Received: from bulge.astrouw.edu.pl (localhost [127.0.0.1]) by bulge.astrouw.edu.pl (8.12.11/8.12.11) with ESMTP id i9RAC0An032002 for ; Wed, 27 Oct 2004 12:12:00 +0200 Received: (from msz@localhost) by bulge.astrouw.edu.pl (8.12.11/8.12.11/Submit) id i9RAC0ZP031997 for linux-xfs@oss.sgi.com; Wed, 27 Oct 2004 12:12:00 +0200 Date: Wed, 27 Oct 2004 12:12:00 +0200 From: Michal Szymanski To: linux-xfs@oss.sgi.com Subject: strange result of an XFS crash test Message-ID: <20041027101200.GB30788@astrouw.edu.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-archive-position: 4328 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: msz@astrouw.edu.pl Precedence: bulk X-list: linux-xfs Content-Length: 2741 Lines: 63 Hi, Experimenting on how reliable is XFS, I made a following test on my Fedora Core 2 system, dual Xean 3.06GHz, Tyan Tiger i7501 mobo, 2.6.7-1.494.2.2smp kernel, xfsprogs-2.6.13-1: On a just-below-2TB filesystem, I ran a script generating 4MB files x.NNNNN, with NNNNN going from 00001 to 10000. Just before the script ended, I did hardware reset and, on rebooting, I chose "file system checking of an uncleanly shut system" that Fedora offers at boot time. I cound not see the XFS filesystem (/export/data2) being checked (it was showing checking /, /usr and /export/data - all EXT3 filesystems). After reboot, the root directory of the XFS partition looked a bit strange. I would expect some problems with last-created files x.NNNNN It was, however, not quite so. The last file present is x.09426. The first file with bad size (3145728 instead of 4194304) is x.08165, with the creation date of about 2 minutes earlier than the last one. There is total of 61 files of bad size, "randomly" distributed between x.08165 and x.09426. A short excerpt from 'ls -l' output follows: -rw-r--r-- 1 root bin 4194304 Oct 27 11:36 x.09403 -rw-r--r-- 1 root bin 2097152 Oct 27 11:36 x.09404 -rw-r--r-- 1 root bin 0 Oct 27 11:36 x.09405 -rw-r--r-- 1 root bin 4194304 Oct 27 11:36 x.09406 -rw-r--r-- 1 root bin 4194304 Oct 27 11:36 x.09407 -rw-r--r-- 1 root bin 4194304 Oct 27 11:36 x.09408 -rw-r--r-- 1 root bin 0 Oct 27 11:36 x.09409 -rw-r--r-- 1 root bin 4194304 Oct 27 11:36 x.09410 -rw-r--r-- 1 root bin 4194304 Oct 27 11:36 x.09411 -rw-r--r-- 1 root bin 3145728 Oct 27 11:36 x.09412 -rw-r--r-- 1 root bin 0 Oct 27 11:36 x.09413 -rw-r--r-- 1 root bin 0 Oct 27 11:36 x.09414 -rw-r--r-- 1 root bin 0 Oct 27 11:36 x.09415 -rw-r--r-- 1 root bin 0 Oct 27 11:36 x.09416 -rw-r--r-- 1 root bin 0 Oct 27 11:36 x.09417 -rw-r--r-- 1 root bin 0 Oct 27 11:36 x.09418 -rw-r--r-- 1 root bin 4194304 Oct 27 11:36 x.09419 -rw-r--r-- 1 root bin 4194304 Oct 27 11:36 x.09420 As I was not sure whether the FS had been really checked during the reboot, I did xfs_repair manually, but nothing changed. It that what I should expect from a journalling file system? BTW, with a "standard" /etc/fstab entry: /dev/sda1 /export/data2 xfs defaults 1 2 is it going to be checked/repaired if needed at boot time? With EXT2/3 FS, "fsck" does both check and repair. With XFS, this job seems to be splitted into xfs_check and xfs_repair? Is the system "fsck" wrapper aware of that? regards, Michal. -- Michal Szymanski (msz at astrouw dot edu dot pl) Warsaw University Observatory, Warszawa, POLAND From owner-linux-xfs Wed Oct 27 04:24:40 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 27 Oct 2004 04:24:45 -0700 (PDT) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9RBOevA020253 for ; Wed, 27 Oct 2004 04:24:40 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i9RBOOxT032135 for ; Wed, 27 Oct 2004 06:24:24 -0500 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i9RBODBV809109; Wed, 27 Oct 2004 06:24:13 -0500 (CDT) Received: from hch by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1CMluX-0002FK-00; Wed, 27 Oct 2004 06:24:13 -0500 To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Subject: TAKE 923980 - splitup pagebuf_get Message-Id: From: Christoph Hellwig Date: Wed, 27 Oct 2004 06:24:13 -0500 X-archive-position: 4329 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1310 Lines: 29 Date: Wed Oct 27 04:23:21 PDT 2004 Workarea: maine.americas.sgi.com:/home/daisy40/hch/ptools/xfs-2.4.x Inspected by: tes The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.4.x-xfs Modid: xfs-linux:xfs-kern:181653a fs/xfs/linux-2.4/xfs_buf.h - 1.106 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_buf.h.diff?r1=text&tr1=1.106&r2=text&tr2=1.105&f=h fs/xfs/linux-2.6/xfs_buf.h - 1.100 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_buf.h.diff?r1=text&tr1=1.100&r2=text&tr2=1.99&f=h - use xfs_buf_get_flags and xfs_buf_read_flags directly fs/xfs/linux-2.4/xfs_buf.c - 1.196 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_buf.c.diff?r1=text&tr1=1.196&r2=text&tr2=1.195&f=h fs/xfs/linux-2.6/xfs_buf.c - 1.178 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_buf.c.diff?r1=text&tr1=1.178&r2=text&tr2=1.177&f=h - split pagebuf_get into xfs_buf_get_flags and xfs_buf_read_flags fs/xfs/linux-2.4/xfs_ksyms.c - 1.9 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_ksyms.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h fs/xfs/linux-2.6/xfs_ksyms.c - 1.12 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_ksyms.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h - export _pagebuf_find instead of pagebuf_find From owner-linux-xfs Wed Oct 27 04:44:57 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 27 Oct 2004 04:45:01 -0700 (PDT) Received: from mail.vcc.de (mail.vcc.de [217.111.2.122]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9RBiucq021357 for ; Wed, 27 Oct 2004 04:44:56 -0700 Received: from localhost (localhost [127.0.0.1]) by mail.vcc.de (Postfix) with ESMTP id B0113162148 for ; Wed, 27 Oct 2004 13:44:39 +0200 (CEST) Received: from mail.vcc.de ([127.0.0.1]) by localhost (mail.vcc.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31597-01 for ; Wed, 27 Oct 2004 13:44:37 +0200 (CEST) Received: from [192.9.209.64] (wolverine.vcc.de [217.111.2.200]) by mail.vcc.de (Postfix) with ESMTP id CD293161F32 for ; Wed, 27 Oct 2004 13:44:37 +0200 (CEST) Message-ID: <417F8A23.6040009@opticalart.de> Date: Wed, 27 Oct 2004 13:44:35 +0200 From: Frank Hellmann Organization: Optical Art Film- und Special-Effects GmbH User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: xfs_check problems on 3.6TB fs References: <20041025150037.GA4665@astrouw.edu.pl> <417E216A.2090503@opticalart.de> <20041027090000.GA29337@astrouw.edu.pl> In-Reply-To: <20041027090000.GA29337@astrouw.edu.pl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at vcc.de X-archive-position: 4330 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: frank@opticalart.de Precedence: bulk X-list: linux-xfs Content-Length: 4206 Lines: 106 Hi Michal! Michal Szymanski wrote: > On Tue, Oct 26, 2004 at 12:05:30PM +0200, Frank Hellmann wrote: > > >>Similar effects here. Basically we have the same setup (Hardware RAID5 >>with Software RAID0 striped together). I ran into some problems during a >>xfs_repair. See these articles: >> >>http://marc.theaimsgroup.com/?l=linux-xfs&m=109714077512194&w=2 >> >>http://marc.theaimsgroup.com/?l=linux-xfs&m=109719162327429&w=2 >> >>Not to good news, I am afraid. We are currently working on a scheme to >>cache our files into multiple directories instead of the filesystem >>root. That as far as I can tell helps to avoid this issue. So you >>shouldn't run into these during xfs_repair. >> >>Concering xfs_check... anyone? > > > Well, I am even more confused now. I got "attracted" to XFS by reading a > comparison between XFS and EXT3 which stated that EXT3 on a huge > partition is a memory and time hog. Don't be confused. XFS is a giant leap forward, at least from my view. Remember the Large Block Device (2+ TB devices) support is working "correctly" since Kernel 2.6.6. So there might be a few issues that have not showed up until recently. > Indeed, I have several hardware RAID > arrays sliced into sub-2TB partitions with EXT3 FS, and it takes a few > hours to complete a filesystem check after a crash. Well, but it > completes. Now the XFS, advertized as a true 64-bit FS, capable of > dealing with Petabytes, seems to be unable to check an almost empty > partition and/or repair a partition with several hundred thousand files. We have two production servers running a similar setup. We work with film images that are usually 10MB-60MB in size and about 130.000 files minimum. Except for that one issue (putting everything into the filesystem root) this works really well, has good performance and is stable. We have way more issues with the nvidia drivers, than anything else. It seems to me, that xfs_check is running into some wrap-around bug at the 2TB limit and just spits out the "out of memory" error. I don't have sufficent knowledge to fix this (IMHO there is a bigger chance of me breaking it completly). > > On the other hand, I've read a page "Who's using XFS" with some > important projects (like Sloan Digital Sky Survey) generating huge > amounts of data. Do they also have partitions that they cannot check/repair? I am guessing that they use IRIX and that is known to support larger devices since quiet some time. I guess the user-tools will just catch up with the new kernel features soon. As I said LBD is known to be working since only a _few_ month. > > The oss.sgi.com/projects/xfs pages content suggests that actually 'fcsk' > is not needed anymore on a journalling FS like XFS. So maybe we can just > live without it? > No. There will be times, you'll need it. Powerloss is never going to give you predictable results. > To resume, could someone tell me whether I can safely put my data on a > 3.6TB XFS filesystem or not? The machine it is currently attached to > has 4GB RAM + 2GB Swap. If this is not enough for XFS to do a > check/repair, I would say it is not a solution for me. As I said, in a very unlikely event (about 500.000 files in the fs-root, + Nvidia driver crashing the machine) there is an issue repairing it. I all other cases we never had an issue with xfs and the xfs_repair. And we have to run xfs_repair at least once a week due to the nvidia crashes and hard resets. > > regards, Michal. > > PS. I've just found, on http://oss.sgi.com/projects/xfs/irix-linux.html > > >>Linux XFS filesystems are limited to 2 Terabytes in size due to >>limitations in the Linux block device I/O layers. > > > Is it just an out-of-date page? Or, maybe, it is just the true reason of > our problems? > A bit outdated I would say. But maybe someone else would like to comment on the LBD stability and sanity? Cheers, Frank... -- -------------------------------------------------------------------------- Frank Hellmann Optical Art GmbH Waterloohain 7a DI Supervisor http://www.opticalart.de 22769 Hamburg frank@opticalart.de Tel: ++49 40 5111051 Fax: ++49 40 43169199 From owner-linux-xfs Wed Oct 27 04:51:06 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 27 Oct 2004 04:51:08 -0700 (PDT) Received: from mail.vcc.de (mail.vcc.de [217.111.2.122]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9RBp5Cl021752 for ; Wed, 27 Oct 2004 04:51:05 -0700 Received: from localhost (localhost [127.0.0.1]) by mail.vcc.de (Postfix) with ESMTP id 78473162187 for ; Wed, 27 Oct 2004 13:50:49 +0200 (CEST) Received: from mail.vcc.de ([127.0.0.1]) by localhost (mail.vcc.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31034-08 for ; Wed, 27 Oct 2004 13:50:48 +0200 (CEST) Received: from [192.9.209.64] (wolverine.vcc.de [217.111.2.200]) by mail.vcc.de (Postfix) with ESMTP id 0A341162148 for ; Wed, 27 Oct 2004 13:50:48 +0200 (CEST) Message-ID: <417F8B95.4030809@opticalart.de> Date: Wed, 27 Oct 2004 13:50:45 +0200 From: Frank Hellmann Organization: Optical Art Film- und Special-Effects GmbH User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: xfs_check problems on 3.6TB fs References: <20041025150037.GA4665@astrouw.edu.pl> <417E216A.2090503@opticalart.de> <20041027090000.GA29337@astrouw.edu.pl> <20041027095434.GA30788@astrouw.edu.pl> In-Reply-To: <20041027095434.GA30788@astrouw.edu.pl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at vcc.de X-archive-position: 4331 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: frank@opticalart.de Precedence: bulk X-list: linux-xfs Content-Length: 1486 Lines: 41 Hi Michal! That would support my theory that there is a wrap-around bug somewhere in xfs_check. It is not in xfs_repair. so I'll give it a try and have a look. Cheers, Frank... Michal Szymanski wrote: > On Wed, Oct 27, 2004 at 11:00:00AM +0200, Michal Szymanski wrote: > >>To resume, could someone tell me whether I can safely put my data on a >>3.6TB XFS filesystem or not? The machine it is currently attached to >>has 4GB RAM + 2GB Swap. If this is not enough for XFS to do a >>check/repair, I would say it is not a solution for me. >> >>PS. I've just found, on http://oss.sgi.com/projects/xfs/irix-linux.html >> >> >>>Linux XFS filesystems are limited to 2 Terabytes in size due to >>>limitations in the Linux block device I/O layers. >> >>Is it just an out-of-date page? Or, maybe, it is just the true reason of >>our problems? > > > PS2. I have made a following test: I stopped the software RAID and > created two separate XFS systems on both "slices", seen by the system as > /dev/sda1 and /dev/sdb1. One is just below 2TB, the other is 1.6TB. > xfs_check works silently on such a (clean) filesystem. So maybe it is > really the 2TB limit that makes the diffrence? > > Michal. > -- -------------------------------------------------------------------------- Frank Hellmann Optical Art GmbH Waterloohain 7a DI Supervisor http://www.opticalart.de 22769 Hamburg frank@opticalart.de Tel: ++49 40 5111051 Fax: ++49 40 43169199 From owner-linux-xfs Wed Oct 27 04:57:04 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 27 Oct 2004 04:57:06 -0700 (PDT) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9RBv3YR022230 for ; Wed, 27 Oct 2004 04:57:03 -0700 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i9RBumxT004478 for ; Wed, 27 Oct 2004 06:56:48 -0500 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i9RBubBV810734; Wed, 27 Oct 2004 06:56:37 -0500 (CDT) Received: from hch by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1CMmPs-0002cl-00; Wed, 27 Oct 2004 06:56:36 -0500 To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Subject: PARTIAL TAKE 921072 - handle inode creating race Message-Id: From: Christoph Hellwig Date: Wed, 27 Oct 2004 06:56:36 -0500 X-archive-position: 4332 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 3290 Lines: 78 Date: Wed Oct 27 04:56:15 PDT 2004 Workarea: maine.americas.sgi.com:/home/daisy40/hch/ptools/xfs-2.4.x Inspected by: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.4.x-xfs Modid: xfs-linux:xfs-kern:181655a fs/xfs/xfs_trans_inode.c - 1.47 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_trans_inode.c.diff?r1=text&tr1=1.47&r2=text&tr2=1.46&f=h - xfs_iget gained another parameter fs/xfs/xfs_rtalloc.c - 1.93 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_rtalloc.c.diff?r1=text&tr1=1.93&r2=text&tr2=1.92&f=h - xfs_iget gained another parameter fs/xfs/xfs_itable.c - 1.127 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_itable.c.diff?r1=text&tr1=1.127&r2=text&tr2=1.126&f=h - xfs_iget gained another parameter fs/xfs/xfs_log_recover.c - 1.290 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_log_recover.c.diff?r1=text&tr1=1.290&r2=text&tr2=1.289&f=h - xfs_iget gained another parameter fs/xfs/xfs_vfsops.c - 1.457 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vfsops.c.diff?r1=text&tr1=1.457&r2=text&tr2=1.456&f=h - xfs_iget gained another parameter fs/xfs/xfs_iget.c - 1.198 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_iget.c.diff?r1=text&tr1=1.198&r2=text&tr2=1.197&f=h - make sure to avoid di_mode = 0 inodes unless creating new ones fs/xfs/xfs_mount.c - 1.351 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_mount.c.diff?r1=text&tr1=1.351&r2=text&tr2=1.350&f=h - xfs_iget gained another parameter fs/xfs/xfs_inode.c - 1.405 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode.c.diff?r1=text&tr1=1.405&r2=text&tr2=1.404&f=h - xfs_iget gained another parameter fs/xfs/xfs_inode.h - 1.195 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode.h.diff?r1=text&tr1=1.195&r2=text&tr2=1.194&f=h - add XFS_INEW flag fs/xfs/xfs_trans.h - 1.127 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_trans.h.diff?r1=text&tr1=1.127&r2=text&tr2=1.126&f=h - xfs_iget gained another parameter fs/xfs/xfs_utils.c - 1.63 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_utils.c.diff?r1=text&tr1=1.63&r2=text&tr2=1.62&f=h - xfs_iget gained another parameter fs/xfs/quota/xfs_qm_syscalls.c - 1.13 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_qm_syscalls.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h - xfs_iget gained another parameter fs/xfs/quota/xfs_qm.c - 1.18 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_qm.c.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h - xfs_iget gained another parameter fs/xfs/linux-2.6/xfs_ioctl.c - 1.115 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_ioctl.c.diff?r1=text&tr1=1.115&r2=text&tr2=1.114&f=h - xfs_iget gained another parameter fs/xfs/linux-2.6/xfs_super.c - 1.319 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_super.c.diff?r1=text&tr1=1.319&r2=text&tr2=1.318&f=h - clear XFS_INEW in xfs_initialize_vnode fs/xfs/linux-2.4/xfs_ioctl.c - 1.111 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_ioctl.c.diff?r1=text&tr1=1.111&r2=text&tr2=1.110&f=h - xfs_iget gained another parameter fs/xfs/linux-2.4/xfs_super.c - 1.298 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_super.c.diff?r1=text&tr1=1.298&r2=text&tr2=1.297&f=h - clear XFS_INEW in xfs_initialize_vnode From owner-linux-xfs Wed Oct 27 05:07:36 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 27 Oct 2004 05:07:38 -0700 (PDT) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9RC7aKw023988 for ; Wed, 27 Oct 2004 05:07:36 -0700 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [198.149.16.14]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i9RDLnZr005979 for ; Wed, 27 Oct 2004 06:21:49 -0700 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by ledzep.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i9RC79k42788471; Wed, 27 Oct 2004 07:07:09 -0500 (CDT) Received: from hch by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1CMma5-0002sU-00; Wed, 27 Oct 2004 07:07:09 -0500 To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Subject: PARTIAL TAKE 921072 - handle inode creating race Message-Id: From: Christoph Hellwig Date: Wed, 27 Oct 2004 07:07:09 -0500 X-archive-position: 4333 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 3039 Lines: 74 Sorry, the last checking didn't change much at all because I only applied one patch of two that should go in (the much smaller one) Date: Wed Oct 27 05:06:24 PDT 2004 Workarea: maine.americas.sgi.com:/home/daisy40/hch/ptools/xfs-2.4.x Inspected by: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.4.x-xfs Modid: xfs-linux:xfs-kern:181657a fs/xfs/xfs_trans_inode.c - 1.48 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_trans_inode.c.diff?r1=text&tr1=1.48&r2=text&tr2=1.47&f=h - xfs_iget gained another parameter fs/xfs/xfs_rtalloc.c - 1.94 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_rtalloc.c.diff?r1=text&tr1=1.94&r2=text&tr2=1.93&f=h - xfs_iget gained another parameter fs/xfs/xfs_itable.c - 1.128 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_itable.c.diff?r1=text&tr1=1.128&r2=text&tr2=1.127&f=h - xfs_iget gained another parameter fs/xfs/xfs_log_recover.c - 1.291 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_log_recover.c.diff?r1=text&tr1=1.291&r2=text&tr2=1.290&f=h - xfs_iget gained another parameter fs/xfs/xfs_vfsops.c - 1.458 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vfsops.c.diff?r1=text&tr1=1.458&r2=text&tr2=1.457&f=h - xfs_iget gained another parameter fs/xfs/xfs_iget.c - 1.199 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_iget.c.diff?r1=text&tr1=1.199&r2=text&tr2=1.198&f=h - make sure to avoid di_mode = 0 inodes unless creating new ones fs/xfs/xfs_mount.c - 1.352 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_mount.c.diff?r1=text&tr1=1.352&r2=text&tr2=1.351&f=h - xfs_iget gained another parameter fs/xfs/xfs_inode.c - 1.406 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode.c.diff?r1=text&tr1=1.406&r2=text&tr2=1.405&f=h - xfs_iget gained another parameter fs/xfs/xfs_inode.h - 1.196 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode.h.diff?r1=text&tr1=1.196&r2=text&tr2=1.195&f=h - add XFS_INEW flag fs/xfs/xfs_trans.h - 1.128 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_trans.h.diff?r1=text&tr1=1.128&r2=text&tr2=1.127&f=h - xfs_iget gained another parameter fs/xfs/xfs_utils.c - 1.64 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_utils.c.diff?r1=text&tr1=1.64&r2=text&tr2=1.63&f=h - xfs_iget gained another parameter fs/xfs/quota/xfs_qm_syscalls.c - 1.14 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_qm_syscalls.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h - xfs_iget gained another parameter fs/xfs/quota/xfs_qm.c - 1.19 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_qm.c.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h - xfs_iget gained another parameter fs/xfs/linux-2.6/xfs_ioctl.c - 1.116 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_ioctl.c.diff?r1=text&tr1=1.116&r2=text&tr2=1.115&f=h - xfs_iget gained another parameter fs/xfs/linux-2.6/xfs_super.c - 1.320 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_super.c.diff?r1=text&tr1=1.320&r2=text&tr2=1.319&f=h - clear XFS_INEW in xfs_initialize_vnode From owner-linux-xfs Wed Oct 27 06:36:50 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 27 Oct 2004 06:36:52 -0700 (PDT) Received: from eik.ii.uib.no (eik.ii.uib.no [129.177.16.3]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9RDanPC032565 for ; Wed, 27 Oct 2004 06:36:50 -0700 Received: from lapprose.ii.uib.no ([129.177.20.37]:53052) by eik.ii.uib.no with esmtp (TLSv1:AES256-SHA:256) (Exim 4.30) id 1CMnyU-0006NP-S2 for linux-xfs@oss.sgi.com; Wed, 27 Oct 2004 15:36:26 +0200 Received: (from jfm@localhost) by lapprose.ii.uib.no (8.12.11/8.12.11/Submit) id i9RDaQ23023595 for linux-xfs@oss.sgi.com; Wed, 27 Oct 2004 15:36:26 +0200 Date: Wed, 27 Oct 2004 15:36:26 +0200 From: Jan-Frode Myklebust To: linux-xfs@oss.sgi.com Subject: RHEL-3 kernels ? Message-ID: <20041027133626.GA23232@ii.uib.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-archive-position: 4334 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Jan-Frode.Myklebust@bccs.uib.no Precedence: bulk X-list: linux-xfs Content-Length: 70 Lines: 5 Does anybody have updated RHEL-3 kernels patched with XFS? -jf From owner-linux-xfs Wed Oct 27 08:01:24 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 27 Oct 2004 08:01:25 -0700 (PDT) Received: from office.cambrium.nl (217-19-18-130.dsl.cambrium.nl [217.19.18.130]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i9RF1M9S003153 for ; Wed, 27 Oct 2004 08:01:23 -0700 Received: (qmail 18282 invoked by uid 526); 27 Oct 2004 15:00:38 -0000 Subject: Re: strange result of an XFS crash test From: Johan Mulder To: Michal Szymanski Cc: linux-xfs@oss.sgi.com In-Reply-To: <20041027101200.GB30788@astrouw.edu.pl> References: <20041027101200.GB30788@astrouw.edu.pl> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Wed, 27 Oct 2004 17:00:38 +0200 Message-Id: <1098889238.25433.20.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 X-archive-position: 4335 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: johan@cambrium.nl Precedence: bulk X-list: linux-xfs Content-Length: 1121 Lines: 27 On Wed, 2004-10-27 at 12:12 +0200, Michal Szymanski wrote: > BTW, with a "standard" /etc/fstab entry: > /dev/sda1 /export/data2 xfs defaults 1 2 > is it going to be checked/repaired if needed at boot time? > With EXT2/3 FS, "fsck" does both check and repair. With XFS, this job > seems to be splitted into xfs_check and xfs_repair? Is the system > "fsck" wrapper aware of that? I can't give you any comments on the other stuff you mentioned, but most linux scripts run /sbin/fsck.$filesystem to check if it's alright. So, if it's an XFS filesystem, it will run /sbin/fsck.xfs to check it. Because the XFS system checks the filesystem on mount time, /sbin/fsck.xfs is rather useless. That's why it doesn't really do anything. The manual even states so: -- NAME fsck.xfs - do nothing, successfully SYNOPSIS fsck.xfs [ ...] DESCRIPTION fsck.xfs is called by the generic Linux fsck(8) program at startup to check and repair an XFS filesystem. XFS is a journaling filesystem and performs recovery at mount(8) time if necessary, so fsck.xfs simply exits with a zero exit status. From owner-linux-xfs Wed Oct 27 13:14:02 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 27 Oct 2004 13:14:04 -0700 (PDT) Received: from bulge.astrouw.edu.pl (bulge.astrouw.edu.pl [193.0.88.25]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9RKE0p6019575 for ; Wed, 27 Oct 2004 13:14:01 -0700 Received: from bulge.astrouw.edu.pl (localhost [127.0.0.1]) by bulge.astrouw.edu.pl (8.12.11/8.12.11) with ESMTP id i9RKDdVk013603 for ; Wed, 27 Oct 2004 22:13:39 +0200 Received: (from msz@localhost) by bulge.astrouw.edu.pl (8.12.11/8.12.11/Submit) id i9RKDd3F013600 for linux-xfs@oss.sgi.com; Wed, 27 Oct 2004 22:13:39 +0200 Date: Wed, 27 Oct 2004 22:13:39 +0200 From: Michal Szymanski To: linux-xfs@oss.sgi.com Subject: Re: xfs_check problems on 3.6TB fs Message-ID: <20041027201339.GA13311@astrouw.edu.pl> References: <20041025150037.GA4665@astrouw.edu.pl> <417E216A.2090503@opticalart.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <417E216A.2090503@opticalart.de> User-Agent: Mutt/1.4.1i X-archive-position: 4336 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: msz@astrouw.edu.pl Precedence: bulk X-list: linux-xfs Content-Length: 667 Lines: 21 Hi Frank, Thanks for your comments. >> The oss.sgi.com/projects/xfs pages content suggests that actually 'fcsk' >> is not needed anymore on a journalling FS like XFS. So maybe we can just >> live without it? > No. There will be times, you'll need it. Powerloss is never going to > give you predictable results. > That would support my theory that there is a wrap-around bug somewhere > in xfs_check. It is not in xfs_repair. so I'll give it a try and have a > look. Still, if I am correct, 'xfs_check' gives just information on the FS status and it is 'xfs_repair' that does the real job. So the 'xfs_check' seems not to be that important. Michal Szymanski From owner-linux-xfs Wed Oct 27 13:44:21 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 27 Oct 2004 13:44:24 -0700 (PDT) Received: from mail00hq.adic.com ([63.81.117.10]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9RKiLha022469 for ; Wed, 27 Oct 2004 13:44:21 -0700 Received: from mail02hq.adic.com ([172.16.9.18]) by mail00hq.adic.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 27 Oct 2004 13:44:00 -0700 Received: from [172.16.82.67] ([172.16.82.67]) by mail02hq.adic.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 27 Oct 2004 13:43:59 -0700 Message-ID: <418007B3.7040207@xfs.org> Date: Wed, 27 Oct 2004 15:40:19 -0500 From: Steve Lord User-Agent: Mozilla Thunderbird 0.7.1 (X11/20040626) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michal Szymanski CC: linux-xfs@oss.sgi.com Subject: Re: xfs_check problems on 3.6TB fs References: <20041025150037.GA4665@astrouw.edu.pl> <417E216A.2090503@opticalart.de> <20041027201339.GA13311@astrouw.edu.pl> In-Reply-To: <20041027201339.GA13311@astrouw.edu.pl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Oct 2004 20:43:59.0579 (UTC) FILETIME=[AF86EAB0:01C4BC65] X-archive-position: 4337 X-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: 1229 Lines: 40 Michal Szymanski wrote: > Hi Frank, > > Thanks for your comments. > > >>>The oss.sgi.com/projects/xfs pages content suggests that actually 'fcsk' >>>is not needed anymore on a journalling FS like XFS. So maybe we can just >>>live without it? > > >>No. There will be times, you'll need it. Powerloss is never going to >>give you predictable results. > > >>That would support my theory that there is a wrap-around bug somewhere >>in xfs_check. It is not in xfs_repair. so I'll give it a try and have a >>look. > > > Still, if I am correct, 'xfs_check' gives just information on the FS > status and it is 'xfs_repair' that does the real job. So the 'xfs_check' > seems not to be that important. > > Michal Szymanski > xfs_check is a wrapper around xfs_db, it does a fairly extensive metadata consistancy check, but does not fix anything up. xfs_repair is the tool for fixing things. I remember cases on Irix were we had to build a special 64 bit version of the tool (to get a larger address space), and get the customer to add more swap to succeed in running to completion. These programs have been put on a diet, but the memory demands of repairing/checking really large filesystems are still significant. Steve From owner-linux-xfs Wed Oct 27 17:20:35 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 27 Oct 2004 17:20:39 -0700 (PDT) Received: from mail.vcc.de (mail.vcc.de [217.111.2.122]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9S0KYWB004606 for ; Wed, 27 Oct 2004 17:20:35 -0700 Received: from localhost (localhost [127.0.0.1]) by mail.vcc.de (Postfix) with ESMTP id 7EAC9162148; Thu, 28 Oct 2004 02:20:18 +0200 (CEST) Received: from mail.vcc.de ([127.0.0.1]) by localhost (mail.vcc.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10559-09; Thu, 28 Oct 2004 02:20:17 +0200 (CEST) Received: from [192.9.209.64] (wolverine.vcc.de [217.111.2.200]) by mail.vcc.de (Postfix) with ESMTP id 237E5161F32; Thu, 28 Oct 2004 02:20:17 +0200 (CEST) Message-ID: <41803B3E.4070803@opticalart.de> Date: Thu, 28 Oct 2004 02:20:14 +0200 From: Frank Hellmann Organization: Optical Art Film- und Special-Effects GmbH User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Steve Lord Cc: linux-xfs@oss.sgi.com Subject: Re: xfs_check problems on 3.6TB fs References: <20041025150037.GA4665@astrouw.edu.pl> <417E216A.2090503@opticalart.de> <20041027201339.GA13311@astrouw.edu.pl> <418007B3.7040207@xfs.org> In-Reply-To: <418007B3.7040207@xfs.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at vcc.de X-archive-position: 4338 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: frank@opticalart.de Precedence: bulk X-list: linux-xfs Content-Length: 2239 Lines: 74 Hi Steve! I think if anybody can spend some time to "extend" (fix) the way xfs_db/xfs_check and xfs_repair are handling large filesystems under linux, this would be really appreciated. I think 2TB+ filesystems on 2GB system memory will get so common over the next couple of months that this really needs to be adressed. Just my opinion... I had a look into the xfs_db sources today and I still have no clue what is going on. There has been so much effort put in there (means a lot of code to understand), so maybe somebody with more expirience with the xfs tools can take a look? Thanks. Cheers, Frank... Steve Lord wrote: > Michal Szymanski wrote: > >> Hi Frank, >> >> Thanks for your comments. >> >> >>>> The oss.sgi.com/projects/xfs pages content suggests that actually >>>> 'fcsk' >>>> is not needed anymore on a journalling FS like XFS. So maybe we can >>>> just >>>> live without it? >> >> >> >>> No. There will be times, you'll need it. Powerloss is never going to >>> give you predictable results. >> >> >> >>> That would support my theory that there is a wrap-around bug >>> somewhere in xfs_check. It is not in xfs_repair. so I'll give it a >>> try and have a look. >> >> >> >> Still, if I am correct, 'xfs_check' gives just information on the FS >> status and it is 'xfs_repair' that does the real job. So the 'xfs_check' >> seems not to be that important. >> >> Michal Szymanski >> > > xfs_check is a wrapper around xfs_db, it does a fairly extensive > metadata consistancy check, but does not fix anything up. xfs_repair > is the tool for fixing things. > > I remember cases on Irix were we had to build a special 64 bit > version of the tool (to get a larger address space), and get > the customer to add more swap to succeed in running to completion. > > These programs have been put on a diet, but the memory demands of > repairing/checking really large filesystems are still significant. > > Steve > > > > -- -------------------------------------------------------------------------- Frank Hellmann Optical Art GmbH Waterloohain 7a DI Supervisor http://www.opticalart.de 22769 Hamburg frank@opticalart.de Tel: ++49 40 5111051 Fax: ++49 40 43169199 From owner-linux-xfs Wed Oct 27 18:10:09 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 27 Oct 2004 18:10:12 -0700 (PDT) Received: from mail04.syd.optusnet.com.au (mail04.syd.optusnet.com.au [211.29.132.185]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9S1A8sC005862 for ; Wed, 27 Oct 2004 18:10:09 -0700 Received: from saturn (c211-28-166-127.eburwd2.vic.optusnet.com.au [211.28.166.127]) by mail04.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id i9S19cVx031627; Thu, 28 Oct 2004 11:09:41 +1000 Received: from saturn ([127.0.0.1] ident=www-data) by saturn with smtp (Exim 3.35 #1 (Debian)) id 1CMynJ-00006D-00; Thu, 28 Oct 2004 11:09:37 +1000 Received: from 61.14.31.138 (SquirrelMail authenticated user stewart) by 127.0.0.1 with HTTP; Thu, 28 Oct 2004 11:09:37 +1000 (EST) Message-ID: <26132.61.14.31.138.1098925777.squirrel@127.0.0.1> Date: Thu, 28 Oct 2004 11:09:37 +1000 (EST) Subject: Re: strange result of an XFS crash test From: "Stewart Smith" To: In-Reply-To: <20041027101200.GB30788@astrouw.edu.pl> References: <20041027101200.GB30788@astrouw.edu.pl> X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal Cc: X-Mailer: SquirrelMail (version 1.2.6) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-archive-position: 4339 X-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 Content-Length: 323 Lines: 13 Michal Szymanski said: > It that what I should expect from a journalling file system? Yes - the journalling protects the filesystem metadata, not your data. run a 'sync' (or fsync) after each file write and you'll get something quite different. -- Stewart Smith (stewart@flamingspork.com) http://www.flamingspork.com From owner-linux-xfs Thu Oct 28 08:02:22 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 28 Oct 2004 08:02:25 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9SF2MmJ025817 for ; Thu, 28 Oct 2004 08:02:22 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i9SF2MGn025816 for linux-xfs@oss.sgi.com; Thu, 28 Oct 2004 08:02:22 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9SF2L7H025802 for ; Thu, 28 Oct 2004 08:02:21 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i9SEQHWx021992; Thu, 28 Oct 2004 07:26:17 -0700 Date: Thu, 28 Oct 2004 07:26:17 -0700 Message-Id: <200410281426.i9SEQHWx021992@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 379] New: CVS Linux 2.4 and 2.6 build failure w/ CONFIG_XFS_DMAPI X-Bugzilla-Reason: AssignedTo X-archive-position: 4340 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1165 Lines: 35 http://oss.sgi.com/bugzilla/show_bug.cgi?id=379 Summary: CVS Linux 2.4 and 2.6 build failure w/ CONFIG_XFS_DMAPI Product: Linux XFS Version: Current Platform: All OS/Version: Linux Status: NEW Severity: blocker Priority: High Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: peter.kovar@gmail.com Linux 2.4 and 2.6 from current CVS trees at SGI failed to build with CONFIG_XFS_DMAPI enabled. xfs_iget() defined in "xfs_inode.h" has 7 parameters, however in Linux 2.6.9 only 6 parameters, without uint lock_flags! xfs_dmapi.c: In function `xfs_dm_bulkstat_one': xfs_dmapi.c:519: warning: passing arg 5 of `xfs_iget' makes integer from pointer without a cast xfs_dmapi.c:519: warning: passing arg 6 of `xfs_iget' makes pointer from integer without a cast xfs_dmapi.c:519: error: too few arguments to function `xfs_iget' make[3]: *** [xfs_dmapi.o] Error 1 Peter Kovář 50 65 74 65 72 20 4B 6F 76 C3 A1 C5 99 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Thu Oct 28 13:02:23 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 28 Oct 2004 13:02:24 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9SK2NEU018653 for ; Thu, 28 Oct 2004 13:02:23 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i9SK2NZ3018652 for linux-xfs@oss.sgi.com; Thu, 28 Oct 2004 13:02:23 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9SK2Mnt018640 for ; Thu, 28 Oct 2004 13:02:22 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i9SK05a6018568; Thu, 28 Oct 2004 13:00:05 -0700 Date: Thu, 28 Oct 2004 13:00:05 -0700 Message-Id: <200410282000.i9SK05a6018568@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 379] CVS Linux 2.4 and 2.6 build failure w/ CONFIG_XFS_DMAPI X-Bugzilla-Reason: AssignedTo X-archive-position: 4341 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 409 Lines: 16 http://oss.sgi.com/bugzilla/show_bug.cgi?id=379 ------- Additional Comments From peter.kovar@gmail.com 2004-28-10 13:00 PDT ------- Correction: actually there has been added uint flags, not uint lock_flags. However, xfs_iget_core() comments dont't describe flags parameter at all! ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Thu Oct 28 17:02:24 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 28 Oct 2004 17:02:26 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9T02O20007061 for ; Thu, 28 Oct 2004 17:02:24 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i9T02O3T007060 for linux-xfs@oss.sgi.com; Thu, 28 Oct 2004 17:02:24 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9T02Mdd007045 for ; Thu, 28 Oct 2004 17:02:23 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i9SNh3LW002532; Thu, 28 Oct 2004 16:43:03 -0700 Date: Thu, 28 Oct 2004 16:43:03 -0700 Message-Id: <200410282343.i9SNh3LW002532@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 379] CVS Linux 2.4 and 2.6 build failure w/ CONFIG_XFS_DMAPI X-Bugzilla-Reason: AssignedTo X-archive-position: 4342 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 543 Lines: 22 http://oss.sgi.com/bugzilla/show_bug.cgi?id=379 roehrich@sgi.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From roehrich@sgi.com 2004-28-10 16:43 PDT ------- fix checked in ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Thu Oct 28 20:29:07 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 28 Oct 2004 20:29:10 -0700 (PDT) Received: from server.xonsecure.com ([65.254.46.236]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9T3T6A0022452 for ; Thu, 28 Oct 2004 20:29:07 -0700 Received: from nobody by server.xonsecure.com with local (Exim 4.34) id 1CNNRG-0003bS-Ok for linux-xfs@oss.sgi.com; Thu, 28 Oct 2004 23:28:30 -0400 To: linux-xfs@oss.sgi.com Subject: Sgi - Developer Central Open Source | =?ISO-8859-1?Q?Opengl=AE?= Sample Implementation Has been added... From: Keith Gill Message-Id: Date: Thu, 28 Oct 2004 23:28:30 -0400 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.xonsecure.com X-AntiAbuse: Original Domain - oss.sgi.com X-AntiAbuse: Originator/Caller UID/GID - [99 99] / [47 12] X-AntiAbuse: Sender Address Domain - qcamortgage.com X-Source: X-Source-Args: X-Source-Dir: X-archive-position: 4343 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: links@qcamortgage.com Precedence: bulk X-list: linux-xfs Content-Length: 1122 Lines: 33 Dear SGI, I'm writing to let you know that I have just added your website, Sgi - Developer Central Open Source | Opengl® Sample Implementation, to my directory. You can find your listing here... http://www.qcamortgage.com/samplereference I also wanted to gauge your interest in networking our websites together more closely for mutual benefit. If you would consider linking to http://www.qcamortgage.com from your own website, I would be more than happy to increase your listing to "premium status". This will always ensure that your listing appears at the top of your category above all other normal listings, even if new webmasters submit their website to the same category in the future. I think you have a fantastic site, and would love to have you as a strategic link partner. If you're interested, simply reply to this entire email and let me know where you've placed the link to http://www.qcamortgage.com on your own site, and I will immediately modify your listing to premium status. I look forward to hearing from you soon & keep up the great work... Sincerely, Keith Gill mailto:links@qcamortgage.com From owner-linux-xfs Fri Oct 29 00:16:41 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 29 Oct 2004 00:16:50 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i9T7GdQv030700 for ; Fri, 29 Oct 2004 00:16: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 RAA04556; Fri, 29 Oct 2004 17:16:12 +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 i9T7GAln5492248; Fri, 29 Oct 2004 17:16:10 +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 i9T7EUiG002102; Fri, 29 Oct 2004 17:14:30 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i9T7ETwo002100; Fri, 29 Oct 2004 17:14:29 +1000 Date: Fri, 29 Oct 2004 17:14:29 +1000 From: Nathan Scott To: Martin MOKREJ? Cc: linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: best linux kernel with memory management Message-ID: <20041029071429.GF1246@frodo> References: <412C87F3.2030602@ribosome.natur.cuni.cz> <20040825114005.GB13285@logos.cnet> <412C94F5.4010902@ribosome.natur.cuni.cz> <20040825120450.GA22509@logos.cnet> <412C9D9C.6060703@ribosome.natur.cuni.cz> <20040827121905.GG32707@logos.cnet> <417F6258.7010209@ribosome.natur.cuni.cz> <20041028105108.GB5741@logos.cnet> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="ReaqsoxgOBHFXBhH" Content-Disposition: inline In-Reply-To: <20041028105108.GB5741@logos.cnet> User-Agent: Mutt/1.5.3i X-archive-position: 4344 X-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: 3406 Lines: 96 --ReaqsoxgOBHFXBhH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Martin, Sorry about the slow reply, been away for a bit... On Thu, Oct 28, 2004 at 08:51:08AM -0200, Marcelo Tosatti wrote: > On Wed, Oct 27, 2004 at 10:54:48AM +0200, Martin MOKREJ? wrote: > > Hi, > > I have hit again memory problem on the same host with 2.4.28-pre3. > > I went to test raid5 filesystem and wanted to evaluate speed Was that software (md) or hardware RAID5? > > of different filesystems while studying different combinations > > of their mkfs options or mount options. I did test reiserfs3, > > ext3, xfs, ext2. > > > > With a subset of xfs test I run on the server out of memory, > > reproducibly. Those are tests on a filesystem which was created > > with "mkfs.xfs -f -b log=9 -d sunit=64,swidth=64 /dev/sdb2" With that blocksize (-blog=9 is 512 byte blocksize) you will have many more buffer_heads per page than the default (4k; i.e. 1-per- page) which may cause a different kind of memory pressure to what you'd otherwise see. Are you tweaking all the filesystems to use that blocksize? I'm not sure they all support that small, actually, for ext2/3 I think they stop at 1k as the smallest blocksize. You should find the ideal MD RAID5 XFS geometry to be a 4k sector size (-s size=4k) and 4K blocksize (-b size=4k) to mkfs.xfs. > > and other sizes of swidth parameter. Omitting those parameters > > makes no trouble and tests finish properly. Thats interesting, I expect this may be a buffer_head reclaim issue then, if the larger blocksize runs are completing fine. In that case, I wonder if the attached patch helps at all? Can you send me your /proc/meminfo and /proc/slabinfo at the time you see the failure? Also the console messages (I guess you sent to Marcelo earlier too) with these failing allocation messages... > > I have noticed that maxfiles was reached and also the > > 0 allocation failed messages. > > although from I forgot if I have again the 0 allocation pages > > ... (oh, and also which kernel versions are associated with which sets of messages - looks like you've tried a few here). > > >>>>kernel worked fine. Also 2.4.25 had problems which was on Gentoo > > >>>>install CDROM. I don't remember exact their exact revisions, but I > > >>>>shouldn't have used xfs also for /. I thought better xfs everywhere > > >>>>than combined with reiserfs. Of course, /boot is ext3. There should be no problems using XFS for everything, including /boot - I do that on all my systems (for a few years now). > > >>on teh internal raid using gdth controller. After mkfs.xfs on internal > > >>disks I had to reboot often. Hmm, that sounds like a device driver bug (if mkfs causes hangs..?). Could you get sysrq-t or kdb stacktraces for the hung processes? cheers. -- Nathan --ReaqsoxgOBHFXBhH Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=free_more_memory Index: 2.4.x-xfs/fs/buffer.c =================================================================== --- 2.4.x-xfs.orig/fs/buffer.c Fri May 28 13:32:47 2004 +++ 2.4.x-xfs/fs/buffer.c Fri May 28 13:33:58 2004 @@ -789,9 +789,9 @@ { balance_dirty(); wakeup_bdflush(); + yield(); try_to_free_pages(GFP_NOIO); run_task_queue(&tq_disk); - yield(); } void init_buffer(struct buffer_head *bh, bh_end_io_t *handler, void *private) --ReaqsoxgOBHFXBhH-- From owner-linux-xfs Fri Oct 29 00:22:34 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 29 Oct 2004 00:22:41 -0700 (PDT) Received: from linux01.gwdg.de (root@linux01.gwdg.de [134.76.13.21]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9T7MUoR001957 for ; Fri, 29 Oct 2004 00:22:33 -0700 Received: from linux01.gwdg.de (localhost [127.0.0.1]) by linux01.gwdg.de (8.12.7/8.12.7/SuSE Linux 0.6) with ESMTP id i9T7MDh9029111; Fri, 29 Oct 2004 09:22:13 +0200 Received: from localhost (jengelh@localhost) by linux01.gwdg.de (8.12.7/8.12.7/Submit) with ESMTP id i9T7MBek029104; Fri, 29 Oct 2004 09:22:12 +0200 Date: Fri, 29 Oct 2004 09:22:11 +0200 (MEST) From: Jan Engelhardt To: Nathan Scott cc: Martin MOKREJ? , linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: best linux kernel with memory management In-Reply-To: <20041029071429.GF1246@frodo> Message-ID: References: <412C87F3.2030602@ribosome.natur.cuni.cz> <20040825114005.GB13285@logos.cnet> <412C94F5.4010902@ribosome.natur.cuni.cz> <20040825120450.GA22509@logos.cnet> <412C9D9C.6060703@ribosome.natur.cuni.cz> <20040827121905.GG32707@logos.cnet> <417F6258.7010209@ribosome.natur.cuni.cz> <20041028105108.GB5741@logos.cnet> <20041029071429.GF1246@frodo> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: 8BIT X-archive-position: 4345 X-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 Content-Length: 686 Lines: 18 >> > >>>>kernel worked fine. Also 2.4.25 had problems which was on Gentoo >> > >>>>install CDROM. I don't remember exact their exact revisions, but I >> > >>>>shouldn't have used xfs also for /. I thought better xfs everywhere >> > >>>>than combined with reiserfs. Of course, /boot is ext3. > >There should be no problems using XFS for everything, including >/boot - I do that on all my systems (for a few years now). /boot (whose root is / for me) can be reiser, the bootload installer just needs to know that is has to unpack files otherwise they might not boot. Jan Engelhardt -- Gesellschaft für Wissenschaftliche Datenverarbeitung Am Fassberg, 37077 Göttingen, www.gwdg.de From owner-linux-xfs Fri Oct 29 00:39:33 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 29 Oct 2004 00:39:36 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i9T7dVYL003167 for ; Fri, 29 Oct 2004 00:39: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 RAA05047; Fri, 29 Oct 2004 17:39:08 +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 i9T7d5ln5494759; Fri, 29 Oct 2004 17:39:06 +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 i9T7bQiG002180; Fri, 29 Oct 2004 17:37:26 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i9T7bNXJ002178; Fri, 29 Oct 2004 17:37:23 +1000 Date: Fri, 29 Oct 2004 17:37:23 +1000 From: Nathan Scott To: Robin Rosenberg Cc: Linux Kernel , linux-xfs@oss.sgi.com Subject: Re: XFS strangeness, xfs_db out of memory Message-ID: <20041029073723.GH1246@frodo> References: <200410240857.31893.robin.rosenberg.lists@dewire.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200410240857.31893.robin.rosenberg.lists@dewire.com> User-Agent: Mutt/1.5.3i X-archive-position: 4346 X-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: 675 Lines: 22 On Sun, Oct 24, 2004 at 08:57:26AM +0200, Robin Rosenberg wrote: > Hi, > > I was testing a tiny script on top of xfs_fsr to show fragmentation and the > resultss of defragmentation. As a result of fine tuning the output I ran the > script repeatedly and suddenly got error from find (unknown error 999 if my > memory serves me. It scrolled off the screen). > ... > xfs_info $dev > xfs_db -r $dev -c "frag -v" This is accessing the device while the filesystem is mounted, in older kernels (like the one you have) that would cause the above corruption error in XFS - thats resolved now. As to the IDE error you saw, I'm not sure how fatal that is. cheers. -- Nathan From owner-linux-xfs Fri Oct 29 00:43:13 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 29 Oct 2004 00:43:14 -0700 (PDT) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i9T7hCcW003829 for ; Fri, 29 Oct 2004 00:43:12 -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 RAA05106; Fri, 29 Oct 2004 17:42:49 +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 i9T7glln5491611; Fri, 29 Oct 2004 17:42:48 +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 i9T7f8iG002221; Fri, 29 Oct 2004 17:41:08 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i9T7f6Au002219; Fri, 29 Oct 2004 17:41:06 +1000 Date: Fri, 29 Oct 2004 17:41:06 +1000 From: Nathan Scott To: Thomas Ledbetter Cc: linux-xfs@oss.sgi.com Subject: Re: xfs out of diskspace issue Message-ID: <20041029074106.GI1246@frodo> References: <20041021123038.14764@web1.app.nyc1.bluetie.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041021123038.14764@web1.app.nyc1.bluetie.com> User-Agent: Mutt/1.5.3i X-archive-position: 4347 X-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: 603 Lines: 21 On Thu, Oct 21, 2004 at 12:30:37PM -0400, Thomas Ledbetter wrote: > > Is there 'other' portions of the filesystem which could take up 33% of it? No. > In this case there was 2.2G being reported as free by df, yet new files could > not be created. Deleting existing files did allow new ones to be created. > > Does anyone have any ideas why this would occur or where I can turn to for > more information? Unmount and run repair - does that show any disconnected inodes? (if so, they'd be put in lost+found - these may account for your missing space, if any exist..). cheers. -- Nathan From owner-linux-xfs Fri Oct 29 03:02:26 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 29 Oct 2004 03:02:28 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9TA2Qs1010301 for ; Fri, 29 Oct 2004 03:02:26 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i9TA2QhD010300 for linux-xfs@oss.sgi.com; Fri, 29 Oct 2004 03:02:26 -0700 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9TA2OsP010276 for ; Fri, 29 Oct 2004 03:02:24 -0700 Received: (from apache@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i9T9c2hc007472; Fri, 29 Oct 2004 02:38:02 -0700 Date: Fri, 29 Oct 2004 02:38:02 -0700 Message-Id: <200410290938.i9T9c2hc007472@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 380] New: CVS Linux 2.4 link failed w/ undefined reference to _pagebuf_find X-Bugzilla-Reason: AssignedTo X-archive-position: 4348 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1119 Lines: 35 http://oss.sgi.com/bugzilla/show_bug.cgi?id=380 Summary: CVS Linux 2.4 link failed w/ undefined reference to _pagebuf_find Product: Linux XFS Version: Current Platform: All OS/Version: Linux Status: NEW Severity: major Priority: High Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: peter.kovar@gmail.com fs/fs.o(.text+0x91d8f): In function `xfs_attr_rmtval_remove': : undefined reference to `_pagebuf_find' fs/fs.o(.text+0xc8e9d): In function `xfs_inode_item_pushbuf': : undefined reference to `_pagebuf_find' fs/fs.o(.text+0xfc9b6): In function `xfs_qm_dqflock_pushbuf_wait': : undefined reference to `_pagebuf_find' fs/fs.o(.text+0xfcda3): In function `xfs_qm_dquot_logitem_pushbuf': : undefined reference to `_pagebuf_find' fs/fs.o(__ksymtab+0x4f8): undefined reference to `_pagebuf_find' make[1]: *** [kallsyms] Error 1 GCC 3.3.4 IA-32 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs Fri Oct 29 05:12:43 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 29 Oct 2004 05:12:49 -0700 (PDT) Received: from mail.vcc.de (mail.vcc.de [217.111.2.122]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9TCCgpT024032 for ; Fri, 29 Oct 2004 05:12:43 -0700 Received: from localhost (localhost [127.0.0.1]) by mail.vcc.de (Postfix) with ESMTP id D4763162148 for ; Fri, 29 Oct 2004 14:12:25 +0200 (CEST) Received: from mail.vcc.de ([127.0.0.1]) by localhost (mail.vcc.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09700-06 for ; Fri, 29 Oct 2004 14:12:23 +0200 (CEST) Received: from [192.9.209.64] (wolverine.vcc.de [217.111.2.200]) by mail.vcc.de (Postfix) with ESMTP id BEE54161F32 for ; Fri, 29 Oct 2004 14:12:23 +0200 (CEST) Message-ID: <418233A3.8000305@opticalart.de> Date: Fri, 29 Oct 2004 14:12:19 +0200 From: Frank Hellmann Organization: Optical Art Film- und Special-Effects GmbH User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: xfs_check problems on 3.6TB fs References: <20041025150037.GA4665@astrouw.edu.pl> <417E216A.2090503@opticalart.de> <20041027201339.GA13311@astrouw.edu.pl> <418007B3.7040207@xfs.org> <41803B3E.4070803@opticalart.de> In-Reply-To: <41803B3E.4070803@opticalart.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at vcc.de X-archive-position: 4349 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: frank@opticalart.de Precedence: bulk X-list: linux-xfs Content-Length: 2657 Lines: 93 Hi Guys! To avoid the xfs_check "out of memory" problems, upgrade the xfs_progs to the current version 2.6.13 or CVS. I'll had a go with that one and it seems to cure the "out of memory" issues on a 2.7TB array. The xfs_repair issue remains with that version. Cheers, Frank... Frank Hellmann wrote: > Hi Steve! > > I think if anybody can spend some time to "extend" (fix) the way > xfs_db/xfs_check and xfs_repair are handling large filesystems under > linux, this would be really appreciated. I think 2TB+ filesystems on 2GB > system memory will get so common over the next couple of months that > this really needs to be adressed. Just my opinion... > > I had a look into the xfs_db sources today and I still have no clue what > is going on. There has been so much effort put in there (means a lot of > code to understand), so maybe somebody with more expirience with the xfs > tools can take a look? > > Thanks. Cheers, > > Frank... > > Steve Lord wrote: > >> Michal Szymanski wrote: >> >>> Hi Frank, >>> >>> Thanks for your comments. >>> >>> >>>>> The oss.sgi.com/projects/xfs pages content suggests that actually >>>>> 'fcsk' >>>>> is not needed anymore on a journalling FS like XFS. So maybe we can >>>>> just >>>>> live without it? >>> >>> >>> >>> >>>> No. There will be times, you'll need it. Powerloss is never going to >>>> give you predictable results. >>> >>> >>> >>> >>>> That would support my theory that there is a wrap-around bug >>>> somewhere in xfs_check. It is not in xfs_repair. so I'll give it a >>>> try and have a look. >>> >>> >>> >>> >>> Still, if I am correct, 'xfs_check' gives just information on the FS >>> status and it is 'xfs_repair' that does the real job. So the 'xfs_check' >>> seems not to be that important. >>> >>> Michal Szymanski >>> >> >> xfs_check is a wrapper around xfs_db, it does a fairly extensive >> metadata consistancy check, but does not fix anything up. xfs_repair >> is the tool for fixing things. >> >> I remember cases on Irix were we had to build a special 64 bit >> version of the tool (to get a larger address space), and get >> the customer to add more swap to succeed in running to completion. >> >> These programs have been put on a diet, but the memory demands of >> repairing/checking really large filesystems are still significant. >> >> Steve >> >> >> >> > -- -------------------------------------------------------------------------- Frank Hellmann Optical Art GmbH Waterloohain 7a DI Supervisor http://www.opticalart.de 22769 Hamburg frank@opticalart.de Tel: ++49 40 5111051 Fax: ++49 40 43169199 From owner-linux-xfs Fri Oct 29 06:09:14 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 29 Oct 2004 06:09:20 -0700 (PDT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.197]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9TD9EJS028703 for ; Fri, 29 Oct 2004 06:09:14 -0700 Received: by wproxy.gmail.com with SMTP id 64so627837wri for ; Fri, 29 Oct 2004 06:08:50 -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:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=U22ETlPVXp1MWAnj3yRm+PYoz7WTHroxJj24P2oS+oqz9T2KDskPL2DT1vGOpE0ku3qqbIH7wsu18XnP6rG0/SVLh1cY3Xf9lWFkuZrMytu5/tound09yj1O3qAfWa7qgLPUkrLr6JKdUUiYZE7IjlhyBUgDqTjvvWy8fjVqgqs= Received: by 10.38.15.20 with SMTP id 20mr924324rno; Fri, 29 Oct 2004 06:08:49 -0700 (PDT) Received: by 10.38.126.42 with HTTP; Fri, 29 Oct 2004 06:08:49 -0700 (PDT) Message-ID: <5b64f7f04102906084b358d5f@mail.gmail.com> Date: Fri, 29 Oct 2004 09:08:49 -0400 From: Rahul Karnik Reply-To: Rahul Karnik To: Nathan Scott Subject: Re: best linux kernel with memory management Cc: Martin MOKREJ? , linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org In-Reply-To: <20041029071429.GF1246@frodo> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <412C87F3.2030602@ribosome.natur.cuni.cz> <20040825114005.GB13285@logos.cnet> <412C94F5.4010902@ribosome.natur.cuni.cz> <20040825120450.GA22509@logos.cnet> <412C9D9C.6060703@ribosome.natur.cuni.cz> <20040827121905.GG32707@logos.cnet> <417F6258.7010209@ribosome.natur.cuni.cz> <20041028105108.GB5741@logos.cnet> <20041029071429.GF1246@frodo> X-archive-position: 4350 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: deathdruid@gmail.com Precedence: bulk X-list: linux-xfs Content-Length: 482 Lines: 13 On Fri, 29 Oct 2004 17:14:29 +1000, Nathan Scott wrote: > There should be no problems using XFS for everything, including > /boot - I do that on all my systems (for a few years now). Last time I checked (~ 2 months ago), there is a GRUB bug that prevents the use of XFS as the /boot filesystem. I use ext3 for my /boot to get around this, with all my other filesystems being XFS. Any chance the XFS devs could help fix the GRUB team fix the bug? Thanks, Rahul From owner-linux-xfs Fri Oct 29 06:15:25 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 29 Oct 2004 06:15:27 -0700 (PDT) Received: from phoenix.infradead.org (phoenix.infradead.org [81.187.226.98]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9TDFPRi029639 for ; Fri, 29 Oct 2004 06:15:25 -0700 Received: from hch by phoenix.infradead.org with local (Exim 4.42 #1 (Red Hat Linux)) id 1CNWal-0003EZ-AD; Fri, 29 Oct 2004 14:14:55 +0100 Date: Fri, 29 Oct 2004 14:14:55 +0100 From: Christoph Hellwig To: Rahul Karnik Cc: Nathan Scott , Martin MOKREJ? , linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: best linux kernel with memory management Message-ID: <20041029131455.GA12382@infradead.org> Mail-Followup-To: Christoph Hellwig , Rahul Karnik , Nathan Scott , Martin MOKREJ? , linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org References: <412C87F3.2030602@ribosome.natur.cuni.cz> <20040825114005.GB13285@logos.cnet> <412C94F5.4010902@ribosome.natur.cuni.cz> <20040825120450.GA22509@logos.cnet> <412C9D9C.6060703@ribosome.natur.cuni.cz> <20040827121905.GG32707@logos.cnet> <417F6258.7010209@ribosome.natur.cuni.cz> <20041028105108.GB5741@logos.cnet> <20041029071429.GF1246@frodo> <5b64f7f04102906084b358d5f@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5b64f7f04102906084b358d5f@mail.gmail.com> User-Agent: Mutt/1.4.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by phoenix.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 4351 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs Content-Length: 634 Lines: 14 On Fri, Oct 29, 2004 at 09:08:49AM -0400, Rahul Karnik wrote: > On Fri, 29 Oct 2004 17:14:29 +1000, Nathan Scott wrote: > > > There should be no problems using XFS for everything, including > > /boot - I do that on all my systems (for a few years now). > > Last time I checked (~ 2 months ago), there is a GRUB bug that > prevents the use of XFS as the /boot filesystem. I use ext3 for my > /boot to get around this, with all my other filesystems being XFS. Any > chance the XFS devs could help fix the GRUB team fix the bug? they just have to remove the broken pass where they try to read from the raw device. From owner-linux-xfs Fri Oct 29 06:58:30 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 29 Oct 2004 06:58:32 -0700 (PDT) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9TDwUId032056 for ; Fri, 29 Oct 2004 06:58:30 -0700 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [198.149.16.14]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i9TDwExT002067 for ; Fri, 29 Oct 2004 08:58:14 -0500 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by ledzep.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i9TDw2k42912635; Fri, 29 Oct 2004 08:58:03 -0500 (CDT) Received: from hch by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1CNXGU-00073f-00; Fri, 29 Oct 2004 08:58:02 -0500 To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Subject: PARTIAL TAKE 923980 - _pagebuf_find must not be static Message-Id: From: Christoph Hellwig Date: Fri, 29 Oct 2004 08:58:02 -0500 X-archive-position: 4352 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 469 Lines: 15 Date: Fri Oct 29 06:57:44 PDT 2004 Workarea: maine.americas.sgi.com:/home/daisy40/hch/ptools/xfs-2.4.x Inspected by: jes The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.4.x-xfs Modid: xfs-linux:xfs-kern:181828a fs/xfs/linux-2.4/xfs_buf.c - 1.197 http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_buf.c.diff?r1=text&tr1=1.197&r2=text&tr2=1.196&f=h - remove STATIC from _pagebuf_find declaration to fix non-DEBU builds From owner-linux-xfs Fri Oct 29 06:58:53 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 29 Oct 2004 06:58:55 -0700 (PDT) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9TDwrMC032211 for ; Fri, 29 Oct 2004 06:58:53 -0700 Received: (from xfs@localhost) by oss.sgi.com (8.13.0/8.12.8/Submit) id i9TDwrdk032210 for linux-xfs@oss.sgi.com; Fri, 29 Oct 2004 06:58:53 -0700 Received: from phoenix.infradead.org (phoenix.infradead.org [81.187.226.98]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9TDwpul032194 for ; Fri, 29 Oct 2004 06:58:52 -0700 Received: from hch by phoenix.infradead.org with local (Exim 4.42 #1 (Red Hat Linux)) id 1CNXH1-0003LY-3O; Fri, 29 Oct 2004 14:58:35 +0100 Date: Fri, 29 Oct 2004 14:58:34 +0100 From: Christoph Hellwig To: peter.kovar@gmail.com Cc: xfs-master@oss.sgi.com Subject: Re: [Bug 380] New: CVS Linux 2.4 link failed w/ undefined reference to _pagebuf_find Message-ID: <20041029135834.GA12839@infradead.org> References: <200410290938.i9T9c2hc007472@oss.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200410290938.i9T9c2hc007472@oss.sgi.com> User-Agent: Mutt/1.4.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by phoenix.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 4353 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs Content-Length: 296 Lines: 8 On Fri, Oct 29, 2004 at 02:38:02AM -0700, bugzilla-daemon@oss.sgi.com wrote: > http://oss.sgi.com/bugzilla/show_bug.cgi?id=380 > > Summary: CVS Linux 2.4 link failed w/ undefined reference to > _pagebuf_find I fixed this, should show up in CVS in about an hour. From owner-linux-xfs Fri Oct 29 22:55:39 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 29 Oct 2004 22:55:42 -0700 (PDT) Received: from hob.acsalaska.net (hob.acsalaska.net [209.112.155.42]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9U5tc9s002291 for ; Fri, 29 Oct 2004 22:55:38 -0700 Received: from erbenson.alaska.net (66-230-90-70-dial-as4.nwc.acsalaska.net [66.230.90.70]) by hob.acsalaska.net (8.13.1/8.13.1) with ESMTP id i9U5tJkr020636 for ; Fri, 29 Oct 2004 21:55:20 -0800 (AKDT) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id C251139D6 for ; Fri, 29 Oct 2004 21:55:18 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id A322440FF35; Fri, 29 Oct 2004 21:55:18 -0800 (AKDT) Date: Fri, 29 Oct 2004 21:55:18 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: best linux kernel with memory management Message-ID: <20041030055518.GK18952@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <412C87F3.2030602@ribosome.natur.cuni.cz> <20040825114005.GB13285@logos.cnet> <412C94F5.4010902@ribosome.natur.cuni.cz> <20040825120450.GA22509@logos.cnet> <412C9D9C.6060703@ribosome.natur.cuni.cz> <20040827121905.GG32707@logos.cnet> <417F6258.7010209@ribosome.natur.cuni.cz> <20041028105108.GB5741@logos.cnet> <20041029071429.GF1246@frodo> <5b64f7f04102906084b358d5f@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wRokNccIwvMzawGl" Content-Disposition: inline In-Reply-To: <5b64f7f04102906084b358d5f@mail.gmail.com> User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-ACS-Spam-Status: no X-ACS-Scanned-By: MD 2.44; SA 2.64; spamdefang 1.109 X-archive-position: 4354 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: erbenson@alaska.net Precedence: bulk X-list: linux-xfs Content-Length: 1983 Lines: 56 --wRokNccIwvMzawGl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 29, 2004 at 09:08:49AM -0400, Rahul Karnik wrote: > On Fri, 29 Oct 2004 17:14:29 +1000, Nathan Scott wrote: >=20 > > There should be no problems using XFS for everything, including > > /boot - I do that on all my systems (for a few years now). >=20 > Last time I checked (~ 2 months ago), there is a GRUB bug that > prevents the use of XFS as the /boot filesystem. I use ext3 for my > /boot to get around this, with all my other filesystems being XFS. Any > chance the XFS devs could help fix the GRUB team fix the bug? grub's install is entirely braindamaged, but it does have the capability of doing non-braindamaged, fully XFS compatible install now, its just less then user friendly: run grub --no-floppy grub> root (hd0,0) # whatever your root or /boot partition is grub> embed /boot/grub/xfs_stage1_5 (hd0) 19 sectors embedded # pay attention to this, use number of sectors below grub> install --stage2=3D/boot/grub/stage2 /boot/grub/stage1 (hd0) (hd0)1+1= 9 p (hd0,0)/boot/grub/stage2 /etc/grub.conf # make sure you use the root device after the ' p ' the --stage2=3D causes grub to read/write the stage2 file via standard unix system calls instead of writing it through the raw block device behind the filesystem's back (which is what causes the problems with xfs). this also has the advantage of moving grub's config file where it belongs in /etc/grub.conf, but note that this won't work if you are using a /boot partition as grub's root. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --wRokNccIwvMzawGl Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iEYEARECAAYFAkGDLMYACgkQJKx7GixEevyrxgCdEpTaCxjkkqduDKJVACII5ZU1 tu0AnA52JXBjqp1vlFOgzgqBBaXOw7wG =GkJd -----END PGP SIGNATURE----- --wRokNccIwvMzawGl-- From owner-linux-xfs Sat Oct 30 11:14:01 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 30 Oct 2004 11:14:04 -0700 (PDT) Received: from mailout.stusta.mhn.de (mailout.stusta.mhn.de [141.84.69.5]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i9UIDxRx003152 for ; Sat, 30 Oct 2004 11:14:00 -0700 Received: (qmail 6165 invoked from network); 30 Oct 2004 18:13:38 -0000 Received: from r063144.stusta.swh.mhn.de (10.150.63.144) by mailout.stusta.mhn.de with SMTP; 30 Oct 2004 18:13:38 -0000 Received: by r063144.stusta.swh.mhn.de (Postfix, from userid 1000) id A9CCFBB8DC; Sat, 30 Oct 2004 20:13:07 +0200 (CEST) Date: Sat, 30 Oct 2004 20:13:07 +0200 From: Adrian Bunk To: nathans@sgi.com Cc: linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: [2.6 patch] some XFS cleanups Message-ID: <20041030181307.GV4374@stusta.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i X-archive-position: 4355 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bunk@stusta.de Precedence: bulk X-list: linux-xfs Content-Length: 8456 Lines: 243 The patch below makes the following cleanups in the XFS code: - remove the unused global function vfs_dmapiops - remove some unused #define's - make several functions static diffstat output: fs/xfs/linux-2.6/xfs_aops.c | 17 ++++++++++++++++- fs/xfs/linux-2.6/xfs_buf.c | 4 ++-- fs/xfs/linux-2.6/xfs_iops.h | 1 - fs/xfs/linux-2.6/xfs_linux.h | 14 -------------- fs/xfs/linux-2.6/xfs_super.c | 2 +- fs/xfs/linux-2.6/xfs_super.h | 12 ------------ fs/xfs/linux-2.6/xfs_vfs.c | 29 ++++++++++++++--------------- fs/xfs/linux-2.6/xfs_vfs.h | 5 ----- 8 files changed, 33 insertions(+), 51 deletions(-) Signed-off-by: Adrian Bunk --- linux-2.6.10-rc1-mm2-full/fs/xfs/linux-2.6/xfs_linux.h.old 2004-10-30 15:33:15.000000000 +0200 +++ linux-2.6.10-rc1-mm2-full/fs/xfs/linux-2.6/xfs_linux.h 2004-10-30 16:54:04.000000000 +0200 @@ -115,20 +115,6 @@ #undef HAVE_REFCACHE /* reference cache not needed for NFS in 2.6 */ #define HAVE_SENDFILE /* sendfile(2) exists in 2.6, but not in 2.4 */ -/* - * State flag for unwritten extent buffers. - * - * We need to be able to distinguish between these and delayed - * allocate buffers within XFS. The generic IO path code does - * not need to distinguish - we use the BH_Delay flag for both - * delalloc and these ondisk-uninitialised buffers. - */ -BUFFER_FNS(PrivateStart, unwritten); -static inline void set_buffer_unwritten_io(struct buffer_head *bh) -{ - bh->b_end_io = linvfs_unwritten_done; -} - #define restricted_chown xfs_params.restrict_chown.val #define irix_sgid_inherit xfs_params.sgid_inherit.val #define irix_symlink_mode xfs_params.symlink_mode.val --- linux-2.6.10-rc1-mm2-full/fs/xfs/linux-2.6/xfs_iops.h.old 2004-10-30 15:30:36.000000000 +0200 +++ linux-2.6.10-rc1-mm2-full/fs/xfs/linux-2.6/xfs_iops.h 2004-10-30 15:32:26.000000000 +0200 @@ -43,7 +43,6 @@ extern struct address_space_operations linvfs_aops; extern int linvfs_get_block(struct inode *, sector_t, struct buffer_head *, int); -extern void linvfs_unwritten_done(struct buffer_head *, int); extern int xfs_ioctl(struct bhv_desc *, struct inode *, struct file *, int, unsigned int, void __user *); --- linux-2.6.10-rc1-mm2-full/fs/xfs/linux-2.6/xfs_aops.c.old 2004-10-30 15:26:37.000000000 +0200 +++ linux-2.6.10-rc1-mm2-full/fs/xfs/linux-2.6/xfs_aops.c 2004-10-30 16:56:46.000000000 +0200 @@ -55,10 +55,25 @@ #include #include +STATIC void linvfs_unwritten_done(struct buffer_head *, int); STATIC void xfs_count_page_state(struct page *, int *, int *, int *); STATIC void xfs_convert_page(struct inode *, struct page *, xfs_iomap_t *, struct writeback_control *wbc, void *, int, int); +/* + * State flag for unwritten extent buffers. + * + * We need to be able to distinguish between these and delayed + * allocate buffers within XFS. The generic IO path code does + * not need to distinguish - we use the BH_Delay flag for both + * delalloc and these ondisk-uninitialised buffers. + */ +BUFFER_FNS(PrivateStart, unwritten); +static inline void set_buffer_unwritten_io(struct buffer_head *bh) +{ + bh->b_end_io = linvfs_unwritten_done; +} + #if defined(XFS_RW_TRACE) void xfs_page_trace( @@ -104,7 +119,7 @@ #define xfs_page_trace(tag, inode, page, mask) #endif -void +STATIC void linvfs_unwritten_done( struct buffer_head *bh, int uptodate) --- linux-2.6.10-rc1-mm2-full/fs/xfs/linux-2.6/xfs_buf.c.old 2004-10-30 15:33:58.000000000 +0200 +++ linux-2.6.10-rc1-mm2-full/fs/xfs/linux-2.6/xfs_buf.c 2004-10-30 15:40:03.000000000 +0200 @@ -1084,7 +1084,7 @@ * done with respect to that I/O. The pb_iodone routine, if * present, will be called as a side-effect. */ -void +static void pagebuf_iodone_work( void *v) { @@ -1263,7 +1263,7 @@ return 0; } -void +static void _pagebuf_ioapply( xfs_buf_t *pb) { --- linux-2.6.10-rc1-mm2-full/fs/xfs/linux-2.6/xfs_super.h.old 2004-10-30 17:00:13.000000000 +0200 +++ linux-2.6.10-rc1-mm2-full/fs/xfs/linux-2.6/xfs_super.h 2004-10-30 17:00:30.000000000 +0200 @@ -32,24 +32,12 @@ #ifndef __XFS_SUPER_H__ #define __XFS_SUPER_H__ -#ifdef CONFIG_XFS_DMAPI -# define vfs_insertdmapi(vfs) vfs_insertops(vfsp, &xfs_dmops) -# define vfs_initdmapi() dmapi_init() -# define vfs_exitdmapi() dmapi_uninit() -#else -# define vfs_insertdmapi(vfs) do { } while (0) -# define vfs_initdmapi() do { } while (0) -# define vfs_exitdmapi() do { } while (0) -#endif - #ifdef CONFIG_XFS_QUOTA -# define vfs_insertquota(vfs) vfs_insertops(vfsp, &xfs_qmops) extern void xfs_qm_init(void); extern void xfs_qm_exit(void); # define vfs_initquota() xfs_qm_init() # define vfs_exitquota() xfs_qm_exit() #else -# define vfs_insertquota(vfs) do { } while (0) # define vfs_initquota() do { } while (0) # define vfs_exitquota() do { } while (0) #endif --- linux-2.6.10-rc1-mm2-full/fs/xfs/linux-2.6/xfs_super.c.old 2004-10-30 16:58:45.000000000 +0200 +++ linux-2.6.10-rc1-mm2-full/fs/xfs/linux-2.6/xfs_super.c 2004-10-30 16:59:50.000000000 +0200 @@ -284,7 +284,7 @@ kmem_cache_free(linvfs_inode_zone, LINVFS_GET_VP(inode)); } -int +STATIC int xfs_inode_shake( int priority, unsigned int gfp_mask) --- linux-2.6.10-rc1-mm2-full/fs/xfs/linux-2.6/xfs_vfs.h.old 2004-10-30 17:08:34.000000000 +0200 +++ linux-2.6.10-rc1-mm2-full/fs/xfs/linux-2.6/xfs_vfs.h 2004-10-30 17:01:57.000000000 +0200 @@ -158,7 +158,6 @@ #define VFS_STATVFS(v, sp,vp, rv) ((rv) = vfs_statvfs(VHEAD(v), sp,vp)) #define VFS_SYNC(v, flag,cr, rv) ((rv) = vfs_sync(VHEAD(v), flag,cr)) #define VFS_VGET(v, vpp,fidp, rv) ((rv) = vfs_vget(VHEAD(v), vpp,fidp)) -#define VFS_DMAPIOPS(v, p, rv) ((rv) = vfs_dmapiops(VHEAD(v), p)) #define VFS_QUOTACTL(v, c,id,p, rv) ((rv) = vfs_quotactl(VHEAD(v), c,id,p)) #define VFS_INIT_VNODE(v, vp,b,ul) ( vfs_init_vnode(VHEAD(v), vp,b,ul) ) #define VFS_FORCE_SHUTDOWN(v, fl,f,l) ( vfs_force_shutdown(VHEAD(v), fl,f,l) ) @@ -176,7 +175,6 @@ #define PVFS_STATVFS(b, sp,vp, rv) ((rv) = vfs_statvfs(b, sp,vp)) #define PVFS_SYNC(b, flag,cr, rv) ((rv) = vfs_sync(b, flag,cr)) #define PVFS_VGET(b, vpp,fidp, rv) ((rv) = vfs_vget(b, vpp,fidp)) -#define PVFS_DMAPIOPS(b, p, rv) ((rv) = vfs_dmapiops(b, p)) #define PVFS_QUOTACTL(b, c,id,p, rv) ((rv) = vfs_quotactl(b, c,id,p)) #define PVFS_INIT_VNODE(b, vp,b2,ul) ( vfs_init_vnode(b, vp,b2,ul) ) #define PVFS_FORCE_SHUTDOWN(b, fl,f,l) ( vfs_force_shutdown(b, fl,f,l) ) @@ -191,7 +189,6 @@ extern int vfs_statvfs(bhv_desc_t *, xfs_statfs_t *, struct vnode *); extern int vfs_sync(bhv_desc_t *, int, struct cred *); extern int vfs_vget(bhv_desc_t *, struct vnode **, struct fid *); -extern int vfs_dmapiops(bhv_desc_t *, caddr_t); extern int vfs_quotactl(bhv_desc_t *, int, int, caddr_t); extern void vfs_init_vnode(bhv_desc_t *, struct vnode *, bhv_desc_t *, int); extern void vfs_force_shutdown(bhv_desc_t *, int, char *, int); @@ -209,8 +206,6 @@ extern vfs_t *vfs_allocate(void); extern void vfs_deallocate(vfs_t *); -extern void vfs_insertops(vfs_t *, bhv_vfsops_t *); -extern void vfs_insertbhv(vfs_t *, bhv_desc_t *, vfsops_t *, void *); extern void bhv_insert_all_vfsops(struct vfs *); extern void bhv_remove_all_vfsops(struct vfs *, int); --- linux-2.6.10-rc1-mm2-full/fs/xfs/linux-2.6/xfs_vfs.c.old 2004-10-30 17:08:29.000000000 +0200 +++ linux-2.6.10-rc1-mm2-full/fs/xfs/linux-2.6/xfs_vfs.c 2004-10-30 17:05:54.000000000 +0200 @@ -47,6 +47,18 @@ #include "xfs_mount.h" #include "xfs_quota.h" +#ifdef CONFIG_XFS_DMAPI +# define vfs_insertdmapi(vfs) vfs_insertops(vfsp, &xfs_dmops) +#else +# define vfs_insertdmapi(vfs) do { } while (0) +#endif + +#ifdef CONFIG_XFS_QUOTA +# define vfs_insertquota(vfs) vfs_insertops(vfsp, &xfs_qmops) +#else +# define vfs_insertquota(vfs) do { } while (0) +#endif + int vfs_mount( struct bhv_desc *bdp, @@ -173,19 +185,6 @@ } int -vfs_dmapiops( - struct bhv_desc *bdp, - caddr_t addr) -{ - struct bhv_desc *next = bdp; - - ASSERT(next); - while (! (bhvtovfsops(next))->vfs_dmapiops) - next = BHV_NEXT(next); - return ((*bhvtovfsops(next)->vfs_dmapiops)(next, addr)); -} - -int vfs_quotactl( struct bhv_desc *bdp, int cmd, @@ -264,7 +263,7 @@ kmem_free(vfsp, sizeof(vfs_t)); } -void +static void vfs_insertops( struct vfs *vfsp, struct bhv_vfsops *vfsops) @@ -276,7 +275,7 @@ bhv_insert(&vfsp->vfs_bh, bdp); } -void +static void vfs_insertbhv( struct vfs *vfsp, struct bhv_desc *bdp, From owner-linux-xfs Sat Oct 30 14:03:21 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 30 Oct 2004 14:03:25 -0700 (PDT) Received: from boss.staszic.waw.pl (postfix@boss.staszic.waw.pl [195.205.163.66]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9UL3KxY014587 for ; Sat, 30 Oct 2004 14:03:21 -0700 Received: from localhost (localhost [127.0.0.1]) by boss.staszic.waw.pl (Postfix) with ESMTP id 796936306B for ; Sat, 30 Oct 2004 23:03:00 +0200 (CEST) Received: from boss.staszic.waw.pl ([127.0.0.1]) by localhost (boss [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24705-09 for ; Sat, 30 Oct 2004 23:03:00 +0200 (CEST) Received: from staszic.waw.pl (unknown [82.177.8.77]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by boss.staszic.waw.pl (Postfix) with ESMTP id 0257363068 for ; Sat, 30 Oct 2004 23:03:00 +0200 (CEST) From: Marek Szyprowski To: linux-xfs@oss.sgi.com Date: Sat, 30 Oct 2004 23:02:30 +0200 Message-ID: X-Mailer: YAM 2.5-dev [MOS/PPC] AmigaOS E-mail Client (c) 2000-2004 by YAM Open Source Team - http://www.yam.ch/ Subject: XFS on-disk structures - docs MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: by amavisd-new at staszic.waw.pl X-archive-position: 4356 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: march@staszic.waw.pl Precedence: bulk X-list: linux-xfs Content-Length: 377 Lines: 12 Hi! Where could I find any information about format of on-disk structures of XFS filesystem? I want to write a XFS-filesystem driver for AmigaOS and MorphOS (AmigaOS compatible clone). Regards -- Marek Szyprowski .. GG:2309080 .. mailto:marek@amiga.pl .. ..... happy MorphOS, AmigaOS and Debian/Linux user ....... ........... http://march.home.staszic.waw.pl/ ............ From owner-linux-xfs Sun Oct 31 03:58:10 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 31 Oct 2004 03:58:12 -0800 (PST) Received: from eik.ii.uib.no (eik.ii.uib.no [129.177.16.3]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9VBw84b028234 for ; Sun, 31 Oct 2004 03:58:09 -0800 Received: from lapprose.ii.uib.no ([129.177.20.37]:46881) by eik.ii.uib.no with esmtp (TLSv1:AES256-SHA:256) (Exim 4.30) id 1COELA-0000nr-SC; Sun, 31 Oct 2004 12:57:44 +0100 Received: (from jfm@localhost) by lapprose.ii.uib.no (8.12.11/8.12.11/Submit) id i9VBviSt031656; Sun, 31 Oct 2004 12:57:44 +0100 Date: Sun, 31 Oct 2004 12:57:43 +0100 From: Jan-Frode Myklebust To: Stas Nikiforov Cc: Linux-XFS Subject: Re: [SOLVED] 2.4.21-20.EL undefined references Message-ID: <20041031115743.GA31443@ii.uib.no> References: <1097666413.2726.299.camel@whirl.lab7.lan> <416D6411.9070806@sgi.com> <1098076806.2726.305.camel@whirl.lab7.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1098076806.2726.305.camel@whirl.lab7.lan> X-archive-position: 4357 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Jan-Frode.Myklebust@bccs.uib.no Precedence: bulk X-list: linux-xfs Content-Length: 250 Lines: 11 On Mon, Oct 18, 2004 at 12:20:07PM +0700, Stas Nikiforov wrote: > Hi, > Thanks again for you help, Eric. > I've applied xfs patches to the 2.4.21-20.EL kernel, > and now I have xfs. Did you make a src.rpm of it? Could I please have a copy? -jf From owner-linux-xfs Sun Oct 31 08:58:28 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 31 Oct 2004 08:58:30 -0800 (PST) Received: from www.dewire.com (212-28-208-94.customer.telia.com [212.28.208.94] (may be forged)) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9VGwRMJ021217 for ; Sun, 31 Oct 2004 08:58:28 -0800 Received: from localhost (kivi.dewire.com [10.1.1.5]) by www.dewire.com (Postfix) with ESMTP id B3843A2E9; Sun, 31 Oct 2004 17:58:10 +0100 (CET) Received: from www.dewire.com ([10.1.1.99]) by localhost (kivi.dewire.com [10.1.1.5]) (amavisd-new, port 10024) with ESMTP id 00872-09; Sun, 31 Oct 2004 17:58:08 +0100 (CET) Received: from xine.hemma.dewire.com (h230n2fls33o811.telia.com [217.208.98.230]) by www.dewire.com (Postfix) with ESMTP id 8CCC0A2E8; Sun, 31 Oct 2004 17:58:09 +0100 (CET) From: Robin Rosenberg To: Nathan Scott Subject: Re: XFS strangeness, xfs_db out of memory Date: Sun, 31 Oct 2004 17:58:05 +0100 User-Agent: KMail/1.7.1 Cc: Linux Kernel , linux-xfs@oss.sgi.com References: <200410240857.31893.robin.rosenberg.lists@dewire.com> <20041029073723.GH1246@frodo> In-Reply-To: <20041029073723.GH1246@frodo> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200410311758.06096.robin.rosenberg.lists@dewire.com> X-Virus-Scanned: by amavisd-new at dewire.com X-archive-position: 4358 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: robin.rosenberg.lists@dewire.com Precedence: bulk X-list: linux-xfs Content-Length: 875 Lines: 22 On Friday 29 October 2004 09.37, Nathan Scott wrote: > On Sun, Oct 24, 2004 at 08:57:26AM +0200, Robin Rosenberg wrote: > > Hi, > > > > I was testing a tiny script on top of xfs_fsr to show fragmentation and > > the resultss of defragmentation. As a result of fine tuning the output I > > ran the script repeatedly and suddenly got error from find (unknown error > > 999 if my memory serves me. It scrolled off the screen). > > ... > > xfs_info $dev > > xfs_db -r $dev -c "frag -v" > > This is accessing the device while the filesystem is mounted, > in older kernels (like the one you have) that would cause the > above corruption error in XFS - thats resolved now. You don't happen to know when or where (patch) this was fixed? I'm usually using Mandrake stock kernels, so I'm looking for something to attach to a bug report. I was looking around without luck. -- robin From owner-linux-xfs Sun Oct 31 14:44:47 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 31 Oct 2004 14:44:49 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i9VMijVY000564 for ; Sun, 31 Oct 2004 14:44:46 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA29657; Mon, 1 Nov 2004 09:44:17 +1100 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 i9VMiFln5535270; Mon, 1 Nov 2004 09:44:15 +1100 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i9VMiCNV5566888; Mon, 1 Nov 2004 09:44:12 +1100 (EST) Date: Mon, 1 Nov 2004 09:44:12 +1100 From: Nathan Scott To: Marek Szyprowski Cc: linux-xfs@oss.sgi.com Subject: Re: XFS on-disk structures - docs Message-ID: <20041101094412.D5462300@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 march@staszic.waw.pl on Sat, Oct 30, 2004 at 11:02:30PM +0200 X-archive-position: 4359 X-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: 427 Lines: 19 On Sat, Oct 30, 2004 at 11:02:30PM +0200, Marek Szyprowski wrote: > Hi! > > Where could I find any information about format of on-disk structures of XFS > filesystem? fs/xfs/*.h :| > I want to write a XFS-filesystem driver for AmigaOS and MorphOS > (AmigaOS compatible clone). I'd advise porting the open source code rather than attempting to write from scratch - XFS is a fairly complex filesystem. cheers. -- Nathan From owner-linux-xfs Sun Oct 31 14:52:16 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 31 Oct 2004 14:52:19 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i9VMqFr4000988 for ; Sun, 31 Oct 2004 14:52:16 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA29826; Mon, 1 Nov 2004 09:51:47 +1100 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 i9VMpjln5566595; Mon, 1 Nov 2004 09:51:45 +1100 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i9VMpgJm5529290; Mon, 1 Nov 2004 09:51:42 +1100 (EST) Date: Mon, 1 Nov 2004 09:51:41 +1100 From: Nathan Scott To: Robin Rosenberg Cc: Linux Kernel , linux-xfs@oss.sgi.com Subject: Re: XFS strangeness, xfs_db out of memory Message-ID: <20041101095141.E5462300@wobbly.melbourne.sgi.com> References: <200410240857.31893.robin.rosenberg.lists@dewire.com> <20041029073723.GH1246@frodo> <200410311758.06096.robin.rosenberg.lists@dewire.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200410311758.06096.robin.rosenberg.lists@dewire.com>; from robin.rosenberg.lists@dewire.com on Sun, Oct 31, 2004 at 05:58:05PM +0100 X-archive-position: 4360 X-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: 364 Lines: 14 On Sun, Oct 31, 2004 at 05:58:05PM +0100, Robin Rosenberg wrote: > > You don't happen to know when or where (patch) this was fixed? I'm usually > using Mandrake stock kernels, so I'm looking for something to attach to a > bug report. I was looking around without luck. > It was bk changeset 1.1803.135.5 -- I'll send you a patch off-list. cheers. -- Nathan From owner-linux-xfs Sun Oct 31 14:55:10 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 31 Oct 2004 14:55:15 -0800 (PST) Received: from boss.staszic.waw.pl (postfix@boss.staszic.waw.pl [195.205.163.66]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9VMt9vg001415 for ; Sun, 31 Oct 2004 14:55:10 -0800 Received: from localhost (localhost [127.0.0.1]) by boss.staszic.waw.pl (Postfix) with ESMTP id 36D566306D; Sun, 31 Oct 2004 23:54:52 +0100 (CET) Received: from boss.staszic.waw.pl ([127.0.0.1]) by localhost (boss [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21854-07; Sun, 31 Oct 2004 23:54:52 +0100 (CET) Received: from staszic.waw.pl (unknown [82.177.8.77]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by boss.staszic.waw.pl (Postfix) with ESMTP id 0183E6306B; Sun, 31 Oct 2004 23:54:52 +0100 (CET) From: Marek Szyprowski To: Nathan Scott Cc: linux-xfs@oss.sgi.com Date: Sun, 31 Oct 2004 23:54:50 +0100 Message-ID: In-Reply-To: <20041101094412.D5462300@wobbly.melbourne.sgi.com> X-Mailer: YAM 2.5-dev [MOS/PPC] AmigaOS E-mail Client (c) 2000-2004 by YAM Open Source Team - http://www.yam.ch/ Subject: Re: XFS on-disk structures - docs MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: by amavisd-new at staszic.waw.pl X-archive-position: 4361 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: march@staszic.waw.pl Precedence: bulk X-list: linux-xfs Content-Length: 899 Lines: 28 Hello Nathan On 31.10.04, you wrote: >> Where could I find any information about format of on-disk structures >> of XFS filesystem? > fs/xfs/*.h :| I read them, but it is really hard to find any valuable information in them... :( >> I want to write a XFS-filesystem driver for AmigaOS and MorphOS >> (AmigaOS compatible clone). > I'd advise porting the open source code rather than attempting > to write from scratch - XFS is a fairly complex filesystem. I know that XFS is complex - that's why I want to write only simple read-only filesystem driver (that also all I need). Also filesystem driver in Linux are completely diffrent than in AmigaOS, so it is easier to write it from scratch, than port. Regards -- Marek Szyprowski .. GG:2309080 .. mailto:marek@amiga.pl .. ..... happy MorphOS, AmigaOS and Debian/Linux user ....... ........... http://march.home.staszic.waw.pl/ ............ From owner-linux-xfs Sun Oct 31 15:21:18 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 31 Oct 2004 15:21:22 -0800 (PST) Received: from hob.acsalaska.net (hob.acsalaska.net [209.112.155.42]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id i9VNLHvK002592 for ; Sun, 31 Oct 2004 15:21:18 -0800 Received: from erbenson.alaska.net (66-230-89-17-dial-as3.nwc.acsalaska.net [66.230.89.17]) by hob.acsalaska.net (8.13.1/8.13.1) with ESMTP id i9VNL0sM053440 for ; Sun, 31 Oct 2004 14:21:00 -0900 (AKST) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 137FB393C for ; Sun, 31 Oct 2004 14:20:59 -0900 (AKST) Received: by plato.local.lan (Postfix, from userid 1000) id 0760A40FF35; Sun, 31 Oct 2004 14:20:58 -0900 (AKST) Date: Sun, 31 Oct 2004 14:20:58 -0900 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: XFS on-disk structures - docs Message-ID: <20041031232058.GM18952@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20041101094412.D5462300@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="L/bWm/e7/ricERqM" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-ACS-Spam-Status: no X-ACS-Scanned-By: MD 2.44; SA 2.64; spamdefang 1.109 X-archive-position: 4362 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: erbenson@alaska.net Precedence: bulk X-list: linux-xfs Content-Length: 1505 Lines: 52 --L/bWm/e7/ricERqM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Oct 31, 2004 at 11:54:50PM +0100, Marek Szyprowski wrote: > Hello Nathan >=20 > On 31.10.04, you wrote: >=20 > >> Where could I find any information about format of on-disk structures > >> of XFS filesystem? > > fs/xfs/*.h :| >=20 > I read them, but it is really hard to find any valuable information in > them... :( you could also read the design documents which are on the sgi site in pdf format, they are not disk-format documentation per se, but they may help somewhat. > >> I want to write a XFS-filesystem driver for AmigaOS and MorphOS > >> (AmigaOS compatible clone). >=20 > > I'd advise porting the open source code rather than attempting > > to write from scratch - XFS is a fairly complex filesystem. >=20 > I know that XFS is complex - that's why I want to write only simple > read-only filesystem driver (that also all I need). Also filesystem driver > in Linux are completely diffrent than in AmigaOS, so it is easier to write > it from scratch, than port. perhaps, perhaps not ;-) --=20 Ethan Benson http://www.alaska.net/~erbenson/ --L/bWm/e7/ricERqM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iEYEARECAAYFAkGFc1oACgkQJKx7GixEevyqsgCfTjsF1ONaBi3D6CPBXMSMPrYf RIMAoJeSLs/ghodTToBcuR0xJaLimYhN =9F/q -----END PGP SIGNATURE----- --L/bWm/e7/ricERqM-- From owner-linux-xfs Sun Oct 31 15:24:58 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 31 Oct 2004 15:25:02 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id i9VNOvIb002987 for ; Sun, 31 Oct 2004 15:24:58 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA00451; Mon, 1 Nov 2004 10:24:31 +1100 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 i9VNOSln5563677; Mon, 1 Nov 2004 10:24:28 +1100 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i9VNOQti5563648; Mon, 1 Nov 2004 10:24:26 +1100 (EST) Date: Mon, 1 Nov 2004 10:24:26 +1100 From: Nathan Scott To: mmokrejs@ribosome.natur.cuni.cz Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: Filesystem performance on 2.4.28-pre3 on hardware RAID5. Message-ID: <20041101102426.G5462300@wobbly.melbourne.sgi.com> References: <20041029111049.GA554@ribosome.natur.cuni.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20041029111049.GA554@ribosome.natur.cuni.cz>; from mmokrejs@ribosome.natur.cuni.cz on Fri, Oct 29, 2004 at 01:10:49PM +0200 X-archive-position: 4363 X-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: 1466 Lines: 40 On Fri, Oct 29, 2004 at 01:10:49PM +0200, mmokrejs@ribosome.natur.cuni.cz wrote: > Hi Nathan, Marcello and others, > the collested meminfo, slabinfo, vmstat output are at > http://www.natur.cuni.cz/~mmokrejs/crash/ On Sun, Oct 31, 2004 at 11:20:35PM +0100, Martin MOKREJ? wrote: > Sorry, fixed by soflink. Was actually http://www.natur.cuni.cz/~mmokrejs/tmp/c rash/ OK, well there's your problem - see the slabinfo output - you have over 700MB of buffer_head structures that are not being reclaimed. Everything else seems to be fine. > If you tell what kind of memory/xfs debugging I should turn > on adn *how*, I can do it immediately. I don't have access I think turning on debugging is going to hinder more than it will help here. > to the machine daily, and already had to be in production. :( > > P.S: It is hardware raid5. I use mkfs.xfs version 2.6.13. Hmm. Did that patch I sent you help at all? That should help free up buffer_heads more effectively in low memory situations like this. You may also have some luck with tweaking bdflush parameters so that flushing out of dirty buffers is started earlier and/or done more often. I can't remember off the top of my head what all the bdflush tunables are - see the bdflush section in Documentation/filesystems/proc.txt. Alternatively, pick a filesystem blocksize that matches your pagesize (4K instead of 512 bytes) to minimise the number of buffer_heads you end up using. cheers. -- Nathan From owner-linux-xfs Sun Oct 31 18:45:09 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 31 Oct 2004 18:45:12 -0800 (PST) Received: from mail42.messagelabs.com (mail42.messagelabs.com [38.118.4.35]) by oss.sgi.com (8.13.0/8.13.0) with SMTP id iA12j91N012445 for ; Sun, 31 Oct 2004 18:45:09 -0800 X-VirusChecked: Checked X-Env-Sender: bvenegas@securities.com X-Msg-Ref: server-17.tower-42.messagelabs.com!1099277086!13220203!1 X-StarScan-Version: 5.4.2; banners=securities.com,-,- X-Originating-IP: [63.87.240.232] Received: (qmail 22728 invoked from network); 1 Nov 2004 02:44:46 -0000 Received: from unknown (HELO mail02.securities.com) (63.87.240.232) by server-17.tower-42.messagelabs.com with SMTP; 1 Nov 2004 02:44:46 -0000 Received: from mail02.securities.com (localhost [127.0.0.1]) by mail02.securities.com (8.12.5/8.12.5-DELIVERY) with ESMTP id iA12ik7K018547 for ; Sun, 31 Oct 2004 21:44:46 -0500 Received: from mail02.securities.com (localhost [127.0.0.1]) by mail02.securities.com (8.12.5/8.12.5-FRONT-END) with ESMTP id iA12ijUe018542 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Sun, 31 Oct 2004 21:44:45 -0500 Received: from localhost (venevene@localhost) by mail02.securities.com (8.12.5/8.12.5/Submit) with ESMTP id iA12igTa018532 for ; Sun, 31 Oct 2004 21:44:45 -0500 X-Authentication-Warning: mail02.securities.com: venevene owned process doing -bs Date: Sun, 31 Oct 2004 21:44:42 -0500 (EST) From: "Benito A. Venegas" X-X-Sender: venevene@mail02.securities.com To: linux-xfs@oss.sgi.com Subject: XFS/Postgres/Fragmentation Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 4364 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bvenegas@securities.com Precedence: bulk X-list: linux-xfs Content-Length: 2677 Lines: 71 Hi people, Thanks to everybody for your great effort day by day to maintain this great project... Now..my problem.. :( I'm experiencing some high fragmentations in one of my boxes, running postgresql database. Last Friday/Saturday I ran some extra maintenance to my postgres DB (reindexing, analyze, vacuum full, etc.) due suddenly we started to have very slow performance in our queries. This maintenance helped, but later I ran xfs_db -r -c "frag -f" and the fragmentation was still high (close to 90%) and xfs_fsr reduced it to 7% after to complete 10 loops for all my file systems in /etc/mtab. Today in the evening I took some statistics and fragmentations level was 64% !! :( #xfs_db -r /dev/sdc1 -c "frag -f" actual 2531, ideal 906, fragmentation factor 64.20% Basic info: -kernel 2.4.19 + xfs 1.2 + some extra patches -postgres 7.2.3-1PGDG #xfs_info /proj meta-data=/proj isize=256 agcount=34, agsize=262144 blks data = bsize=4096 blocks=8885945, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=1200 version=1 = sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 -HW level PE2650 PIII 1400 Mhz Dual CPU, 1Gb ram, /proj is in RAID1 using Perc3/Di (Yes, I know this is a bad raid card, but IMHO this is not causing the fragmentations) Only postgres and a small mysql DB are using this partition. Qs: -Can I ran xfs_fsr daily instead weekly? -DO you think if I update my kernel and recreate my partition, using version 2 (or 3) I can mitigate my fragmentation level? (Risky task) -Is really postgres the frag killer here (if any one of you is running postgres and only the data is one paritition..) Suggestions? They will be very well appreciated .. Cheers, -- Vene.- Internet Securities, Inc. (trading as ISI Emerging Markets) is a Euromoney Institutional Investor company. ________________________________________________________________________ This communication contains information which is confidential. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s) please note any distribution, copying or use of this communication or the information in it is strictly prohibited. If you have received this communication in error please notify us by e-mail or bytelephone (as above) and then delete the e-mail and all attachments and any copies thereof. ________________________________________________________________________ From owner-linux-xfs Sun Oct 31 19:09:36 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 31 Oct 2004 19:09:38 -0800 (PST) Received: from internalmx.vasoftware.com (internalmx1.vasoftware.com [12.152.184.149]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iA139ZqS013471 for ; Sun, 31 Oct 2004 19:09:36 -0800 Received: from adsl-67-121-190-98.dsl.sntc01.pacbell.net ([67.121.190.98]:61277 helo=[10.0.0.1]) by internalmx.vasoftware.com with asmtp (Cipher TLSv1:RC4-MD5:128) (Exim 4.22 #1 (Debian)) id 1COSZK-0000LX-G3 by VAauthid with fixed_plain; Sun, 31 Oct 2004 19:09:18 -0800 Message-ID: <4185A8E1.6050009@linux-sxs.org> Date: Sun, 31 Oct 2004 19:09:21 -0800 From: "Net Llama!" Organization: HAL V User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a5) Gecko/20041003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Benito A. Venegas" , linux-xfs@oss.sgi.com Subject: Re: XFS/Postgres/Fragmentation References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-EA-Verified: internalmx.vasoftware.com 1COSZK-0000LX-G3 94f48610b8ada28fbe24fe42572949a8 X-archive-position: 4365 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: netllama@linux-sxs.org Precedence: bulk X-list: linux-xfs Content-Length: 2658 Lines: 73 On 10/31/2004 06:44 PM, Benito A. Venegas wrote: > Hi people, > > Thanks to everybody for your great effort day by day to maintain this > great project... > > Now..my problem.. :( > > I'm experiencing some high fragmentations in one of my boxes, running > postgresql database. > > Last Friday/Saturday I ran some extra maintenance to my postgres DB > (reindexing, analyze, vacuum full, etc.) due suddenly we started to have > very slow performance in our queries. This maintenance helped, but later > I ran xfs_db -r -c "frag -f" and the > fragmentation was still high (close to 90%) and xfs_fsr reduced it to 7% > after to complete 10 loops for all my file systems in /etc/mtab. > > Today in the evening I took some statistics and fragmentations level was > 64% !! :( > > #xfs_db -r /dev/sdc1 -c "frag -f" > actual 2531, ideal 906, fragmentation factor 64.20% > > > Basic info: > > -kernel 2.4.19 + xfs 1.2 + some extra patches > -postgres 7.2.3-1PGDG Wow, those are some truly ancient versions of both the kernel and postgresql. > > #xfs_info /proj > > meta-data=/proj isize=256 agcount=34, agsize=262144 > blks > data = bsize=4096 blocks=8885945, imaxpct=25 > = sunit=0 swidth=0 blks, unwritten=0 > naming =version 2 bsize=4096 > log =internal bsize=4096 blocks=1200 version=1 > = sunit=0 blks > realtime =none extsz=65536 blocks=0, rtextents=0 > > -HW level > PE2650 PIII 1400 Mhz Dual CPU, 1Gb ram, > /proj is in RAID1 using Perc3/Di (Yes, I know this is a bad raid card, > but IMHO this is not causing the fragmentations) > Only postgres and a small mysql DB are using this partition. > > > Qs: > -Can I ran xfs_fsr daily instead weekly? > > -DO you think if I update my kernel and recreate my partition, using > version 2 (or 3) I can mitigate my fragmentation level? (Risky task) > > -Is really postgres the frag killer here (if any one of you is running > postgres and only the data is one paritition..) I'm running postgresql 7.3.x and 7.4.x on several boxes with XFS using 2.4.x and 2.6.x kernels and i'm not seeing fragmentation at anything even remotely close to what you're reporting. The worst of my boxes is under 10%, and most are under 5%. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ L. Friedman netllama@linux-sxs.org Linux Step-by-step & TyGeMo: http://netllama.ipfox.com 19:05:00 up 63 days, 9:43, 1 user, load average: 1.36, 1.28, 1.16