From owner-xfs@oss.sgi.com Thu Jun 1 00:30:19 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 01 Jun 2006 00:30:23 -0700 (PDT) Received: from dynamicweb.hu (ns.dynamicweb.hu [195.228.155.139]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k517UFeZ013467 for ; Thu, 1 Jun 2006 00:30:18 -0700 Received: from dcccs (53d8296a.adsl.enternet.hu [83.216.41.106]) by dynamicweb.hu (8.13.5/8.12.8) with SMTP id k517QAvl011405; Thu, 1 Jun 2006 09:26:10 +0200 Message-ID: <00d901c6854d$1fc49230$1800a8c0@dcccs> From: "Janos Haar" To: "Jan Engelhardt" Cc: , , References: <01b701c6818d$4bcd37b0$1800a8c0@dcccs> <20060527234350.GA13881@voodoo.jdc.home> <004501c68225$00add170$1800a8c0@dcccs> <9a8748490605280917l73f5751cmf40674fc22726c43@mail.gmail.com> <01d801c6827c$fba04ca0$1800a8c0@dcccs> <01a801c683d2$e7a79c10$1800a8c0@dcccs> <200605301903.k4UJ3xQU008919@turing-police.cc.vt.edu> <1149038431.21827.20.camel@localhost.localdomain> <20060531143849.C478554@wobbly.melbourne.sgi.com> <00f501c68488$4d10c080$1800a8c0@dcccs> Subject: Re: XFS related hang (was Re: How to send a break? - dump from frozen 64bit linux) Date: Thu, 1 Jun 2006 09:29:26 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-archive-position: 7863 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: djani22@netcenter.hu Precedence: bulk X-list: xfs ----- Original Message ----- From: "Jan Engelhardt" To: "Janos Haar" Cc: "Nathan Scott" ; ; Sent: Wednesday, May 31, 2006 11:54 PM Subject: Re: XFS related hang (was Re: How to send a break? - dump from frozen 64bit linux) > > > >Hey, i think i found something. > >My quota on my huge device is broken. > > That should not be a problem. I ran into that "problem" too but had no > lockups back then (2.6.16-rc1). 09:21:36 up 23:05, 1 user, load average: 13.45, 13.14, 13.11 This looks like fixed with disable the quota usage. The system hangs more often, when i use a script what heavily uses chown and chgrp and chmod. Thats why i think, to disable the quota. At this point it looks like fixed. > > >(inferno -- 18014398504855404 0 0 18446744073709551519 > >0 0) > >I cant found a way to re-initialize it. > > Reinit: > > quotaoff /mntpt > umount /mntpt > mount /mntpt Thanks! :-) Janos > > >But anyway, at this point i dont need it, trying to disable the quota usage. > >We will see.... > > > Jan Engelhardt > -- > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ From owner-xfs@oss.sgi.com Thu Jun 1 02:44:59 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 01 Jun 2006 02:45:06 -0700 (PDT) Received: from linux01.gwdg.de (linux01.gwdg.de [134.76.13.21]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k519iteZ025187 for ; Thu, 1 Jun 2006 02:44:58 -0700 Received: from linux01.gwdg.de (localhost [127.0.0.1]) by linux01.gwdg.de (8.13.3/8.13.3/SuSE Linux 0.7) with ESMTP id k519ilWH000995; Thu, 1 Jun 2006 11:44:49 +0200 Received: from localhost (jengelh@localhost) by linux01.gwdg.de (8.13.3/8.13.3/Submit) with ESMTP id k519ikLZ000953; Thu, 1 Jun 2006 11:44:47 +0200 Date: Thu, 1 Jun 2006 11:44:46 +0200 (MEST) From: Jan Engelhardt To: Janos Haar cc: nathans@sgi.com, linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: XFS related hang (was Re: How to send a break? - dump from frozen 64bit linux) In-Reply-To: <00d901c6854d$1fc49230$1800a8c0@dcccs> Message-ID: References: <01b701c6818d$4bcd37b0$1800a8c0@dcccs> <20060527234350.GA13881@voodoo.jdc.home> <004501c68225$00add170$1800a8c0@dcccs> <9a8748490605280917l73f5751cmf40674fc22726c43@mail.gmail.com> <01d801c6827c$fba04ca0$1800a8c0@dcccs> <01a801c683d2$e7a79c10$1800a8c0@dcccs> <200605301903.k4UJ3xQU008919@turing-police.cc.vt.edu> <1149038431.21827.20.camel@localhost.localdomain> <20060531143849.C478554@wobbly.melbourne.sgi.com> <00f501c68488$4d10c080$1800a8c0@dcccs> <00d901c6854d$1fc49230$1800a8c0@dcccs> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 7864 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jengelh@linux01.gwdg.de Precedence: bulk X-list: xfs >> Reinit: >> >> quotaoff /mntpt >> umount /mntpt >> mount /mntpt > >Thanks! :-) > Too bad XFS does not reinit quota on these commands: qutoaoff /mp quotaon /mp Yes, it would lock the filesystem for a moment, but that's better than trying to unmount it under someone having inodes open! Jan Engelhardt -- From owner-xfs@oss.sgi.com Thu Jun 1 14:59:01 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 01 Jun 2006 14:59:05 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k51LwueZ014368 for ; Thu, 1 Jun 2006 14:58:59 -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 HAA07762; Fri, 2 Jun 2006 07:58:35 +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 k51LwVgw529855; Fri, 2 Jun 2006 07:58:31 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k51LwRZS529077; Fri, 2 Jun 2006 07:58:27 +1000 (EST) Date: Fri, 2 Jun 2006 07:58:26 +1000 From: Nathan Scott To: Janos Haar Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: XFS related hang (was Re: How to send a break? - dump from frozen 64bit linux) Message-ID: <20060602075826.B530100@wobbly.melbourne.sgi.com> References: <01b701c6818d$4bcd37b0$1800a8c0@dcccs> <20060527234350.GA13881@voodoo.jdc.home> <004501c68225$00add170$1800a8c0@dcccs> <9a8748490605280917l73f5751cmf40674fc22726c43@mail.gmail.com> <01d801c6827c$fba04ca0$1800a8c0@dcccs> <01a801c683d2$e7a79c10$1800a8c0@dcccs> <200605301903.k4UJ3xQU008919@turing-police.cc.vt.edu> <1149038431.21827.20.camel@localhost.localdomain> <20060531143849.C478554@wobbly.melbourne.sgi.com> <00f501c68488$4d10c080$1800a8c0@dcccs> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <00f501c68488$4d10c080$1800a8c0@dcccs>; from djani22@netcenter.hu on Wed, May 31, 2006 at 10:00:33AM +0200 X-archive-position: 7868 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 599 Lines: 22 On Wed, May 31, 2006 at 10:00:33AM +0200, Janos Haar wrote: > > Hey, i think i found something. > My quota on my huge device is broken. > (inferno -- 18014398504855404 0 0 18446744073709551519 > 0 0) Hmm, that is interesting. I guess you don't know whether this accounting problem happened before you rebooted or whether it only just got this way (after journal recovery)? > I cant found a way to re-initialize it. > But anyway, at this point i dont need it, trying to disable the quota usage. > We will see.... Jan's recipe was spot on, do that. cheers. -- Nathan From owner-xfs@oss.sgi.com Thu Jun 1 15:04:30 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 01 Jun 2006 15:04:33 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k51M4PeZ014837 for ; Thu, 1 Jun 2006 15:04:28 -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 IAA07971; Fri, 2 Jun 2006 08:04:14 +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 k51M4Agw530420; Fri, 2 Jun 2006 08:04:11 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k51M47HD530492; Fri, 2 Jun 2006 08:04:07 +1000 (EST) Date: Fri, 2 Jun 2006 08:04:07 +1000 From: Nathan Scott To: Jan Engelhardt Cc: Janos Haar , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: XFS related hang (was Re: How to send a break? - dump from frozen 64bit linux) Message-ID: <20060602080406.C530100@wobbly.melbourne.sgi.com> References: <9a8748490605280917l73f5751cmf40674fc22726c43@mail.gmail.com> <01d801c6827c$fba04ca0$1800a8c0@dcccs> <01a801c683d2$e7a79c10$1800a8c0@dcccs> <200605301903.k4UJ3xQU008919@turing-police.cc.vt.edu> <1149038431.21827.20.camel@localhost.localdomain> <20060531143849.C478554@wobbly.melbourne.sgi.com> <00f501c68488$4d10c080$1800a8c0@dcccs> <00d901c6854d$1fc49230$1800a8c0@dcccs> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jengelh@linux01.gwdg.de on Thu, Jun 01, 2006 at 11:44:46AM +0200 X-archive-position: 7869 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 793 Lines: 30 On Thu, Jun 01, 2006 at 11:44:46AM +0200, Jan Engelhardt wrote: > >> Reinit: > >> > >> quotaoff /mntpt > >> umount /mntpt > >> mount /mntpt > > > >Thanks! :-) > > > Too bad XFS does not reinit quota on these commands: > > qutoaoff /mp > quotaon /mp Hmm, remount would be saner if we wanted to take that approach... > Yes, it would lock the filesystem for a moment, but that's better than > trying to unmount it under someone having inodes open! But its not just a moment, a quotacheck needs to scan every inode in the filesystem (on disk) to correctly account for all space/inode usage. Its not something to be encouraging people to do frequently, and it would also be very difficult to correctly implement (while the filesystem is actively being modified I mean). cheers. -- Nathan From owner-xfs@oss.sgi.com Thu Jun 1 15:14:38 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 01 Jun 2006 15:14:40 -0700 (PDT) Received: from dynamicweb.hu (ns.dynamicweb.hu [195.228.155.139]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k51MEZeZ016191 for ; Thu, 1 Jun 2006 15:14:37 -0700 Received: from dcccs (53d8296a.adsl.enternet.hu [83.216.41.106]) by dynamicweb.hu (8.13.5/8.12.8) with SMTP id k51MAl4L007296; Fri, 2 Jun 2006 00:10:47 +0200 Message-ID: <01ed01c685c8$b46ec6f0$1800a8c0@dcccs> From: "Janos Haar" To: "Nathan Scott" Cc: , References: <01b701c6818d$4bcd37b0$1800a8c0@dcccs> <20060527234350.GA13881@voodoo.jdc.home> <004501c68225$00add170$1800a8c0@dcccs> <9a8748490605280917l73f5751cmf40674fc22726c43@mail.gmail.com> <01d801c6827c$fba04ca0$1800a8c0@dcccs> <01a801c683d2$e7a79c10$1800a8c0@dcccs> <200605301903.k4UJ3xQU008919@turing-police.cc.vt.edu> <1149038431.21827.20.camel@localhost.localdomain> <20060531143849.C478554@wobbly.melbourne.sgi.com> <00f501c68488$4d10c080$1800a8c0@dcccs> <20060602075826.B530100@wobbly.melbourne.sgi.com> Subject: Re: XFS related hang (was Re: How to send a break? - dump from frozen 64bit linux) Date: Fri, 2 Jun 2006 00:14:04 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-archive-position: 7870 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: djani22@netcenter.hu Precedence: bulk X-list: xfs Content-Length: 1787 Lines: 58 ---- Original Message ----- From: "Nathan Scott" To: "Janos Haar" Cc: ; Sent: Thursday, June 01, 2006 11:58 PM Subject: Re: XFS related hang (was Re: How to send a break? - dump from frozen 64bit linux) > On Wed, May 31, 2006 at 10:00:33AM +0200, Janos Haar wrote: > > > > Hey, i think i found something. > > My quota on my huge device is broken. > > (inferno -- 18014398504855404 0 0 18446744073709551519 > > 0 0) > > Hmm, that is interesting. I guess you don't know whether this > accounting problem happened before you rebooted or whether it > only just got this way (after journal recovery)? In my system, this huge device is difficult. I often need to reboot, and run xfs_repair, to make it clean. (nodes hangs, reboots, etc...) On the beginning, i use the xfs_repair without any options, but it requires to do a mount/umount the mtp before. The problem is, i often get an error message, (dump) during the journal recovery, and after i cannot run the xfs_repair from script, because it needs the log done by mount. Now is my default reboot option is xfs_repair -L, so i dont know, this happens before, or after, sorry. > > > I cant found a way to re-initialize it. > > But anyway, at this point i dont need it, trying to disable the quota usage. > > We will see.... > > Jan's recipe was spot on, do that. The qouta stop solves the hangs problem. This is a bug? Cheers, Janos > > cheers. > > -- > Nathan > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ From owner-xfs@oss.sgi.com Thu Jun 1 16:43:54 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 01 Jun 2006 16:43:57 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k51NhoeZ026911 for ; Thu, 1 Jun 2006 16:43:52 -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 JAA10061; Fri, 2 Jun 2006 09:43:33 +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 k51NhUgw531765; Fri, 2 Jun 2006 09:43:30 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k51NhQTO531400; Fri, 2 Jun 2006 09:43:26 +1000 (EST) Date: Fri, 2 Jun 2006 09:43:25 +1000 From: Nathan Scott To: Janos Haar Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: XFS related hang (was Re: How to send a break? - dump from frozen 64bit linux) Message-ID: <20060602094325.A531851@wobbly.melbourne.sgi.com> References: <004501c68225$00add170$1800a8c0@dcccs> <9a8748490605280917l73f5751cmf40674fc22726c43@mail.gmail.com> <01d801c6827c$fba04ca0$1800a8c0@dcccs> <01a801c683d2$e7a79c10$1800a8c0@dcccs> <200605301903.k4UJ3xQU008919@turing-police.cc.vt.edu> <1149038431.21827.20.camel@localhost.localdomain> <20060531143849.C478554@wobbly.melbourne.sgi.com> <00f501c68488$4d10c080$1800a8c0@dcccs> <20060602075826.B530100@wobbly.melbourne.sgi.com> <01ed01c685c8$b46ec6f0$1800a8c0@dcccs> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <01ed01c685c8$b46ec6f0$1800a8c0@dcccs>; from djani22@netcenter.hu on Fri, Jun 02, 2006 at 12:14:04AM +0200 X-archive-position: 7871 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 1452 Lines: 43 On Fri, Jun 02, 2006 at 12:14:04AM +0200, Janos Haar wrote: > ---- Original Message ----- > > On Wed, May 31, 2006 at 10:00:33AM +0200, Janos Haar wrote: > > > > > > Hey, i think i found something. > > > My quota on my huge device is broken. > > > (inferno -- 18014398504855404 0 0 > 18446744073709551519 > > > 0 0) > > > > Hmm, that is interesting. I guess you don't know whether this > > accounting problem happened before you rebooted or whether it > > only just got this way (after journal recovery)? > > In my system, this huge device is difficult. Can you describe your hardware a bit more? (and send xfs_info output too please). > I often need to reboot, and run xfs_repair, to make it clean. (nodes hangs, > reboots, etc...) Ehrm, hmm, that smells fishy... does this device have a write cache enabled by any chance? > Now is my default reboot option is xfs_repair -L, so i dont know, this > happens before, or after, sorry. Oh, thats bad, all bets are off then - you really cant go doing that routinely, thats an "in emergency only" big red button - it throws away the contents of the journal, and will pretty much guarantee filesystem corruption. But, it sounds alot like you may have a big hardware reliability issue there, which is going to make it difficult to distinguish any software problems. However, if you find a way to reproduce that quota accounting problem (above), I'm all ears. cheers. -- Nathan From owner-xfs@oss.sgi.com Thu Jun 1 22:11:16 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 01 Jun 2006 22:11:23 -0700 (PDT) Received: from linux01.gwdg.de (linux01.gwdg.de [134.76.13.21]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k525BDeZ022246 for ; Thu, 1 Jun 2006 22:11:15 -0700 Received: from linux01.gwdg.de (localhost [127.0.0.1]) by linux01.gwdg.de (8.13.3/8.13.3/SuSE Linux 0.7) with ESMTP id k525B1VM026895; Fri, 2 Jun 2006 07:11:04 +0200 Received: from localhost (jengelh@localhost) by linux01.gwdg.de (8.13.3/8.13.3/Submit) with ESMTP id k525B1Om026889; Fri, 2 Jun 2006 07:11:01 +0200 Date: Fri, 2 Jun 2006 07:11:00 +0200 (MEST) From: Jan Engelhardt To: Nathan Scott cc: Janos Haar , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: XFS related hang (was Re: How to send a break? - dump from frozen 64bit linux) In-Reply-To: <20060602080406.C530100@wobbly.melbourne.sgi.com> Message-ID: References: <9a8748490605280917l73f5751cmf40674fc22726c43@mail.gmail.com> <01d801c6827c$fba04ca0$1800a8c0@dcccs> <01a801c683d2$e7a79c10$1800a8c0@dcccs> <200605301903.k4UJ3xQU008919@turing-police.cc.vt.edu> <1149038431.21827.20.camel@localhost.localdomain> <20060531143849.C478554@wobbly.melbourne.sgi.com> <00f501c68488$4d10c080$1800a8c0@dcccs> <00d901c6854d$1fc49230$1800a8c0@dcccs> <20060602080406.C530100@wobbly.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 7872 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jengelh@linux01.gwdg.de Precedence: bulk X-list: xfs Content-Length: 1060 Lines: 35 >> Too bad XFS does not reinit quota on these commands: >> >> qutoaoff /mp >> quotaon /mp > >Hmm, remount would be saner if we wanted to take that approach... > quotacheck would be sanest :) But the struct super_block->remount is probably the best idea in kernel space. >> Yes, it would lock the filesystem for a moment, but that's better than >> trying to unmount it under someone having inodes open! > >But its not just a moment, a quotacheck needs to scan every inode >in the filesystem (on disk) to correctly account for all space/inode >usage. Yeah right, XFS was designed for large systems rather than for just my 262188 files. (The latter of which completes in an "adequate" time of a few secs.) >Its not something to be encouraging people to do frequently, > Certainly not, but XFS has the advange of bulkstat for quota scanning. `quotacheck` on vfsv0 quota databases always takes longer IMO. >and it would also be very difficult to correctly implement (while the >filesystem is actively being modified I mean). > Noted. Jan Engelhardt -- From owner-xfs@oss.sgi.com Fri Jun 2 01:00:21 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 02 Jun 2006 01:00:25 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k5280HeZ012460 for ; Fri, 2 Jun 2006 01:00:19 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA21063 for ; Fri, 2 Jun 2006 18:00:08 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 4D54B4A5892A; Fri, 2 Jun 2006 18:00:06 +1000 (EST) To: linux-xfs@oss.sgi.com Subject: TAKE 904196 - update KDB patches Message-Id: <20060602080006.4D54B4A5892A@chook.melbourne.sgi.com> Date: Fri, 2 Jun 2006 18:00:06 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 7873 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 1692 Lines: 30 Update KDB x86_64 patches from Keith. Date: Fri Jun 2 17:59:45 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/2.6.x-xfs Inspected by: kaos 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:26155a split-patches/kdb-v4.4-2.6.17-rc5-x86_64-2 - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/split-patches/kdb-v4.4-2.6.17-rc5-x86_64-2 arch/x86_64/kdb/kdb_cmds - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/x86_64/kdb/kdb_cmds split-patches/kdb-v4.4-2.6.17-rc5-common-2 - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/split-patches/kdb-v4.4-2.6.17-rc5-common-2 kdb/kdbmain.c - 1.24 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/kdb/kdbmain.c.diff?r1=text&tr1=1.24&r2=text&tr2=1.23&f=h kdb/ChangeLog - 1.27 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/kdb/ChangeLog.diff?r1=text&tr1=1.27&r2=text&tr2=1.26&f=h split-patches/series - 1.38 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/split-patches/series.diff?r1=text&tr1=1.38&r2=text&tr2=1.37&f=h split-patches/kdb-v4.4-2.6.17-rc5-x86_64-1 - 1.2 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/split-patches/kdb-v4.4-2.6.17-rc5-x86_64-1.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h split-patches/kdb-v4.4-2.6.17-rc5-common-1 - 1.2 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/split-patches/kdb-v4.4-2.6.17-rc5-common-1.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/x86_64/kdb/ChangeLog - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/x86_64/kdb/ChangeLog.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h From owner-xfs@oss.sgi.com Fri Jun 2 01:24:42 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 02 Jun 2006 01:24:46 -0700 (PDT) Received: from dynamicweb.hu (ns.dynamicweb.hu [195.228.155.139]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k528OeeZ015598 for ; Fri, 2 Jun 2006 01:24:42 -0700 Received: from dcccs (53d8296a.adsl.enternet.hu [83.216.41.106]) by dynamicweb.hu (8.13.5/8.12.8) with SMTP id k528Kpm8002441; Fri, 2 Jun 2006 10:20:52 +0200 Message-ID: <017001c6861d$eef931c0$1800a8c0@dcccs> From: "Janos Haar" To: "Nathan Scott" Cc: , References: <004501c68225$00add170$1800a8c0@dcccs> <9a8748490605280917l73f5751cmf40674fc22726c43@mail.gmail.com> <01d801c6827c$fba04ca0$1800a8c0@dcccs> <01a801c683d2$e7a79c10$1800a8c0@dcccs> <200605301903.k4UJ3xQU008919@turing-police.cc.vt.edu> <1149038431.21827.20.camel@localhost.localdomain> <20060531143849.C478554@wobbly.melbourne.sgi.com> <00f501c68488$4d10c080$1800a8c0@dcccs> <20060602075826.B530100@wobbly.melbourne.sgi.com> <01ed01c685c8$b46ec6f0$1800a8c0@dcccs> <20060602094325.A531851@wobbly.melbourne.sgi.com> Subject: Re: XFS related hang (was Re: How to send a break? - dump from frozen 64bit linux) Date: Fri, 2 Jun 2006 10:01:12 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-archive-position: 7874 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: djani22@netcenter.hu Precedence: bulk X-list: xfs Content-Length: 4085 Lines: 118 ----- Original Message ----- From: "Nathan Scott" To: "Janos Haar" Cc: ; Sent: Friday, June 02, 2006 1:43 AM Subject: Re: XFS related hang (was Re: How to send a break? - dump from frozen 64bit linux) > On Fri, Jun 02, 2006 at 12:14:04AM +0200, Janos Haar wrote: > > ---- Original Message ----- > > > On Wed, May 31, 2006 at 10:00:33AM +0200, Janos Haar wrote: > > > > > > > > Hey, i think i found something. > > > > My quota on my huge device is broken. > > > > (inferno -- 18014398504855404 0 0 > > 18446744073709551519 > > > > 0 0) > > > > > > Hmm, that is interesting. I guess you don't know whether this > > > accounting problem happened before you rebooted or whether it > > > only just got this way (after journal recovery)? > > > > In my system, this huge device is difficult. > > Can you describe your hardware a bit more? (and send xfs_info > output too please). [root@X64 ~]# xfs_info /mnt/md0 meta-data=/dev/md31 isize=256 agcount=2600, agsize=1240024 blks = sectsz=512 attr=0 data = bsize=4096 blocks=3223457536, imaxpct=25 = sunit=1 swidth=4 blks, unwritten=1 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=32768, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=16384 blocks=0, rtextents=0 (I used the xfs_grow 2 times) The hw: I use 4 nodes, each has 3.3TiB (RAID4 array), and serves NBD. On the concentrator the RAID0 makes one 12.9TiB from 4x3.3TiB nbd device. The strip is 4kb. (tested, and optimal for performance) > > > I often need to reboot, and run xfs_repair, to make it clean. (nodes hangs, > > reboots, etc...) > > Ehrm, hmm, that smells fishy... does this device have a write > cache enabled by any chance? Yes, you have right! I know, this is a big chance to corrupt the fs, but i need strongly the write caching! This quota corruption is from that case too.... > > > Now is my default reboot option is xfs_repair -L, so i dont know, this > > happens before, or after, sorry. > > Oh, thats bad, all bets are off then - you really cant go doing > that routinely, thats an "in emergency only" big red button - :-) Yes, i know. But on my case, the service is much more important than the data inside the fs. I run a huge "free web storage", and i hate that thing, when i get up, and can see, the system stops on the automatic reboot, and down for few hours... >8-( If it can reboot normally, and drop some MB or GB, this is a "little lose" for me. > it throws away the contents of the journal, and will pretty much > guarantee filesystem corruption. Anyway, if i remove the he -L, the boot hangs on mount about 8 from10 times. The ~1GB lose of 4K strip can pretty much damage the journal too..... If it can repair the fs (2 times from 10), it is often uncompleted, and some minutes or hours lated i get the XFS_FORCE_SHUTDOWN message thanks to the corruption.... (I planned to use an external log, but at this time i dont trust too much the journal recovery.... And if the concentrator finish the flush, the journal notes that it is completed, but the node can hang during write, and drop the data anyway.) > > But, it sounds alot like you may have a big hardware reliability > issue there, which is going to make it difficult to distinguish > any software problems. However, if you find a way to reproduce > that quota accounting problem (above), I'm all ears. Sorry, but i cant. Additionally, i allready have shut down the quota, and i cannot reproduce the "bad quota related hang" problem. Thanks a lot! Janos > > cheers. > > -- > Nathan > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ From owner-xfs@oss.sgi.com Fri Jun 2 03:29:07 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 02 Jun 2006 03:29:11 -0700 (PDT) Received: from lucidpixels.com (lucidpixels.com [66.45.37.187]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k52AT5eZ029902 for ; Fri, 2 Jun 2006 03:29:07 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id 966E015EA97; Fri, 2 Jun 2006 04:29:55 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id 91C4C100EC460 for ; Fri, 2 Jun 2006 04:29:55 -0400 (EDT) Date: Fri, 2 Jun 2006 04:29:55 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34 To: xfs@oss.sgi.com Subject: Tuning XFS. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 7875 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs Content-Length: 220 Lines: 11 Hello all, So far I have been following: http://everything2.com/index.pl?node_id=1479435 For tuning XFS; are there any other parameters or methods of tuning/optimization that are available to the end user? Justin. From owner-xfs@oss.sgi.com Sun Jun 4 03:42:43 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 04 Jun 2006 03:42:49 -0700 (PDT) Received: from mail.ukfsn.org (s2.ukfsn.org [217.158.120.143]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k54AgfeZ018356 for ; Sun, 4 Jun 2006 03:42:42 -0700 Received: from localhost.localdomain (i-83-67-36-194.freedom2surf.net [83.67.36.194]) by mail.ukfsn.org (Postfix) with ESMTP id 6A00EE706B; Sun, 4 Jun 2006 10:35:19 +0100 (BST) Received: from [10.0.0.90] (helo=[10.0.0.90]) by localhost.localdomain with esmtp (Exim 4.50) id 1Fmp9W-0001MB-PH; Sun, 04 Jun 2006 10:44:10 +0100 Message-ID: <4482AB6A.9010105@dgreaves.com> Date: Sun, 04 Jun 2006 10:44:10 +0100 From: David Greaves User-Agent: Thunderbird 1.5.0.2 (X11/20060516) MIME-Version: 1.0 To: xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: 2.6.17-rc3: XFS internal error xlog_clear_stale_blocks(1) X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 7878 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: david@dgreaves.com Precedence: bulk X-list: xfs Content-Length: 1387 Lines: 38 Hi vanilla 2.6.17-rc3 mounting onto an lvm2 ontop of raid5 on top of sata Filesystem "dm-0": Disabling barriers, not supported by the underlying device XFS mounting filesystem dm-0 Filesystem "dm-0": XFS internal error xlog_clear_stale_blocks(1) at line 1225 of file fs/xfs/xfs_log_recover.c. Caller 0xb01fca2f xlog_find_tail+0xa39/0xeb0 xlog_recover+0x2f/0x2f0 xlog_recover+0x2f/0x2f0 xfs_log_mount+0x256/0x650 xfs_mountfs+0xd09/0x1260 xfs_mountfs_check_barriers+0x39/0x120 xfs_mount+0xa2f/0xbf0 xfs_fs_fill_super+0xa0/0x250 snprintf+0x2b/0x30 disk_name+0xd5/0xf0 sb_set_blocksize+0x1f/0x50 get_sb_bdev+0x117/0x155 xfs_fs_get_sb+0x2f/0x40 xfs_fs_fill_super+0x0/0x250 do_kern_mount+0x52/0xe0 do_mount+0x29d/0x770 do_path_lookup+0x10e/0x270 getname+0xda/0x100 __alloc_pages+0x5e/0x2f0 __get_free_pages+0x34/0x60 copy_mount_options+0x44/0x140 sys_mount+0x9d/0xe0 syscall_call+0x7/0xb XFS: failed to locate log tail XFS: log mount/recovery failed: error 990 XFS: log mount failed Anything else I can do? (is it worth trying -rc5?) I'm building 2.6.16.19 and I'll try that shortly... David -- From owner-xfs@oss.sgi.com Sun Jun 4 03:42:42 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 04 Jun 2006 03:42:49 -0700 (PDT) Received: from mail.ukfsn.org (s2.ukfsn.org [217.158.120.143]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k54AgfeZ018354 for ; Sun, 4 Jun 2006 03:42:42 -0700 Received: from localhost.localdomain (i-83-67-36-194.freedom2surf.net [83.67.36.194]) by mail.ukfsn.org (Postfix) with ESMTP id 45F35E70CD; Sun, 4 Jun 2006 11:01:32 +0100 (BST) Received: from [10.0.0.90] (helo=[10.0.0.90]) by localhost.localdomain with esmtp (Exim 4.50) id 1FmpYt-00020j-Rj; Sun, 04 Jun 2006 11:10:23 +0100 Message-ID: <4482B18F.1050606@dgreaves.com> Date: Sun, 04 Jun 2006 11:10:23 +0100 From: David Greaves User-Agent: Thunderbird 1.5.0.2 (X11/20060516) MIME-Version: 1.0 To: xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: 2.6.17-rc3: XFS internal error xlog_clear_stale_blocks(1) References: <4482AB6A.9010105@dgreaves.com> In-Reply-To: <4482AB6A.9010105@dgreaves.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 7878 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: david@dgreaves.com Precedence: bulk X-list: xfs Content-Length: 1539 Lines: 44 David Greaves wrote: > Hi > > vanilla 2.6.17-rc3 > > mounting onto an lvm2 ontop of raid5 on top of sata > > Filesystem "dm-0": Disabling barriers, not supported by the underlying > device > XFS mounting filesystem dm-0 > Filesystem "dm-0": XFS internal error xlog_clear_stale_blocks(1) at line > 1225 of file fs/xfs/xfs_log_recover.c. Caller 0xb01fca2f > xlog_find_tail+0xa39/0xeb0 xlog_recover+0x2f/0x2f0 > xlog_recover+0x2f/0x2f0 xfs_log_mount+0x256/0x650 > xfs_mountfs+0xd09/0x1260 > xfs_mountfs_check_barriers+0x39/0x120 > xfs_mount+0xa2f/0xbf0 xfs_fs_fill_super+0xa0/0x250 > snprintf+0x2b/0x30 disk_name+0xd5/0xf0 > sb_set_blocksize+0x1f/0x50 get_sb_bdev+0x117/0x155 > xfs_fs_get_sb+0x2f/0x40 xfs_fs_fill_super+0x0/0x250 > do_kern_mount+0x52/0xe0 do_mount+0x29d/0x770 > do_path_lookup+0x10e/0x270 getname+0xda/0x100 > __alloc_pages+0x5e/0x2f0 __get_free_pages+0x34/0x60 > copy_mount_options+0x44/0x140 sys_mount+0x9d/0xe0 > syscall_call+0x7/0xb > XFS: failed to locate log tail > XFS: log mount/recovery failed: error 990 > XFS: log mount failed > > > Anything else I can do? > (is it worth trying -rc5?) > > I'm building 2.6.16.19 and I'll try that shortly... > > David > So I tried 2.6.17-rc5 and the problem resolved itself. David -- From owner-xfs@oss.sgi.com Mon Jun 5 02:42:56 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 05 Jun 2006 02:43:00 -0700 (PDT) Received: from smtp-1.hut.fi (smtp-1.hut.fi [130.233.228.91]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k559gseZ006076 for ; Mon, 5 Jun 2006 02:42:55 -0700 Received: from localhost (katosiko.hut.fi [130.233.228.115]) by smtp-1.hut.fi (8.13.6/8.12.10) with ESMTP id k5581XUQ026515 for ; Mon, 5 Jun 2006 11:01:33 +0300 Received: from smtp-1.hut.fi ([130.233.228.91]) by localhost (katosiko.hut.fi [130.233.228.115]) (amavisd-new, port 10024) with LMTP id 17023-14-3 for ; Mon, 5 Jun 2006 11:01:32 +0300 (EEST) Received: from kurp.hut.fi (kurp.hut.fi [130.233.157.234]) by smtp-1.hut.fi (8.13.6/8.12.10) with ESMTP id k556nAii031069 for ; Mon, 5 Jun 2006 09:49:10 +0300 Received: from kurp.hut.fi (jwagner@localhost [127.0.0.1]) by kurp.hut.fi (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k556nAbo013673 for ; Mon, 5 Jun 2006 09:49:10 +0300 Received: from localhost (jwagner@localhost) by kurp.hut.fi (8.13.4/8.13.4/Submit) with ESMTP id k556nA8F013670 for ; Mon, 5 Jun 2006 09:49:10 +0300 Date: Mon, 5 Jun 2006 09:49:10 +0300 (EEST) From: Jan Wagner To: xfs@oss.sgi.com Subject: separate log and structure from user data device? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at katosiko.hut.fi Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id k559gueZ006083 X-archive-position: 7880 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jwagner@kurp.hut.fi Precedence: bulk X-list: xfs Content-Length: 1060 Lines: 32 Hi, I saw with the logdev parameter it is possible to specify an external log device on a separate disk and partition. What would be even more interesting for my special purposes is whether even the file system structure (inodes etc) could be placed on a different disk? Rationale being, when one wants to build a data recorder like a Linux personal video recorder that is using A/V harddisks (ATA Streaming Feature Set, or SmoothStream), one could use the A/V disk with A/V streaming enabled to unreliably(!) write or read all the user data, and a second disk to reliably store the actual log and file system structure on. Yes, there is alreayd the realtime subvolume in XFS, but can it tolerate unreliable A/V read/write? (i.e., where drive has been told to disable and skip all read error correction and write verification?) Very curious about this...! thanks, - Jan -- **************************************************** Helsinki University of Technology Dept. of Metsähovi Radio Observatory Work +358-9-256-4424 http://www.hut.fi/~jwagner/ From owner-xfs@oss.sgi.com Mon Jun 5 03:55:57 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 05 Jun 2006 03:56:01 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k55AtqeZ017555 for ; Mon, 5 Jun 2006 03:55:56 -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 UAA01367; Mon, 5 Jun 2006 20:55:36 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k55AtWgw635994; Mon, 5 Jun 2006 20:55:33 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k55AtUMa636352; Mon, 5 Jun 2006 20:55:30 +1000 (EST) Date: Mon, 5 Jun 2006 20:55:29 +1000 From: Nathan Scott To: Jan Wagner Cc: xfs@oss.sgi.com Subject: Re: separate log and structure from user data device? Message-ID: <20060605205529.B635526@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 jwagner@kurp.hut.fi on Mon, Jun 05, 2006 at 09:49:10AM +0300 X-archive-position: 7881 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 1249 Lines: 32 On Mon, Jun 05, 2006 at 09:49:10AM +0300, Jan Wagner wrote: > Hi, > > I saw with the logdev parameter it is possible to specify an external log > device on a separate disk and partition. > > What would be even more interesting for my special purposes is whether > even the file system structure (inodes etc) could be placed on a > different disk? The realtime subvolume will indeed give you this split. See xfs(5) and mkfs/xfs(8) where most doco resides on this. > Rationale being, when one wants to build a data recorder like a > Linux personal video recorder that is using A/V harddisks (ATA Streaming > Feature Set, or SmoothStream), one could use the A/V disk with A/V > streaming enabled to unreliably(!) write or read all the user data, and a > second disk to reliably store the actual log and file system structure on. > > Yes, there is alreayd the realtime subvolume in XFS, but can it tolerate > unreliable A/V read/write? (i.e., where drive has been told to disable > and skip all read error correction and write verification?) Not 100% sure what unreliable means here from a software POV... would we be seeing errors at the filesystem layer on IOs to/from the driver? If not, I think it would work just fine. cheers. -- Nathan From owner-xfs@oss.sgi.com Mon Jun 5 06:13:29 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 05 Jun 2006 06:13:33 -0700 (PDT) Received: from smtp-3.hut.fi (smtp-3.hut.fi [130.233.228.93]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k55DDReZ022801 for ; Mon, 5 Jun 2006 06:13:29 -0700 Received: from localhost (putosiko.hut.fi [130.233.228.114]) by smtp-3.hut.fi (8.13.6/8.12.10) with ESMTP id k55DDGk5032490; Mon, 5 Jun 2006 16:13:16 +0300 Received: from smtp-3.hut.fi ([130.233.228.93]) by localhost (putosiko.hut.fi [130.233.228.114]) (amavisd-new, port 10024) with LMTP id 04639-05-7; Mon, 5 Jun 2006 16:13:15 +0300 (EEST) Received: from kurp.hut.fi (kurp.hut.fi [130.233.157.234]) by smtp-3.hut.fi (8.13.6/8.12.10) with ESMTP id k55BManp016215; Mon, 5 Jun 2006 14:22:36 +0300 Received: from kurp.hut.fi (jwagner@localhost [127.0.0.1]) by kurp.hut.fi (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k55BMZK4018166; Mon, 5 Jun 2006 14:22:35 +0300 Received: from localhost (jwagner@localhost) by kurp.hut.fi (8.13.4/8.13.4/Submit) with ESMTP id k55BMZkc018163; Mon, 5 Jun 2006 14:22:35 +0300 Date: Mon, 5 Jun 2006 14:22:35 +0300 (EEST) From: Jan Wagner To: Nathan Scott cc: xfs@oss.sgi.com Subject: Re: separate log and structure from user data device? In-Reply-To: <20060605205529.B635526@wobbly.melbourne.sgi.com> Message-ID: References: <20060605205529.B635526@wobbly.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at putosiko.hut.fi X-archive-position: 7882 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jwagner@kurp.hut.fi Precedence: bulk X-list: xfs Content-Length: 1981 Lines: 48 Hi and thanks for your quick reply! On Mon, 5 Jun 2006, Nathan Scott wrote: > On Mon, Jun 05, 2006 at 09:49:10AM +0300, Jan Wagner wrote: > > I saw with the logdev parameter it is possible to specify an external log > > device on a separate disk and partition. > > > > What would be even more interesting for my special purposes is whether > > even the file system structure (inodes etc) could be placed on a > > different disk? > > The realtime subvolume will indeed give you this split. See xfs(5) > and mkfs/xfs(8) where most doco resides on this. Thanks for clarifying. That had been a bit unclear to me from the docs. Also realized only now that xfsctl has to be used to set an empty file's realtime bit to really use the rt subvolume, not quite as straightforward as I thought. Will have to "correct" my progs a bit. > > Rationale being, when one wants to build a data recorder like a > > Linux personal video recorder that is using A/V harddisks (ATA Streaming > > Feature Set, or SmoothStream), one could use the A/V disk with A/V > > streaming enabled to unreliably(!) write or read all the user data, and a > > second disk to reliably store the actual log and file system structure on. > > > > Yes, there is alreayd the realtime subvolume in XFS, but can it tolerate > > unreliable A/V read/write? (i.e., where drive has been told to disable > > and skip all read error correction and write verification?) > > Not 100% sure what unreliable means here from a software POV... would > we be seeing errors at the filesystem layer on IOs to/from the driver? With A/V feature enabled there are no data I/O errors from the disk, thus very likely no errors from the driver either. The only thing is that the data read from or written to that disk has no guarantees to be correct (thus keeping all filesystem structure related stuff on an entirely different disk is kind of essential :-)) > If not, I think it would work just fine. Pretty good, then :) thanks, - Jan From owner-xfs@oss.sgi.com Mon Jun 5 08:49:39 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 05 Jun 2006 08:49:45 -0700 (PDT) Received: from omx1.americas.sgi.com (omx1.americas.sgi.com [198.149.16.13]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k55FnbeZ017965 for ; Mon, 5 Jun 2006 08:49:38 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with SMTP id k55EZHnx002310 for ; Mon, 5 Jun 2006 09:35:18 -0500 Received: from mail.ocs.com.au (kao1.melbourne.sgi.com [134.14.55.179]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id AAA07315; Tue, 6 Jun 2006 00:19:17 +1000 Received: from ocs3.ocs.com.au (ocs3w.ocs.com.au [192.168.254.3]) by mail.ocs.com.au (Postfix) with ESMTP id 3EE4AE0B20A; Tue, 6 Jun 2006 00:19:16 +1000 (EST) Received: by ocs3.ocs.com.au (Postfix, from userid 16331) id 77E2B2EB8; Tue, 6 Jun 2006 00:19:08 +1000 (EST) Received: from ocs3.ocs.com.au (localhost [127.0.0.1]) by ocs3.ocs.com.au (Postfix) with ESMTP id 4F9528017B; Tue, 6 Jun 2006 00:19:08 +1000 (EST) X-Mailer: exmh version 2.7.0 06/18/2004 with nmh-1.1-RC1 From: Keith Owens To: Jan Wagner cc: Nathan Scott , xfs@oss.sgi.com Subject: Re: separate log and structure from user data device? In-reply-to: Your message of "Mon, 05 Jun 2006 14:22:35 +0300." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 06 Jun 2006 00:19:08 +1000 Message-ID: <8630.1149517148@ocs3.ocs.com.au> X-archive-position: 7883 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: xfs Content-Length: 2798 Lines: 55 Jan Wagner (on Mon, 5 Jun 2006 14:22:35 +0300 (EEST)) wrote: > >On Mon, 5 Jun 2006, Nathan Scott wrote: >> On Mon, Jun 05, 2006 at 09:49:10AM +0300, Jan Wagner wrote: >> > I saw with the logdev parameter it is possible to specify an external log >> > device on a separate disk and partition. >> > >> > What would be even more interesting for my special purposes is whether >> > even the file system structure (inodes etc) could be placed on a >> > different disk? >> >> The realtime subvolume will indeed give you this split. See xfs(5) >> and mkfs/xfs(8) where most doco resides on this. > >Thanks for clarifying. That had been a bit unclear to me from the docs. > >Also realized only now that xfsctl has to be used to set an empty file's >realtime bit to really use the rt subvolume, not quite as straightforward >as I thought. Will have to "correct" my progs a bit. > >> > Rationale being, when one wants to build a data recorder like a >> > Linux personal video recorder that is using A/V harddisks (ATA Streaming >> > Feature Set, or SmoothStream), one could use the A/V disk with A/V >> > streaming enabled to unreliably(!) write or read all the user data, and a >> > second disk to reliably store the actual log and file system structure on. >> > >> > Yes, there is alreayd the realtime subvolume in XFS, but can it tolerate >> > unreliable A/V read/write? (i.e., where drive has been told to disable >> > and skip all read error correction and write verification?) >> >> Not 100% sure what unreliable means here from a software POV... would >> we be seeing errors at the filesystem layer on IOs to/from the driver? > >With A/V feature enabled there are no data I/O errors from the disk, thus >very likely no errors from the driver either. > >The only thing is that the data read from or written to that disk has no >guarantees to be correct (thus keeping all filesystem structure related >stuff on an entirely different disk is kind of essential :-)) The ATA Streaming Feature Set defines the Handle Stream Error (HSE) bit to mark data which is critical, and therefore needs full error recovery. That leaves all other data to be handled as best case, returning no data instead of taking too long. Why not use HSE to mark the filesystem metadata and journals? Then you do not need to separate metadata from normal data at the disk level. Of course that requires a change to the VFS layer to pass a flag saying "this data is critical", plus support in the I/O path for setting HSE. Until the kernel is changed, your only option is to use a filesystem that lets you manually separate the two classes of data. The Streaming Feature Set is held in the cfsse field and nothing in the kernel uses cfsse in any significant way, so it will probably be a while before Linux supports AV mode. From owner-xfs@oss.sgi.com Mon Jun 5 16:14:15 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 05 Jun 2006 16:14:20 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k55NEBeZ025779 for ; Mon, 5 Jun 2006 16:14:14 -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 JAA01853; Tue, 6 Jun 2006 09:13:54 +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 k55NDqgw652669; Tue, 6 Jun 2006 09:13:52 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k55NDne5653682; Tue, 6 Jun 2006 09:13:49 +1000 (EST) Date: Tue, 6 Jun 2006 09:13:48 +1000 From: Nathan Scott To: Jan Wagner Cc: xfs@oss.sgi.com Subject: Re: separate log and structure from user data device? Message-ID: <20060606091348.D652166@wobbly.melbourne.sgi.com> References: <20060605205529.B635526@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jwagner@kurp.hut.fi on Mon, Jun 05, 2006 at 02:22:35PM +0300 X-archive-position: 7884 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 1958 Lines: 50 Hi Jan, On Mon, Jun 05, 2006 at 02:22:35PM +0300, Jan Wagner wrote: > > Hi and thanks for your quick reply! No worries. > On Mon, 5 Jun 2006, Nathan Scott wrote: > > On Mon, Jun 05, 2006 at 09:49:10AM +0300, Jan Wagner wrote: > > > I saw with the logdev parameter it is possible to specify an external log > > > device on a separate disk and partition. > > > > > > What would be even more interesting for my special purposes is whether > > > even the file system structure (inodes etc) could be placed on a > > > different disk? > > > > The realtime subvolume will indeed give you this split. See xfs(5) > > and mkfs/xfs(8) where most doco resides on this. > > Thanks for clarifying. That had been a bit unclear to me from the docs. > > Also realized only now that xfsctl has to be used to set an empty file's > realtime bit to really use the rt subvolume, not quite as straightforward > as I thought. Will have to "correct" my progs a bit. You can set the rtinherit bit on a directory, and all new files created there will be automatically written to the realtime device. Theres also a (probably undocumented, I really only added it for my own testing) mkfs option which will let you set the rtinherit bit on the root directory at mkfs time, so all file data will be allocated on the realtime device from the start. Finally, it should be a SMOP to allow a realtime device to be attached to an existing filesystem. Likewise, xfs_fsr could gain a new option or two that would cause it to pass over a filesystem and migrate existing data off to realtime (tiny bit of kernel code needed there to allow that, but not too tricky I think). And if you get truly adventurous, growing of rt should work but shrinking will not - however, this is a much simpler problem to solve than shrinking of the data device. Bonus points if you tackle that :) - all interesting little research projects if anyone is up for a bit of a challenge. cheers. -- Nathan From owner-xfs@oss.sgi.com Mon Jun 5 17:13:26 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 05 Jun 2006 17:13:30 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k560DNeZ004488 for ; Mon, 5 Jun 2006 17:13:25 -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 KAA03587; Tue, 6 Jun 2006 10:13:04 +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 k560D2gw652957; Tue, 6 Jun 2006 10:13:02 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k560CxJB653546; Tue, 6 Jun 2006 10:12:59 +1000 (EST) Date: Tue, 6 Jun 2006 10:12:58 +1000 From: Nathan Scott To: Jan Wagner , Keith Owens Cc: xfs@oss.sgi.com Subject: Re: separate log and structure from user data device? Message-ID: <20060606101258.B644608@wobbly.melbourne.sgi.com> References: <8630.1149517148@ocs3.ocs.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <8630.1149517148@ocs3.ocs.com.au>; from kaos@sgi.com on Tue, Jun 06, 2006 at 12:19:08AM +1000 X-archive-position: 7885 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 1689 Lines: 40 On Tue, Jun 06, 2006 at 12:19:08AM +1000, Keith Owens wrote: > The ATA Streaming Feature Set defines the Handle Stream Error (HSE) bit > to mark data which is critical, and therefore needs full error > recovery. That leaves all other data to be handled as best case, > returning no data instead of taking too long. Why not use HSE to mark > the filesystem metadata and journals? Then you do not need to separate > metadata from normal data at the disk level. Hmm, OK, interesting. > Of course that requires a change to the VFS layer to pass a flag saying > "this data is critical", plus support in the I/O path for setting HSE. Its a trivial thing from the filesystem POV - in XFS, it would require a change in fs/xfs/linux-2.6/xfs_buf.c - the call into submit_bio() there is the point all metadata and log IO gets funnelled through, and file data doesn't travel that path. So, if the drivers/block layer supported a bio flag to say "this is critical", it should be a one-line XFS change to support that I would think. I actually spoke to Jens awhile back about having a bio flag to tag this kind of difference, it'd also be useful to us from a block device tracing POV (i.e. in blktrace) for easily distinguishing file data from metadata/log IOs, so maybe this is one way we'd be able to see a little featurette like that someday too. > Until the kernel is changed, your only option is to use a filesystem > that lets you manually separate the two classes of data. The Streaming > Feature Set is held in the cfsse field and nothing in the kernel uses > cfsse in any significant way, so it will probably be a while before > Linux supports AV mode. Oh well. cheers. -- Nathan From owner-xfs@oss.sgi.com Mon Jun 5 22:33:25 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 05 Jun 2006 22:33:33 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k565XKeZ014484 for ; Mon, 5 Jun 2006 22:33:23 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA12617 for ; Tue, 6 Jun 2006 15:33:09 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 35FEE4A588D4; Tue, 6 Jun 2006 15:33:08 +1000 (EST) To: linux-xfs@oss.sgi.com Subject: TAKE 904196 - Merge up to 2.6.17-rc6 Message-Id: <20060606053308.35FEE4A588D4@chook.melbourne.sgi.com> Date: Tue, 6 Jun 2006 15:33:08 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 7886 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 35348 Lines: 436 Date: Tue Jun 6 15:32:41 AEST 2006 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:26177a include/asm-mips/sparsemem.h - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-mips/sparsemem.h include/asm-um/irqflags.h - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-um/irqflags.h Documentation/serial/driver - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/Documentation/serial/driver.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h MAINTAINERS - 1.27 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/MAINTAINERS.diff?r1=text&tr1=1.27&r2=text&tr2=1.26&f=h Makefile - 1.42 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/Makefile.diff?r1=text&tr1=1.42&r2=text&tr2=1.41&f=h arch/alpha/kernel/alpha_ksyms.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/alpha/kernel/alpha_ksyms.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h arch/alpha/kernel/process.c - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/alpha/kernel/process.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h arch/alpha/kernel/smp.c - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/alpha/kernel/smp.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h arch/alpha/kernel/sys_titan.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/alpha/kernel/sys_titan.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/arm/mm/mm-armv.c - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/mm/mm-armv.c.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h arch/i386/kernel/acpi/boot.c - 1.26 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/i386/kernel/acpi/boot.c.diff?r1=text&tr1=1.26&r2=text&tr2=1.25&f=h arch/i386/mach-generic/probe.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/i386/mach-generic/probe.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/mips/Kconfig - 1.20 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/Kconfig.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h arch/mips/au1000/common/irq.c - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/au1000/common/irq.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h arch/mips/au1000/common/prom.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/au1000/common/prom.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/mips/au1000/common/time.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/au1000/common/time.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h arch/mips/ddb5xxx/ddb5476/dbg_io.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/ddb5xxx/ddb5476/dbg_io.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/mips/ddb5xxx/ddb5477/kgdb_io.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/ddb5xxx/ddb5477/kgdb_io.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/mips/gt64120/momenco_ocelot/dbg_io.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/gt64120/momenco_ocelot/dbg_io.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/mips/ite-boards/generic/dbg_io.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/ite-boards/generic/dbg_io.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/mips/kernel/cpu-bugs64.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/kernel/cpu-bugs64.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h arch/mips/kernel/cpu-probe.c - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/kernel/cpu-probe.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h arch/mips/kernel/entry.S - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/kernel/entry.S.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h arch/mips/kernel/gdb-low.S - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/kernel/gdb-low.S.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h arch/mips/kernel/proc.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/kernel/proc.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h arch/mips/kernel/scall64-o32.S - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/kernel/scall64-o32.S.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h arch/mips/kernel/setup.c - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/kernel/setup.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h arch/mips/kernel/smp.c - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/kernel/smp.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h arch/mips/kernel/syscall.c - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/kernel/syscall.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h arch/mips/kernel/traps.c - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/kernel/traps.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h arch/mips/kernel/vmlinux.lds.S - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/kernel/vmlinux.lds.S.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h arch/mips/math-emu/dp_fint.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/math-emu/dp_fint.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/mips/math-emu/dp_flong.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/math-emu/dp_flong.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/mips/math-emu/sp_fint.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/math-emu/sp_fint.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/mips/math-emu/sp_flong.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/math-emu/sp_flong.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/mips/mm/c-r4k.c - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/mm/c-r4k.c.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h arch/mips/momentum/ocelot_c/dbg_io.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/momentum/ocelot_c/dbg_io.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/mips/momentum/ocelot_g/dbg_io.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/momentum/ocelot_g/dbg_io.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/mips/sgi-ip32/ip32-irq.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/sgi-ip32/ip32-irq.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h arch/ppc/kernel/asm-offsets.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ppc/kernel/asm-offsets.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h arch/s390/kernel/time.c - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/s390/kernel/time.c.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h arch/sparc64/kernel/head.S - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/sparc64/kernel/head.S.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h arch/sparc64/kernel/setup.c - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/sparc64/kernel/setup.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h arch/sparc64/kernel/smp.c - 1.18 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/sparc64/kernel/smp.c.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h arch/sparc64/lib/checksum.S - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/sparc64/lib/checksum.S.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/um/Makefile-i386 - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/um/Makefile-i386.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h arch/um/include/kern_util.h - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/um/include/kern_util.h.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h arch/um/kernel/time_kern.c - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/um/kernel/time_kern.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h arch/um/sys-i386/syscalls.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/um/sys-i386/syscalls.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h arch/x86_64/ia32/ia32_binfmt.c - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/x86_64/ia32/ia32_binfmt.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h arch/x86_64/kernel/e820.c - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/x86_64/kernel/e820.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h arch/x86_64/kernel/entry.S - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/x86_64/kernel/entry.S.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h arch/x86_64/kernel/pci-dma.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/x86_64/kernel/pci-dma.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h arch/x86_64/kernel/pci-gart.c - 1.21 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/x86_64/kernel/pci-gart.c.diff?r1=text&tr1=1.21&r2=text&tr2=1.20&f=h arch/x86_64/kernel/setup.c - 1.21 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/x86_64/kernel/setup.c.diff?r1=text&tr1=1.21&r2=text&tr2=1.20&f=h drivers/base/power/suspend.c - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/base/power/suspend.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h drivers/char/agp/Kconfig - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/char/agp/Kconfig.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h drivers/char/agp/amd64-agp.c - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/char/agp/amd64-agp.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h drivers/char/agp/via-agp.c - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/char/agp/via-agp.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h drivers/char/vt.c - 1.18 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/char/vt.c.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h drivers/i2c/busses/scx200_acb.c - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/i2c/busses/scx200_acb.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h drivers/ieee1394/sbp2.c - 1.19 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/ieee1394/sbp2.c.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h drivers/input/joystick/sidewinder.c - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/input/joystick/sidewinder.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h drivers/input/mouse/logips2pp.c - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/input/mouse/logips2pp.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h drivers/md/md.c - 1.20 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/md/md.c.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h drivers/message/fusion/mptbase.c - 1.19 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/message/fusion/mptbase.c.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h drivers/net/e1000/e1000_main.c - 1.19 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/e1000/e1000_main.c.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h drivers/net/irda/Kconfig - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/irda/Kconfig.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h drivers/net/pcmcia/nmclan_cs.c - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/pcmcia/nmclan_cs.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h drivers/net/pcnet32.c - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/pcnet32.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h drivers/net/pppoe.c - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/pppoe.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h drivers/net/wireless/arlan-main.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/wireless/arlan-main.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/net/wireless/wavelan.c - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/wireless/wavelan.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h drivers/pcmcia/ds.c - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/pcmcia/ds.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h drivers/s390/cio/css.h - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/s390/cio/css.h.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h drivers/s390/cio/device_fsm.c - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/s390/cio/device_fsm.c.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h drivers/s390/net/ctcmain.c - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/s390/net/ctcmain.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h drivers/s390/net/ctctty.c - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/s390/net/ctctty.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h drivers/s390/net/cu3088.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/s390/net/cu3088.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h drivers/s390/net/iucv.c - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/s390/net/iucv.c.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h drivers/s390/net/iucv.h - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/s390/net/iucv.h.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h drivers/s390/net/lcs.c - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/s390/net/lcs.c.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h drivers/s390/net/lcs.h - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/s390/net/lcs.h.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h drivers/s390/net/netiucv.c - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/s390/net/netiucv.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h drivers/s390/net/qeth.h - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/s390/net/qeth.h.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h drivers/s390/net/qeth_mpc.h - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/s390/net/qeth_mpc.h.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h drivers/scsi/libata-core.c - 1.24 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/libata-core.c.diff?r1=text&tr1=1.24&r2=text&tr2=1.23&f=h drivers/scsi/ppa.c - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/ppa.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h drivers/scsi/scsi_devinfo.c - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/scsi_devinfo.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h drivers/scsi/scsi_lib.c - 1.21 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/scsi_lib.c.diff?r1=text&tr1=1.21&r2=text&tr2=1.20&f=h drivers/video/console/fbcon.c - 1.20 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/video/console/fbcon.c.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h drivers/video/maxinefb.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/video/maxinefb.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h fs/affs/namei.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/affs/namei.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h fs/cifs/CHANGES - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/cifs/CHANGES.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h fs/cifs/cifsfs.h - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/cifs/cifsfs.h.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h fs/cifs/cifsproto.h - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/cifs/cifsproto.h.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h fs/cifs/cifssmb.c - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/cifs/cifssmb.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h fs/cifs/connect.c - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/cifs/connect.c.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h fs/cifs/file.c - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/cifs/file.c.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h fs/namei.c - 1.23 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/namei.c.diff?r1=text&tr1=1.23&r2=text&tr2=1.22&f=h include/asm-alpha/smp.h - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-alpha/smp.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h include/asm-alpha/termbits.h - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-alpha/termbits.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h include/asm-arm/arch-l7200/serial_l7200.h - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-arm/arch-l7200/serial_l7200.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/asm-arm/arch-l7200/uncompress.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-arm/arch-l7200/uncompress.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-arm/system.h - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-arm/system.h.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h include/asm-generic/pgtable.h - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-generic/pgtable.h.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h include/asm-mips/addrspace.h - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-mips/addrspace.h.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h include/asm-mips/cpu.h - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-mips/cpu.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h include/asm-mips/delay.h - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-mips/delay.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h include/asm-mips/inst.h - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-mips/inst.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h include/asm-mips/mipsregs.h - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-mips/mipsregs.h.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h include/asm-mips/page.h - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-mips/page.h.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h include/asm-mips/pgtable-32.h - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-mips/pgtable-32.h.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h include/asm-mips/pgtable-64.h - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-mips/pgtable-64.h.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h include/asm-mips/pgtable.h - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-mips/pgtable.h.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h include/asm-mips/sigcontext.h - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-mips/sigcontext.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h include/asm-mips/smp.h - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-mips/smp.h.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h include/asm-s390/lowcore.h - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-s390/lowcore.h.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h include/asm-sparc64/pgtable.h - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-sparc64/pgtable.h.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h include/asm-um/uaccess.h - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-um/uaccess.h.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h include/asm-x86_64/elf.h - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-x86_64/elf.h.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h include/linux/input.h - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/input.h.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h include/linux/mmzone.h - 1.20 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/mmzone.h.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h include/linux/pci_ids.h - 1.26 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/pci_ids.h.diff?r1=text&tr1=1.26&r2=text&tr2=1.25&f=h include/linux/vt_kern.h - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/vt_kern.h.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h include/net/compat.h - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/net/compat.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h mm/slab.c - 1.22 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/mm/slab.c.diff?r1=text&tr1=1.22&r2=text&tr2=1.21&f=h net/bridge/br_if.c - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/bridge/br_if.c.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h net/core/dev.c - 1.23 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/core/dev.c.diff?r1=text&tr1=1.23&r2=text&tr2=1.22&f=h net/ethernet/Makefile - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ethernet/Makefile.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h net/ethernet/sysctl_net_ether.c - 1.3 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ethernet/sysctl_net_ether.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h net/ipv4/netfilter/Kconfig - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv4/netfilter/Kconfig.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h net/ipv4/netfilter/ip_conntrack_core.c - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv4/netfilter/ip_conntrack_core.c.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h net/ipv4/tcp_output.c - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv4/tcp_output.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h net/ipv6/route.c - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv6/route.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h net/irda/irlap.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/irda/irlap.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h net/sysctl_net.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/sysctl_net.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h security/selinux/hooks.c - 1.24 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/security/selinux/hooks.c.diff?r1=text&tr1=1.24&r2=text&tr2=1.23&f=h drivers/ide/pci/sgiioc4.c - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/ide/pci/sgiioc4.c.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h drivers/net/forcedeth.c - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/forcedeth.c.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h arch/mips/momentum/jaguar_atx/dbg_io.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/momentum/jaguar_atx/dbg_io.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/mips/mm/pg-r4k.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/mm/pg-r4k.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h arch/mips/mm/init.c - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/mm/init.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h arch/mips/gt64120/ev64120/serialGT.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/gt64120/ev64120/serialGT.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/mips/au1000/common/sleeper.S - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/au1000/common/sleeper.S.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/net/netconsole.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/netconsole.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h split-patches/dmapi-enable - 1.23 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/split-patches/dmapi-enable.diff?r1=text&tr1=1.23&r2=text&tr2=1.22&f=h split-patches/series - 1.39 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/split-patches/series.diff?r1=text&tr1=1.39&r2=text&tr2=1.38&f=h arch/arm/mach-s3c2410/Kconfig - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/mach-s3c2410/Kconfig.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h drivers/s390/net/qeth_fs.h - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/s390/net/qeth_fs.h.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h drivers/char/ipmi/ipmi_si_intf.c - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/char/ipmi/ipmi_si_intf.c.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h drivers/s390/net/qeth_main.c - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/s390/net/qeth_main.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h drivers/s390/net/qeth_proc.c - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/s390/net/qeth_proc.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h drivers/s390/net/qeth_sys.c - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/s390/net/qeth_sys.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h arch/arm/mach-pxa/mainstone.c - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/mach-pxa/mainstone.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h arch/arm/mach-ixp4xx/Kconfig - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/mach-ixp4xx/Kconfig.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h drivers/serial/cpm_uart/cpm_uart_core.c - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/serial/cpm_uart/cpm_uart_core.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h drivers/serial/cpm_uart/cpm_uart_cpm2.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/serial/cpm_uart/cpm_uart_cpm2.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h arch/mips/kernel/module.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/kernel/module.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/arm/Kconfig.debug - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/Kconfig.debug.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/mmc/Kconfig - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/mmc/Kconfig.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h arch/um/os-Linux/time.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/um/os-Linux/time.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/mips/mm/tlbex.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/mm/tlbex.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h fs/ext3/resize.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/ext3/resize.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h drivers/infiniband/ulp/ipoib/ipoib_ib.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/ulp/ipoib/ipoib_ib.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h drivers/input/mouse/alps.c - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/input/mouse/alps.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h arch/um/sys-x86_64/signal.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/um/sys-x86_64/signal.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h arch/um/sys-x86_64/syscalls.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/um/sys-x86_64/syscalls.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/x86_64/mm/srat.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/x86_64/mm/srat.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h drivers/video/au1100fb.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/video/au1100fb.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h arch/mips/oprofile/op_model_rm9000.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/oprofile/op_model_rm9000.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/mips/oprofile/common.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/oprofile/common.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h arch/mips/kernel/signal-common.h - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/kernel/signal-common.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/input/keyboard/corgikbd.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/input/keyboard/corgikbd.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h arch/x86_64/kernel/pmtimer.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/x86_64/kernel/pmtimer.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/sparc64/lib/csum_copy.S - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/sparc64/lib/csum_copy.S.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/s390/net/qeth_eddp.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/s390/net/qeth_eddp.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h drivers/s390/net/qeth_tso.h - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/s390/net/qeth_tso.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/i386/kernel/syscall_table.S - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/i386/kernel/syscall_table.S.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h net/ipv4/tcp_highspeed.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv4/tcp_highspeed.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/input/mouse/lifebook.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/input/mouse/lifebook.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/scsi/scsi_transport_sas.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/scsi_transport_sas.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h include/asm-powerpc/termbits.h - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-powerpc/termbits.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h net/ipv4/netfilter/ip_conntrack_helper_pptp.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv4/netfilter/ip_conntrack_helper_pptp.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/ppc/syslib/pq2_sys.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ppc/syslib/pq2_sys.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/ppc/syslib/pq2_devices.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ppc/syslib/pq2_devices.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-mips/futex.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-mips/futex.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/mips/kernel/asm-offsets.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/kernel/asm-offsets.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/infiniband/hw/mthca/mthca_srq.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/hw/mthca/mthca_srq.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/input/keyboard/spitzkbd.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/input/keyboard/spitzkbd.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/char/pcmcia/cm4000_cs.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/char/pcmcia/cm4000_cs.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/input/misc/wistron_btns.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/input/misc/wistron_btns.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h block/cfq-iosched.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/block/cfq-iosched.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h mm/memory_hotplug.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/mm/memory_hotplug.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h arch/um/os-Linux/main.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/um/os-Linux/main.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/powerpc/platforms/powermac/setup.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/powerpc/platforms/powermac/setup.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h arch/powerpc/platforms/powermac/low_i2c.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/powerpc/platforms/powermac/low_i2c.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/powerpc/kernel/prom_init.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/powerpc/kernel/prom_init.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h drivers/scsi/sata_sil24.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/sata_sil24.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/mips/oprofile/op_model_mipsxx.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/oprofile/op_model_mipsxx.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/input/touchscreen/ads7846.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/input/touchscreen/ads7846.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h kernel/hrtimer.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/kernel/hrtimer.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/char/tpm/tpm_bios.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/char/tpm/tpm_bios.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/powerpc/platforms/powermac/pfunc_core.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/powerpc/platforms/powermac/pfunc_core.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-arm/arch-ixp23xx/memory.h - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-arm/arch-ixp23xx/memory.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/char/tpm/tpm_tis.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/char/tpm/tpm_tis.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/arm/mach-ixp23xx/core.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/mach-ixp23xx/core.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/spi/spi_s3c24xx.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/spi/spi_s3c24xx.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/rtc/rtc-m48t86.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/rtc/rtc-m48t86.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/ppc/platforms/mpc8272ads_setup.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ppc/platforms/mpc8272ads_setup.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/arm/mm/proc-xsc3.S - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/mm/proc-xsc3.S.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/linux/m48t86.h - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/m48t86.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h From owner-xfs@oss.sgi.com Tue Jun 6 01:17:23 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 06 Jun 2006 01:17:29 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k568HKeZ006481 for ; Tue, 6 Jun 2006 01:17:22 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA16272; Tue, 6 Jun 2006 18:17:02 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 4D4A24A588D4; Tue, 6 Jun 2006 18:17:01 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 953563 - fix recent freeze/thaw issue Message-Id: <20060606081701.4D4A24A588D4@chook.melbourne.sgi.com> Date: Tue, 6 Jun 2006 18:17:01 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 7887 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 478 Lines: 14 Fix mismerge of the fs_writable cleanup patch causing a freeze/thaw test hang. Date: Tue Jun 6 18:16:31 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: nathans The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:26182a xfs_fsops.c - 1.117 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_fsops.c.diff?r1=text&tr1=1.117&r2=text&tr2=1.116&f=h From owner-xfs@oss.sgi.com Tue Jun 6 09:08:09 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 06 Jun 2006 09:09:20 -0700 (PDT) Received: from mail.ukfsn.org (s2.ukfsn.org [217.158.120.143]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k56G86eZ017134 for ; Tue, 6 Jun 2006 09:08:08 -0700 Received: from localhost.localdomain (i-83-67-36-194.freedom2surf.net [83.67.36.194]) by mail.ukfsn.org (Postfix) with ESMTP id 6BD89E705E; Tue, 6 Jun 2006 16:58:50 +0100 (BST) Received: from [10.0.0.90] (helo=[10.0.0.90]) by localhost.localdomain with esmtp (Exim 4.50) id 1Fne5z-0002tS-Nz; Tue, 06 Jun 2006 17:07:55 +0100 Message-ID: <4485A85B.3080102@dgreaves.com> Date: Tue, 06 Jun 2006 17:07:55 +0100 From: David Greaves User-Agent: Thunderbird 1.5.0.2 (X11/20060516) MIME-Version: 1.0 To: Nathan Scott Cc: "'linux-kernel@vger.kernel.org'" , xfs@oss.sgi.com Subject: Oops and panic running xfs_fsr on 2.6.16.9 X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 7888 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: david@dgreaves.com Precedence: bulk X-list: xfs Content-Length: 3638 Lines: 85 Hi Nathan I was running xfs_fsr on 2.6.16.9 on a 1.2Tb raid5 using xfs_fsr version 2.2.30 The filesystem is very heavily fragmented: cu:~# xfs_db -c frag -r /dev/huge_vg/huge_lv actual 110636, ideal 3856, fragmentation factor 96.51% I've appended the oopses and an image of the panic that occurred. Just so you know (in case it's related) I also got lots of: could not allocate buf: /huge/.fsr/ag2/tmp681 (I've since seen http://marc.theaimsgroup.com/?l=linux-xfs&m=114380655102639&w=2 but not applied the patch) Can I supply anything else? David cu kernel: Oops: 0002 [#1] cu kernel: CPU: 0 cu kernel: EIP is at __page_cache_release+0x35/0xa0 cu kernel: eax: b151d678 ebx: b1056040 ecx: b1056058 edx: 03056078 cu kernel: esi: b03cee10 edi: 00000212 ebp: ffffffff esp: c7761d5c cu kernel: ds: 007b es: 007b ss: 0068 cu kernel: Process xfs_fsr (pid: 27562, threadinfo=c7760000 task=eeeab070) cu kernel: Stack: <0>16001c68 00000005 b1056040 b013feed b1056040 b1056040 00001c62 0000000e cu kernel: 00000000 00000000 00000000 0000000e 00000000 b12ac1e0 b1760b00 b1760b20 cu kernel: b151d640 b151d660 b1056040 b1056060 b11a7e80 b11a7ea0 b1716b00 b1716b20 cu kernel: [truncate_inode_pages_range+269/736] truncate_inode_pages_range+0x10d/0x2e0 cu kernel: [truncate_inode_pages+47/64] truncate_inode_pages+0x2f/0x40 cu kernel: [xfs_swapext+1052/2368] xfs_swapext+0x41c/0x940 cu kernel: [xfs_ioctl+2058/2128] xfs_ioctl+0x80a/0x850 cu kernel: [notify_change+508/662] notify_change+0x1fc/0x296 cu kernel: [linvfs_ioctl_invis+71/144] linvfs_ioctl_invis+0x47/0x90 cu kernel: [do_ioctl+104/128] do_ioctl+0x68/0x80 cu kernel: [vfs_ioctl+141/464] vfs_ioctl+0x8d/0x1d0 cu kernel: [sys_ioctl+69/128] sys_ioctl+0x45/0x80 cu kernel: [syscall_call+7/11] syscall_call+0x7/0xb cu kernel: Call Trace: cu kernel: Code: 89 7c 24 08 89 c3 8b 00 c1 e8 1e 8b 34 85 c8 79 41 b0 9c 5f fa 0f ba 33 05 19 c0 85 c0 74 2c 8d 4b 18 8b 43 18 8b 51 04 89 50 04 <89> 02 c7 41 04 00 02 20 00 8b 03 c7 43 18 00 01 10 00 a8 40 74 cu kernel: Oops: 0002 [#2] cu kernel: CPU: 0 cu kernel: EIP is at isolate_lru_pages+0x4c/0xb0 cu kernel: eax: b03ceee4 ebx: b03ceee4 ecx: b151d678 edx: 03056078 cu kernel: esi: 00000014 edi: 00000013 ebp: efc17e9c esp: efc17e6c cu kernel: ds: 007b es: 007b ss: 0068 cu kernel: Process kswapd0 (pid: 114, threadinfo=efc16000 task=efeef070) cu kernel: Stack: <0>b03cee10 b03cee10 efc17e9c efc17f40 b0140f53 00000020 b03ceee4 efc17e9c cu kernel: efc17e98 b03ceee4 00000020 00000296 b151d658 b127dd38 00000000 00000001 cu kernel: efa38420 00000000 efc17ec8 b011703e b19cfab0 0000000f 00000000 efc2b9e0 cu kernel: Call Trace: cu kernel: [shrink_cache+115/640] shrink_cache+0x73/0x280 cu kernel: [wake_up_process+30/32] wake_up_process+0x1e/0x20 cu kernel: [xfsbufd_wakeup+79/96] xfsbufd_wakeup+0x4f/0x60 cu kernel: [shrink_slab+132/496] shrink_slab+0x84/0x1f0 cu kernel: [shrink_zone+182/224] shrink_zone+0xb6/0xe0 cu kernel: [balance_pgdat+667/944] balance_pgdat+0x29b/0x3b0 cu kernel: [kswapd+244/272] kswapd+0xf4/0x110 cu kernel: [autoremove_wake_function+0/96] autoremove_wake_function+0x0/0x60 cu kernel: [autoremove_wake_function+0/96] autoremove_wake_function+0x0/0x60 cu kernel: [kswapd+0/272] kswapd+0x0/0x110 cu kernel: [kernel_thread_helper+5/20] kernel_thread_helper+0x5/0x14 cu kernel: Code: 4b 04 8b 41 04 39 d8 74 07 83 e8 18 0f 0d 08 90 0f ba 71 e8 05 19 c0 85 c0 75 08 0f 0b 41 04 0b ea 37 b0 8b 51 04 8b 01 89 50 04 <89> 02 c7 41 04 00 02 20 00 c7 01 00 01 10 00 ff 41 ec 0f 94 c0 Crash image: http://www.dgreaves.com/pics/xfs_crash.jpg From owner-xfs@oss.sgi.com Tue Jun 6 16:42:56 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 06 Jun 2006 16:42:59 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k56NgqeZ030072 for ; Tue, 6 Jun 2006 16:42:54 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA07230 for ; Wed, 7 Jun 2006 09:42:41 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 274F34A588D4; Wed, 7 Jun 2006 09:42:40 +1000 (EST) To: linux-xfs@oss.sgi.com Subject: TAKE 907752 - acl Message-Id: <20060606234240.274F34A588D4@chook.melbourne.sgi.com> Date: Wed, 7 Jun 2006 09:42:40 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 7890 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 1105 Lines: 22 Fix a segfault in get/setfacl with non-existent files, nftw-workaround-related. Date: Wed Jun 7 09:42:29 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-cmds Inspected by: Daniel Kahn Gillmor The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:26189a acl/VERSION - 1.79 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/VERSION.diff?r1=text&tr1=1.79&r2=text&tr2=1.78&f=h acl/doc/CHANGES - 1.88 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/doc/CHANGES.diff?r1=text&tr1=1.88&r2=text&tr2=1.87&f=h acl/debian/changelog - 1.76 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/debian/changelog.diff?r1=text&tr1=1.76&r2=text&tr2=1.75&f=h acl/setfacl/setfacl.c - 1.19 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/setfacl/setfacl.c.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h acl/getfacl/getfacl.c - 1.19 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/getfacl/getfacl.c.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h From owner-xfs@oss.sgi.com Tue Jun 6 21:27:15 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 06 Jun 2006 21:28:32 -0700 (PDT) Received: from omx1.americas.sgi.com (omx1.americas.sgi.com [198.149.16.13]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k574REeZ012632 for ; Tue, 6 Jun 2006 21:27:15 -0700 Received: from imr2.americas.sgi.com (imr2.americas.sgi.com [198.149.16.18]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id k573Nknx029672 for ; Tue, 6 Jun 2006 22:23:46 -0500 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by imr2.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id k573h27p32962979; Tue, 6 Jun 2006 20:43:02 -0700 (PDT) Received: from attica.americas.sgi.com (attica.americas.sgi.com [128.162.236.44]) by poppy-e236.americas.sgi.com (8.12.9/ASC-news-1.4) with ESMTP id k573NhSQ14825024; Tue, 6 Jun 2006 22:23:43 -0500 (CDT) Received: by attica.americas.sgi.com (Postfix, from userid 3682) id 86F37105FEA2; Tue, 6 Jun 2006 22:23:43 -0500 (CDT) To: sgi.bugs.snlinux@sgi.com, sgi.bugs.xfs@sgi.com, xfs@sgi.com Subject: TAKE 951958 - Regression in bonnie++ due to messed up nused counter in xfs_dir2_free_hdr_t Message-Id: <20060607032343.86F37105FEA2@attica.americas.sgi.com> Date: Tue, 6 Jun 2006 22:23:43 -0500 (CDT) From: alkirkco@sgi.com (Mandy Miklos) X-archive-position: 7893 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: alkirkco@sgi.com Precedence: bulk X-list: xfs Content-Length: 876 Lines: 21 Fix nused counter. It's currently getting set to -1 rather than getting decremented by 1. Since nused never reaches 0, the "if (!free->hdr.nused)" check in xfs_dir2_leafn_remove() fails every time and xfs_dir2_shrink_inode() doesn't get called when it should. This causes extra blocks to be left on an empty directory and the directory in unable to be converted back to inline extent mode. Date: Tue Jun 6 20:21:01 PDT 2006 Workarea: attica.americas.sgi.com:/data/lwork/attica2/alkirkco/XFS/2.6.x-xfs-i386 Inspected by: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: xfs-linux:xfs-kern:211382a fs/xfs/xfs_dir2_node.c - 1.56 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir2_node.c.diff?r1=text&tr1=1.56&r2=text&tr2=1.55&f=h - Fix nused counter to get decremented by 1 rather than set to -1. From owner-xfs@oss.sgi.com Wed Jun 7 04:09:57 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 07 Jun 2006 04:10:00 -0700 (PDT) Received: from smtp-4.hut.fi (smtp-4.hut.fi [130.233.228.94]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k57B9seZ013371 for ; Wed, 7 Jun 2006 04:09:56 -0700 Received: from localhost (katosiko.hut.fi [130.233.228.115]) by smtp-4.hut.fi (8.13.6/8.12.10) with ESMTP id k57B9g2b008393; Wed, 7 Jun 2006 14:09:42 +0300 Received: from smtp-4.hut.fi ([130.233.228.94]) by localhost (katosiko.hut.fi [130.233.228.115]) (amavisd-new, port 10024) with LMTP id 26768-07-8; Wed, 7 Jun 2006 14:09:41 +0300 (EEST) Received: from kurp.hut.fi (kurp.hut.fi [130.233.157.234]) by smtp-4.hut.fi (8.13.6/8.12.10) with ESMTP id k57B5wWm007892; Wed, 7 Jun 2006 14:05:58 +0300 Received: from kurp.hut.fi (jwagner@localhost [127.0.0.1]) by kurp.hut.fi (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k57B5wuH012313; Wed, 7 Jun 2006 14:05:58 +0300 Received: from localhost (jwagner@localhost) by kurp.hut.fi (8.13.4/8.13.4/Submit) with ESMTP id k57B5vnS012310; Wed, 7 Jun 2006 14:05:57 +0300 Date: Wed, 7 Jun 2006 14:05:57 +0300 (EEST) From: Jan Wagner To: Nathan Scott cc: Keith Owens , xfs@oss.sgi.com Subject: Re: separate log and structure from user data device? In-Reply-To: <20060606101258.B644608@wobbly.melbourne.sgi.com> Message-ID: References: <8630.1149517148@ocs3.ocs.com.au> <20060606101258.B644608@wobbly.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at katosiko.hut.fi X-archive-position: 7894 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jwagner@kurp.hut.fi Precedence: bulk X-list: xfs Content-Length: 2188 Lines: 58 On Tue, 6 Jun 2006, Nathan Scott wrote: > > Of course that requires a change to the VFS layer to pass a flag saying > > "this data is critical", plus support in the I/O path for setting HSE. > > Its a trivial thing from the filesystem POV - in XFS, it would > require a change in fs/xfs/linux-2.6/xfs_buf.c - the call into > submit_bio() there is the point all metadata and log IO gets > funnelled through, and file data doesn't travel that path. So, > if the drivers/block layer supported a bio flag to say "this is > critical", it should be a one-line XFS change to support that I > would think. (Short-lived discussion/probing at http://lkml.org/lkml/2006/5/18/261) Don't know what a bio flag is but it sounds good :), like some ioctl() command to tag the block device into critical / noncritical mode. Or since not in the kernel yet, maybe incorporate the ATA commands (HD internal flag on/off) for enabling Streaming into the xfs realtime data code sections, while taking care to switch Streaming back off when accessing other fs partition / xfs subvolume on same drive (quite a hack, I guess...). Oh well. Other question, is the below really the correct way to enable realtime for a new file? /* O_DIRECT for "realtime" */ int fid; assert( (fid = open(pn, O_WRONLY|O_CREAT|O_DIRECT|O_SYNC|O_LARGEFILE)) != -1 ); // ------------------- XFS realtime struct fsxattr fsxinfo; if (ioctl(fid, XFS_IOC_FSGETXATTR, &fsxinfo) == -1) { perror("fsgetxattr failed"); } else { fsxinfo.fsx_xflags = XFS_XFLAG_REALTIME; if (ioctl(fid, XFS_IOC_FSSETXATTR, &fsxinfo) == -1) { perror("setxattr ioctl failed"); } } //------------------- //... write to file created file //... assert( (close(fid) != -1) ); I'm getting only about 500mbits/s write speed into the file (continuously writing 1024 byte or much larger chunks) with the above code on XFS with the rtdev on a RAID0 /dev/md0 and "actual" XFS on /dev/hda6. With XFS directly on /dev/md0 and no realtime section but logdev=/dev/hda6, throughput is a nice ~2.5gbits/s. Hence not sure if the above code is correct? (but maybe rt support in the linux 2.6.16 kernel really is /this/ "experimental" ;-)... thanks, - Jan From owner-xfs@oss.sgi.com Wed Jun 7 11:21:11 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 07 Jun 2006 11:21:19 -0700 (PDT) Received: from MAIL01HQ.adic.com (mail01hq.adic.com [63.81.117.10]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k57IL9eZ014068 for ; Wed, 7 Jun 2006 11:21:11 -0700 Received: from mail01dn.adic.com ([172.16.40.35]) by MAIL01HQ.adic.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Jun 2006 10:12:13 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 MIME-Version: 1.0 Subject: xfs version info in kernel 2.4.20 Date: Wed, 7 Jun 2006 11:12:12 -0600 Message-ID: <51A9A4FCBC06324F8BFE956A551B58E00565E353@mail01dn.adic.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: xfs version info in kernel 2.4.20 Thread-Index: AcaKVYKYu9zg1B9DRfqZdkS3qNrokQ== From: "Rishi Malik" To: X-OriginalArrivalTime: 07 Jun 2006 17:12:13.0829 (UTC) FILETIME=[85345350:01C68A55] Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit X-archive-position: 7895 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: rishi.malik@adic.com Precedence: bulk X-list: xfs Content-Length: 595 Lines: 34 Hi all, I'm trying to find out what version of xfs is included in kernel 2.4.20. Grepping the source hasn't been very helpful. I've looked for XFS_VERSION as suggested around the net, but it is not there. Grepping for version leaves a lot of info, that doesn't look to be useful. Anyone know how I can find this out? Also, is there a publicly available changelog of bugfixes, etc for xfs? Thanks a lot, Rishi Malik Rishi Malik::Firmware Engineer::Rishi.Malik@adic.com ::o720-249-5932::c303-396-3568 [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Wed Jun 7 13:34:08 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 07 Jun 2006 13:34:13 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k57KY6eZ032320 for ; Wed, 7 Jun 2006 13:34:08 -0700 Received: by nf-out-0910.google.com with SMTP id l23so235346nfc for ; Wed, 07 Jun 2006 13:33:57 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:x-mailer:mime-version:content-type:content-transfer-encoding; b=eeQherdLcxEKQ6u1QXtPEhg2mdHh3HnButlX4yM9uRBSniXg/rrWrTz3JnyFvEqjDxrViaZfzfrHOMS0iKqsw3wX80Do6M2odsZG1dT+BgRiiBfy+AikJHRueYkwGmVvwmRU4iTWMONo33KP1INbIp+GMR7oLpqZKkxkdrJ0c9w= Received: by 10.49.92.15 with SMTP id u15mr754722nfl; Wed, 07 Jun 2006 11:55:10 -0700 (PDT) Received: from estel ( [80.103.4.236]) by mx.gmail.com with ESMTP id y24sm1240988nfb.2006.06.07.11.54.43; Wed, 07 Jun 2006 11:55:09 -0700 (PDT) Date: Wed, 7 Jun 2006 20:53:16 +0200 From: Diego Calleja To: linux-kernel@vger.kernel.org Cc: akpm@osdl.org, netdev@vger.kernel.org, linux-xfs@oss.sgi.com, ecki@lina.inka.de, lkml@rtr.ca Subject: Updated sysctl documentation take #2 Message-Id: <20060607205316.bbb3c379.diegocg@gmail.com> X-Mailer: Sylpheed version 2.2.4 (GTK+ 2.8.17; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7896 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: diegocg@gmail.com Precedence: bulk X-list: xfs Content-Length: 671 Lines: 20 Since people didn't like the "many small files" approach, I've moved it to directories containing index.txt files: Documentation/sysctl/vm/index.txt Documentation/sysctl/net/core/index.txt Documentation/sysctl/net/unix/index.txt Documentation/sysctl/net/ipv4/index.txt Documentation/sysctl/net/ipv4/conf/index.txt Documentation/sysctl/net/ipv4/route/index.txt Documentation/sysctl/net/ipv4/neigh/index.txt and so on. As previously, this moves all sysctl documentation (including XFS and network) to Documentation/sysctl/*. The patch is against linus tree and weights more than 200K in size and is place at: http://www.terra.es/personal/diegocg/sysctl-docs Comments? From owner-xfs@oss.sgi.com Wed Jun 7 14:14:25 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 07 Jun 2006 14:14:29 -0700 (PDT) Received: from xenotime.net (xenotime.net [66.160.160.81]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k57LENeZ004621 for ; Wed, 7 Jun 2006 14:14:24 -0700 Received: from midway.site ([71.245.102.105]) by xenotime.net for ; Wed, 7 Jun 2006 13:04:05 -0700 Date: Wed, 7 Jun 2006 13:06:53 -0700 From: "Randy.Dunlap" To: Diego Calleja Cc: linux-kernel@vger.kernel.org, akpm@osdl.org, netdev@vger.kernel.org, linux-xfs@oss.sgi.com, ecki@lina.inka.de, lkml@rtr.ca Subject: Re: Updated sysctl documentation take #2 Message-Id: <20060607130653.9a4d572c.rdunlap@xenotime.net> In-Reply-To: <20060607205316.bbb3c379.diegocg@gmail.com> References: <20060607205316.bbb3c379.diegocg@gmail.com> Organization: YPO4 X-Mailer: Sylpheed version 2.2.5 (GTK+ 2.8.3; x86_64-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 7897 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: rdunlap@xenotime.net Precedence: bulk X-list: xfs Content-Length: 4430 Lines: 115 On Wed, 7 Jun 2006 20:53:16 +0200 Diego Calleja wrote: > Since people didn't like the "many small files" approach, I've moved > it to directories containing index.txt files: > > Documentation/sysctl/vm/index.txt > Documentation/sysctl/net/core/index.txt > Documentation/sysctl/net/unix/index.txt > Documentation/sysctl/net/ipv4/index.txt > Documentation/sysctl/net/ipv4/conf/index.txt > Documentation/sysctl/net/ipv4/route/index.txt > Documentation/sysctl/net/ipv4/neigh/index.txt > > and so on. > > As previously, this moves all sysctl documentation (including > XFS and network) to Documentation/sysctl/*. The patch is > against linus tree and weights more than 200K in size > and is place at: http://www.terra.es/personal/diegocg/sysctl-docs ~> diffstat -p1 -w 70 sysctl-docs Documentation/filesystems/proc.txt | 1210 ---------------- Documentation/filesystems/xfs.txt | 84 - Documentation/networking/00-INDEX | 2 Documentation/networking/Configurable | 2 Documentation/networking/decnet.txt | 4 Documentation/networking/ip-sysctl.txt | 899 ----------- Documentation/networking/xfrm_sync.txt | 11 Documentation/sysctl/README | 121 - Documentation/sysctl/abi.txt | 54 Documentation/sysctl/abi/index.txt | 49 Documentation/sysctl/dev/README | 2 Documentation/sysctl/fs.txt | 150 - Documentation/sysctl/fs/index.txt | 240 +++ Documentation/sysctl/fs/xfs/index.txt | 170 ++ Documentation/sysctl/kernel.txt | 344 ---- Documentation/sysctl/kernel/index.txt | 628 ++++++++ Documentation/sysctl/net/README | 8 Documentation/sysctl/net/appletalk/index.txt | 38 Documentation/sysctl/net/bridge/index.txt | 44 Documentation/sysctl/net/core/index.txt | 115 + Documentation/sysctl/net/ipv4/conf/index.txt | 270 +++ Documentation/sysctl/net/ipv4/index.txt | 739 +++++++++ Documentation/sysctl/net/ipv4/neigh/index.txt | 138 + Documentation/sysctl/net/ipv4/route/index.txt | 143 + Documentation/sysctl/net/ipv6/conf/index.txt | 256 +++ Documentation/sysctl/net/ipv6/icmp/index.txt | 15 Documentation/sysctl/net/ipv6/index.txt | 65 Documentation/sysctl/net/ipv6/neigh/index.txt | 134 + Documentation/sysctl/net/ipv6/route/index.txt | 78 + Documentation/sysctl/net/unix/index.txt | 15 Documentation/sysctl/sunrpc.txt | 20 Documentation/sysctl/sunrpc/index.txt | 64 Documentation/sysctl/vm.txt | 180 -- Documentation/sysctl/vm/index.txt | 334 ++++ Documentation/sysrq.txt | 20 35 files changed, 3611 insertions(+), 3035 deletions(-) I don't know how long it takes to review such a large patch, but I'll continue to do so. For now: README: 1. +Documentation for /proc/sys/, aka. sysctl a.k.a. or just "aka". Not "aka.". or spell it out, or omit it, maybe like: Documentation for /proc/sys/ (sysctl) 2. Limit lines to max. of 80 characters, but around 70-72 is better IMO. That allows someone to make minor corrections without having to fudge the lines around. 3. +This means there're several parameters use "there are" 4. +are: enabling or disabling forwading in a certain network interface forwarding 5. +is also used to export some stadistic information, ej: some statistic or statistics or statistical ej: ?? use e.g.: (preferred) or eg: 6. +can be read but can _not_ be written. _cannot_ 7. +own program to read them aswell) as well) 8. +to change '/' by '.' and ignore the '/proc/sys' part of the path, ie s/by/to/ s/ie/i.e./ 9. +means that any tweak that you do will be lost the next time you restart your * collapse 2 spaces to 1 10. +_VERY_ DANGEROUS and can ruin the performance performance, drop one "performance" 11. +As a quick 'ls /proc/sys' will show, the directory consists of several subdirs. +Each subdir is mainly about one part of the kernel, so you can do configuration Spell out "subdirectories" and "subdirectory". 12. +fs/ specific filesystems filehandle, inode, dentry and quota tuning insert ":" after "filesystems" OK, that's all for the README file. I'll look at the rest of it sometime this week. I don't think that it's quite ready to be merged. --- ~Randy From owner-xfs@oss.sgi.com Wed Jun 7 15:19:06 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 07 Jun 2006 15:19:10 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.185]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k57MJ5eZ012230 for ; Wed, 7 Jun 2006 15:19:06 -0700 Received: by nf-out-0910.google.com with SMTP id c29so239298nfb for ; Wed, 07 Jun 2006 15:18:54 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer:mime-version:content-type:content-transfer-encoding; b=laeRbbUuM8w8BbWO/dhw5Ja+11LiFWZygt4Sik9J5QA14OGR3j+E4S45c/kkBcu9j5xqcJvjaztsAGdepGKpicyOJ7H37+eUa28wNuKLdkQSfLL1wXWSWvEXjnlk1G9Q+sqncJmWSshFq4zjToPJ3YGm8vifOpHcvlNhSd/Cjyw= Received: by 10.49.58.9 with SMTP id l9mr907218nfk; Wed, 07 Jun 2006 15:18:54 -0700 (PDT) Received: from estel ( [80.103.5.46]) by mx.gmail.com with ESMTP id a23sm1396163nfc.2006.06.07.15.18.52; Wed, 07 Jun 2006 15:18:54 -0700 (PDT) Date: Thu, 8 Jun 2006 00:18:06 +0200 From: Diego Calleja To: "Randy.Dunlap" Cc: linux-kernel@vger.kernel.org, akpm@osdl.org, netdev@vger.kernel.org, linux-xfs@oss.sgi.com, ecki@lina.inka.de, lkml@rtr.ca Subject: Re: Updated sysctl documentation take #2 Message-Id: <20060608001806.028ab05a.diegocg@gmail.com> In-Reply-To: <20060607130653.9a4d572c.rdunlap@xenotime.net> References: <20060607205316.bbb3c379.diegocg@gmail.com> <20060607130653.9a4d572c.rdunlap@xenotime.net> X-Mailer: Sylpheed version 2.2.4 (GTK+ 2.8.17; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id k57MJ6eZ012235 X-archive-position: 7898 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: diegocg@gmail.com Precedence: bulk X-list: xfs Content-Length: 701 Lines: 22 El Wed, 7 Jun 2006 13:06:53 -0700, "Randy.Dunlap" escribió: > I don't know how long it takes to review such a large patch, but > I'll continue to do so. For now: Yeah, my english is poor ;) Most of the sysctl documentation cames from other files anyway, README was (re)written by me, so the rest is not so bad... > OK, that's all for the README file. I'll look at the rest of it > sometime this week. I don't think that it's quite ready to be merged. Thank's for your review, altought I didn't though someone was to review so deeply a documentation patch ;) I've gone through all the files and fixed the 72-col limit and everything I could. I've updated the patch From owner-xfs@oss.sgi.com Wed Jun 7 15:30:55 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 07 Jun 2006 15:31:00 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k57MUpeZ013695 for ; Wed, 7 Jun 2006 15:30:54 -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 IAA10529; Thu, 8 Jun 2006 08:30:35 +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 k57MUWgw710732; Thu, 8 Jun 2006 08:30:32 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k57MUTwH709616; Thu, 8 Jun 2006 08:30:29 +1000 (EST) Date: Thu, 8 Jun 2006 08:30:29 +1000 From: Nathan Scott To: Rishi Malik Cc: xfs@oss.sgi.com Subject: Re: xfs version info in kernel 2.4.20 Message-ID: <20060608083029.A710447@wobbly.melbourne.sgi.com> References: <51A9A4FCBC06324F8BFE956A551B58E00565E353@mail01dn.adic.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <51A9A4FCBC06324F8BFE956A551B58E00565E353@mail01dn.adic.com>; from rishi.malik@adic.com on Wed, Jun 07, 2006 at 11:12:12AM -0600 X-archive-position: 7899 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 601 Lines: 22 On Wed, Jun 07, 2006 at 11:12:12AM -0600, Rishi Malik wrote: > Hi all, > > I'm trying to find out what version of xfs is included in kernel 2.4.20. XFS wasn't merged in 2.4 until 2.4.25. I try to keep this page uptodate, it has this kind of information: http://oss.sgi.com/projects/xfs/news.html > know how I can find this out? Also, is there a publicly available > changelog of bugfixes, etc for xfs? Nothing changes in 2.4 anymore, 2.6 is so much more interesting. There's numerous changelogs posted around the net - Linus sends one out with every update, for example. cheers. -- Nathan From owner-xfs@oss.sgi.com Wed Jun 7 15:46:24 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 07 Jun 2006 15:46:34 -0700 (PDT) Received: from MAIL01HQ.adic.com (mail01hq.adic.com [63.81.117.10]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k57MkMeZ015593 for ; Wed, 7 Jun 2006 15:46:24 -0700 Received: from mail01dn.adic.com ([172.16.40.35]) by MAIL01HQ.adic.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Jun 2006 15:46:13 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: xfs version info in kernel 2.4.20 Date: Wed, 7 Jun 2006 16:46:12 -0600 Message-ID: <51A9A4FCBC06324F8BFE956A551B58E0056A4C69@mail01dn.adic.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: xfs version info in kernel 2.4.20 Thread-Index: AcaKg0sde1okownIRHiIp8gslfVS5QAAEduQ From: "Rishi Malik" To: "Nathan Scott" Cc: X-OriginalArrivalTime: 07 Jun 2006 22:46:13.0703 (UTC) FILETIME=[2DE66D70:01C68A84] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id k57MkOeZ015598 X-archive-position: 7900 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: rishi.malik@adic.com Precedence: bulk X-list: xfs Content-Length: 1403 Lines: 47 Thanks for the reply Nathan. I was unclear. I know it wasn't included until later, but I'm looking for the patch set that was created for 2.4.20. Is there something in the source code I can look for? I agree, the 2.6 kernel is way more interesting! However, what I'm looking for is a XFS specific changelog, not the whole kernel. I can go through are parse out the XFS stuff though, I'm just not sure it would have every change that was made. Basically, I'm tracking a corruption bug. It's highly unlikely that its in XFS, but I want to explore all avenues of possibility. Thanks for the info, Rishi -----Original Message----- From: Nathan Scott [mailto:nathans@sgi.com] Sent: Wednesday, June 07, 2006 4:30 PM To: Rishi Malik Cc: xfs@oss.sgi.com Subject: Re: xfs version info in kernel 2.4.20 On Wed, Jun 07, 2006 at 11:12:12AM -0600, Rishi Malik wrote: > Hi all, > > I'm trying to find out what version of xfs is included in kernel 2.4.20. XFS wasn't merged in 2.4 until 2.4.25. I try to keep this page uptodate, it has this kind of information: http://oss.sgi.com/projects/xfs/news.html > know how I can find this out? Also, is there a publicly available > changelog of bugfixes, etc for xfs? Nothing changes in 2.4 anymore, 2.6 is so much more interesting. There's numerous changelogs posted around the net - Linus sends one out with every update, for example. cheers. -- Nathan From owner-xfs@oss.sgi.com Wed Jun 7 16:11:58 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 07 Jun 2006 16:12:02 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k57NBseZ017929 for ; Wed, 7 Jun 2006 16:11:57 -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 JAA11337; Thu, 8 Jun 2006 09:11:38 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k57NBagw711836; Thu, 8 Jun 2006 09:11:36 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k57NBYSb709751; Thu, 8 Jun 2006 09:11:34 +1000 (EST) Date: Thu, 8 Jun 2006 09:11:34 +1000 From: Nathan Scott To: Rishi Malik Cc: xfs@oss.sgi.com Subject: Re: xfs version info in kernel 2.4.20 Message-ID: <20060608091134.E710447@wobbly.melbourne.sgi.com> References: <51A9A4FCBC06324F8BFE956A551B58E0056A4C69@mail01dn.adic.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <51A9A4FCBC06324F8BFE956A551B58E0056A4C69@mail01dn.adic.com>; from rishi.malik@adic.com on Wed, Jun 07, 2006 at 04:46:12PM -0600 X-archive-position: 7901 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 540 Lines: 15 On Wed, Jun 07, 2006 at 04:46:12PM -0600, Rishi Malik wrote: > Thanks for the reply Nathan. I was unclear. I know it wasn't included > until later, but I'm looking for the patch set that was created for > 2.4.20. Is there something in the source code I can look for? Oh, I see. We don't keep patches that old around anywhere, at least, not that I'm aware of. And the CVS trees aren't tagged at each 2.4/2.6 release, or anything like that, so there's not really any way I can think of to get what you're after here. cheers. -- Nathan From owner-xfs@oss.sgi.com Wed Jun 7 16:44:10 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 07 Jun 2006 16:44:14 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k57Ni5eZ025372 for ; Wed, 7 Jun 2006 16:44:08 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA11918; Thu, 8 Jun 2006 09:43:50 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id CB8254A588D4; Thu, 8 Jun 2006 09:43:48 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: PARTIAL TAKE 952342 - xfsprogs tweaks Message-Id: <20060607234348.CB8254A588D4@chook.melbourne.sgi.com> Date: Thu, 8 Jun 2006 09:43:48 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 7902 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 1234 Lines: 25 Ongoing xfs_repair/libxfs scaling work - incorporate lio_listio detection into the build. Date: Thu Jun 8 09:43:21 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-cmds Inspected by: mvalluri,tes The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:26199a xfsprogs/m4/package_aiodev.m4 - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/m4/package_aiodev.m4 xfsprogs/configure.in - 1.36 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/configure.in.diff?r1=text&tr1=1.36&r2=text&tr2=1.35&f=h xfsprogs/doc/CHANGES - 1.205 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/doc/CHANGES.diff?r1=text&tr1=1.205&r2=text&tr2=1.204&f=h xfsprogs/include/builddefs.in - 1.48 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/builddefs.in.diff?r1=text&tr1=1.48&r2=text&tr2=1.47&f=h xfsprogs/aclocal.m4 - 1.22 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/aclocal.m4.diff?r1=text&tr1=1.22&r2=text&tr2=1.21&f=h xfsprogs/m4/Makefile - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/m4/Makefile.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h From owner-xfs@oss.sgi.com Wed Jun 7 17:17:59 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 07 Jun 2006 17:18:03 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k580HteZ029132 for ; Wed, 7 Jun 2006 17:17:57 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA13033 for ; Thu, 8 Jun 2006 10:17:44 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 89F204A588E3; Thu, 8 Jun 2006 10:17:44 +1000 (EST) To: linux-xfs@oss.sgi.com Subject: TAKE 904196 - fix a busted const use Message-Id: <20060608001744.89F204A588E3@chook.melbourne.sgi.com> Date: Thu, 8 Jun 2006 10:17:44 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 7903 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 467 Lines: 14 Fix broken const use inside local suffix_strtoul routine. Date: Thu Jun 8 10:17:23 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: Craig Rodrigues The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:26201a xfs_vfsops.c - 1.507 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vfsops.c.diff?r1=text&tr1=1.507&r2=text&tr2=1.506&f=h From owner-xfs@oss.sgi.com Wed Jun 7 17:43:09 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 07 Jun 2006 17:43:13 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k580h5eZ031985 for ; Wed, 7 Jun 2006 17:43:08 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA13541; Thu, 8 Jun 2006 10:42:49 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k580gkgw713853; Thu, 8 Jun 2006 10:42:46 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k580gg54713031; Thu, 8 Jun 2006 10:42:42 +1000 (EST) Date: Thu, 8 Jun 2006 10:42:42 +1000 From: Nathan Scott To: Jan Wagner Cc: xfs@oss.sgi.com Subject: Re: separate log and structure from user data device? Message-ID: <20060608104242.I710447@wobbly.melbourne.sgi.com> References: <8630.1149517148@ocs3.ocs.com.au> <20060606101258.B644608@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jwagner@kurp.hut.fi on Wed, Jun 07, 2006 at 02:05:57PM +0300 X-archive-position: 7904 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 2122 Lines: 59 On Wed, Jun 07, 2006 at 02:05:57PM +0300, Jan Wagner wrote: > On Tue, 6 Jun 2006, Nathan Scott wrote: > Other question, is the below really the correct way to enable realtime for > a new file? Its one way. Also try: # xfs_io -fR /mnt/test/realtime -c 'pwrite -b 1m 0 100m' wrote 104857600/104857600 bytes at offset 0 100 MiB, 100 ops; 0:00:01.00 (95.473 MiB/sec and 95.4726 ops/sec) # xfs_io -f /mnt/test/regular -c 'pwrite -b 1m 0 100m' wrote 104857600/104857600 bytes at offset 0 100 MiB, 100 ops; 0:00:01.00 (67.574 MiB/sec and 67.5735 ops/sec) Or more simply (ie. without create + set-realtime-explicitly)... # mkdir /mnt/test/realtime # xfs_io -c 'chattr +t' -c 'lsattr -v' /mnt/test/realtime [rt-inherit] /mnt/test/realtime # xfs_io -f /mnt/test/realtime/foo -c 'pwrite -b 1m 0 100m' wrote 104857600/104857600 bytes at offset 0 100 MiB, 100 ops; 0:00:01.00 (93.357 MiB/sec and 93.3569 ops/sec) (above is all buffered I/O btw, not direct - use -d flag for that). > /* O_DIRECT for "realtime" */ You don't need O_DIRECT for realtime these days. > assert( (fid = open(pn, O_WRONLY|O_CREAT|O_DIRECT|O_SYNC|O_LARGEFILE)) != -1 ); Thats a shocking use of assert. :) > fsxinfo.fsx_xflags = XFS_XFLAG_REALTIME; fsxinfo.fsx_xflags |= ... (to not blow away any other flags you might have had set on that file). > I'm getting only about 500mbits/s write speed into the file (continuously > writing 1024 byte or much larger chunks) with the above code on XFS with > the rtdev on a RAID0 /dev/md0 and "actual" XFS on /dev/hda6. With XFS > directly on /dev/md0 and no realtime section but logdev=/dev/hda6, > throughput is a nice ~2.5gbits/s. Sounds like youre comparing buffered to direct IO? (and for a very small amount of data that goes straight to the page cache for your buffered writes, and you're not accounting flush times). But thats just a guess, maybe your md0 really does do 2.5gbits/s? Doubt it. > Hence not sure if the above code is correct? (but maybe rt support in the > linux 2.6.16 kernel really is /this/ "experimental" ;-)... Looks more like pilot error to me. :) cheers. -- Nathan From owner-xfs@oss.sgi.com Wed Jun 7 18:20:01 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 07 Jun 2006 18:20:06 -0700 (PDT) Received: from allen.werkleitz.de (allen.werkleitz.de [80.190.251.108]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k581JxeZ004234 for ; Wed, 7 Jun 2006 18:20:01 -0700 Received: from p54bde0b1.dip.t-dialin.net ([84.189.224.177] helo=void.local) by allen.werkleitz.de with esmtpsa (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA1:24) (Exim 4.62) (envelope-from ) id 1Fo7t3-0000R5-Oj; Thu, 08 Jun 2006 01:56:39 +0200 Received: from js by void.local with local (Exim 3.35 #1 (Debian)) id 1Fo7t1-0002nD-00; Thu, 08 Jun 2006 01:56:31 +0200 Date: Thu, 8 Jun 2006 01:56:31 +0200 From: Johannes Stezenbach To: Diego Calleja Cc: linux-kernel@vger.kernel.org, akpm@osdl.org, netdev@vger.kernel.org, linux-xfs@oss.sgi.com, ecki@lina.inka.de, lkml@rtr.ca Message-ID: <20060607235631.GA10688@linuxtv.org> References: <20060607205316.bbb3c379.diegocg@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060607205316.bbb3c379.diegocg@gmail.com> User-Agent: Mutt/1.5.11+cvs20060403 X-SA-Exim-Connect-IP: 84.189.224.177 Subject: Re: Updated sysctl documentation take #2 X-SA-Exim-Version: 4.2.1 (built Mon, 27 Mar 2006 13:42:28 +0200) X-SA-Exim-Scanned: Yes (on allen.werkleitz.de) X-archive-position: 7905 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: js@linuxtv.org Precedence: bulk X-list: xfs Content-Length: 339 Lines: 17 On Wed, Jun 07, 2006, Diego Calleja wrote: > Since people didn't like the "many small files" approach, I've moved > it to directories containing index.txt files: > > Documentation/sysctl/vm/index.txt > Documentation/sysctl/net/core/index.txt Why not just Documentation/sysctl/vm.txt Documentation/sysctl/net/core.txt etc.? Johannes From owner-xfs@oss.sgi.com Wed Jun 7 19:04:29 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 07 Jun 2006 19:04:36 -0700 (PDT) Received: from warden.diginsite.com (warden-p.diginsite.com [208.29.163.248]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k5824ReZ009545 for ; Wed, 7 Jun 2006 19:04:29 -0700 Received: from no.name.available by warden.diginsite.com via smtpd (for oss.sgi.com [192.48.170.157]) with SMTP; Wed, 7 Jun 2006 19:04:19 -0700 Received: from dlang.diginsite.com ([10.201.10.67]) by wlvims02.corp.ad.diginsite.com with InterScan Message Security Suite; Wed, 07 Jun 2006 18:03:45 -0700 Date: Wed, 7 Jun 2006 15:52:32 -0700 (PDT) From: David Lang X-X-Sender: dlang@dlang.diginsite.com To: Johannes Stezenbach cc: Diego Calleja , linux-kernel@vger.kernel.org, akpm@osdl.org, netdev@vger.kernel.org, linux-xfs@oss.sgi.com, ecki@lina.inka.de, lkml@rtr.ca Subject: Re: Updated sysctl documentation take #2 In-Reply-To: <20060607235631.GA10688@linuxtv.org> Message-ID: References: <20060607205316.bbb3c379.diegocg@gmail.com> <20060607235631.GA10688@linuxtv.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 7906 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dlang@digitalinsight.com Precedence: bulk X-list: xfs Content-Length: 448 Lines: 18 On Thu, 8 Jun 2006, Johannes Stezenbach wrote: > On Wed, Jun 07, 2006, Diego Calleja wrote: >> Since people didn't like the "many small files" approach, I've moved >> it to directories containing index.txt files: >> >> Documentation/sysctl/vm/index.txt >> Documentation/sysctl/net/core/index.txt > > Why not just > > Documentation/sysctl/vm.txt > Documentation/sysctl/net/core.txt > > etc.? better matching of the proc layout would be my guess. From owner-xfs@oss.sgi.com Wed Jun 7 20:37:00 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 07 Jun 2006 20:37:07 -0700 (PDT) Received: from FPNYEXCBE01.opus-i.corp (mail4.opus-i.net [209.10.181.136]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k583aweZ025175 for ; Wed, 7 Jun 2006 20:37:00 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: separate log and structure from user data device? Date: Wed, 7 Jun 2006 22:34:34 -0400 Message-ID: <14BC3454F4B4614FBC4F3FB19A84C372D27F96@FPNYEXCBE01.opus-i.corp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: separate log and structure from user data device? Thread-Index: AcaKlKTmzyWWawHxTim4lLvUqYA/DgADc0KA From: "Patrick Freeman" To: "Nathan Scott" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id k583b0eZ025186 X-archive-position: 7907 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: patrickf@datallegro.com Precedence: bulk X-list: xfs Content-Length: 1234 Lines: 40 > -----Original Message----- > From: xfs-bounce@oss.sgi.com [mailto:xfs-bounce@oss.sgi.com] On Behalf Of > Nathan Scott > Sent: Wednesday, June 07, 2006 5:43 PM > To: Jan Wagner > Cc: xfs@oss.sgi.com > Subject: Re: separate log and structure from user data device? > [ ... ] > > I'm getting only about 500mbits/s write speed into the file > (continuously > > writing 1024 byte or much larger chunks) with the above code on XFS with > > the rtdev on a RAID0 /dev/md0 and "actual" XFS on /dev/hda6. With XFS > > directly on /dev/md0 and no realtime section but logdev=/dev/hda6, > > throughput is a nice ~2.5gbits/s. > > Sounds like youre comparing buffered to direct IO? (and for a very > small amount of data that goes straight to the page cache for your > buffered writes, and you're not accounting flush times). But thats > just a guess, maybe your md0 really does do 2.5gbits/s? Doubt it. I just wanted to comment that this is about 320 MB/s which is very reasonable for a 6 disk raid0 volume (between 50 and 60 MB/s per drive with 6 disks). It would be kind of at the edge for a hardware raid 5 (but I know that 3ware yields ~315MB/s sequential writes with RAID5 using XFS). Anyway -- just a note. Regards, Patrick From owner-xfs@oss.sgi.com Thu Jun 8 07:48:50 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 08 Jun 2006 07:48:59 -0700 (PDT) Received: from ty.sabi.co.UK (82-69-39-138.dsl.in-addr.zen.co.uk [82.69.39.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k58EmleZ008779 for ; Thu, 8 Jun 2006 07:48:50 -0700 Received: from from [127.0.0.1] (helo=base.ty.sabi.co.UK) by ty.sabi.co.UK with esmtp(Exim 4.62 #1) id 1FoLIW-0004h7-EX for ; Thu, 08 Jun 2006 15:15:44 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17544.12555.858981.847208@base.ty.sabi.co.UK> Date: Thu, 8 Jun 2006 15:15:39 +0100 X-Face: SMJE]JPYVBO-9UR%/8d'mG.F!@.,l@c[f'[%S8'BZIcbQc3/">GrXDwb#;fTRGNmHr^JFb SAptvwWc,0+z+~p~"Gdr4H$(|N(yF(wwCM2bW0~U?HPEE^fkPGx^u[*[yV.gyB!hDOli}EF[\cW*S H&spRGFL}{`bj1TaD^l/"[ msn( /TH#THs{Hpj>)]f> Subject: Re: separate log and structure from user data device? In-Reply-To: <20060608104242.I710447@wobbly.melbourne.sgi.com> References: <8630.1149517148@ocs3.ocs.com.au> <20060606101258.B644608@wobbly.melbourne.sgi.com> <20060608104242.I710447@wobbly.melbourne.sgi.com> X-Mailer: VM 7.17 under 21.4 (patch 19) XEmacs Lucid From: pg_xfs@xfs.for.sabi.co.UK (Peter Grandi) X-Disclaimer: This message contains only personal opinions X-archive-position: 7908 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: pg_xfs@xfs.for.sabi.co.UK Precedence: bulk X-list: xfs Content-Length: 684 Lines: 23 [ ... curious complaints about write performance ... ] >> /* O_DIRECT for "realtime" */ nathans> You don't need O_DIRECT for realtime these days. >> assert( (fid = open(pn, >> O_WRONLY|O_CREAT|O_DIRECT|O_SYNC|O_LARGEFILE)) != -1 ); nathans> Thats a shocking use of assert. :) Thats too kind :-). However, I am puzzled as you comment on 'O_DIRECT' but not on 'O_SYNC'. IIRC XFS performance, and in particular the strategy to used to allocate large extents, is based on hugely delayed flushing, and 'O_SYNC' would defeat that, resulting perhaps in the allocation of many small extents, and this might impact write speed too (more metadata writes). Is this plausible? [ ... ] From owner-xfs@oss.sgi.com Thu Jun 8 09:09:18 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 08 Jun 2006 09:09:20 -0700 (PDT) Received: from star.tech-arts.co.jp (star.tech-arts.co.jp [221.249.253.101]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k58G9GeZ026221 for ; Thu, 8 Jun 2006 09:09:17 -0700 Received: (qmail 25021 invoked from network); 9 Jun 2006 00:08:57 +0900 Received: from unknown (HELO ml.tech-arts.co.jp) (127.0.0.1) by localhost with SMTP; 9 Jun 2006 00:08:57 +0900 Date: Fri, 9 Jun 2006 00:08:56 +0900 From: macosx-dev-jp-admin@ml.tech-arts.co.jp Subject: You linux-xfs@oss.sgi.com are not member (macosx-dev-jp ML) To: linux-xfs@oss.sgi.com Message-Id: <200606090008.FMLAAB25014.macosx-dev-jp@ml.tech-arts.co.jp> X-MLServer: fml [fml 4.0.3 release (20011202/4.0.3)] X-ML-Info: If you have a question, please contact macosx-dev-jp-admin@ml.tech-arts.co.jp; Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp X-archive-position: 7909 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: macosx-dev-jp-admin@ml.tech-arts.co.jp Precedence: bulk X-list: xfs Content-Length: 272 Lines: 13 $B$"$J$?$O$3$N%a!<%j%s%0%j%9%H(B $B$N%a%s%P!<$G$O$"$j$^$;$s!#(B $B%a!<%j%s%0%j%9%H$K$D$$$F$N0lHLE*$J0FFb$O%a!<%k$NK\J8$K(B guide $B$H=q$$$?%a!<%k$r(B macosx-dev-jp-ctl@ml.tech-arts.co.jp $B08$KAw$k$HAw$i$l$F$-$^$9!#(B From owner-xfs@oss.sgi.com Thu Jun 8 13:37:48 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 08 Jun 2006 13:37:53 -0700 (PDT) Received: from slurp.thebarn.com (cattelan-host201.dsl.visi.com [208.42.117.201]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k58KbkeZ013579 for ; Thu, 8 Jun 2006 13:37:47 -0700 Received: from [127.0.0.1] ([63.175.1.98]) (authenticated bits=0) by slurp.thebarn.com (8.13.5/8.13.5) with ESMTP id k58GjGvL065991; Thu, 8 Jun 2006 11:45:18 -0500 (CDT) (envelope-from cattelan@thebarn.com) Message-ID: <44885416.3030105@thebarn.com> Date: Thu, 08 Jun 2006 11:45:10 -0500 From: Russell Cattelan User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Nathan Scott CC: Rishi Malik , xfs@oss.sgi.com Subject: Re: xfs version info in kernel 2.4.20 References: <51A9A4FCBC06324F8BFE956A551B58E0056A4C69@mail01dn.adic.com> <20060608091134.E710447@wobbly.melbourne.sgi.com> In-Reply-To: <20060608091134.E710447@wobbly.melbourne.sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7910 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: cattelan@thebarn.com Precedence: bulk X-list: xfs Content-Length: 785 Lines: 22 Nathan Scott wrote: > On Wed, Jun 07, 2006 at 04:46:12PM -0600, Rishi Malik wrote: > >> Thanks for the reply Nathan. I was unclear. I know it wasn't included >> until later, but I'm looking for the patch set that was created for >> 2.4.20. Is there something in the source code I can look for? >> > > Oh, I see. We don't keep patches that old around anywhere, at > least, not that I'm aware of. And the CVS trees aren't tagged > at each 2.4/2.6 release, or anything like that, so there's not > really any way I can think of to get what you're after here. > > cheers. > > Use cvsweb to find a date that corresponds to the version you're interested in and tell cvs to checkout a tree using that date http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs-OLD/linux/Makefile From owner-xfs@oss.sgi.com Thu Jun 8 15:51:05 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 08 Jun 2006 15:51:24 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k58MoueZ003178 for ; Thu, 8 Jun 2006 15:51:04 -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 IAA12132; Fri, 9 Jun 2006 08:50:35 +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 k58MoVgw738646; Fri, 9 Jun 2006 08:50:32 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k58MoRnB738962; Fri, 9 Jun 2006 08:50:27 +1000 (EST) Date: Fri, 9 Jun 2006 08:50:26 +1000 From: Nathan Scott To: Peter Grandi Cc: xfs@oss.sgi.com Subject: Re: separate log and structure from user data device? Message-ID: <20060609085026.A737425@wobbly.melbourne.sgi.com> References: <8630.1149517148@ocs3.ocs.com.au> <20060606101258.B644608@wobbly.melbourne.sgi.com> <20060608104242.I710447@wobbly.melbourne.sgi.com> <17544.12555.858981.847208@base.ty.sabi.co.UK> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <17544.12555.858981.847208@base.ty.sabi.co.UK>; from pg_xfs@xfs.for.sabi.co.UK on Thu, Jun 08, 2006 at 03:15:39PM +0100 X-archive-position: 7911 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 866 Lines: 35 On Thu, Jun 08, 2006 at 03:15:39PM +0100, Peter Grandi wrote: > > [ ... curious complaints about write performance ... ] > > >> /* O_DIRECT for "realtime" */ > > nathans> You don't need O_DIRECT for realtime these days. > > >> assert( (fid = open(pn, > >> O_WRONLY|O_CREAT|O_DIRECT|O_SYNC|O_LARGEFILE)) != -1 ); > > nathans> Thats a shocking use of assert. :) > > Thats too kind :-). > > However, I am puzzled as you comment on 'O_DIRECT' but not on > 'O_SYNC'. IIRC XFS performance, and in particular the strategy Heh, I completely overlooked the O_SYNC there. > to used to allocate large extents, is based on hugely delayed > flushing, and 'O_SYNC' would defeat that, resulting perhaps in Indeed. > the allocation of many small extents, and this might impact > write speed too (more metadata writes). Is this plausible? Indeed. cheers. -- Nathan From owner-xfs@oss.sgi.com Fri Jun 9 06:29:14 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 09 Jun 2006 06:29:33 -0700 (PDT) Received: from lucidpixels.com (lucidpixels.com [66.45.37.187]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k59DT9eZ023561 for ; Fri, 9 Jun 2006 06:29:13 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id D4EA716381F; Fri, 9 Jun 2006 09:28:58 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id D0DD7100EC460; Fri, 9 Jun 2006 09:28:58 -0400 (EDT) Date: Fri, 9 Jun 2006 09:28:58 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: Ralf Hildebrandt cc: xfs@oss.sgi.com Subject: Re: EIP is at xfs_trans_update_ail+0x9c/0x1a0 In-Reply-To: <20060609122707.GR871@charite.de> Message-ID: References: <20060609122707.GR871@charite.de> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1463747160-1748042046-1149859738=:3438" X-archive-position: 7915 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs Content-Length: 4141 Lines: 88 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1463747160-1748042046-1149859738=:3438 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE > May 24 21:08:58 kasbah kernel: Modules linked in: tun nvidia Do you get the error without NVIDIA loaded? What kernel version? These are some of the things the developers will want to know. On Fri, 9 Jun 2006, Ralf Hildebrandt wrote: > I left my laptop running and went on vacation. When I came back, I found: > > May 24 21:08:58 kasbah kernel: BUG: unable to handle kernel NULL pointer = dereference at virtual address 00000004 > May 24 21:08:58 kasbah kernel: printing eip: > May 24 21:08:58 kasbah kernel: c01ee94c > May 24 21:08:58 kasbah kernel: *pde =3D 00000000 > May 24 21:08:58 kasbah kernel: Oops: 0002 [#1] > May 24 21:08:58 kasbah kernel: PREEMPT > May 24 21:08:58 kasbah kernel: Modules linked in: tun nvidia cpufreq_onde= mand cpufreq_userspace cpufreq_powersave thermal fan button ac battery powe= rnow_k8 freq_table processor usbhid tsdev pcmcia snd_intel8x0m snd_pcm_oss= snd_mixer_oss bcm43xx snd_intel8x0 i2c_nforce2 firmware_class ieee80211sof= tmac snd_ac97_codec snd_ac97_bus snd_pcm snd_timer snd psmouse i2c_core iee= e80211 yenta_socket rsrc_nonstatic pcmcia_core ehci_hcd rtc evdev 8139cp oh= ci_hcd usbcore soundcore snd_page_alloc 8139too ieee80211_crypt ide_cd cdro= m unix > May 24 21:08:58 kasbah kernel: CPU: 0 > May 24 21:08:58 kasbah kernel: EIP: 0060:[xfs_trans_update_ail+156/416] = Tainted: P VLI > May 24 21:08:58 kasbah kernel: EFLAGS: 00210297 (2.6.17-rc4-git2 #1) > May 24 21:08:58 kasbah kernel: EIP is at xfs_trans_update_ail+0x9c/0x1a0 > May 24 21:08:58 kasbah kernel: eax: 00000000 ebx: 0000a1e2 ecx: 00008= c58 edx: 0000a1e2 > May 24 21:08:58 kasbah kernel: esi: dc6e2348 edi: df3c7460 ebp: dfe1f= 014 esp: c14a6e5c > May 24 21:08:58 kasbah kernel: ds: 007b es: 007b ss: 0068 > May 24 21:08:58 kasbah kernel: Process xfslogd/0 (pid: 151, threadinfo=3D= c14a6000 task=3Dc14a4a70) > May 24 21:08:58 kasbah kernel: Stack: <0>00008c58 0000a1e2 dfe1f000 00000= 000 df3c7f50 0000a1e2 00008c58 0000a1e2 > May 24 21:08:58 kasbah kernel: df3c7460 0000a1e2 c01ed99a 00008c58= 0000a1e2 00000000 00008c58 0000a1e2 > May 24 21:08:58 kasbah kernel: c8453cc4 c8453ccc dfe1f000 00000000= c14a6000 c8453cc4 c14a6000 00000000 > May 24 21:08:58 kasbah kernel: Call Trace: > May 24 21:08:58 kasbah kernel: xfs_trans_chunk_committed+0x5a= /0x140 xfs_trans_committed+0x47/0x100 > May 24 21:08:58 kasbah kernel: xlog_state_do_callback+0x38c/0= x4b0 xlog_iodone+0xab/0x150 > May 24 21:08:58 kasbah kernel: xfs_buf_iodone_work+0xf/0x40 = run_workqueue+0xa1/0x150 > May 24 21:08:58 kasbah kernel: xfs_buf_iodone_work+0x0/0x40 = worker_thread+0xee/0x120 > May 24 21:08:58 kasbah kernel: default_wake_function+0x0/0x10= kthread+0xd6/0xe0 > May 24 21:08:58 kasbah kernel: worker_thread+0x0/0x120 kthread+0x0/0xe0 > May 24 21:08:58 kasbah kernel: kernel_thread_helper+0x5/0x10 > May 24 21:08:58 kasbah kernel: Code: 8b 5c 24 04 8b 0c 24 89 5c 24 14 8b = 5c 24 14 39 5e 0c 8b 46 08 74 5c 72 07 8b 76 04 39 f5 75 eb 8b 06 89 77 04 = 89 07 89 3e 8b 07 <89> 78 04 8b 44 24 08 ff 40 1c 8b 54 24 10 39 54 24 0c 0= f 84 7d > May 24 21:08:58 kasbah kernel: EIP: [xfs_trans_update_ail+156/416] xfs_tr= ans_update_ail+0x9c/0x1a0 SS:ESP 0068:c14a6e5c > May 24 21:08:58 kasbah kernel: <6>note: xfslogd/0[151] exited with preem= pt_count 1 > > --=20 > Ralf Hildebrandt (i.A. des IT-Zentrums) Ralf.Hildebrandt@charite.= de > Charite - Universit=E4tsmedizin Berlin Tel. +49 (0)30-450 570= -155 > Gemeinsame Einrichtung von FU- und HU-Berlin Fax. +49 (0)30-450 570-9= 62 > IT-Zentrum Standort CBF send no mail to spamtrap@charite.= de > > ---1463747160-1748042046-1149859738=:3438-- From owner-xfs@oss.sgi.com Fri Jun 9 06:26:51 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 09 Jun 2006 06:27:00 -0700 (PDT) Received: from mail.charite.de (mail.charite.de [160.45.207.131]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k59DQmeZ023087 for ; Fri, 9 Jun 2006 06:26:51 -0700 Received: from localhost (localhost [127.0.0.1]) by mail.charite.de (Postfix) with ESMTP id EE82D220B55 for ; Fri, 9 Jun 2006 14:27:23 +0200 (CEST) Received: from mail.charite.de ([127.0.0.1]) by localhost (mail.charite.de [127.0.0.1]) (amavisd-new, port 10025) with LMTP id o0Qpo6btSZPh for ; Fri, 9 Jun 2006 14:27:22 +0200 (CEST) Received: from postamt.charite.de (postamt.charite.de [160.45.207.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.charite.de (Postfix) with ESMTP id DD30C220BBA for ; Fri, 9 Jun 2006 14:27:07 +0200 (CEST) Received: by postamt.charite.de (Postfix, from userid 7945) id 942EE220801; Fri, 9 Jun 2006 14:27:07 +0200 (CEST) Date: Fri, 9 Jun 2006 14:27:07 +0200 From: Ralf Hildebrandt To: xfs@oss.sgi.com Subject: EIP is at xfs_trans_update_ail+0x9c/0x1a0 Message-ID: <20060609122707.GR871@charite.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.11+cvs20060403 X-archive-position: 7914 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Ralf.Hildebrandt@charite.de Precedence: bulk X-list: xfs Content-Length: 3412 Lines: 38 I left my laptop running and went on vacation. When I came back, I found: May 24 21:08:58 kasbah kernel: BUG: unable to handle kernel NULL pointer dereference at virtual address 00000004 May 24 21:08:58 kasbah kernel: printing eip: May 24 21:08:58 kasbah kernel: c01ee94c May 24 21:08:58 kasbah kernel: *pde = 00000000 May 24 21:08:58 kasbah kernel: Oops: 0002 [#1] May 24 21:08:58 kasbah kernel: PREEMPT May 24 21:08:58 kasbah kernel: Modules linked in: tun nvidia cpufreq_ondemand cpufreq_userspace cpufreq_powersave thermal fan button ac battery powernow_k8 freq_table processor usbhid tsdev pcmcia snd_intel8x0m snd_pcm_oss snd_mixer_oss bcm43xx snd_intel8x0 i2c_nforce2 firmware_class ieee80211softmac snd_ac97_codec snd_ac97_bus snd_pcm snd_timer snd psmouse i2c_core ieee80211 yenta_socket rsrc_nonstatic pcmcia_core ehci_hcd rtc evdev 8139cp ohci_hcd usbcore soundcore snd_page_alloc 8139too ieee80211_crypt ide_cd cdrom unix May 24 21:08:58 kasbah kernel: CPU: 0 May 24 21:08:58 kasbah kernel: EIP: 0060:[xfs_trans_update_ail+156/416] Tainted: P VLI May 24 21:08:58 kasbah kernel: EFLAGS: 00210297 (2.6.17-rc4-git2 #1) May 24 21:08:58 kasbah kernel: EIP is at xfs_trans_update_ail+0x9c/0x1a0 May 24 21:08:58 kasbah kernel: eax: 00000000 ebx: 0000a1e2 ecx: 00008c58 edx: 0000a1e2 May 24 21:08:58 kasbah kernel: esi: dc6e2348 edi: df3c7460 ebp: dfe1f014 esp: c14a6e5c May 24 21:08:58 kasbah kernel: ds: 007b es: 007b ss: 0068 May 24 21:08:58 kasbah kernel: Process xfslogd/0 (pid: 151, threadinfo=c14a6000 task=c14a4a70) May 24 21:08:58 kasbah kernel: Stack: <0>00008c58 0000a1e2 dfe1f000 00000000 df3c7f50 0000a1e2 00008c58 0000a1e2 May 24 21:08:58 kasbah kernel: df3c7460 0000a1e2 c01ed99a 00008c58 0000a1e2 00000000 00008c58 0000a1e2 May 24 21:08:58 kasbah kernel: c8453cc4 c8453ccc dfe1f000 00000000 c14a6000 c8453cc4 c14a6000 00000000 May 24 21:08:58 kasbah kernel: Call Trace: May 24 21:08:58 kasbah kernel: xfs_trans_chunk_committed+0x5a/0x140 xfs_trans_committed+0x47/0x100 May 24 21:08:58 kasbah kernel: xlog_state_do_callback+0x38c/0x4b0 xlog_iodone+0xab/0x150 May 24 21:08:58 kasbah kernel: xfs_buf_iodone_work+0xf/0x40 run_workqueue+0xa1/0x150 May 24 21:08:58 kasbah kernel: xfs_buf_iodone_work+0x0/0x40 worker_thread+0xee/0x120 May 24 21:08:58 kasbah kernel: default_wake_function+0x0/0x10 kthread+0xd6/0xe0 May 24 21:08:58 kasbah kernel: worker_thread+0x0/0x120 kthread+0x0/0xe0 May 24 21:08:58 kasbah kernel: kernel_thread_helper+0x5/0x10 May 24 21:08:58 kasbah kernel: Code: 8b 5c 24 04 8b 0c 24 89 5c 24 14 8b 5c 24 14 39 5e 0c 8b 46 08 74 5c 72 07 8b 76 04 39 f5 75 eb 8b 06 89 77 04 89 07 89 3e 8b 07 <89> 78 04 8b 44 24 08 ff 40 1c 8b 54 24 10 39 54 24 0c 0f 84 7d May 24 21:08:58 kasbah kernel: EIP: [xfs_trans_update_ail+156/416] xfs_trans_update_ail+0x9c/0x1a0 SS:ESP 0068:c14a6e5c May 24 21:08:58 kasbah kernel: <6>note: xfslogd/0[151] exited with preempt_count 1 -- Ralf Hildebrandt (i.A. des IT-Zentrums) Ralf.Hildebrandt@charite.de Charite - Universitätsmedizin Berlin Tel. +49 (0)30-450 570-155 Gemeinsame Einrichtung von FU- und HU-Berlin Fax. +49 (0)30-450 570-962 IT-Zentrum Standort CBF send no mail to spamtrap@charite.de From owner-xfs@oss.sgi.com Fri Jun 9 06:30:55 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 09 Jun 2006 06:31:12 -0700 (PDT) Received: from lucidpixels.com (lucidpixels.com [66.45.37.187]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k59DUreZ024041 for ; Fri, 9 Jun 2006 06:30:54 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id D3691163824; Fri, 9 Jun 2006 09:30:39 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id D2D61100EC460; Fri, 9 Jun 2006 09:30:39 -0400 (EDT) Date: Fri, 9 Jun 2006 09:30:39 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: Ralf Hildebrandt cc: xfs@oss.sgi.com Subject: Re: EIP is at xfs_trans_update_ail+0x9c/0x1a0 In-Reply-To: Message-ID: References: <20060609122707.GR871@charite.de> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1463747160-1582378924-1149859839=:3438" X-archive-position: 7916 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs Content-Length: 4486 Lines: 111 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1463747160-1582378924-1149859839=:3438 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE 2.6.17-rc4-git2 Nevermind on that part, but regarding the binary-only modules, that's a=20 different story ;) On Fri, 9 Jun 2006, Justin Piszcz wrote: >> May 24 21:08:58 kasbah kernel: Modules linked in: tun nvidia > > Do you get the error without NVIDIA loaded? > What kernel version? > > These are some of the things the developers will want to know. > > > On Fri, 9 Jun 2006, Ralf Hildebrandt wrote: > >> I left my laptop running and went on vacation. When I came back, I found: >>=20 >> May 24 21:08:58 kasbah kernel: BUG: unable to handle kernel NULL pointer= =20 >> dereference at virtual address 00000004 >> May 24 21:08:58 kasbah kernel: printing eip: >> May 24 21:08:58 kasbah kernel: c01ee94c >> May 24 21:08:58 kasbah kernel: *pde =3D 00000000 >> May 24 21:08:58 kasbah kernel: Oops: 0002 [#1] >> May 24 21:08:58 kasbah kernel: PREEMPT >> May 24 21:08:58 kasbah kernel: Modules linked in: tun nvidia=20 >> cpufreq_ondemand cpufreq_userspace cpufreq_powersave thermal fan button = ac=20 >> battery powernow_k8 freq_table processor usbhid tsdev pcmcia snd_intel8= x0m=20 >> snd_pcm_oss snd_mixer_oss bcm43xx snd_intel8x0 i2c_nforce2 firmware_clas= s=20 >> ieee80211softmac snd_ac97_codec snd_ac97_bus snd_pcm snd_timer snd psmou= se=20 >> i2c_core ieee80211 yenta_socket rsrc_nonstatic pcmcia_core ehci_hcd rtc= =20 >> evdev 8139cp ohci_hcd usbcore soundcore snd_page_alloc 8139too=20 >> ieee80211_crypt ide_cd cdrom unix >> May 24 21:08:58 kasbah kernel: CPU: 0 >> May 24 21:08:58 kasbah kernel: EIP: 0060:[xfs_trans_update_ail+156/416]= =20 >> Tainted: P VLI >> May 24 21:08:58 kasbah kernel: EFLAGS: 00210297 (2.6.17-rc4-git2 #1) >> May 24 21:08:58 kasbah kernel: EIP is at xfs_trans_update_ail+0x9c/0x1a0 >> May 24 21:08:58 kasbah kernel: eax: 00000000 ebx: 0000a1e2 ecx:=20 >> 00008c58 edx: 0000a1e2 >> May 24 21:08:58 kasbah kernel: esi: dc6e2348 edi: df3c7460 ebp:=20 >> dfe1f014 esp: c14a6e5c >> May 24 21:08:58 kasbah kernel: ds: 007b es: 007b ss: 0068 >> May 24 21:08:58 kasbah kernel: Process xfslogd/0 (pid: 151,=20 >> threadinfo=3Dc14a6000 task=3Dc14a4a70) >> May 24 21:08:58 kasbah kernel: Stack: <0>00008c58 0000a1e2 dfe1f000=20 >> 00000000 df3c7f50 0000a1e2 00008c58 0000a1e2 >> May 24 21:08:58 kasbah kernel: df3c7460 0000a1e2 c01ed99a 00008c5= 8=20 >> 0000a1e2 00000000 00008c58 0000a1e2 >> May 24 21:08:58 kasbah kernel: c8453cc4 c8453ccc dfe1f000 0000000= 0=20 >> c14a6000 c8453cc4 c14a6000 00000000 >> May 24 21:08:58 kasbah kernel: Call Trace: >> May 24 21:08:58 kasbah kernel: =20 >> xfs_trans_chunk_committed+0x5a/0x140 =20 >> xfs_trans_committed+0x47/0x100 >> May 24 21:08:58 kasbah kernel: =20 >> xlog_state_do_callback+0x38c/0x4b0 xlog_iodone+0xab/0x150 >> May 24 21:08:58 kasbah kernel: xfs_buf_iodone_work+0xf/0x40= =20 >> run_workqueue+0xa1/0x150 >> May 24 21:08:58 kasbah kernel: xfs_buf_iodone_work+0x0/0x40= =20 >> worker_thread+0xee/0x120 >> May 24 21:08:58 kasbah kernel: default_wake_function+0x0/0x1= 0=20 >> kthread+0xd6/0xe0 >> May 24 21:08:58 kasbah kernel: worker_thread+0x0/0x120=20 >> kthread+0x0/0xe0 >> May 24 21:08:58 kasbah kernel: kernel_thread_helper+0x5/0x10 >> May 24 21:08:58 kasbah kernel: Code: 8b 5c 24 04 8b 0c 24 89 5c 24 14 8b= 5c=20 >> 24 14 39 5e 0c 8b 46 08 74 5c 72 07 8b 76 04 39 f5 75 eb 8b 06 89 77 04 = 89=20 >> 07 89 3e 8b 07 <89> 78 04 8b 44 24 08 ff 40 1c 8b 54 24 10 39 54 24 0c 0= f=20 >> 84 7d >> May 24 21:08:58 kasbah kernel: EIP: [xfs_trans_update_ail+156/416]=20 >> xfs_trans_update_ail+0x9c/0x1a0 SS:ESP 0068:c14a6e5c >> May 24 21:08:58 kasbah kernel: <6>note: xfslogd/0[151] exited with=20 >> preempt_count 1 >>=20 >> --=20 >> Ralf Hildebrandt (i.A. des IT-Zentrums) Ralf.Hildebrandt@charite= .de >> Charite - Universit=E4tsmedizin Berlin Tel. +49 (0)30-450 57= 0-155 >> Gemeinsame Einrichtung von FU- und HU-Berlin Fax. +49 (0)30-450 570-= 962 >> IT-Zentrum Standort CBF send no mail to spamtrap@charite= .de >>=20 > ---1463747160-1582378924-1149859839=:3438-- From owner-xfs@oss.sgi.com Fri Jun 9 06:34:50 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 09 Jun 2006 06:34:55 -0700 (PDT) Received: from mail.charite.de (mail.charite.de [160.45.207.131]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k59DYleZ025374 for ; Fri, 9 Jun 2006 06:34:49 -0700 Received: from localhost (localhost [127.0.0.1]) by mail.charite.de (Postfix) with ESMTP id 1823622065C; Fri, 9 Jun 2006 15:34:36 +0200 (CEST) Received: from mail.charite.de ([127.0.0.1]) by localhost (mail.charite.de [127.0.0.1]) (amavisd-new, port 10025) with LMTP id ID5icLbEVPDr; Fri, 9 Jun 2006 15:34:34 +0200 (CEST) Received: from postamt.charite.de (postamt.charite.de [160.45.207.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.charite.de (Postfix) with ESMTP id 1DD942206B4; Fri, 9 Jun 2006 15:32:58 +0200 (CEST) Received: by postamt.charite.de (Postfix, from userid 7945) id F2C06220949; Fri, 9 Jun 2006 15:32:57 +0200 (CEST) Date: Fri, 9 Jun 2006 15:32:57 +0200 From: Ralf Hildebrandt To: Justin Piszcz Cc: Ralf Hildebrandt , xfs@oss.sgi.com Subject: Re: EIP is at xfs_trans_update_ail+0x9c/0x1a0 Message-ID: <20060609133256.GD871@charite.de> References: <20060609122707.GR871@charite.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.11+cvs20060403 X-archive-position: 7917 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Ralf.Hildebrandt@charite.de Precedence: bulk X-list: xfs Content-Length: 692 Lines: 28 * Justin Piszcz : > 2.6.17-rc4-git2 > > Nevermind on that part, but regarding the binary-only modules, that's a > different story ;) Yeah, blame me :( > >Do you get the error without NVIDIA loaded? Well, no problem. I use the nv driver and wait another 3 weeks :(((( -- _________________________________________________ Charité - Universitätsmedizin Berlin _________________________________________________ Ralf Hildebrandt i.A. Geschäftsbereich Informationsmanagement Campus Benjamin Franklin Hindenburgdamm 30 | Berlin Tel. +49 30 450 570155 | Fax +49 30 450 570962 Ralf.Hildebrandt@charite.de http://www.charite.de From owner-xfs@oss.sgi.com Fri Jun 9 08:53:39 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 09 Jun 2006 08:53:44 -0700 (PDT) Received: from sahara.openoffice.nl (openoffice.demon.nl [212.238.150.237]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k59FrceZ018573 for ; Fri, 9 Jun 2006 08:53:39 -0700 Received: by sahara.openoffice.nl (Postfix, from userid 1001) id 8B1D03D0CF; Fri, 9 Jun 2006 15:51:40 +0200 (CEST) Date: Fri, 9 Jun 2006 15:51:40 +0200 From: Valentijn Sessink To: Russell Cattelan , xfs@oss.sgi.com Subject: Re: linux-xfs list name change? Message-ID: <20060609135140.GA32445@openoffice.nl> References: <446CB160.7030808@thebarn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: <446CB160.7030808@thebarn.com> User-Agent: Mutt/1.5.6+20040907i X-archive-position: 7918 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: valentyn+xfs@nospam.openoffice.nl Precedence: bulk X-list: xfs Content-Length: 1858 Lines: 52 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello Russell, hello list, There's a weird side effect: At Thu, May 18, 2006 at 12:39:44PM -0500, Russell Cattelan wrote: > Nathan and I have been talking about changing the name of > the "linux-xfs" on oss to just "xfs". I filtered the linux-xfs to a separate mail box. I didn't look at the linux-xfs list for a while, then suddenly mail on a formerly unknown "xfs" list came in my regular inbox. I couldn't find out how it came there. Now finally I find this message, and things become clear: it's a rename. > We would create an alias that would direct linux-xfs -> xfs so people > wouldn't be to lost or confused by the change. [...] > Please let us know if this change would cause any great hardships? Side effects: 1) the list-ID changed, so there's different filtering now. 2) as your "let's rename" mail came on the old list-ID, people with the same filters as I have, will have the same problem and will not know why (until they look in the original mail archive). Well, you predicted this one. But: 3) the Ecartis mail server seems to be unable to unsubscribe me. I have tried a couple of times to unsubscribe. It will send me an unsubscription acknowledge mail message for "xfs", but after carefully replying (resending) the commands in it, nothing happens. I'm sending this to the list itself as well, maybe there's people that are as ignorant as I was on the xfs stuff in their mail box. Could you please look into the unsubscription problem? Best regards, Valentijn - -- http://www.openoffice.nl/ Open Office - Linux Office Solutions Valentijn Sessink v.sessink@openoffice.nl +31(0)20-4214059 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFEiXzsTRf3oaxjt6kRAt5qAJ4h5NTangMzqzkkVUrHJ4HK+R7xywCfSl8c okYS7QlTbbl55ulbpZyud7E= =LRc/ -----END PGP SIGNATURE----- From owner-xfs@oss.sgi.com Fri Jun 9 09:56:21 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 09 Jun 2006 09:56:25 -0700 (PDT) Received: from mxfep03.bredband.com (mxfep03.bredband.com [195.54.107.76]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k59GuEeZ028105 for ; Fri, 9 Jun 2006 09:56:20 -0700 Received: from [192.168.1.11] ([213.114.216.208] [213.114.216.208]) by mxfep02.bredband.com with ESMTP id <20060609154105.QWSP18449.mxfep02.bredband.com@[192.168.1.11]> for ; Fri, 9 Jun 2006 17:41:05 +0200 Message-ID: <4489968E.7070102@stesmi.com> Date: Fri, 09 Jun 2006 17:41:02 +0200 From: Stefan Smietanowski User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501) X-Accept-Language: en-us, en MIME-Version: 1.0 To: xfs@oss.sgi.com Subject: XFS + software raid + 4k stacks = BOOM? X-Enigmail-Version: 0.93.0.0 Content-Type: multipart/signed; micalg=pgp-ripemd160; protocol="application/pgp-signature"; boundary="------------enig05A0014B5571247F5D34EB1B" X-archive-position: 7919 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: stesmi@stesmi.com Precedence: bulk X-list: xfs Content-Length: 1224 Lines: 41 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig05A0014B5571247F5D34EB1B Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi all. I was wondering if the above config will work or if it's still considered "if it breaks you get to keep the broken stack" ? I'm building a new toy-server for myself which will run both raid1, raid0+1, raid5 and maybe raid0+1+5 all using software raid. raid1 is straightfoward, raid0+1 as well, but I'm thinking of taking 4 disks, raid0+1 them and use THAT as a component in a raid5. (hence raid0+1+5). If it's possible to do - yes, but will this thing run with xfs using 4kstacks? (Using FC5). Thanx for answers. // Stefan --------------enig05A0014B5571247F5D34EB1B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEiZaRBrn2kJu9P78RAwRkAKDGLvncFzLkgtQmlBkq0cXewskpaQCgp8GS gxX6UDJ3ldDuY4iVfTbMZSg= =iXCU -----END PGP SIGNATURE----- --------------enig05A0014B5571247F5D34EB1B-- From owner-xfs@oss.sgi.com Fri Jun 9 10:53:23 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 09 Jun 2006 10:53:57 -0700 (PDT) Received: from sccrmhc14.comcast.net (sccrmhc14.comcast.net [204.127.200.84]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k59HrLeZ003532 for ; Fri, 9 Jun 2006 10:53:23 -0700 Received: from [127.0.0.1] (c-24-147-252-110.hsd1.ma.comcast.net[24.147.252.110]) by comcast.net (sccrmhc14) with ESMTP id <200606091650440140099b5le>; Fri, 9 Jun 2006 16:50:44 +0000 Message-ID: <4489A6E1.9080703@comcast.net> Date: Fri, 09 Jun 2006 12:50:41 -0400 From: The Levinson Family Reply-To: hal@umich.edu User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: xfs@oss.sgi.com Subject: Files not starting on swidth Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7920 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: levinson.h@comcast.net Precedence: bulk X-list: xfs Content-Length: 2451 Lines: 55 We are using Suse SLES 9 SP2 (soon to upgrade to SP3) for a DB2 database platform on an AMD64 dual cpu server. Each server has two 256GB partitions mounted from a clariion storage array. The clariion luns are each a RAID 5 array with 64KByte stripe units x 4 data disks for a 256KByte stripe width. The xfs filesystems look like # xfs_info /dev/emcpowera1 meta-data=/mnt/db02-01 isize=256 agcount=16, agsize=4365040 blks = sectsz=512 data = bsize=4096 blocks=69840576, imaxpct=25 = sunit=16 swidth=64 blks, unwritten=1 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=32768, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 I think we will adjust sunit setting on logs to match the sunit setting of the rest of the filesystem. When DB2 creates containers for the tables, I notice two things. First is that files don't start on swidth boundaries. They don't seem to match up to even an sunit boundary, but I should double check that. Do I need to preallocate with xfs_io to get files to line up on swidth boundaries? What does the offset argument to resvsp control? I didn't see it described in the man page and the reference to xfs(5) didn't have any details either. Should I be using the realtime section for these files to get minium extents of swidth for the large container files or is there a way to enforce extent size in the normal data section? The DBA's like to create parallel containers instead of one container. When this is done, sets of database blocks (extents in their terms) are striped across the various container files. For this to work, each write needs to in the same order that the database issued. Unfortunately the files are thrown all over. Is this a side effect of the allocation groups? If so, and we changed to one allocation group (if possible) how much would that effect performance. I saw a note on the list about a new feature that would assign allocation groups to directories. Would this help them with the write order of these striped containers, if all striped containers for a tablespace were under a single directory? My ultimate goal is to get them away from striped containers and use one big one. thanks harry levinson From owner-xfs@oss.sgi.com Fri Jun 9 11:00:43 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 09 Jun 2006 11:00:46 -0700 (PDT) Received: from service.eng.exegy.net (68-191-203-42.static.stls.mo.charter.com [68.191.203.42]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k59I0geZ004921 for ; Fri, 9 Jun 2006 11:00:43 -0700 Received: from HANAFORD.eng.exegy.net (hanaford.eng.exegy.net [10.19.1.4]) by service.eng.exegy.net (8.13.1/8.13.1) with ESMTP id k59I0QeM030692 for ; Fri, 9 Jun 2006 13:00:27 -0500 Received: from [10.19.4.98] ([10.19.4.98]) by HANAFORD.eng.exegy.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Jun 2006 13:00:26 -0500 Message-ID: <4489B73A.8030709@exegy.com> Date: Fri, 09 Jun 2006 13:00:26 -0500 From: Dave Lloyd User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: Files not starting on swidth Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Jun 2006 18:00:26.0901 (UTC) FILETIME=[966F9450:01C68BEE] X-archive-position: 7921 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dlloyd@exegy.com Precedence: bulk X-list: xfs Content-Length: 1509 Lines: 38 The Levinson Family wrote: > We are using Suse SLES 9 SP2 (soon to upgrade to SP3) for a DB2 database > platform on an AMD64 dual cpu server. Each server has two 256GB > partitions mounted from a clariion storage array. The clariion luns are > each a RAID 5 array with 64KByte stripe units x 4 data disks for a > 256KByte stripe width. The xfs filesystems look like > > # xfs_info /dev/emcpowera1 > meta-data=/mnt/db02-01 isize=256 agcount=16, agsize=4365040 > blks > = sectsz=512 > data = bsize=4096 blocks=69840576, > imaxpct=25 > = sunit=16 swidth=64 blks, > unwritten=1 > naming =version 2 bsize=4096 > log =internal bsize=4096 blocks=32768, version=1 > = sectsz=512 sunit=0 blks > realtime =none extsz=65536 blocks=0, rtextents=0 > > > I think we will adjust sunit setting on logs to match the sunit setting > of the rest of the filesystem. Those numbers indicate that they're right. Numbers reported there are in 4kb blocks, not 512 byte blocks. 4*16=64, 4*16*4=256. The other thing to check would be to make sure that your partition begins on stripe alignment. parted 1.7 and up should be able to split partitions on block sizes rather that the supid sector crap that fdisk does. Make sure that you're using 1.7 and up, though. -- Dave Lloyd Test Engineer, Exegy, Inc. 314.450.5342 dlloyd@exegy.com From owner-xfs@oss.sgi.com Fri Jun 9 21:01:35 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 09 Jun 2006 21:02:13 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k5A41UeZ008236 for ; Fri, 9 Jun 2006 21:01:33 -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 OAA19835; Sat, 10 Jun 2006 14:01:12 +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 k5A419gw775986; Sat, 10 Jun 2006 14:01:10 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k5A415Yf775083; Sat, 10 Jun 2006 14:01:05 +1000 (EST) Date: Sat, 10 Jun 2006 14:01:05 +1000 From: Nathan Scott To: Stefan Smietanowski Cc: xfs@oss.sgi.com Subject: Re: XFS + software raid + 4k stacks = BOOM? Message-ID: <20060610140105.C775761@wobbly.melbourne.sgi.com> References: <4489968E.7070102@stesmi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4489968E.7070102@stesmi.com>; from stesmi@stesmi.com on Fri, Jun 09, 2006 at 05:41:02PM +0200 X-archive-position: 7922 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 329 Lines: 13 On Fri, Jun 09, 2006 at 05:41:02PM +0200, Stefan Smietanowski wrote: > I was wondering if the above config will work or if it's still > considered "if it breaks you get to keep the broken stack" ? > ... We are unaware of any remaining XFS issues with 4K stacks... so, let us know if anything does go BOOM. cheers. -- Nathan From owner-xfs@oss.sgi.com Fri Jun 9 21:34:13 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 09 Jun 2006 21:34:48 -0700 (PDT) Received: from mxfep02.bredband.com (mxfep02.bredband.com [195.54.107.73]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5A4YAeZ012362 for ; Fri, 9 Jun 2006 21:34:12 -0700 Received: from [192.168.1.11] ([213.114.216.208] [213.114.216.208]) by mxfep02.bredband.com with ESMTP id <20060610043359.VEVE18449.mxfep02.bredband.com@[192.168.1.11]>; Sat, 10 Jun 2006 06:33:59 +0200 Message-ID: <448A4BB3.1010104@stesmi.com> Date: Sat, 10 Jun 2006 06:33:55 +0200 From: Stefan Smietanowski User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nathan Scott CC: xfs@oss.sgi.com Subject: Re: XFS + software raid + 4k stacks = BOOM? References: <4489968E.7070102@stesmi.com> <20060610140105.C775761@wobbly.melbourne.sgi.com> In-Reply-To: <20060610140105.C775761@wobbly.melbourne.sgi.com> X-Enigmail-Version: 0.93.0.0 Content-Type: multipart/signed; micalg=pgp-ripemd160; protocol="application/pgp-signature"; boundary="------------enigED53367AE490D88C1BD28F40" X-archive-position: 7923 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: stesmi@stesmi.com Precedence: bulk X-list: xfs Content-Length: 1161 Lines: 41 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigED53367AE490D88C1BD28F40 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Nathan Scott wrote: > On Fri, Jun 09, 2006 at 05:41:02PM +0200, Stefan Smietanowski wrote: > >>I was wondering if the above config will work or if it's still >>considered "if it breaks you get to keep the broken stack" ? >>... > > > We are unaware of any remaining XFS issues with 4K stacks... so, > let us know if anything does go BOOM. > > cheers. > Will do. Running some tests now that will take a while. (Test is run using FC5 latest everything). // Stefan --------------enigED53367AE490D88C1BD28F40 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFEiku3Brn2kJu9P78RA7k1AKCsTQVFuUxTkAS7kbrYIHiXgVg9kACfRxHS t/mQ9B9rXhZEGXS32a6l/6w= =3xqq -----END PGP SIGNATURE----- --------------enigED53367AE490D88C1BD28F40-- From owner-xfs@oss.sgi.com Sat Jun 10 04:16:24 2006 Received: with ECARTIS (v1.0.0; list xfs); Sat, 10 Jun 2006 04:16:32 -0700 (PDT) Received: from moving-picture.com (mpc-26.sohonet.co.uk [193.203.82.251]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5ABGMeZ006637 for ; Sat, 10 Jun 2006 04:16:24 -0700 Received: from [192.168.101.20] (helo=[192.168.101.20]) by moving-picture.com with esmtp (Exim 4.43) id 1Fp0I4-00049g-3A; Sat, 10 Jun 2006 11:02:00 +0100 Message-ID: <448A98E8.9040109@moving-picture.com> Date: Sat, 10 Jun 2006 11:03:20 +0100 From: James Pearson User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: xfs@oss.sgi.com Subject: Re: XFS + software raid + 4k stacks = BOOM? 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: 7925 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: james-p@moving-picture.com Precedence: bulk X-list: xfs Content-Length: 583 Lines: 20 Nathan Scott wrote: > On Fri, Jun 09, 2006 at 05:41:02PM +0200, Stefan Smietanowski wrote: >> I was wondering if the above config will work or if it's still >> considered "if it breaks you get to keep the broken stack" ? >> ... > > We are unaware of any remaining XFS issues with 4K stacks... so, > let us know if anything does go BOOM. Do you know at which point these remaining issues got resolved? - for example, could there be any potential stack problems using RHEL4 (U3) with the XFS module from ? Thanks James Pearson From owner-xfs@oss.sgi.com Sat Jun 10 08:12:42 2006 Received: with ECARTIS (v1.0.0; list xfs); Sat, 10 Jun 2006 08:12:49 -0700 (PDT) Received: from postfix1-c.free.fr (postfix1-c.free.fr [213.228.0.79]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5AFCeeZ011708 for ; Sat, 10 Jun 2006 08:12:42 -0700 Received: from smtp2-g19.free.fr (smtp2-g19.free.fr [212.27.42.28]) by postfix1-c.free.fr (Postfix) with ESMTP id B4C561CD0B81 for ; Sat, 10 Jun 2006 14:48:51 +0200 (CEST) Received: from inara.maison.net (lns-bzn-35-82-250-218-242.adsl.proxad.net [82.250.218.242]) by smtp2-g19.free.fr (Postfix) with ESMTP id A58D572871 for ; Sat, 10 Jun 2006 15:48:46 +0200 (CEST) Received: by inara.maison.net (Postfix, from userid 32266) id 0EC445A69A; Sat, 10 Jun 2006 15:48:46 +0200 (CEST) Date: Sat, 10 Jun 2006 15:48:46 +0200 From: KELEMEN Peter To: xfs@oss.sgi.com Subject: Re: XFS + software raid + 4k stacks = BOOM? Message-ID: <20060610134845.GA12469@inara.maison.net> Mail-Followup-To: xfs@oss.sgi.com References: <448A98E8.9040109@moving-picture.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <448A98E8.9040109@moving-picture.com> Organization: CERN European Laboratory for Particle Physics, Switzerland X-GPG-KeyID: 1024D/9FF0CABE 2004-04-03 X-GPG-Fingerprint: 6C9E 5917 3B06 E4EE 6356 7BF0 8F3E CAB6 9FF0 CABE X-Comment: Personal opinion. Paragraphs might have been reformatted. X-Copyright: Forwarding or publishing without permission is prohibited. X-Accept-Language: hu,en User-Agent: Mutt/1.5.11+cvs20060403 X-archive-position: 7926 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Peter.Kelemen@cern.ch Precedence: bulk X-list: xfs Content-Length: 579 Lines: 15 * James Pearson (james-P@moving-Picture.com) [20060610 11:03]: > Do you know at which point these remaining issues got resolved? - for > example, could there be any potential stack problems using RHEL4 (U3) > with the XFS module from ? There are, but you need many parallel I/O streams to trigger it. Peter -- .+'''+. .+'''+. .+'''+. .+'''+. .+'' Kelemen Péter / \ / \ Peter.Kelemen@cern.ch .+' `+...+' `+...+' `+...+' `+...+' From owner-xfs@oss.sgi.com Sat Jun 10 20:38:28 2006 Received: with ECARTIS (v1.0.0; list xfs); Sat, 10 Jun 2006 20:38:36 -0700 (PDT) Received: from xenotime.net (xenotime.net [66.160.160.81]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k5B3cReZ019188 for ; Sat, 10 Jun 2006 20:38:28 -0700 Received: from midway.site ([71.245.102.105]) by xenotime.net for ; Sat, 10 Jun 2006 20:38:12 -0700 Date: Sat, 10 Jun 2006 20:41:00 -0700 From: "Randy.Dunlap" To: Diego Calleja Cc: linux-kernel@vger.kernel.org, akpm@osdl.org, netdev@vger.kernel.org, linux-xfs@oss.sgi.com, ecki@lina.inka.de, lkml@rtr.ca Subject: Re: Updated sysctl documentation take #2 Message-Id: <20060610204100.901a0de1.rdunlap@xenotime.net> In-Reply-To: <20060608001806.028ab05a.diegocg@gmail.com> References: <20060607205316.bbb3c379.diegocg@gmail.com> <20060607130653.9a4d572c.rdunlap@xenotime.net> <20060608001806.028ab05a.diegocg@gmail.com> Organization: YPO4 X-Mailer: Sylpheed version 2.2.5 (GTK+ 2.8.3; x86_64-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id k5B3cSeZ019194 X-archive-position: 7927 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: rdunlap@xenotime.net Precedence: bulk X-list: xfs Content-Length: 967 Lines: 34 On Thu, 8 Jun 2006 00:18:06 +0200 Diego Calleja wrote: > El Wed, 7 Jun 2006 13:06:53 -0700, > "Randy.Dunlap" escribió: > > > OK, that's all for the README file. I'll look at the rest of it > > sometime this week. I don't think that it's quite ready to be merged. > > Thank's for your review, altought I didn't though someone was to review > so deeply a documentation patch ;) I've gone through all the files and > fixed the 72-col limit and everything I could. I've updated the patch > http://terra.es/personal/diegocg/sysctl-docs Here are some more comments for you. 1. There are quite a few lines (17) ending with ^M (carriage return) that should be removed. 2. Lines like this one should end with a period (full stop): +This file is SPARC-only 3. I would put this comment near the top of each file, not at the end: +PLEASE KEEP THIS FILE ORDERED ALPHABETICALLY. Other than that, it's looking good to me. Thanks, --- ~Randy From owner-xfs@oss.sgi.com Sun Jun 11 13:55:26 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 11 Jun 2006 13:55:29 -0700 (PDT) Received: from mail.net-conex.com (pops.net-conex.com [204.244.176.3]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5BKtNeZ013752 for ; Sun, 11 Jun 2006 13:55:25 -0700 Received: from curie.orbis-terrarum.net (S01060050da688d47.vc.shawcable.net [24.80.100.253]) by mail.net-conex.com (8.13.4/8.12.11) with ESMTP id k5BJpqsh029182 for ; Sun, 11 Jun 2006 12:51:52 -0700 Received: (qmail 29620 invoked by uid 10000); 11 Jun 2006 12:51:56 -0700 Date: Sun, 11 Jun 2006 12:51:56 -0700 From: "Robin H. Johnson" To: xfs@oss.sgi.com Subject: [XFSDUMP PATCH] Fixes for parallel compiles Message-ID: <20060611195156.GF26475@curie-int.vc.shawcable.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="MZf7D3rAEoQgPanC" Content-Disposition: inline User-Agent: Mutt/1.5.11 X-archive-position: 7928 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: robbat2@gentoo.org Precedence: bulk X-list: xfs Content-Length: 2586 Lines: 84 --MZf7D3rAEoQgPanC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Several of the directories in xfsdump are not parallel compile safe, due to their behavior of deleting and symlinking heads from other directories. This patch modifies those Makefiles to have the symlinks be a dependancy of= the source in those directories, ensuring that all of the symlinks will exist before the actual compiling is started. Signed-off-by: Robin H. Johnson diff -Nuar --exclude '*.orig' --exclude builddefs.in xfsdump-2.2.33/dump/Ma= kefile xfsdump-2.2.33/dump/Makefile --- xfsdump-2.2.33/dump/Makefile 2006-01-11 21:06:47.000000000 -0800 +++ xfsdump-2.2.33/dump/Makefile 2006-06-11 12:36:21.436682241 -0700 @@ -102,7 +102,9 @@ install-dev: =20 $(COMMINCL) $(COMMON): - @$(RM) $@; $(LN_S) ../common/$@ $@ + $(RM) $@; $(LN_S) ../common/$@ $@ =20 $(INVINCL) $(INVCOMMON): - @$(RM) $@; $(LN_S) ../inventory/$@ $@ + $(RM) $@; $(LN_S) ../inventory/$@ $@ + +$(LOCALS): $(LINKS) diff -Nuar --exclude '*.orig' --exclude builddefs.in xfsdump-2.2.33/invutil= /Makefile xfsdump-2.2.33/invutil/Makefile --- xfsdump-2.2.33/invutil/Makefile 2006-01-11 21:06:48.000000000 -0800 +++ xfsdump-2.2.33/invutil/Makefile 2006-06-11 12:36:21.438682223 -0700 @@ -66,7 +66,9 @@ install-dev: =20 $(COMMINCL) $(COMMON): - @$(RM) $@; $(LN_S) ../common/$@ $@ + $(RM) $@; $(LN_S) ../common/$@ $@ =20 $(INVINCL) $(INVCOMMON): - @$(RM) $@; $(LN_S) ../inventory/$@ $@ + $(RM) $@; $(LN_S) ../inventory/$@ $@ + +$(LOCALS): $(LINKS) diff -Nuar --exclude '*.orig' --exclude builddefs.in xfsdump-2.2.33/restore= /Makefile xfsdump-2.2.33/restore/Makefile --- xfsdump-2.2.33/restore/Makefile 2006-01-11 21:06:49.000000000 -0800 +++ xfsdump-2.2.33/restore/Makefile 2006-06-11 12:36:21.433682268 -0700 @@ -112,7 +112,9 @@ install-dev: =20 $(COMMINCL) $(COMMON): - @$(RM) $@; $(LN_S) ../common/$@ $@ + $(RM) $@; $(LN_S) ../common/$@ $@ =20 $(INVINCL) $(INVCOMMON): - @$(RM) $@; $(LN_S) ../inventory/$@ $@ + $(RM) $@; $(LN_S) ../inventory/$@ $@ + +$(LOCALS): $(LINKS) --=20 Robin Hugh Johnson E-Mail : robbat2@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 --MZf7D3rAEoQgPanC Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2-ecc0.1.6 (GNU/Linux) Comment: Robbat2 @ Orbis-Terrarum Networks iD8DBQFEjHRcPpIsIjIzwiwRAl+9AKDMF+Ue3UMAvPqVY+jaB1m/0YO5DwCfU+Qg x9o6H/wCkjOuvOmZF+ozt4E= =5aJA -----END PGP SIGNATURE----- --MZf7D3rAEoQgPanC-- From owner-xfs@oss.sgi.com Tue Jun 13 00:30:17 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 13 Jun 2006 00:30:29 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5D7UBDW031055 for ; Tue, 13 Jun 2006 00:30:15 -0700 Received: from [84.133.141.188] (helo=[192.168.1.201]) by mrelayeu.kundenserver.de (node=mrelayeu5) with ESMTP (Nemesis), id 0ML25U-1Fq2Hf2h01-0001V9; Tue, 13 Jun 2006 08:21:52 +0200 Message-ID: <448E59AA.50802@kohnos.net> Date: Tue, 13 Jun 2006 08:22:34 +0200 From: Norman Krebs User-Agent: Thunderbird 1.5.0.2 (X11/20060516) MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: error 990 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: kundenserver.de abuse@kundenserver.de login:9d9846e72bba3c210c69e904869487e0 X-archive-position: 7931 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: norman.krebs@kohnos.net Precedence: bulk X-list: xfs Content-Length: 2053 Lines: 57 Dear Sirs and Madams, I got an Error with an XFS filesystem on my machine. I have mounted an xfs-partition /dev/hdb6 on /usr3. Now I tried to delete something there and earned the error 990. After that nothing was visible anymore on the partition until a remount. I tried an xfs_check and xfs_repair what moved a lot of stuff to the lost+found folder on the partition. finally the xfs_repair told me to send a mail to you what I do now. Following are some Informations about my computer - I hope that it may help. /Greetings from germany and thank You Norman Krebs The computer is an Athlon 900 on a Biostar m7vkt-Board with a VIA KT133 chipset and 1.5GB RAM 20# uname -a Linux odin 2.6.15 #2 Thu Jun 8 13:04:02 CEST 2006 i686 GNU/Linux The output of fdisk gives: 19# fdisk -l /dev/hdb Disk /dev/hdb: 200.0 GB, 200049647616 bytes 255 heads, 63 sectors/track, 24321 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/hdb1 1 1912 15358108+ 7 HPFS/NTFS /dev/hdb2 1913 24321 180000262 5 Extended /dev/hdb5 4346 9209 39070048+ 7 HPFS/NTFS /dev/hdb6 9210 24321 121387108+ 83 Linux /dev/hdb7 1913 2156 1959898+ 82 Linux swap / Solaris /dev/hdb8 2157 4345 17583111 c W95 FAT32 (LBA) 19# xfs_repair /dev/hdb6 ... ... disconnected dir inode 477981539, moving to lost+found disconnected dir inode 503327476, moving to lost+found disconnected dir inode 510570834, moving to lost+found disconnected dir inode 511775075, moving to lost+found Phase 7 - verify and correct link counts... resetting inode 128 nlinks from 12 to 10 resetting inode 131 nlinks from 7 to 4 resetting inode 34287363 nlinks from 3 to 2 corrupt dinode 34665031, extent total = 1, nblocks = 0. This is a bug. Please report it to linux-xfs@oss.sgi.com. fatal error -- couldn't map inode 34665031, err = 990 odin - root - [ ~ ] - (bash) 19# From owner-xfs@oss.sgi.com Tue Jun 13 01:27:18 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 13 Jun 2006 01:27:31 -0700 (PDT) Received: from lucidpixels.com (lucidpixels.com [66.45.37.187]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5D8RHDW010529 for ; Tue, 13 Jun 2006 01:27:17 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id 8C715616D16C; Tue, 13 Jun 2006 04:27:01 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id 726DA161975FF; Tue, 13 Jun 2006 04:27:01 -0400 (EDT) Date: Tue, 13 Jun 2006 04:27:01 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: Norman Krebs cc: linux-xfs@oss.sgi.com Subject: Re: error 990 In-Reply-To: <448E59AA.50802@kohnos.net> Message-ID: References: <448E59AA.50802@kohnos.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 7932 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs Content-Length: 2284 Lines: 64 Have you done some basic disk testing to make sure the disk is ok? Anything from dmesg or syslog? On Tue, 13 Jun 2006, Norman Krebs wrote: > Dear Sirs and Madams, > > I got an Error with an XFS filesystem on my machine. I have mounted an > xfs-partition /dev/hdb6 on /usr3. > Now I tried to delete something there and earned the error 990. After that > nothing was visible anymore on the partition until a remount. I tried an > xfs_check and xfs_repair what moved a lot of stuff to the lost+found folder > on the partition. finally the xfs_repair told me to send a mail to you what I > do now. Following are some Informations about my computer - I hope that it > may help. > > /Greetings from germany and thank You > Norman Krebs > > The computer is an Athlon 900 on a Biostar m7vkt-Board with a VIA KT133 > chipset and 1.5GB RAM > > 20# uname -a > Linux odin 2.6.15 #2 Thu Jun 8 13:04:02 CEST 2006 i686 GNU/Linux > > The output of fdisk gives: > > 19# fdisk -l /dev/hdb > > Disk /dev/hdb: 200.0 GB, 200049647616 bytes > 255 heads, 63 sectors/track, 24321 cylinders > Units = cylinders of 16065 * 512 = 8225280 bytes > > Device Boot Start End Blocks Id System > /dev/hdb1 1 1912 15358108+ 7 HPFS/NTFS > /dev/hdb2 1913 24321 180000262 5 Extended > /dev/hdb5 4346 9209 39070048+ 7 HPFS/NTFS > /dev/hdb6 9210 24321 121387108+ 83 Linux > /dev/hdb7 1913 2156 1959898+ 82 Linux swap / Solaris > /dev/hdb8 2157 4345 17583111 c W95 FAT32 (LBA) > > 19# xfs_repair /dev/hdb6 > ... > ... > > disconnected dir inode 477981539, moving to lost+found > disconnected dir inode 503327476, moving to lost+found > disconnected dir inode 510570834, moving to lost+found > disconnected dir inode 511775075, moving to lost+found > Phase 7 - verify and correct link counts... > resetting inode 128 nlinks from 12 to 10 > resetting inode 131 nlinks from 7 to 4 > resetting inode 34287363 nlinks from 3 to 2 > corrupt dinode 34665031, extent total = 1, nblocks = 0. This is a bug. > Please report it to linux-xfs@oss.sgi.com. > > fatal error -- couldn't map inode 34665031, err = 990 > odin - root - [ ~ ] - (bash) > 19# > > > > From owner-xfs@oss.sgi.com Tue Jun 13 21:12:48 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 13 Jun 2006 21:13:11 -0700 (PDT) Received: from omx1.americas.sgi.com (omx1.americas.sgi.com [198.149.16.13]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5E4CcDW028805 for ; Tue, 13 Jun 2006 21:12:48 -0700 Received: from spindle.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id k5E4CGnx000841 for ; Tue, 13 Jun 2006 23:12:16 -0500 Received: from [127.0.0.1] (sshgate.corp.sgi.com [198.149.36.12]) by spindle.corp.sgi.com (SGI-8.12.5/8.12.9/generic_config-1.2) with ESMTP id k5E4BsnB41142869; Tue, 13 Jun 2006 21:11:55 -0700 (PDT) Message-ID: <448F8C8A.4070008@sgi.com> Date: Tue, 13 Jun 2006 23:11:54 -0500 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060516) MIME-Version: 1.0 To: James Pearson CC: xfs@oss.sgi.com Subject: Re: XFS + software raid + 4k stacks = BOOM? References: <448A98E8.9040109@moving-picture.com> In-Reply-To: <448A98E8.9040109@moving-picture.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7934 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: xfs Content-Length: 812 Lines: 20 James Pearson wrote: > Nathan Scott wrote: >> On Fri, Jun 09, 2006 at 05:41:02PM +0200, Stefan Smietanowski wrote: >>> I was wondering if the above config will work or if it's still >>> considered "if it breaks you get to keep the broken stack" ? >>> ... >> >> We are unaware of any remaining XFS issues with 4K stacks... so, >> let us know if anything does go BOOM. > > Do you know at which point these remaining issues got resolved? - for > example, could there be any potential stack problems using RHEL4 (U3) > with the XFS module from ? There were more stack reductions after that. Which is -not- to say that you -will- have problems with the above... all depends on what you're doing. But Nathan did more stack work after I put that rpm out. -Eric From owner-xfs@oss.sgi.com Tue Jun 13 22:51:11 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 13 Jun 2006 22:51:21 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5E5p8DW005286 for ; Tue, 13 Jun 2006 22:51:09 -0700 Received: from [84.133.172.98] (helo=[192.168.1.201]) by mrelayeu.kundenserver.de (node=mrelayeu7) with ESMTP (Nemesis), id 0ML2Dk-1FqOHH1o8v-0004rE; Wed, 14 Jun 2006 07:50:56 +0200 Message-ID: <448FA3EF.20603@kohnos.net> Date: Wed, 14 Jun 2006 07:51:43 +0200 From: Norman Krebs User-Agent: Thunderbird 1.5.0.2 (X11/20060516) MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: error 990 References: <448E59AA.50802@kohnos.net> In-Reply-To: Content-Type: multipart/mixed; boundary="------------070404010101010005070107" X-Provags-ID: kundenserver.de abuse@kundenserver.de login:9d9846e72bba3c210c69e904869487e0 X-archive-position: 7935 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: norman.krebs@kohnos.net Precedence: bulk X-list: xfs Content-Length: 66213 Lines: 1103 This is a multi-part message in MIME format. --------------070404010101010005070107 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hallo Justin, thank you for Your prompt answer. I attached the output of my /var/log/messages, dmesg and smartctl to this mail. The partition is on the second drive /dev/hdb6 and in the /var/log/messages file You´ll find some funny kernel output at [Jun 9 20:37:59]. The harddrive seems to be ok to me, it's not very old and when I shoveled some data around today I found no problem. I hope this helps and thanks a lot for Your effort! /greetings, Norman Krebs PS: by sending a mail to jpiszcz@lucidpixels.com it was rejected by the spam-filter so I use the generic address. --------------070404010101010005070107 Content-Type: application/x-compressed-tar; name="dmesg_messages_smartctl.tgz" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="dmesg_messages_smartctl.tgz" H4sIAEsxj0QAA+w7/XPaSJb5cUp/xauZvQueA6EvELCbrWBwYiYm4YyTTFV2 JiUkAVqEpNEHMVP3x9973RIGG1BjJ7e3VaFcRkj9Pvr1+2z1c5ZuMnv2bT8K fpqGwb7xc+9baxh685mqGPilGpquPlNUpak0n4HyjflinyxJrRjgWRyG6bFx Zc//TT9XXpDdwsqNEy8MQJObstqACk32Zeh4wRlUZra9eW7IimyAhsupNBQT KlHsxq7vWomLA/vuxLP4GL2mn53BTxrczDP4JQugBareUYyOokHvYnzDUEjn g3fjWhSHK89xHYjm68SzLR+uu0NYWlFHAjbAbWlKB5R7H6ht32pPbbxVyRJr 4rtnhwD5qB1Ai+GqxG7ixivXOQg6fUBTVcRA1fvsNqZTju0ou5tRu4A6A+z2 RgN4+2F8GFTfBW0WUuOgjpVa+2GnD8iqG4lvTbWpt4fncDl4fTm8GIK1sjyf piJLrXYTH1y9+3jv/rsAgtBxQYE0TC0/smZu0gG9raMiSAD9YRf+DAO3A4bS bgJ7XIWrwat3MLFSe97JB+laPkw5MOZtGC9RhfggTWtorX0jdRWHXnqz+dBd 5mPVpt7SjP1j+8MBWoYOEQkgSGWJhNiB63F/BJUViYYkedOFks8ZvATllqRs WrZyh+WGYVELLN2P1322TMotukNFc3WV3eOw7MMxFQudY3rVfSImo8DUv+Pp w6DbbBvbmAqlgOH41Q395hpib2bHPjmm0bB24y3dGAbvYBTGaYdYUZSW1PX9 0LZSL5jBqDcAlGyYxbabALljdttKwdyo3gz9ARRa3GnnWnomnWeen4LKFtH3 kjSR3rgxXoIdLpdW4IDv0eqSP3tRd9xVfe5YKv6UrkJyNd3RoAeOx+zQgcma CQ5qNViHGdjozNyAHoGXwhcvncOPvhV59o8SuqcIARh4GgJZjcP4VFQbPSNx Ngi81LN870+aS2/0/idFGg36MLeSOaQMKapS7JEZMJ2vhLHjxqiIWhWajYbe RHZSNzmT+m7q2ilSa7VNWTUbMLz8E1UxRGElYSxL7xOiEC3TZQzTMIY56nUN 5QkpCp5LVeqFQRL6KAg79PEOfHjd/S9oKbdaA9EjG2ucrD1393Kn6qpiahv+ zCo0NENrtQr+BmTYtcPwfDIFeLMKWlNTDaMARxMM4zWSaWBEUZuLutow0WqV xZ37gIpqNtUFLIqldVzEorBBhU9CrlRjwTxbFXD4AjxcACZKrY2/SCpLd3km 9eauvSCJeVNI515yJ0qYhwEKBwWHM/k4ggmuurtyA8QESRYhGY9GLZG8LMvw biFLPVzgSczV2HF9aw0ZW42U6XwSubY39WzUtwyHIBRy1m7K5DDCWTgcjMZQ 8aN/vtAbbY0pzdi1s9hL1/AqtpbulzBewErFeKqw2TB1ch1pfMGidgddYqG6 aCwT1HFZGoZZkB5ZjYaqSaiNHehOU2Rx5gZujBxiBA5Sb7quoiJEOExRW/oU zQxs1TbZxSYMCFxsU0ABOii1b0HgSoUB9GiqqFfGG6g0c62qk9WfVaGfq/We hzkGrYDXGs0DY/g0LN9na5AIT0A7OoFBkKIqL5E4UgKblBKsGH+RsWexSxoX ocN0HXnv2Nilp6Rr3EU5gOkZczOytExjtLSVhmpT0YiRhtouJjPsQzed+2FQ SZdnMNrofpK6UUToFE26IIx0PbWSFF6N3kNirVwgd4rmloYx038HXa58Z07P 5376HEWUpHFmp5gsMht5UwTLxE0ZtxdXvWtymcgVcjeNwyUoroWqb2/ZpbfE MAxomyRxtIRpgsjQGr0keJ5CZWI5MPvTi1AkM9TdIFtOMD89+yv4YbhI0OUv iFkO7EivYtdleNlPWOb+xmg30C1M8aEjvb24wUDszjCAYD7rkEtIQ3SVKICl 568xOchnMcnQO6wjFyLbQ1kUABKGsA6LYyx+xC56Cp5Oqwpw/4oGqtxOJ6qp VMEnsSKqFyoH5B7cDoOpN8vImyAoo6LmZMfZJFkjqeUWaszzlDYuFh9BKhJj fkKqmitE/oQjp0BFwcGjcXEWpblPmhVxGnm/RgcC57HnoOw/4Q3lN4xnFG7J M/EZxuGkiNhzK3a+WKioFRIKDeGYukmSLV0WcWGSI/vH5/H5Z5mjpNG4sgph hD8yL150mCRxThTfa03FRJvyLfSgLCKv0pZmN1tNuPxYW4bBHjCKtzX8tx9s PDyXzokZqjJC9NIrz2a6xaem4uxkZUsKg42ErrmE4IZ50K1JyJ9H1ze/7YVB x7yAT1dv33RReIPr/04wN9HBgAY0wYSfUR1UFUM8qAYGvLPjKM73oUAMP4uj 6O2i+HmDQxxF/yEXPz9EwcvIkZ/NmJsYUSgccw8GK0VuY62ICWLXsZZwTnFS igJM6EbBCFhWSba5e6uD6pohJiTElyyR8BGZV+cu6uE6M/DR29G2JbF7pO3I 90bP2fPBFKxCBZzQZe6EomwVyEZ/RKt+QeNdL/7jRxloOHqduetH6PajEK3W yh0vR8eNpZOrEmmTTEUI5rpfPIx6Xzqb3FLG21QSFffdPA7UXHXKPvh8dH3x 6uKmd3kH3MoHOdN8EKM6zl2pb6VuYK/zZCOcFhPb5oZcbdOQ8uwHc4QswBFR iL4twVyC4iaveaQPr7hkF2hdWKIl4ND356bckLECousjWYWqYO3EUzxAB8cS 2k16uJ0Hx+soDWexFc3RcWP6LHkhJIjVyXwEDcIw2narOw8tzB9sL7Iw/qwP DnJcy6HYfXCAPf1j+1k3ivw1cYZ1DmCynM5zn0VaYcWkgjKXOlc6NtSzwL1F +KCoIAodwyFMicdYOgQsgKISkkbb6Cwphm1GvA25sfwnN5V85ZjKS6jNaAfj OuYmIQo49InvT3hX0RW9Mxprb6r0Y6qyH8PfeGxpKlX8ZwCqLqhVzPIwL/bC DngtxdCg+/5XYMb4cOy9kW/O+4dGYnoa41J2oKU1lLqKqTUaZ+ytkL2/XOeB CXVBbivwF3QVhAXthowwwWixlaswipZPaDqQpuuxQtQG9XdIUZ+2oELkXoBx Rn7aAkap+wBIvQPS7oD0XSCyg+YJRGi8eQL+a8yoBuM3hRy20nTaU2B7WegD MCtB+2ypbe0NsztuMBMsgRf0szQB0SQviDKsnrs3cBNbQUK275AnAA3LovUk RAUDNNo6hsAkqbPR/D+mmiOmoO6RGq+kRrvpjQATP9L/BA1pL4ocosDRwipM MVoNs7mNBLOH/dDlDHTgcgOXbJIlZKayzVkBRnQYTk43doNw2+w5L/b2LR46 Bhg5xnNUXDtLWaXHgiN8sRZuFhWRqAPS+Gp0ThFTgffjc/ZPhffda/ZPgzyi VvIcPgHUPVSnsQFjjJW5ymAxzlJbmHo4I57e8ZhHxRypBiZJm7FXoeUQg5S2 vvHO4ZPK9Oo3yuhwahhX6Sfl3P/zQ/2H2g//+OH79/fvb/3Na0CWOrCNB7RA lvhXHqj2GdqahcP9tbypyLIgSxAi39YpCjO2eSNYl0nvAw9j7BKGmZ96NYyl Kft5URv0LwqffBeaTFlRLD+aW+hPHTevVYgTXadNtdwIqUJJIqTPwzdmc+QI kr9CiNgwO3D5XiBeUA13eyt9GH1GcphdIk37LmSjGVNOnfgokE1OZsp50UdZ BIXGqXeLnoUobY+pAiuNtUaDFcsbEvbci7CUvqsDm5tHAZJRFeU/IMAKEst1 YrqDrPo+yW3iUgxPWNIYb2Ao6ykqpQlt8K8wdztjE3nfH3YR3faEkBxmyDtT oW1tFARG5PNhjXbxWdZAe6E19mVWeUmcl//oOueO1cGBVbyY0EWBQn2AosVR TPegsAsUTifyQqmoS4lvVuFOLarxkC/KuYgijG90lfZCmgjWvenCXdCWiBF6 jo9b+54THs6UOqVpqVOzSilEkwTCEiPjMAcq58DG8HVV69/UxjfQ/9CntOD1 uFsz1KZ5zghikOn16/iodv1ueEdYzQmbjLDJCJt3hBt8ckvrFjXijwwjYZ7W U36BYYI/1nTDQEpGC2VoY/qcQIVkoRswPD+DL3WWl2BMYVthVehdjl/Q6xC9 jupXb+pVpgsVlWp8ho/nEVM/w5Cb3G1USWxtge2w4z+N/un0z+AiPsblhF4G KaamtptbXNKmqNE+zKVm6Jq6l8vJUS4nxOWEuJxo8Df6atC/Jv0z6V8L/i4t /hlmlOI7m1cSWBH2wuWSNqJoiVeY/jeI2TBwEuni1xu9NkXtXOaOcCusM3/B chu8T1vUfBNZ6jospqvtRrvVai0g+WJFtLb5m4qJiRRHmJvTlnCnprKqI0iT DmqFHYcJXuSQjDq8GhMwyb/KOaQCJZ+FdO3iD3oXAz2WW/S5c1ypMlYAr/Nt 4Oub3tYDxeSay9XTaP0KhX6y7xppcQ8v6tcfucbSrrzRWmzWiK2Irp9t3HRv S723HbMua4q0xNwqL3xQholbVEX0KgfnRS6SdmFpmORjpdgBH5MiygBJs1pF dnYmjXtjdLubPbPtrXP0X5/nYRph7cV3PC7Ra7JKjH70wtgt3nVjVS83pGQe 2XOq6FIrcCjHvjd+4xsLqd0BG1KWTGzE2NlKMyFwvxTTx8fTpGzQPJvsltCY asIQc3xkKYxpm5QPJDdTTq+WcCDpAZbcPrZA5aLmGCzZmlyFM9qcnsPHuYvh esiWaG/JoUp8KWrsNRnm84ZsyErNC+3UZ0bdqClqTdXONkuTULnkLGsI5/ov kfjcSmVc98cY4Z0ZaHvM4DFm+iQmjP8HTEyaX4kJvs1nzaIZsrAV6FaKrCoq 2+Pr06uCXzAvTKTIikmnPkc2zzQwyejWW5qOpUv+TnNnSJTHUDuLsV5LdzfE d0b28hF4Dz0CKiNT3YmV0F7crfKA8O64zfteL2CZhdRS9XYahvCK9uUv0jnl o2lhNYrcljWzdKe2eAtDWwaY1al5lle89uD3yFx8UvEalr2zGd+B2oN4k2K1 ZeVT9zeo/X2HFv58jR4O8VUYtio6wi9ndDsn7aZzhRJny79xF+jUr2iGeV5l K0oVCXQMpTM1OpNpx9U7qlrdBYUBf13n0WtngqW8k7+TeI7oai0Ms+d1etJ/ XroDfU80jYeSaZwsGOuhYHobwTT2yqXBnB5GIvLRaAeXtJ+75cEHG23OV36l yXrp3vi9yZkPJ2eePDlT1j71dyfX30zO3Ds5U8rmFNpsZwdNB95fsiC3M9VD YylWkIyoALqLA1XkP/FmAe234wP+tg1LrwNIKC/FrN8LmT3mJ0IcQ1EkDGWg 1pQOJhYdRodu8C3PnUca3zm8cxIlwtK/jrD0E4SlnyYs7RCS/cJq5cLSDgtL OygsjPIoynw1pxkmTLyWJRx5QsXPKGxYohc2luPELqYDWr4U2uFVyh8Z9wlz z+HTImQR7f4pwwm9NyEeak4W+e4tLkNk0QmgxoWKWQ0GMp/tqC+CaYJpnB1G a7SQeQqV3hlmxW0sdBZe/BKzP8uRky8T2XHPZOntq3G/eNVTX1lx3fcmdcRQ XxkxRj803TWZHJ3iwKErgwJmSm8E8meOF7MCY51j2pw4ais1Hj5hFpMfiGhf XGAXQsF0dOutFGbsK8tewwVl65QNJtJgtGqy7QPAKwPSLKDjSnRohLkaKVh5 jkeFXEhvKVCINkKir337YdAfdJ9DamGsTfKdErn0zeP9YKTsCUbKaW6Jvye9 73O7d8FI2R+MFOnth+shT9WJNp8R8ETittUsbuTHtoZcAIAqhkHGbAF8xHn0 XZu9aGx2NK3TULFGYCdIG7nOBSEwAbNd7jgpzukVpiA/1hh06V99Ovfbf5Y4 UXr/9y1pkAYdOv+tmjrW7+rm/LfSMJ8pqqrryvfz3/8XHzqcjWFS0zsG/hlA pzL9OYVALAX8cOagKRqy+pNqdtjhH3SVsnQYiHuoDix2QMknzICfRYQXUKcj d/XFMplx30u1ZjlKjBcR+m3m9emsW33MahUZi8waO7eu1dTawhTAdMW3DTTT NBWc5nIS+gnfbz2GWITHcY5sSUeHi43tncP1mgiat2ERCQru8p2O2maznD1O 2KZv7u1lEJn6w+P+fHZQmYfxMnmZWhMrnVuyb03kzKfDV2GwcNdyGM/29AJo +Tkk9UgvgFprUS+ACjeZC2M3QrlTMwB6csWEXwpPXs56WbdAOYZH9xM8GrVI x8GjkYv0JDwWuUDXwuNQC/Y1PB65SOfD47AL9kaUIz/YPVEOeqi/ohzyQRND OUjJEX4BBCKH/O9W6NAhfwHf8KANoBxGrFFAyKk+qZdAJPI9aCUoB3pcs4GA Hu20IzT1++0I5RhEGhbKsRxpaRCZxBObHkQW7UltEeUEthsnmu1DjRPNtvag ccI0te3GCVNTRRonBJbka7ZWCCRbQs0SAniOtFMILINAw4WA6J7czyBK43jH g4heizcuPA7bsdYGwVkKtTmU4zqlEeIE8zjYKiEakkubKcoRfbN2i3LShxoy WopRHPwRKJHKWzYEYuRj2zYEUR9p7CjHsL+LR1RFDrWM6EpbGMe+phJR2LK2 E+Hss6wxRXSVj7aunMLNo5s9nkhErB3kiUTEGkaeSESspUR0M+OEppNylHva Uk4E2tO4IqCiR1tbTvI2e5tfBDF8vfaYcoICLSnlSI42rQiUAY9vaylHjnKk 0xXodQ067qKrcO3Z5HrgdRjac6jEM/p+aaXBVLYTLw5lKzsBMSWon8OIgkrC jz2cWkk+aMYRsGuRfhlBbRPpqClHVd5zI47jWFeOwKS+Tt9OOSHxzp4TcR3r /RGpx07oDmodaw8qpyXczyOGSqjV59+Vq6MtdieCH2rCOxHNvja9E1Hca+Qr h/46nVpPr0xErHIw6hQu8OEmFfJHx7ORq8xeuGRDqtZ6w+KSAOpH9HK1adOo baoNTTz6PaXbSwj7o/vBxJLXhy1fAg7weFOYaNZ8oG1MWMOFGstOwLZpPcMY UdJ69vtl/ffL2u+X//j98vv19+vv1/+Sa9ENyVP79gQitECXMvUuJRa9ma2z 5FPEFwl3DArswlqRNfF8em9wNR6e+KqgvCFR4PXXY1sWBcT/FZsaBdTnxLZH wbLwtMZIcTb3tE6KAxfNlULdleJon9x/KXCS4ekdmsJEntLDKbBjVNLHKYLh eKenkIWV9oKK8PGoflAh9ko7RgUFfbhbUxDBV+w6FaR4qONTQH/ZkQ+UXp1u K3X0gUo9teKZiz/8LEDriVSINIh0iMRW+GjDqyCCr9gSK0jxm4hQ3RHh3yBq QNSEyISI+mwFDpP+b3vv3t7GkaR7zt/9Kep4zllL0yJZV9zOuJ+RJdnW2rI1 kuzuXR8PnyJQEDEiATQASvLs5bNvZlYBBMDKiDcyE6LaC7ZbgsDKN/J+q8xf yK6+Ae91Ha6+Aas319u8YIzp+728hvWSL9hh1b1Sknbc7wHjsyPypjA8EaWu ru7PQ6F3soIrysAe31IfY7qel39Xc5mb4eVyqOaw09tJ5exmpVIBvwhDr2UC L7Rk9yeBY4vADUv/16N372CCU07+lqZb5DZTNcd7nLxVj5ue/m+K71zsdMju 1qufnrntdDmUtwld5/eW0Rf+gW5SfJUVWT+KL7s6FHjrdVjPAne6MAuUVPsN V90jvlGjyXR2pcYVjYt/Ph2eRr+86aUf9U99jVSXUHKabN8kdbYou5jrbMZ+ dReYIdgv9woD37nR6l05HC4Iu+Vh5l45ogf/nCLzI9/rvWhhtF4AFga+c0XY OVdll62dzdivY2Mpt1zYFgZ2aADN1G/rdL6phx9MRp18f/b9myTLPp59/0L9 td4Ik8g+/vZlVM6rhTngO1nqF44vjLuHUXNbA5lUCtE72KxyONer6jO9U6Zl 9ueWaoGTRg9elKpapI/MWRykkVXLJOsmg81VNzWPzlJzPcHcXOsN0nR9kw28 vNasR14+iV7Pq/IdNBhIL9QH2L7e7/i6WyIqyPWHhb6iM5mOZ4PotVop62Pb 5oCrvooR6dNNeodVY3+MF4RZ9Pz1Tye9XtE/uY1eMigyffXvVvlqPvo1SYuk +9vmjulWrTfPp4VLcmJAhLi2r5eI6wVenKXjXi9+cDV7CIhy9/13FLLelsJb /SZ7VHtgOkmyOE4ebhEKHtze3OydJg8fRfPJKDJPqV5fWftSB/tSKv+qUsX3 vrodJr74eH010O99PizUunlwpp8+OzVhv9ClWkb6F+ad/u7h5uaKr5ofzmfL iflqpwyKQZxxsXn2cbJz9MsES1JrsE6cp3we6adseYTIf8o8yrpcbFryqDeI C2uwXl50+TzST9nyCJG355F+fzg4q1bDMxOw/vNU/fZU370zp4maTNNPn+jH hbnmF78AZZh8itwaVePy5mq1lGdWuhc9exVrotdaxdLcGqwf50BXpZ+yVzFe /n6rmE/8wlexw+RWsCqWdrjotVaxLLEHS/IYqGLqKXsV4+Xvt4r5xC98FTtM bgWrYpl9MtFEr7WK5anDZLLY1ujv1u55qWew/azo385gowepBmQ8RIM9+fnl 6w2Fc73R9iBR9XqjkA7SvYn9yUn04vGr79XfWw/lylLcdjzx2+fR3755Xb/h evzkB7WUWK6v0Jar1WJycbPSGxaqPK70WkffeFu8rZojg821v0eatqQPidw9 rc1b/nd9SSN6UU7Lt9W1BjhuIK2AiBYw7+vMIf/bF3Yab4nEYd1raJ0NC0y/ tNlIDWoI8AM1568/PgR0n01HzqpqHaQKtKALNDOlzj6UMw/19KsAzpx5iDNn HspUZdzOjuXlzWo0+zD9Nc2zbk/VZ/1F7RdPfWvejG3uI+qbK7tSWdsi6vv6 lNfV7O1b09vr2+QPVe8/074XT0UC0ais9As6vYadTA2RghKo6l5Dl6PeXyqv Nucm1OPq2Xx3GcORkloDbV5uO5GSSEmWlLSfmNZ3ig0kKVXrMgSSVOzHrPWE NMtHgmS8+Eh0qkXukLPT7LTYwI6Sgfm3Wsg2vKON72Nl0Lg/3vJ9zEcF4h2R Cn68IxdpmHfkIg7zjhzEUd6RWFrCO3ISh3lHYnUJ74gUp3lHZFCSd0SGbOcd kUEQ3hEtEMapMdA3tPOOyDDNaIjxjpihYejLOyL1bbwjMpAH74iuRzu8I7W0 bOMdkQow74hU4XhHTCJC8I6YQvPnHZEGtnhHSZykNt5Rt3+Hd5T3dh1FF32Y d0QXSXDeEW3Ozdl02uZsuugjCRQQlmgdjrBEFzxKWKJzLwxhCbABEJaYliQk LInVWMISqUiAafjcwclMpJaYzIQ1ZJrMBEweMDITKXRYMhNp2kZm6uxdsKIX ZyCZCchNm7ttYDbgRXbipTmyE5A4yqk3qmElNAFhIUITMl+GCE2AEOw5HCoj F9/iLsK893FJRvrBpdyNCOBS7kYEcCl3IwK4FLATJIVLkZI2uBQeyAaXouss D5dCOzw7XIpXCAyX4g22emcHtkLa/bcjAWkP74gC4AOel0HRWqQIj9aiV5ye aC3BBkE7xooU4JE4eHASiYPLWJE4uEQbEofuSGGaF9/aYJoXnR6M5gVpsDQv OlEBaV6kISHNC9diaV7M2l9A82JhXmysyyttSIrQEsniOC1SVo8knaARNefP g8YxIOvKa62H1FmEGdLqZhQZzJ+/rL1CEVuf3huTDkStnj7OnfeKrmDQ8yZq cep+RC027otqOpMNT3WKh7JA9UT1uZqnvr5UndLwZmW2WcFlhQX7RfeUAPYL WM9Q2C+ksePYL0xtg/3qdDtH7Nfx8/HzZ/IZ3dV2wntB+8MYhstvlxjp6r1I WvSkJDRJiy4pF5IWvyRzIGlB0bSRtKDAcpIWJBuGpMXszoQhaSFGvEla9AYR QtJiFACSFtfCMJIWEw93khYXPYykxWc0g4HiBUKTtHiLJAaKrr8mvDlMpP5I 9R+Z/gMrTB6axQuEhmbxFr1y68KI6Ny60Gws9VdRHxjXxCj9x4aRRSq5MLLo N+yujCx6qePKyIrK4WK2VB+akGAKAGYW37/UnUje8+ReQXMZnnuFbKZQ3KvW vRRk/HOgTNFvthwoU/RhUZQy5fWe1EKZ4qdjIGVKHLnNNMaHMkVa9aVMeb0y bqdMybLbTplyz213yhRpE6dM+chsKFN0pySmTGUBXt+3U6ZkBW6nTLkXuDtl ii6pdhiT4QTtZbm7mgNBysUMQ5Cih1qGIIUHbgfo+BS8K0FKnIdZ0IJ3Iye5 mGHISWzZUeQkPLBDwQfhaQFV087TwgO387TI8GJgKakmAZaSQu68KkwW5FXR 01MXXhX9QvpyPrycm6vI05F+rbmnuBlZ13TeW3lk+eyDw6JfCamJX6TvREVP zGukW3gwdCjhDvuqfQmCSDkhsfz2ofd78o6LyH59axO5mpEwKkABok61KmgC V95JO3cBXF7p3msUO/fnDfwg7+Q9GzKBDcURE2qBzu5l9nXUp+8no4nenKvv EV+pDnCquscvf/zl+dPnj7+MVqVa4C6bx0/3BNvygjvDu79sjAHNu8vGmJnX CiJXD+CJGsPvLmQe3y4b4/ZlIxL9H3959ULX6/o9cp2zzS7Cx15nfSHxRV0C kRriTnrdThqpb6bRi1I1m0Lj9uKORpi9fHr34nR3kLURGQ6cWIvVe0rsZsj7 pn7VPzVjn76bo4b4+dWknK7WY365NaVV2XAqUX/ZwBy0+C+pRbE+GZB/vHPg wlM9odV7g7zXon5Q3AlkmcOdkCI87qQO3mfQnX71glP3qxee6nS9KLLdoUOP cZ2iF7eOcXXL67ZExuwAz0vtaXFzd1p1KrOFAVGtbpZfxR+LJPq/6lmRmiqN fo9eV9U7PU++UrPb6Jl+OPp//EyZv7SlXFl6fGHeLzxpHvmhXK6+KVUNGb3W Y5h6Ki4ge+Yl99iEjGZzfVs2+lCqKf7N9N109mG6q1BYgXa9OMlYLJd+6C6V Cxa/HyhXgOiFY3IdNK+8kVx17LqDtA1Ic4g2JDfl14Ys9gRtqLvLKzts5khN +WZOqz08c9J0kLSNggfIHAdTXpljsyfKnKwNWXeYzJGa8s2cVnt45uwv7Fto ZWoiwD+UDxLkIW2OgaPlxhzzUGHMsQ8B5gpjrkM/1DHm2IfS7iDfRj4CZLMO Yr5rzHe5hzLkoYJ/qKdnnsV2WZJEt54eVql091rS3RskMeEsK2SzdDLl0Szt 9tBm2RukqoK37bvYlzVb5zLr4H1Z8HwreJ6oJDDTpB00qArVN7UgpWuWJngC D+XsQ0kMmFMPaXMZ95BqNzuTE7NL1u8V+1trtydR6ED8zpquIHzMEpNG9iEl VrTVlXq9d6LdCehbLblqjPHJZDZcXZkjXcVJnJwk6cPN9aalvt40uj4Z6S2c f1tUo8tydaqaxbapnIDGdu0LmUSZblYyXctKBlS/r5WMd/RCrmQOmFcBVjKB Yve+XJxdTS6aGI4MJNIjetmBo+car3wvXlbsd7e139WhCgIW3k07HaBRqqds jRJQv89G6RW90I3yQHkVqFEGiN0hG+UBohekURZUo6zj1dIoO4O4bw2VdXOg UaqnbI0SUL/PRukVvdCN8kB5FahRBojdIRvlAaIXpFF22vcTn09Vo7oyb+3f TcdLFdPhbP77YvL2Us3hnzyMkn6/E83eTRb/dj2blqPT5YcLlVMPTwHpH795 /XR9P3qTJmXj7H2+IdeXNbJSPfo+N6vV6pZqP5oszIWK32Fbm/6hH5/UNw+i twt9YHSuORWjPR2rn6qmmO72UWm+t2xfQ+h7nW6XYtBfllerXZ2iLRW6AAY1 Hc7AQxf67r3ZS6hGcPCbafVxjVvUZ61uV61LQKN5b8xA8CEBCoLfCKBbJurx PN7dLeO3TFoCbW6v7ATFIfiNZNvi8VOT3ImogCR3QsGX5C6XFpDc5eICkrtY HCe5C6VlJHcHcQHJXaguI7kT4hzJnQjKkNyJkDaSOxEEI7lTAkFJ7lTfYCO5 E2GaLp0jub9/W37V7SdIX6m/8QW6E/p2oDsRyAvoTlWnHaC7mnW0A90JBQHQ nVDZB7qPbq6vN5SyHbA7mZgwYHey8EKA3QkD9wR2p4rmAGB3ypwD2L3QBNI7 YPekX3SQBIrA7pQOD3anCh4Hu1O5FwrsztqAwO5kSxKD3YVqANidUCTB7lzu SMDuhJYD2B1pyBzYnZ1LoGB3QujQYHfCNA52J0RwsDubmwzYnZoVeILdOWke 7M4mDgC7sxoE2J0NC4Ld+ekzCHZnhaRgd7qMPMDuImEY7A5lpC/Y3dWICOzu akQEdnc1IgK7sxtDcrA7IWkHu6OB7GB3qs4iYHesw6PA7pxCcLA7Z5ACu1M7 IyTYnQwIgd1JBRzsTsjgYHdCBAG7UytOb7A7vFFgA7sTAgjYHQ3OgN1RGQLs jkq0g92pjlQAdudamwDsTqUHBbsDGgDYnUpUULA7YUgMdke1ALA7ufYPC3Zn Yu0KdhfISqDphKwj2J1RdAC7E4pBwe4eaz2kzvqD3amRIhTYnbAREuzOmPEE u9PqvmB3Ju4WsDub4jawO7vrbgW7M8sKK9id6ikhsDu7nqHB7nxjl4DdEbUj 2P34+fj5M/yM7mo7gt2B/WEU7O6zS4x09Z5gd2pSEh7sTpWUG9idW5I5gd2B aNrB7kBgF7A7IBsK7E7uzoQCu/NGAoDdqQ0iDOxOKkBgd7qFoWB3Mh4+YHc6 eijYnctoFlXOCYQHu3MWGVQ5VX85sDtXqfxy6yBgd86iV25JwO6EkhvYnXrD 7g52p5Y6ocHuTAogsDu1GgKYhkTwb6tptVAr2FdvnmwFjbtoz1Z3X5k/Uh6Y RSFIeX4bxx0pT2gf4IYv/dpPSK+nXt850eupA7I4vd7jZbCVXs/NOWF6vTBy m7maH72esOpPr/d4L26j10uym6LXu+a2D72esCmh17vLbNHrqf7PnV7vcUbB Rq+XFDhFr3ctcB96PVVScnq9XM2JXi83w9LrqVGdpdejgW0Qc/eCd6fXC/OQ odfL1Zzo9XIzLL2eKTuaXo8Gdij4QPR6tmpS9Ho0sI1ez47cYtx3o+hH6iZE QFI3oQCSulsUNMU06ff6bRRTj3Tvje13mduaFU/ghOhQAE/orsDtmSDvG9E2 6UPciKZtoTeiU9M5bbeJFnJSOkiRh/ZbV8tDGWIuQ8xld6pg60OFvm+89dDm 5nbejamL24tKXy7ZE2oDhUFXt7ngyNVtu8b39VsU7uo2IkBe3TYCO4Bt8uq2 ejzd5QEDV7fvBtrsT7le3bZLyq5u56onys1V7LiIuzqbVQ93VamB/OHmQrd+ Jjsxt7nTrdvc5ir3IE5bbnPbY4fe5rYreN/mFktLbnOLxSW3uaXigtvcMmnh bW65uOQ2t0xdeJvbLs7e5rYH5W5z20Nab3Pbg4C3uQmBsLe5ib7BepvbHqbp 5Znb3Ei3qb/xvsVt1yducdsD+d3iJqrRzi3uPI4st7jtCpJb3HaV/Vvcv3z7 +M97t7epRAS6vU0VWpDb23YDW7e3427Ssdze7naSO7e3zUNbt7eTXHJ7myiS Q9zeJsw53N7unKpJx53b22lcdJEEym5vEzrA7W2i4AW3t4ncC3Z7m7OB3d6m WpL89rZMDbm9bVekb28zuSO6vW3Xcrm9DTRk9vY2N3eAb2/bhQ5+e9tu2nZ7 u1/cOZdnFxHc3uZyk7u9TcwGfG9vM9LA7W0uccjtbU6Dur3NhUVvb7PTZfT2 Nickvr1NlpHP7W2JMH57G8lI79vbjkZkt7cdjchubzsakd3e5vaGHG5v2yWJ 29tgIOL2NlFnodvbUIdH3t5mFMLf3mYMkre3iZ0Q+vY2FRC7vU0pCG5v22UE t7ftItDtbWLF6X97G90gsN7etgtAt7fB4NztbVCGur0NSlhubxMdqeT2NtPa JLe3ifTAt7d5DeT2NpGosLe37Ybkt7dBLeT2NrX2D3x7m4618+1tXFZ0M9ou 63p7m1Z0ub1tVwx7e9t9rYfU2QC3t4mRItjtbbuNoLe3aTO+t7dJde/b23Tc bbe3uRS33t7mdtvtt7fpZYX99jbRU2K3t7n1DHN7m23sotvbgNrm9na/ON7e Pn4+fv4H/oxuhLte+Oa3lOEL3x4by8jo4Hvhm5jHHODCN1FSjhe+mVWc24Vv PprEhW8+sNOFb1422IVvakMn2IVv1kiIC9/EnhJ44ZtSwC58ky0MvvBNxcPr wjcZPfjCN5PR/BVmRuAAF74Zi9wVZqL+she+mUrll1uHufDNWPTKLdGFb+JA rduFb+KlvMeFb2J1FPzCN50C7MI3sYBCLnzbg7MXvpmeLdyFb34WBV34Znd+ PC5827WDX/jm3hRKL3wTb/zcLnwTZ2gFF77d3x/bL3wzc078wrcscpu5mueF b7vVABe+3V+lWy98C7KbvPDtmNteF77tNkUXvp1lti98E/2fx4Vv92MN1gvf ggInL3w7FrjXhW+ipBwufIvV3C58i83wF76JUZ2/8A0Gtt77dS54jwvfsjzk LnyL1dwufIvN8Be+6bJjLnyDgR0KPtSFb65qkhe+wcDWC9/cyC2/8F0r9loU BRe+7SLohW+7Anrh+65Cc+G723rh2z3dO2N7NkjTLY311e2UuPBNhwIufNcC B3GBbZcOf+Gbs4Ve+FY6+SBvu7o/fT8ZTfTm00wfJ1KNY6iqXRV9+eMvz58+ f/xltCrV2mbZPH4KCHLHWvdXDDGgeXfFEDNTGkHk6r47Ud333Tns49sVQ9y+ YkCi/+Mvr17oZl6/Wq1ztllAfux11lf0XtQlEKne7aTX7aSR+mYavShVL1Jo 9bij2+LLp3evEncGRfLpE2uxeujE9ge5DFITJLEWqwdNbK5nFNmnrsZ2q4dO bDLIt8eaW2hD2kspasNlebXa1SnavMBDzAYuOMJssGs0WcQxGxABktlQC2xX WJLZ0Bvk2SDbZkQAzIa7gTZbzK7MBrvk58BssMcOZTbYFbyZDWJpCbNBLC5h NkjFBcwGmbSQ2SAXlzAbZOpCZoNdnGU22INyzAZ7SCuzwR4EZDYQAmGZDUTf YGU22MM0vTzKbCC6Tf2NN7PBrk8wG+yB/JgNRDXaYTZ0i8jCbLArSJgNdhWA 2UAlIhCzgSq0IMwGu4H7YjYQRXIIZgNhzoHZUJz2+3eZDUm/lyEJlDEbCB2A 2UAUvIDZQOReMGYDZwNjNlAtSc5skKkhzAa7Is1sYHJHxGywa7kwG4CGzDIb uLkDzGywCx2c2WA3LWA22EUEzAYuNzlmAzEb8GU2MNIAs4FLHMJs4DQoZgMX FmU2sNNllNnACYmZDWQZ+TAbJMI4swHJSG9mg6MRGbPB0YiM2eBoRMZs4PaG HJgNdkmC2QAGIpgNRJ2FmA1Qh0cyGxiF8MwGxiDJbCB2QmhmAxUQYzZQCgJm g11GwGywi0DMBmLF6c9sQDcIrMwGuwDEbACDc8wGUIZiNoASFmYD0ZFKmA1M a5MwG4j0wMwGXgNhNhCJCstssBuSMxtALYTZQK39AzMb6Fg7MxtwWREPwS7r ymygFV2YDXbFsMwG97UeUmcDMBuIkSIYs8FuIyizgTbjy2wg1b2ZDXTcbcwG LsWtzAZut93ObKCXFXZmA9FTYswGbj3DMBvYxi5iNgBqR2bD8fPx8x/jM7oR 7sps4LeUYWaDx8YyMjr4MhuIecwBmA1ESTkyG5hVnBuzgY8mwWzgAzsxG3jZ YMwGakMnGLOBNRKC2UDsKYHMBkoBYzaQLQxmNlDx8GI2kNGDmQ1MRvMUAkbg AMwGxiJHISDqL8tsYCqVX24dhtnAWPTKLRGzgThQ68ZsIF7KezAbiNVRcGYD nQKM2UAsoBBmgz04y2xgerZwzAZ+FgUxG9idHw9mg107OLOBe1MoZTYQb/zc mA3EGVoBs8H9/bGd2cDMOXFmgyxym7maJ7PBbjUAs8H9VbqV2SDIbpLZ4Jjb XswGu00Rs8FZZpvZQPR/HswG92MNVmaDoMBJZoNjgXsxG4iScmA2iNXcmA1i MzyzgRjVeWYDGNh6dd+54D2YDbI85JgNYjU3ZoPYDM9soMuOYTaAgR0KPhSz gauaJLMBDGxlNnAjt5zZYBTzVlfpOLPBLoIyG+wKKLPhrkLDbOi3Mhvc070z tue7DtTX9IWcYDbQoQBmQy3Qds3am9lglw7PbOBsocyGWqetTTgyG+yC7swG u6aQ2SCLXN13+192t1s96GX33qAo2hvptSrL5jTTtVlXN124vgs4q2+962vn +rFdtWIbEvJWnwkY1RekT7K03324Ve0e3F6jTtRa++GjaD4ZRfopNVCo7uhL HepLofqrajm7el/dDixffLy+GqzfPw3OqtXwzISr/zxVvz3VlxvNYbwv9EuK 0rytOtGP7x3Xb+6Oq8o3ny0n5qs4WPQ+LCaranCmHz47NUGb2OhfmKMbbGSS T5BXo2pc3lytlvKsSgPHbt1H1jEcmdv0HtHLDhw913jle/Hq32cN26nuHT6T Xj//9ruf9UGeYTUxNykX1bon072H3tXVs9ylUPY+G7lX9EI38gPlVaBGHiB2 h2zkB4hekEYOxOtbtaAdr+kxk6V53z2Z6mHz0S6e5lQo/KzGs2xC9fXMIW3D K73+9nn0t29e169pHj/5QS2FluvLv+VKzasublbVUrf48krfN9Z35hZvq+Zc WXPx8JGKeaTPMNw9/Mtb/nd9y0DNcabl2+q6mq7UrL65H7cnkraIaAHz0skc Gb9966Tfim0FT/dWgycn0YvHr75Xf289lPV3GTcbYFCWF10KGLSo9I3mLaVc TybbJtoIMogLjiCD7BrNRJNDBiECJDKoFtguMhIZpB5Xs+/tIgKQQXcDbd5w uiKD7JKfAzLIHjsUGWRX8EYGiaUlyCCxuAQZJBUXIINk0kJkkFxcggySqQuR QXZxFhlkD8ohg+whrcggexAQGUQIhEUGEX2DFRlkD9P08gwyKHr/tvyq20+Q 7lN/440OsusT6CB7ID90EFGddtBBaS+yoIPsChJ0kF1lHx00urm+3tyH20UI UYkJhBCiCi8IQshu4L4QQkTRHAIhRJhzQAh1TuPOXYRQmqQFkkAZQojQARBC RMELEEJE7gVDCHE2MIQQ1ZLkCCGZGoIQsivSCCEmd0QIIbuWC0IIaMgsQoib S8AIIbvQwRFCdtMChJBdRIAQ4nKTQwgRswJfhBAjDSCEuMQhCCFOg0IIcWFR hBA7fUYRQpyQGCFElpEPQkgijCOEkIz0Rgg5GpEhhByNyBBCjkZkCCFur8gB IWSXJBBCYCACIUTUWQghBHV4JEKIUQiPEGIMkgghYmeERghRATGEEKUgQAjZ ZQQIIbsIhBAiVpz+CCF0o8CKELILQAghMDiHEAJlKIQQKGFBCBEdqQQhxLQ2 CUKISA+MEOI1EIQQkaiwCCG7ITlCCNRCEELU2j8wQoiOtTNCCJcV4Xnssq4I IVrRBSFkVwyLEHJf6yF1NgBCiBgpgiGE7DaCIoRoM74IIVLdGyFEx92GEOJS 3IoQ4nbd7QghellhRwgRPSWGEOLWMwxCiG3sIoQQoHZECB0/Hz//MT6jG+Gu CCF+SxlGCHlsLCOjgy9CiJjHHAAhRJSUI0KIWcW5IYT4aBIIIT6wE0KIlw2G EKI2dIIhhFgjIRBCxJ4SiBCiFDCEENnCYIQQFQ8vhBAZPRghxGQ0D8VhBA6A EGIsclAcov6yCCGmUvnl1mEQQoxFr9wSIYSIA7ZuCCHipbwHQohYHQVHCNEp wBBCxAIKQQjZg7MIIaZnC4cQ4mdREEKI3fnxQAjZtYMjhLg3hVKEEPHGzw0h RJypFSCE3N8f2xFCzJwTRwjJIreZq3kihOxWAyCE3F+lWxFCguwmEUKOue2F ELLbFCGEnGW2EUJE/+eBEHI/1mBFCAkKnEQIORa4F0KIKCkHhJBYzQ0hJDbD I4SIUZ1HCIGBrSQZ54L3QAjJ8pBDCInV3BBCYjM8QoguOwYhBAZ2KPhQCCGu apIIITCwFSHEjdxyhJBRTDwRQnYRFCFkV0ARQrXC9uXQGiHUzVsRQncfR9O9 N7bv3M41MKBdbNEdhBAdCkAI3RW4PUbkiRCyS4dHCHG2UIRQrdPWJhwRQnZB d4SQXVOIEJJFru67E2+EkN3qQRFCfUNM27n+Dl3A3gu02R/yuIBtkfxMLmBb Yie4gG1RCHEBWyYtvIAtExdewBaJyy5gC6TlF7CF4sIL2AJ1+QVsizhyAdsS FLiAbQlJXcC2BMEvYNsEgl/AtvUN1AVsS5imN2cuYCPdpv4mxMVriz598doS yPvita0a7Vy87mSR/eK1RUF48dqisn/x+pdvH//57oVrayLCXbi2FlqoC9cW A/d44dpWJAe6cG0z53Dhujjt9+5euFbrqi6SQPGFa5sOduHaVvCyC9e23At5 4Zq0AV+4trYkpwvXAjXwwrVFkb1wTeWO9MK1RcvxwjXXkJEL1+TcQXLh2iL0 KS5cW0zLLlxbRGQXrsncBC5c22YDAS5cU9LYhWsyceCFa1KDuXBNhhVcuKan y4IL16SQy4Vrexl5XriGhUUXrtmMDHHh2sWI+MK1ixHxhWsXI+IL1+TekNuF a4skfeEaCURfuLbVWfTCNd/hcReuKYWDXLimDHIXrm07IeyFa2tA+MK1VUF2 4doiI7twbRFBL1zbVpxBLlxDGwTUhWuLAHrhGgkOXLhGZJgL14iE/cK1rSMV XrimWpvwwrUtPZIL14wGeOHalqjgF64thpwuXCNa4IVr69o//IVrItY+F65B WellZousx4VrQtHxwrVFMfiFa8e1HlJnw1y4to0UIS9cW2yEvnBNmAlw4dqu HuLCNRF34sI1mWLbhWtyt528cE0sK8gL17aeEr5wTa5n+AvXdGOXXrjm1I4X ro+fj5//GJ/RjXCPC9fMlrLkwrXrxjIyOgS4cG2bxxzmwrWtpNwvXFOrOOcL 10w06QvXTGDXC9eMbMgL19YNnZAXrmkjgS5c2/aU8AvXVgX4wrW9hUkuXFvj 4Xvh2h49yYVrKqOhK8SUwGEuXFMWgSvEtvqLXLimKpVfbh3swjVl0Su3pBeu be/Q1/ejn//4zU+D28PeOisni/pQwHqo3xr/kVF/I23c2kXlUL/krzvsi2pz 6GB0YzaK1oahQ8DOl8S5mG6SP5xdz6+qFTRf8rxiblsPHuKKOZEC+Iq5bckI XjG3BEeumFN9edAr5sy8Eb1iTu91+V0xt2gf4oo5+W7U4Yq57R2n8xVzi6Dw irnjG3Pyijk1yxZdMRdEbjM79b9ibrEa5oq54+EB6oo5mt3cFXOX3Pa9Ym6x Kb1i7iazd8Xc1v/5XTF3PMhBXTFHC5y7Yu5S4L5XzG0l5XbFXKbmfMVcZga6 Ym4b1aEr5khg6qaxW8H7XTEX5CFwxVym5nzFXGYGumJOlB1/xRwJ7FDwAa+Y k1WTu2KOBKaumJMjt9MVc6XYcdmP3S/yNhHBFXOLguCK+Z4Cd8XcMd07Y3s+ SLfvxYNXzIlQ2BXzvN1Bdogr5hbpg1wxJ20JrpgrnbxFx/2KuRJ0OchLXjG3 aMqvmAsiV/fdQa6YW6we+Ip5oRpp1mL2WpVlc37r2qyrmy5c336c1a7Wtadz /diuWrFd4Tb+2tNu0hf5a9dKvbYqh/lrp4Nj/tptGk2W8/7aeQHGX7sW2MYO MP7ai2KQbJclhAvYD7TZKXTHBdgkPw9cgC12OC7AphAAFyCUluEChOIyXIBM XIQLkEiLcQFScRkuQKIuxgXYxAFcgC0ojwuwhSRwAbYgMC7AKhAaF2DtGwhc gC1M08vL/bVbu0/9TQBsgE2fxAbYAvliA6zVaQcb0C0iKzbApiDDBthURP7a 7YkJhg+wF14gfIDNwP3hA6xFcxh8gNWcm7/2tMVfe1x0kQRK8QFWHQgfYC14 ET7AmnsB8QG0DRQfYG9JLvgAiRqGD7ApcvgAMneE+ACblhs+gG3IAD6AnksI 8AE2oU+AD7CZFuEDbCIifACdmzw+wDor8McHkNIQPoBOHIYPoDVofAAdFscH MNNnHB9ACzngA4gy8sMH4MISfACfkQHwAU5GpPgAJyNSfICTESk+gN4rcsIH 2CRJfAAUiMQHWOssiA8AOjwGH0AqHAIfQBpk8AHWnREOH2APiOID7AoifIBN RoQPsImA+ADrijMEPgDbKCDwATYBEB8ABefxAZAMjQ+AJKz4AGtHKsMHkK1N hg+wpkeAD+A0MHyANVGh8QE2Qy74AEgLwwfY1/7B8QFUrD3wAais8Gq+TdYd H0ApuuEDbIqh8QGuaz2kzgbBB1hHioD4AJuNwPgAyow/PoBQD4APoOJuxwfQ KbbgA+hddwofQC0rKHyAtadE8QH0eobFBzCNXYgPYNWO+IDj5+PnP8ZndCPc HR/AbSkL8AHOG8vI6OCPD7DOYw6CD7CWlDM+gFzFueIDuGiS+AAusCM+gJMN iA+wb+gExAcwRsLgA6x7SjA+wK6A4gOIFibAB9jj4YkPIKInwAeQGY1ciCcF DoIPIC3yF+Kt9RfAB5CVyi+3DoUPIC165ZYQH2A9YOt6Fd/6Ut7rMr11dXSA y/RUCtDL9NYFFHaZ3hYcuExP9mwhL9NzsyjwMr31IInbEX/Hl6jU1Q1yTiS5 uiGJXD2XCHF1w2a1vh4zVv3F9Bf9qcngs/VsLImfPouzFKmWt1JPVM1UuaAa w+wtvJu+GzxZB9czO7nEs6fPnzZbG2Y++vXPr5HJ2G4cIpWG+bwq9SG9WXRp Tg/pX6j6sdINQhaletdJB9cnqYy8KPyLN69e6Yqm4/LTj6KgulI1xfvjL1mq sqS8VuuI8Vg1yQed/MXX0b+pKcnT5j0i0rwPAKJgNn+9eBr0G3w55ML6Jt4V cmETlEEuXM91UJALvN9jIBfyfi8E5MJmNQjkwvWICwG5gLObgVw45bYn5MJm Uwi5cJTZhVxY5yVekAvX40YE5AIucAZy4VTgnpALa0k5QS6Eaq6QC6EZBHJh nW0jkAsoMME6cCx4L8iFJA95yIVQzRVyITSDQC6osmMhF1Bgh4IPB7mgqyYD uYACE5ALeuR2gVxoxW1EQM2GyFMLG2L/8dujZd6ABZv0IQALtC0csKB1nJDN +w2mTQRHhNgUcERI0VH/WddLDqQIm2CNRXijC6tGItRvIprbV9EHVZJ6dTvU S4T6vU/SNNAHy4cSA5OluVU5Gw5vFtGHy2qqj9HWE5jljVorKUM6S8cXjzaL wmiGZEltQIddvTfx1YyHqu4wZhc6Q/TFoA9TNZu6nMz1UaHVJrWwvEuSVV2/ ma6BE9pmS/rW8V6/UDTFCpt4oNJ4pkWqzTEXfX11sZbTu5WqIBvDZ2u7sH6z ofvwkY7+1Bxw3k5PU2N24q4WqirH8Vz6cbaWaY6+LlUvX871TRBTE0f/bVuq O0gOW4kZA/6VmDTgX4lJeZckB6nEpIkAlZjUD1OJSRPSStzuViBgJSYNhKjE hIEQlZiQd0lyoEpMmAhSiQn9UJWYMCGrxL1BEh+0EjMG/CsxacC/EpPyLkkO UolJEwEqMakfphKTJsSVuHXVEbISUwaCVGK7gSCV2C7vkuRQldhuIkwltusH q8R2E9JKvNOp36Liko4QFdcb5GnbmhNExZHBQVScReP7OjsBVBwrwKHilMD2 jg6HiusP8u527kOouL1Am5MsHqg4i+RngoqzxE6AirMohEDFyaSFqDiZuBAV JxKXoeIE0nJUnFBciIoTqMtRcRZxBBVnCQqg4lTINv4lhYqzBMFRcTaB4Kg4 iyESFWcJ0/TyDCoOEPpBfxMCEWfRpxFxlkDeiDhbNdpBxOVxZEfEWRSEiDiL yj4i7pdvH//5LhrOmohwaDhroYVCw1kM3CMazlYkB0LD2cw5oOGK037/Lhou 6fdzJIFiNJxNB0PD2Qpehoaz5V5INBxpA0bDWVuSExpOoAai4SyKLBqOyh0p Gs6i5YiG4xoygoYj5w4SNJxF6FOg4SymZWg4i4gMDUfmJoCGs80GAqDhKGkM DUcmDkTDkRoMGo4MK0DD0dNlARqOFHJBw9nLyBMNBwuL0HBsRoZAw7kYEaPh XIyI0XAuRsRoONsixwMNZ5Gk0XBIIBoNZ6uzKBqO7/A4NBylcBA0HGWQQ8NZ wvJoOGtAGA1nVZCh4SwyMjScRQRFw9lWnEHQcNAGAYWGswigaDgkOICGQ2QY NBwiYUfD2TpSIRqOam1CNJwtPRI0HKMBouFsiQqOhrMYckLDIVogGs669g+P hiNi7YOGA2Wl2DWLrAcajlB0RMNZFIOj4RzXekidDYOGs40UIdFwFhuh0XCE mQBoOLt6CDQcEXcCDUem2IaGI3fbSTQcsawg0XC2nhJGw5HrGR4NRzd2KRqO Uzui4Y6fj5//GJ/RjXAPNByzpSxBw7luLCOjQwA0nG0ecxg0nK2k3NFw1CrO GQ3HRJNGwzGBXdFwjGxINJx1QyckGo42EggNZ9tTwtFwVgUYDWdvYRI0nDUe vmg4e/QkaDgqoyHYGSVwGDQcZRGAndnqL4KGoyqVX24dDA1HWfTKLSkazqLk joazvZT3Q8PZVkeHQMMRKYDRcLYFFIiGswRH0HBUzxYUDcfMolA0nO0giRsa zvElKomGo+ZEIjScIHL1XCIIGs5i1QUNx0rRaDgoOI2GYyU4NBwUBxEajlVk 0HBseDsajg3qgYazaB8CDUdv/vqh4cg3+A5oONubeGc0nEVQiIZzPNdBouHg fo9Dw4n7vSBoOIvVMGg4xyMuFBoOzW4ODeeS275oOItNKRrOTWYPDWebl/ih 4RyPG1FoOLTAOTScS4H7ouFsJeWGhpOpOaPhZGYgNJxttg2h4ZDAFCHMreD9 0HCCPATQcDI1ZzSczAyEhiPKjkfDIYEdCj4gGo6smhwaDglMoeHIkdsJDben yKHhrEfL/NFwtvcXh0DDkbYEaDil03d557LfYNpEBGg4iwKIhktNC09b79k7 oeEIwTAYDMCAHwaDNeCHwWDlXZLsjcFgTXhiMFh9fwwGawLHYNRSWXLgSkwa CFGJCQMhKjEh75LkQJWYMBGkEhP6oSoxYUJaiYu29nA7F769xKSrajMd2t5m 3ezS7Mm2kQcOuGVLWK3zZZ3PTebUO1kfe531Hf4XdW5Happ10ut20kh9M41e lGpALgxspDPIetHLp7usEW02G6RtfKjX3z6P/vbN6/o1zeMnP6gp13J9+bdc qSXpxc2qUl8uqvJK3zfWd+YWb6vmXFlz8VDV7VmkzzDcOfwLWP53fctAJWFa vq2uq+lKVb+L+t0RIKIFzEsnc2T89q2Tfiu2HTxvny3Zg9++hKyDt1ZAIni6 Hbw7yNsoiWBwNT3aIWScnEQvHr/6Xv299VDWU2a2Hnqru4ZRzbQ5SdO083Br VvjglnyT5KexaujzySjST6k1hGqCX+pQXwrVX1XL2dX76nbN8cXH66vB+sjQ 4KxaDc9MuPrPU/XbU82jMPcnvtD736U5YHSiH9+7YdngfsqVvhA0MV/FwaL3 QVX2anCmHz47NUGb2OhfmNO2bGSST5BXo2pc3lytlvKsSgPHbr2EqWM4MgAk j+hlB46ea7y2e4D95VZLG0x0J5Vxkf/2ifpuDQyb1LOsyVQ3u0e7TLJTofCz msi1HarYZXbt7SScuu4lZNs21HjTtm5rAFuTUTVT87+5oRdsXsQMzIvtGJCZ z1V0BqZTOlnOzQJ2993L7iqQEYr1iTK9oTQbTsxlA63x37ZCJ8nuKnQ3n/tZ DnSi6qnWThRTv7dO1Dd6QTvRw+VViE40TOwO1okeJnr+naiKV6HmMky8nPpH RPhu/5ghffr+xlTLQ6mZobEPpXvd8U4ks6LT5zsX/VRr54Kp31vn4hu9oJ3L 4fIqROcSJnYH61wOEz3/zkXFq7Prc6YtXg6dCya837moUN32ydfVbDYfrPeq HugDrL31nbOHW8GzVC06BUtGLbtdxbN8kMXWSPfSLtDZqKcsnQ2ifo+djV/0 Anc2h8qrMJ1NiNgdsLM5RPRCdDZq6hBz8XLqbBDhu51N3tnlZu+G6hcx0NrV U5bWjqjfY2v3i17g1n6ovArT2kPE7oCt/RDRC9HaVbxS+wygjtfdRgmsHDK9 NZxak5x3MmCc1k+1tlxM/d5arm/0grbcw+VViJYbJnYHa7mHiZ5/y80GSczH y2GcxoT3u4TMbMy0vRM95BtHu1XmjWPzRduLx6Tbi6K/qqJ8Wg0NWE91kKrD S6KXtZODYtt62u708cBptlj9NGnWLwy2a8fG+UhR9FPc+YhWUpnRVnaI8xE2 OOB8hNB49fLJIBqXE31ARLVR1QBW5XBl9tSvy3n0QJXpdBadFA9PAbEmxxlP JpAA5cmkEdh+l0t5MtGP57uvXnhPJi2BNhcvHT2ZEJKfgScTInagJxNCwdeT iVxa4MlELi7wZCIWxz2ZCKVlnkwcxAWeTITqMk8mhDjnyYQIyngyIULaPJkQ QTBPJpRAUE8mVN9g82RChGl6edCTCdVt6m98PZkQ+nZPJkQgL08mVDXa8WSS 9qJ2TyaEgsCTCaHyhPVkQiYijCcTstBCeDIhDNyTJxOqSA7gyYQy5+bJpNfm yaTbRRIo8mRC6fCeTKiCxz2ZULkXypMJawPyZEK2JLEnE6Ea4MmEUCQ9mXC5 I/FkQmg5eDJBGjLnyYSdO6CeTAihQ3syIUzjnkwIEdyTCZubjCcTajbg6cmE k+Y9mbCJAzyZsBqEJxM2LOjJhJ8ug55MWCGpJxO6jDw8mYiEYU8mUEb6ejJx NSLyZOJqROTJxNWIyJMJuzck92RCSNo9maCB7J5MqDqLeDLBOjzKkwmnENyT CWeQ8mRC7YSQnkzIgJAnE1IB92RCyOCeTAgRxJMJteL09mQCbxDYPJkQAogn EzQ448kElSE8maAS7Z5MqI5U4MmEa20CTyZUelBPJoAG4MmESlRQTyaEIbEn E1QL8GRCrv3DejJhYu3qyUQgK/ESQsg6ejJhFB08mRCKQT2ZeKz1kDrr78mE GilCeTIhbIT0ZMKY8fRkQqv7ejJh4m7xZMKmuM2TCbvbbvVkwiwrrJ5MqJ4S 8mTCrmdoTyZ8Y5d4MkHUjp5Mjp+Pn/8Yn9GNcEdPJsCWMurJxGdjGRkdPD2Z UPOY8J5MqJJy82TCreKcPJkA0bR7MgECu3gyAWRDeTIhN3RCeTLhjQTwZELt KWGeTEgFyJMJ3cJQTyZkPHw8mdDRQz2ZcBnN+ubgBMJ7MuEsMr45qPrLeTLh KpVfbh3Ekwln0Su3JJ5MqAO1Tp5MqJfy7p5MqNVRaE8mTAogTybUAgrwZEIE 5zyZcD1bME8mwCwK8WRCHSSRezIh1KDL4ew2lLtPBUI7tGsIajPiwEg63jKA pLOLQFQ3p+DIaPJ6fUpX62wIwroqbqTMQJVHD/RlBE1XWncQSBV7Nh0dThyC +XGvu4VuP6jX1k5uPwhBgdsPj0MQVrcf3MIJdvshjNxmweHn9oOw6u/2w+M8 iM3thyS7Kbcfrrnt4/aDsClx++Eus+X2gxrE3d1+eJzNsbn9kBQ45fbDtcB9 3H5QJSV3+yFXc3L7ITfDuv2gpqas2w80sM37g3vBu7v9EOYh4/ZDrubk9kNu hnX7wZQd7fYDDexQ8IHcfrBVk3L7gQa2uf1gR26x249G8a7bj6Lb5vaj5fHb c1h+bj8I6eBuP1hboNuPRsfP7QchArr9IBRQtx+ZxtElbZw1R7cfdkFnL6OE pszLqDBydQcYAqZgs/ppYApZd5BsV/k9+HGOQHnVUxZEDqJ+j4gcv+gFRuQc Kq/CIHJCxO6AiJxDRC8EIiffc43QFq/Xz7/97md9/GlYTcz900W1bvV6d1Pv hetp1VIoe4/tyi96gdvVofIqTLsKEbsDtqtDRO9TtSsn9BQivIOe6pvTuXsT x30anXkoKXa5RbvSWT8Bhlr11N2hFla/ny4hQPTCdQkHzSvvLiFY7A7TJRws ep5dgolXyBcNpGB9BeakXlyXVzq6v6v19XbIQvUjba+Pnqg1weZt111GwiZw m9nx1Ww+/732slF/3jp9tNzeU6hlOoN4m9FmrjBfq7LQF8YX1bwyx+izmjGy Gy5v8wVVJ/flYnY9WQ5vZjdL835+vTA7BRSaDRUtpM+lr1fAO3qAzE72r9eF jE5bYWxH56oar1w0duKyqUqUUHeQtfm6in7913HvIuulce8vv0Ufx8tzVTHU Y+e6dp2Xbyd/jj8mSe9MHxrqR7+qB37DVTvd3nBXtXx7vqyuquFKyxZDJZup pSon216F0rtViInOeNRvojOq46Ni0en3VSwuxnwsttSGcZJn5fhCqb27rq7P 31Yrc3tR6XUvzvTZNlwn76eV0jHnbs7fLmYflEhV6Qwfgio6bVWW9Hey2iRN qRSpKGVKq+iOq4tNPi1u9Xo6aZlYrxOn/arRu36nFP+sqVU6hb1CqFWOe53h uqKWw6vz95flUv/d9ORaWdfVjjiOF2WcK92ryfS9ieZ0NlJi6UWukyyrHDoL R3E82kRTc0R0zEZOMRvGZec2ZnONP1zqCZqOXkfHTlpzO/20zJTijlQn0zUu wWucilcvtsQrFkfLFMHFtqAGhdzMG7FSnsasq8XuZlkdN4FQv99VQufnejf7 fF6uLs8/lFfvlFS/q6QqVKtOYbfcrmR1W0hLp1K8qExvtq001g0+yQWpuxiP UiWi5gUbkYtUi8S4SJzFZVGLqAeuzvUfuiPU3eq2SK/dc6h0eqFk2kZEqUx/ kLQlSTDbsChIZxsWGfFso9+eL6LZhkVDPtuwCIlyl00Olrt8ioDczdR/bXvl kty1aYhz1yaE5y6SHCB3oRT9w+VuMrAzwJtlpmznFJa9x20Sv+gF3iY5VF6F 2SYJEbsDbpMcInohtkmQeEl3TmHhuzunOb9zmiDbq8mdt92tD2XZ7jC/Ycfn aRpT7PjL8mq1p9P2ap0nxwPBWXI8qSElx5NizetlkhwPCtjJ8WuBHR/kdnK8 erw7yPc8wHHk+NZAm4suTuR4UvLeyfFk7CByPKngR453kYbJ8S7iMDneQRwl x4ulJeR4J3GYHC9Wl5DjSXGaHE8GJcnxZMh2cjwZBCHH0wIByfF039BOjifD NL08RI6nu039jR85ntS3kePJQB7keLoa7ZDju0XURo4nFWByPKnCkeOZRIQg xzOF5k+OJw3cCzmeLpLg5HjanBs5vt9Gju91kAQKyPG0DkeOpwseJcfTuReG HA/YAMjxTEsSkuPFaiw5nlQkyPF87uDkeFJLTI7HGjJNjgfmDhg5nhQ6LDme NI2S40kRlBwP5CZJjqdnA17keF6aI8cDiWPJ8YCGlRwPhIXI8ch0GSLHA0Iy cjxXRs7keKEwSI4HM9KPHO9uRECOdzciIMe7GxGQ44G9ISk5npS0kePxQDZy PF1neXI82uHZyfG8QmByPG/QTo6nd0IIcjwTECDHMwooOZ6UQcnxpAhPjqdX nJ7keMEGQTs5nhTgyfF4cJIcj8tYyfG4RBs5nu5IYXI839pgcjydHowcD2mw 5Hg6UQHJ8aQhITke12LJ8czaPyQ5no21GzleJItT2UlZJ3I8qygmx5OKAcnx Xms9pM76kuPpkSIMOZ60EY4cz5rxIsdz6n7keDbureR4IMV3yfHAbruFHM8u KyzkeLqnBMjxwHqGIscjjR0nx2NqR3L88fPx8x/jM7oR7kSOh7aUMXK838Yy Mjp4kePpeUxocjxdUi7keH4V50COh6JpI8dDgeXkeEg2DDme2dAJQ45HjHiT 4+k9JYQczygA5HiuhWHkeCYe7uR4LnoYOZ7PaIaFzguEJsfzFkkWOl1/aXI8 X6n8cusA5Hjeoldu4eR4+kCtAzmefinvSo6nV0dhyfFsCgByPL2AYsnxZHCa HM/3bIHI8dAsiifH0wdJpOR4Uo0nxyPbUK7keFI7LDme3ow4JDkessyR40kR nhzvGhwZTXj6OvDKWERfp1/9ukFR7IIwfd3rIIGFvs4vPkD6ujhym0m7D32d tOpLX/c6U9FOX5dlt52+7p7b7vR10iZOX/eR2dDX6YHQlb7udb6lnb4uK3A7 fd29wN3p63RJSenrLmoO9HUXMwx9nZ7eMfR1PHA7hNun4F3p6+I8JOnrLmoO 9HUXMwx9nS07ir6OB3Yo+CD0daBq2unreOB2+jowcgvp662Kdvo6c5bJh75O b5iHpa8DtiD6+kanaNMB6eukCERfJxUg+nqt0FONvEXBhb5OCjrS10lNCX1d HLm6A/Skr5NWD05fX1vfuTW/y0xIkh6AhFVPtSJhMfV7Y534Ri8o6+RweRWC dRImdgdjnRwmev6sE9Wyi12mBLcZo/f54q3wST4oOlvhN7SQNI17MC2kp5G5 cRtcDKKFcMERWohdw4EWYhdrukOOFoIIkLSQWmB7rkDRQpL+IEt33QPwtJCW QJuXG460EELyM6CFELEDaSGEgi8tRC4toIXIxQW0ELE4TgsRSstoIQ7iAlqI UF1GCyHEOVoIEZShhRAhbbQQIghGC6EEgtJCqL7BRgshwjS9PEgLobpN/Y0v LYTQt9NCiEBetBCqGu3QQtJe1E4LIRQEtBBChaeFkIkIQwshCy0ELYQwcE+0 EKpIDkALocw50EI6p3FylxaSxlmBJFBEC6F0eFoIVfA4LYTKvVC0ENYGRAsh W5KYFiJUA2ghhCJJC+FyR0ILIbQcaCFIQ+ZoIezcAaWFEEKHpoUQpnFaCCGC 00LY3GRoIdRswJMWwknztBA2cQAthNUgaCFsWJAWwk+XQVoIKySlhdBl5EEL EQnDtBAoI31pIa5GRLQQVyMiWoirEREthN0bktNCCEk7LQQNZKeFUHUWoYVg HR5FC+EUgtNCOIMULYTaCSFpIWRAiBZCKuC0EEIGp4UQIggthFpxetNC4A0C Gy2EEEBoIWhwhhaCyhC0EFSinRZCdaQCWgjX2gS0ECo9KC0E0ABoIVSigtJC CENiWgiqBdBCyLV/WFoIE2tXWohAVkLiIGQdaSGMogMthFAMSgvxWOshddaf FkKNFKFoIYSNkLQQxownLYRW96WFMHG30ELYFLfRQtjddisthFlWWGkhVE8J 0ULY9QxNC+Ebu4QWgqgdaSHHz8fPf4zP6Ea4Iy0E2FJGaSE+G8vI6OBJC6Hm MeFpIVRJudFCuFWcEy0EiKadFgIEdqGFALKhaCHkhk4oWghvJAAthNpTwmgh pAJEC6FbGEoLIePhQwuho4fSQriMZvkXnEB4WghnkeFfUPWXo4Vwlcovtw5C C+EseuWWhBZCHah1ooVQL+XdaSHU6ig0LYRJAUQLoRZQAC2ECM7RQrieLRgt BJhFIbQQ6iCJnBZCqCG0EH4byp0WQmiHpoVQmxGHpYUAlnlaCCGC0ELcgiOj CUILYV8ZC2kh1KtfJ1oIISighXgcJLDSQrjFB0wLEUZuM2n3o4UQVv1pIR5n Kmy0EEl2U7QQ19z2oYUQNiW0EHeZLVoINRC600I8zrfYaCGSAqdoIa4F7kML oUpKTguRqznRQuRmWFoINb1jaSFoYBs0wr3g3WkhwjxkaCFyNSdaiNwMSwth yo6mhaCBHQo+EC2ErZqpT71OaVoIO3KLaSEtig0tJG+jhTSP91si4EsLIaSD 00JYWyAtpNZpvSOO00IIEZAWQiiAtBClkGeDvNOi4EYLIQSdaSGEpowWIoxc 3QF600IIq5+AFqKsF6rKt92aj37913HvIuulce8vv0Ufx8tztXZXj53r92Pn 5dvJn+OPSdI70zvB/ehX9cBvuGqn2xvuqpZvz5fVlWqQWrYYKtlM5R0na642 XKuuWF8kWVTzyhyvSeu7h4LojEf9JjqjOj4qFp1+X8XiYszHYkttGCd5nJbp X/SB/vFY16/zxfXfb6qbSidsmJ6Z7X1cLCvHF0rs3XV1ff62WpnzrUqpe3Gm 337gOnk/rZSO2Zk9f7uYfVAiVaVjMwRVdEZVWdLfKTeTT0qlSEXZpLSK7ri6 2GT64lavp5OWifU6cdqvGr3rd0rxz/pes05hrxBqleNeZ7iu9eXw6vz9ZbnU fzcAEa2sK35HHMeLMs6Vrupr35toTmcjJZZe5DrJspqms3CkJlmbaOqbZjpm I6eYDeOycxuzuQZkLPVwoqPX0bGTNoNOPy0zpbgj1cl0jUvwGqfi1Yst8YrF 0TJFcLEtqK+S3cwbsVKexqyrxe5mWR03gVC/31VC5+d6rnY+L1eX5x/Kq3dK qt9VUhWqVaewW25XsrotpKVTKV5UpmvcVhrrBq+6OYHIeKR7xOXvtyIXpieM cZE4i8uiFlEPXJ3rP3RHqPvotUgaaxCJGvCsE/1T16l+tmsjTQgbiaONfNdG 1mbj9RM1q9jsObfdVNaBi0FKrHZ0BE2MJks1iZ2qQfdRexyKQX6IdBbbNnqD pI3P9/XVTbWazVaXmg2wqDSmJkpPe0BIbo6dJTLzej3epEknoskxfcrj2rwF WNgKAZNezobvKj2T+d1XyWR+sxVncqsPaHAbhar41CO7QinB3aTq1l65c1XU qW51dm1kbas5IKp7Mq3MRd+odrdsJNkga1upAVHdl+keIKrb7S7JB3Fbrra/ Nr2Z1u8sdwWStkhCXZst8GRUnSyHy4m+SjCq5mppb5YC+i3rUO9yLfR9m/8W /awWqfrRJn1v9Xkrlfw1I+Zven1YZwdgU9uLoybi5jflqJyb28rXN1f1tWlz nfDps+bF9d61RkI7in6ppqPZYuswj17j6V/tH+qJ9Ltp9fUPt2/gSeE3v88r /XdTUNTP4x9VykzyFpvX37djNpU1i7jOn5Nk94QREUby3r2WyaiRnmgye9U5 Z1qeU5PZ7nz1+ptplrao7sh0VV90gKgm8a4RiqtMxfWOTtuuhndkt4fvpNfe bY57vSrrji+AR+uNk6XZJDWvm3XlPb+eqZF+pI+Dqt7i3HQsy5H5Vn82H5qh MbpYj8JRtY5vvTsWTebvO4anqM2+U0Fvpov58DZZzdgbLaej82q6TLJuEr0t r801YPPlovxwrZTM52X19/Mmd/Q/y2G/e64RQEPzz/nw+nymckd/vp58rBab f6nfmL8bjo7KyaXefN4Y1jsK52btfaurXwqs36ZfTyZbr+rXHzfnANRqIqpR kerD6NrkTFktzydFrxMNzeVVfXTFnF+J5sv6JIz5UyUmWqyG+kRTFv3nxSi6 vqjPjekc15cvzIe3zYGh95Oylw4/fvwYrRbXaT9Wf03GV9XHaHk17MdVpxMt J8uiUHOc5aTmitTwS33XU2XEUJ8PjBb/pRFv0Xwy+RjNR8M0Tj9+PJ9djW7/ oavkbL6adNQEf7rsdfOkiC7nq0zp67/yj9E6QsPf9dnafhYNlVlVs/Rfqfrr etRRT6nOf/JxHpXXo26u4qyGseuk+JiprBl2lB2TNFMEN9PJR6CWGrqM+omB Z589f1k/G3figV4S1m1BrZ105683ZvUBnJd1D//LD88RyW9+ePzta3PZXOdg RwV8UAMlH0ZYjMwVv5VOt2lAmx2xWO/25Hq/Yt3QfgMEq/LjLchPRaa6UP9W pdHtFB3z7+He70fq3+Nuqtb+HSQLq+Vk/XxZmfCTjX5p7M1NJ9PJimGu/72c m+ez7jDOAf3RUkeve2GCbj4uzcdODxBoyELR4lo3uAfziSrRzJy4Xl3qDdrJ dDz7SkdIk0GiVbl899VQLcPHcXF7ipOQf70qh+9UNMc1gbHJyjS+zdMmc3L1 oTPudDtbv6qfVc2/+ZAjVaT5GSbjTjHciKjmtS61tX5f5XvVzbu97u2vzDdl v/7QHSkDuMVxt9J9Q3xreiM7TKqLi2ExNLIXebdq+dUaHYlYfKLP+73Rb4wG SPx0061Tqrc9dKtRveK8XA0vz1UvY7bf9e5HqvcN16MS0njWwirDNsKzabW1 o+agpnN9rWZ2389nN6utfTUHSZ3ja8nmAPT5WO+uJWW13iIWyg7jZNjNSh3T ph8/v5nOr27eNkOr6ZF0niKdRKPXS3Pdt15cvTuvPlbDm1V1vvj7eou+kgjl pkCMkB7wf58Oa6XdzURWqBP3zGbixWR2rrm6aurwVh9V1LvDaVemNex3ukUT qcXfz43kotIbpr1C77xJkpfk41ul63J+rh/QSmOBkq4Y/XFnU9eaLNfbkjqb Eqfqe1EWRa63OdXMbzQ7N2dXdcT0Rmfa1YoLUSVLLzoXfb2d/qGcqDo7W6ix /np+Va3q3eFuR5RgFbu008RuXurdIl2QOm65NGpqyLroVuNEvwnSs1v9Skn3 KsNzPWDoDfrEvFeKfjW/Fqhm3YveRvV68eFcw7N1c9IvSnougllPVzw1ZW42 ps6Ngo6jrnlDsaTOxrKss/HdohqfN3jr9d54Ic9MLWneJtyVjF0UVTMZdbKh biZGbm660HRsshCXKErzru/d7OI/1fqsUUkqQcs3ScvMm1+VgEV1PXuvE5Xp wsy7n0E+pVm/30nMG5O6515LntfbBuuqXMLZphUv9Etpm14yFHWdSi82I7da TDU5eDvIdHQ33Bdo9eIsu43bqNLdU54J6oXuN6uqykyWNUPqbpyKzMTJaage jdLxukdW3Z3uVfRjOpLj5nWkg2pRFMPbCYCJbaNqDggkiYusWgwVHd081uuN 2+pdVE1fJVmKHK46lql+uVsLKFk1Jb/UkdTvd4uxQCetkr1quI5TkYh6FqU1 SuLbON32zdJ5ky6GPDF1Ro8T5+tlYX2cSA/mZix3KIkkK/Ki27xsVO2kUtOx jWqS63aX4A1PTVk6F/H61eXNVM1adLbFsg4ZfHVpXTaY+8B5FqW9yKyMmv96 F1GRR2keZbn+nKf6n71+VKgnh/qDCpLkzYd4aJ6pn+81XypzZRL11T/V9+NI jalxpnWydSj9pApVRMkw+tfexV8i1Tr6atGTNlEoVYySqJtHcRHF4+iijDoX OrR6QMcu0+F0jIzZvaS2vVKJ/jX5y881WH01iy7L6Uh9qn8Z/fjzDz9E85m5 eBLpm3b6dM20dtTyfrJY3ZRXm03CZvU4BExatgrbHj1uFR63Cj+vrcK2Wmrb Kmx71nOrsFVys1WY6hxMia1CS4zctwrbBO1bhVkp3Sps1d/aKix3tgqzsmPf Ksz0DhLSP4m2CtsE1luF9XL58jxutgvTvoZD72wXZsN4d7uw6N7ZLmwzId0u 7G1+VXT2PrRsF7YOFPWPNhKneWd7Y26zi6eyeBzXe4I9VXl2twvVhHorehKL 27uc8a2h/PbDXqo7zYek02s+xD3Eon27sDV+9ZxZp3Q9Z17qbaRK7xZOR+sN qaQgJs2Ubny7v6cktzYMqck9JViU+Zbg6kZPIvt5fSrMTVHVqy3F8kKPQ6qT NedlUw/hfhFvonoz/c/yer0MKXMz53VU7WztYi0Ws8V5Pd9ZNPmaUPublG43 S226o9RRWE+sdUPT2wp1l6HP8HXMRoxAITE7nLcKsUxASXT1Rlj97Xktc64p yvVyRqshDesPOaFuPaoX/WvnL8ib+72X6sVBjhnsHE/pD5LtCO94d1RVLeOd lOqn2pyUgur35aTUO3ohnZQeMK8COCkNFLtDOSk9UPS8nZSqeOn/tg/pbZyM Zmocp5yMLirtuGhXyfWY1U6D1zqtN8kAd6VscMBdKaHxfb3BwHgYhQQoD6ON wPZBMMrDqH482T2bxnsYbQm0jqSrh1FC8jPwMErEDvQwSij4ehiVSws8jMrF BR5GxeK4h1GhtMzDqIO4wMOoUF3mYZQQ5zyMEkEZD6NESJuHUSII5mGUEgjq YZTqG2weRokwTS8Pehiluk39ja+HUULf7mGUCOTlYZSqRjseRrtF1O5hlFAQ eBglVHgPo2QiwngYJQsthIdRwsA9eRiliuQAHkYpc24eRrM2D6OdBEmgyMMo pcN7GKUKHvcwSuVeKA+jrA3IwyjZksQeRoVqgIdRQpH0MMrljsTDKKHl4GEU acich1F27oB6GCWEDu1hlDCNexglRHAPo2xuMh5GqdmAp4dRTpr3MMomDvAw ymoQHkbZsKCHUX66DHoYZYWkHkbpMvLwMCoShj2MQhnp62HU1YjIw6irEZGH UVcjIg+j7N6Q3MMoIWn3MIoGsnsYpeos4mEU6/AoD6OcQnAPo5xBysMotRNC ehglA0IeRkkF3MMoIYN7GCVEEA+j1IrT28MovEFg8zBKCCAeRtHgjIdRVIbw MIpKtHsYpTpSgYdRrrUJPIxS6UE9jAIagIdRKlFBPYwShsQeRlEtwMMoufYP 62GUibWrh1GBrMR7JyHr6GGUUXTwMEooBvUw6rHWQ+qsv4dRaqQI5WGUsBHS wyhjxtPDKK3u62GUibvFwyib4jYPo+xuu9XDKLOssHoYpXpKyMMou56hPYzy jV3iYRRRO3oYPX4+fv5jfEY3wh09jAJbyqiHUZ+NZWR08PQwSs1jwnsYpUrK zcMot4pz8jAKRNPuYRQI7OJhFJAN5WGU3NAJ5WGUNxLAwyi1p4R5GCUVIA+j dAtDPYyS8fDxMEpHD/UwymU06zOTEwjvYZSzyPjMpOov52GUq1R+uXUQD6Oc Ra/ckngYJZTcPIxSL+XdPYxSq6PQHkaZFEAeRqkFFOBhlAjOeRjlera6+8r9 PYwCsyiQdGo9SCL3MEqoIR5G+W0odw+jhHZoD6PUZsRhPYwClnkPo4QI4mHU LTgymiAeRtlXxkIPo9SrXycPo4SgwMOox0ECq4dRbvEBexgVRm4zaffzMEpY 9fcw6nGmwuZhVJLdlIdR19z28TBK2JR4GHWX2fIwSg2E7h5GPc632DyMSgqc 8jDqWuA+HkapkpJ7GJWrOXkYlZthPYxS0zvWwyga2OZo0r3g3T2MCvOQ8TAq V3PyMCo3w3oYZcqO9jCKBnYo+EAeRtmqSXkYRQPbPIyyI7fYwyifYUE8NWkb 29ezGy+mvTYvpi2P356X8vNiSkgH92LK2gK9mDY6bQ65cC+mhAjoxZRQAL2Y 1goF49PC22FXmrX7WnXzlEoIOntKJTRlnlKFkas7cm9PqYTVT+ApVVvvtHs0 gfwWpV2V/rY1qq5Ws5VmkNf59t1sVR+70/9Yuz5rPO+cFoDi8nI+vJwbKNd0 pA//7CluptdPN77C1vL5rnzS3hdunR3VzeSFGumVsdlCX7Wpm97eOUOL0o77 pF2PSXd1757Wtqjyy5uTZS0KiN2JR7PTvCW+n9K2GrLlzOnN6yLX/K+1M6f4 2/7jNwY8t/4xzpxefJ3/AgmvnTk9NePAyWPjBlTgzCkFrJgwa6CkfteQFJ0s TvJeT98dPNFnpKLL0YfF7e5/T7/k0pv/n1S91d2VkVzqlyPLvT0wSwg1vKvu yvwverzS1N2qRnma8zpaZVukt8tZ8X83YBHc2llfsjvrhIb7+4VMDaLbIJgd 1E2a9Lo8sUk/ZSE2afWCUb9HYpNf9AITmw6VV2GITSFid0Bi0yGiF4LYlHUH RVuj9fDDzqs6+WFvkYX8sAPREfhhp9Vw1+m8DuI6nU8b7jqd1RK6Tmf1BK7T OS1X1+l8HEWu0/kshF2n8zGTuk5naxzkOh2Jl8h1OlAEuOt0II2Y63RACHad jqQQdp3ORwxwnQ6I8K7TWRHI/0Cil+g7G3InJ9GLx6++V39vPbS/t9T6UM4/ lBpz7EOAudSYS9mHlFjb8mN7uv+0XoXo85J6dN06oGsPrxnLzeGpgbl5ZJi7 j/SKRs/UHzXLFrWWUVW+t3WELTM5wMQ7u7P71foQkwNJHNVbMDueXVsfSpGH cv6hBDGXIObq6pTTD9XViX0oRR4CzNVlV3APpchDOf9QjpjLjbkO91DOP1QY c+xDgLnCmOvSD3WMOfahFHqov5tPDDGzDgTEsYvEsWvi2OMeyvmHesYc+xBg rjfI0kHStn1uO6yjz4HF2+F77dDTrfc0NgBstifj6AM738j0Tb706ST3Tb6w D+XsQ4npMwtiTKwfSpGHsmx3+2Sd/vHVbD7/Pdan9JvPW6fml1vv8W5l2rJR KpMPkrbN4/r++kn9Vq+8MqNgdDPfCxkiHUqmDTIulVGdh6y9twTabNq5EHJp yfsm5NKxQwi5tIIXIddJGiXkOomjhFwXcZCQK5cWEHLdxFFCrlxdQMilxUlC Lh2UIuTSIVsJuXQQgJDLCIQj5DJ9Qyshlw7TvGFFCLlMt6m/8SLk0voWQi4d yJ2Qy1SjHUJu2otaCLm0AkrIpVUYQi6XiACEXK7QvAm5tIH7IOQyRRKakMuY cyDkFqf9/l1CbtLvQ70MTshldBhCLlPwICGXyb0ghFzEBk/I5VqSjJArV+MI ubSinZAL5A5MyKW1pIRcsCGThFxk7gARcmmhgxJyadMgIZcWAQm5SG5ShFxm NuBDyAWkGUIukjiOkIto2Ai5SFiEkAtNlxFCLiIkIuSyZeRKyJUKY4RcNCO9 CLkeRnBCrocRnJDrYQQn5CJ7Q0JCLi1pIeQKAlkIuUydZQm5cIdnJeQCCmEJ uYBBKyGX2QmxE3K5gDwhl1MACbm0DEjIpUVYQi6z4vQj5Eo2CFoJubQAS8gV BKcIuQIZGyFXINFCyGU6UpSQC7Q2lJDLpAci5GIaHCGXSVQ4Qi5tSEbIFWhx hFxu7R+QkMvH2omQK5OF6bO0rAshl1eUEnJpxXCEXL+1HlJnPQm5zEgRhJBL 2whGyOXN+BByWXUvQi4f9zZCLpLiO4RcZLe9nZDLLyvaCblMT8kTcpH1DEHI hRo7TMgF1Y6E3OPn4+c/xmd0I9yFkIttKUOEXM+NZWR08CHkMvOYwIRcpqQc CLnAKk5OyMWiaSHkYoHFhFxMNgghl9vQCULIhYz4EnKZPSWAkMsp8IRctoVB hFwuHs6EXDZ6ECEXyGia+QoIBCbkAhYp5itTf0lCLlCp/HIrPCEXsOiVWzAh l3mHvr5w/vzHb34a3EJrdFZOFvWhgPVQvzX+I6P+RtrcrY7qO3x1h31RbQ4d jG7MRtHaMHQIWH5zH4zpJvnD2fX8qlpB8yXXO/vMejAoE5hPAc8EZpaMHBOY Dk4ygYG+PAwTGJs3skxg5uiMkAlMq7FMYGbfgibjMK8lHcg4zHatLxmHlofB ml4ya7Cm4P0VQ+nxTdUOT4ep5ChPB9rQdWRN09pBWdNM8zggaxqzzLCmaRGW Nc3EYX1gXetsxkbdR22kBvV07YG+l6OpSOuRA+l7nk1HhxNnOdmuwS+QVSuY c2q6driccxWXM76ZUULO+KYFUca331GodsY3sH2CMb7lkdtsO3gwvmmrnoxv v1NhrYxvYXZbGd8eue3M+ObHWReutt+puFautjCTrVxtj0x25mozMyMhV9tJ Tc7VdjJDc7WZJRLN1RYEbsUrexW8I1dbnocUV9tJTc7VdjJDc7X5siO42oLA DgUfgquNVE0rV1sQuJWrjYyWMq72reI2r6FmXneLO8zr9sdvV5AezGtaOizz GrGFMK9vddr4CiDzmhZBmNe0AsK83ijkbYAFBx41LejGo6Y1BTxqeeTqDtCP R01bPTSPurFugRYDDA8LilcK39gj6O6iNNNuDhBh1VN3iLC4+r0QYUNELxgR 9rB55UuEDRe7gxBhDxc9PyLsbbzaoH7yVroDruNZrZtwOZct36qZ7jgy194X +gCxPkcxmeoG/ShaXt7U/fdo9mF6KhR+9nGyd56/UH12zxqqyDKgs1FPWTob RP0eOxu/6AXubA6VV2E6mxCxO2Bnc4johehsVLySNhcpws5GywSYWSiZjMsl p74HEW7pe9RksS1z6inWy8XserIc3szUgly/gF/PeE8BhWalqoX0Ufv10mJH D5DZmfKtJ9yUTn+Q2l9+1dG5qsYrF42duGw24K1CKkXpLrx0t0y6SQL07Oqp 1p4dU7+3nt03ekF79sPlVYiePUzsDtazHyZ6/j17ovrj3Z2RFjplcmf7pPWh gn8oRcyld7Y3Wh8q+IcyY459SJujOanqoYJ/KDfm2IcAc4bDm7X6pzck8osL qb8HSLUv9vfQLoutIfjooP4eWDXQ3wOkw/p7QNI2TDB/D4jWqMT9PSB6VYb5 e0C0uhdyfw9QHCvY3wMkF0P+HiCpscTfA1LjeH8PYLxwfw9YtAAXDZgQ5qIB 0UrL2iHCZKqb5s38XHugyLVHhL4gqyrQzwOUOs7PAybC+HlARFg/D7UIMNAV ZqBj6NiFGejYhwr+oQ5irqPNJQxnu6PNcQ91B3qe4g2xrmW8Ydx6L76d6Y0u L+0KouWlXUa2vOzqVxbtNws85jasqtvc5q4sNrfhoyOZ23BqVb+b6Q5Lz2ku bsbn+kKjkst0h3UhElPdRNJL+nosLIeryXuVuPNVudR9cUcPh70YjpRkisNp Sac4bIYlw2wdt+FCF6HOrqGOXE8s5jrHYSNZqYGxZY6T91vnOFy5YtMINlLS aQQfLXAawQvh0whOC5pGsBG6qMfb99uVLIkLneOFRKbf0emazavp+bS8rnQ3 WFzoJHU6uExRFhe6lo4nV/NzraVrfF0vBRrdvq5Cavl0Xt+nPh/rKllkpqMR 6PQudM6MZud6RtPEpij2JjScDDSh6Zp5AeEkqn6o4B/q6QGQfwgw1zPmaI9M Sd+YYx/Kiva5Cr5Xa9cQ7tX2gWSlsUkW7dQpNWcn+IcK/qEEMWc2uBLaqVNq Nri4h8wGF/8QYC4dFPmuSxj91kK/sPg1K3rd3wa7bzHM1a31PYHyarWtox02 tR31GS9Hg3o+07wmUQNXVH2cbJ0AY4PfTKuPa5azvjl2ew1gCWg0Z1yuZm/f mt17zS9/GC1Xak68NYOFBKJRWekrbCs9hkwNpHxfYLtmVvVbHOMwefJWXzdc X45OtBMmlfc7Tr44xzGtgdaRdHMcQ0reu+MYMnaQ4xhSwc9xjIs07DjGRRx2 HOMgjjqOEUtLHMc4icOOY8TqEscxpDjtOIYMSjqOIUO2O44hgyCOY2iBgI5j 6L6h3XEMGabp5SHHMXS3qb/xcxxD6tscx5CBPBzH0NVox3FMHkdtjmNIBdhx DKnCOY5hEhHCcQxTaP6OY0gD9+I4hi6S4I5jaHMOjmM6p2rCd8dxTBqnfSSB AscxtA7nOIYueNRxDJ17YRzHADYAxzFMSxI6jhGrsY5jSEXCcQyfO7jjGFJL 7DgGa8i04xhg7oA5jiGFDus4hjSNOo4hRVDHMUBuko5j6NmAl+MYXppzHAMk jnUcA2hYHccAYSHHMch0GXIcAwjJHMdwZeTsOEYoDDqOATPSz3GMuxGB4xh3 IwLHMe5GBI5jgL0hqeMYUtLmOAYPZHMcQ9dZ3nEM2uHZHcfwCoEdx/AG7Y5j 6J0QwnEMExBwHMMooI5jSBnUcQwpwjuOoVecno5jBBsE7Y5jSAHecQwenHQc g8tYHcfgEm2OY+iOFHYcw7c22HEMnR7McQykwTqOoRMV0HEMaUjoOAbXYh3H MGv/kI5j2Fi7OY4RyeJOWUhZJ8cxrKLYcQypGNBxjNdaD6mzvo5j6JEijOMY 0kY4xzGsGS/HMZy6n+MYNu6tjmOAFN91HAPstlscx7DLCovjGLqnBBzHAOsZ ynEM0thxxzGY2tFxzPHz8fMf4zO6Ee7kOAbaUsYcx/htLCOjg5fjGHoeE9px DF1SLo5j+FWcg+MYKJo2xzFQYLnjGEg2jOMYZkMnjOMYxIi34xh6TwlxHMMo AI5juBaGOY5h4uHuOIaLHuY4hs9oxhUKLxDacQxvkXSFQtdf2nEMX6n8cusA jmN4i165hTuOoQ/UOjhhoV/Ku7pRoVdHYd2osCkA3KjQCyjWjQoZnHajwvds gdyoQLMo3o0KfZBE6kaFVOPdqNCreMaNCv2SzsWNCr156e1GhZTH3aj4yGzc qOBvczg3Kp6p2nWjQldy2I0Ksr3p6kaF1A7rRoVuHod0owJZ5tyokCK8GxXX 4Ehr412RAEcRRO486N7KwZ0HKQi78/A6oGJx58EvakF3HuLIbRaDPu48SKu+ 7jy8zuq0u/OQZbfdnYd7bru782D7eyd3Hl5nldrdecgy2e7Owz2T3d150CO0 1J2Hi5qDOw8XM4w7D3qqzrjzwAO3e3XwKXhXdx7iPCTdebioObjzcDHDuPNg y45y54EHdij4IO48gKppd+eBB2535wGMlkJ3Hq2KjTuP5K47j83j7Q4hfdx5 kNKB3XkAtiB3HhudVrcgoDsPUgRy50EqQO48aoViELdVLBd3HqSgozsPUlPi zkMcuboD9HTnQVo9uDsPZb1n+vBtjMWaH6sr6H+VJ2lRpAjivkgbEHId7kux hfuBIQeJYINDvpxdV2d1GE8q8oGzzZuLHDB+hyEjHzCCnmzkdcwyPmZS0rxA eoc1b8Il+SC1E+o73R7QCain7tLQYfV77AD8oheOhn7QvArT6kPE7oBt/hDR C9HiUyBeTu0dEb7b2lWoHeLmBgGV9voJhoCqdYp2jhqPgAKCswgoUqOZF5EI KFDAjoDaCGzPsikElJ6GqRA7ec8ioFoCbd5YOyKgCMnPAAFFxA5EQBEKvggo ubQAASUXFyCgxOI4AkooLUNAOYgLEFBCdRkCihDnEFBEUAYBRYS0IaCIIBgC ihIIioCi+gYbAooI0/TyIAKK6jb1N74IKELfjoAiAnkhoKhqtIOAUhOQdgQU oSBAQBEqPAKKTEQYBBRZaCEQUISBe0JAUUVyAAQUZc4NAZW2IaCKHEmgCAFF 6fAIKKrgcQQUlXuhEFCsDQgBRbYkMQJKqAYgoAhFEgHF5Y4EAUVoOSCgkIbM IaDYuQOKgCKEDo2AIkzjCChCBEdAsbnJIKCo2YAnAoqT5hFQbOIABBSrQSCg 2LAgAoqfLoMIKFZIioCiy8gDASUShhFQUEb6IqBcjYgQUK5GRAgoVyMiBBS7 NyRHQBGSdgQUGsiOgKLqLIKAwjo8CgHFKQRHQHEGKQQUtRNCIqDIgBACilTA EVCEDI6AIkQQBBS14vRGQMEbBDYEFCGAIKDQ4AwCCpUhEFCoRDsCiupIBQgo rrUJEFBUelAEFKABIKCoRAVFQBGGxAgoVAtAQJFr/7AIKCbWrggogawEr0TI OiKgGEUHBBShGBQB5bHWQ+qsPwKKGilCIaAIGyERUIwZTwQUre6LgGLibkFA sSluQ0Cxu+1WBBSzrLAioKieEkJAsesZGgHFN3YJAgpROyKgjp+Pn/8Yn9GN cEcEFLCljCKgfDaWkdHBEwFFzWPCI6CoknJDQHGrOCcEFBBNOwIKCOyCgAJk QyGgyA2dUAgo3kgABBS1p4QhoEgFCAFFtzAUAUXGwwcBRUcPRUBxGc1CjTiB 8AgoziIDNaLqL4eA4iqVX24dBAHFWfTKLQkCijpQ64SAol7KuyOgqNVRaAQU kwIIAUUtoAAEFBGcQ0BxPVswBBQwi0IQUNRBEjkCilBDEFDUKp5FQFEv6dwQ UNTmZQAEFCEvQUC5y2whoNC3OTwCyitV+wgoqpILEFD89qY7AorQDo2AoprH YRFQgGUeAUWIIAgot+BIa0MQUOxRBCECiuqtnBBQhKAAAeVxQMWKgOIWtTAC Shi5zWLQDwFFWPVHQHmc1bEhoCTZTSGgXHPbBwHF9PeOCCiPs0o2BJQkkykE lGsm+yCgqBFajoCSqzkhoORmWAQUNVVnEVBoYBsJyL3g3RFQwjxkEFByNScE lNwMi4Biyo5GQKGBHQo+EAKKrZoUAgoNbENAsaOlGAHVKG5fLW8QUJ02BFTL 47crGT8EFCEdHAHF2gIRUI1O3+WFzX6DaRMBEVCEAoiAqhWytEXBDQFFCDoj oAhNGQJKGLm6A/RGQBFWPwECKs10Enas7zIkkn4HYL+op9rYL6D6fbFfvKMX kv1ywLwKwH4JFLtDsV8OFD1v9ouKV7I3Mp+cRC8ev/pe/b31UIY8tD827T+U 6qVvYiFAbWeDFDUDC++gZupQ+W7CNqiZLMlB1MxaZ8f6ZhhiUTNAcBY1Q2q8 evlkoIbviR6cVEXR78fL4cpM1a7LefRADRfTWXRSPDwFxJrOnOTWgAJ2bs1G YJs7aOfWpBpTqP5LtzE3HLemNdDmNZsTt4aUvHduDRk7iFtDKvhxa1ykYW6N izjMrXEQR7k1YmkJt8ZJHObWiNUl3BpSnObWkEFJbg0Zsp1bQwZBuDW0QEBu Dd03tHNryDBNLw9xa+huU3/jx60h9W3cGjKQB7eGrkY73JpuEbVxa0gFmFtD qnDcGiYRIbg1TKH5c2tIA/fCraGLJDi3hjbnxq3J2rg1nQxJoIBbQ+tw3Bq6 4FFuDZ17Ybg1gA2AW8O0JCG3RqzGcmtIRYJbw+cOzq0htcTcGqwh09waYO6A cWtIocNya0jTKLeGFEG5NUBuktwaejbgxa3hpTluDZA4llsDaFi5NUBYiFuD TJchbg0gJOPWcGXkzK0RCoPcGjAj/bg17kYE3Bp3IwJujbsRAbcG2BuScmtI SRu3Bg9k49bQdZbn1qAdnp1bwysE5tbwBu3cGnonhODWMAEBbg2jgHJrSBmU W0OK8NwaesXpya0RbBC0c2tIAZ5bgwcnuTW4jJVbg0u0cWvojhTm1vCtDebW 0OnBuDWQBsutoRMVkFtDGhJya3AtllvDrP1DcmvYWLtxa0SyOBOGlHXi1rCK Ym4NqRiQW+O11kPqrC+3hh4pwnBrSBvhuDWsGS9uDafux61h497KrQFSfJdb A+y2W7g17LLCwq2he0qAWwOsZyhuDdLYcW4Npnbk1hw/Hz//MT6jG+FO3Bpo Sxnj1vhtLCOjgxe3hp7HhObW0CXlwq3hV3EO3BoomjZuDRRYzq2BZMNwa5gN nTDcGsSIN7eG3lNCuDWMAsCt4VoYxq1h4uHOreGih3Fr+IxmSCy8QGhuDW+R JLHQ9Zfm1vCVyi+3DsCt4S165RbOrSGVXLg19Et5V24NvToKy61hUwBwa+gF FMutIYPT3Bq+ZwvErYFmUTy3hj5IIuXWkGo8t4ZexTPcGvolnQu3ht689ObW kPI4t8ZHZsOtwd/mcNwaz1TtcmvoSg5za5DtTVduDakdlltDN49Dcmsgyxy3 hhThuTWuwZHWxnNrgKMIIm4N3Vs5cGtIQZhb43VAxcKt4Re1ILdGHLnNYtCH W0Na9eXWeJ3VaefWyLLbzq1xz213bg3b3ztxa7zOKrVza2SZbOfWuGeyO7eG HqGl3BoXNQdujYsZhltDT9UZbg0euB1f4lPwrtwacR6S3BoXNQdujYsZhlvD lh3FrcEDOxR8EG4NUDXt3Bo8cDu3BhgthdyaVsWaW9Pp3uXWbB5vJ3D6cGtI 6cDcGsAWxK3Z6LTyb0BuDSkCcWtIBYhbs1bI4hYFF24NKejIrSE1JdwaceTq DtCTW0NaPTi3prbeGyTbVX4PSNHtIdwaZe8OtwZWvx9uTYDohePWHDSvvLk1 wWJ3GG7NwaLnya0x8VLtLk8EGyB6z3a7huZdGmmjHurdGbZaH0rSQbpNKtkw ZNK8l8MMGaOTtaUIYshwwRGGjF2j6Qs57AsiQGJfaoFtTBKFfUn6gyJVFXQ7 71nsS0ugzVsqR+wLIfkZYF+I2IHYF0LBF/silxZgX+TiAuyLWBzHvgilZdgX B3EB9kWoLsO+EOIc9oUIymBfiJA27AsRBMO+UAJBsS9U32DDvhBhml4exL5Q 3ab+xhf7QujbsS9EIC/sC1WNdrAval3Zjn0hFATYF0KFx76QiQiDfSELLQT2 hTBwT9gXqkgOgH2hzLlhX5I27EuaIQkUYV8oHR77QhU8jn2hci8U9oW1AWFf yJYkxr4I1QDsC6FIYl+43JFgXwgtB+wL0pA57As7d0CxL4TQobEvhGkc+0KI 4NgXNjcZ7As1G/DEvnDSPPaFTRyAfWE1COwLGxbEvvDTZRD7wgpJsS90GXlg X0TCMPYFykhf7IurERH2xdWICPviakSEfWH3huTYF0LSjn1BA9mxL1SdRbAv WIdHYV84heDYF84ghX2hdkJI7AsZEMK+kAo49oWQwbEvhAiCfaFWnN7YF3iD wIZ9IQQQ7AsanMG+oDIE9gWVaMe+UB2pAPvCtTYB9oVKD4p9ATQA7AuVqKDY F8KQGPuCagHYF3LtHxb7wsTaFfsikJUgVQhZR+wLo+iAfSEUg2JfPNZ6SJ31 x75QI0Uo7AthIyT2hTHjiX2h1X2xL0zcLdgXNsVt2Bd2t92KfWGWFVbsC9VT QtgXdj1DY1/4xi7BviBqR+zL8fPx8x/jM7oR7oh9AbaUUeyLz8YyMjp4Yl+o eUx47AtVUm7YF24V54R9AaJpx74AgV2wL4BsKOwLuaETCvvCGwmAfaH2lDDs C6kAYV/oFoZiX8h4+GBf6Oih2Bcuo1mQCScQHvvCWWRAJlT95bAvXKXyy62D YF84i165JcG+UAdqnbAv1Et5d+wLtToKjX1hUgBhX6gFFIB9IYJz2BeuZwuG fQFmUQj2hTpIIse+EGoI9oVaxbPYF+olnRv2hdq8DIB9IeQl2Bd3mS3sC/o2 h8e+eKVqH/tCVXIB9oXf3nTHvhDaobEvVPM4LPYFsMxjXwgRBPviFhxpbQj2 hT2KIMS+UL2VE/aFEBRgXzwOqFixL9yiFsa+CCO3WQz6YV8Iq/7YF4+zOjbs iyS7KeyLa277YF+Y/t4R++JxVsmGfZFkMoV9cc1kH+wLNULLsS9yNSfsi9wM i32hpuos9gUNbKN/uBe8O/ZFmIcM9kWu5oR9kZthsS9M2dHYFzSwQ8EHwr6w VZPCvqCBbdgXdrQUY18axf6WYoN96bRhX1oev13J+GFfCOng2BfWFoh9qXWS VpIHjH0hREDsC6EAYl8ahaxFwQ37Qgg6Y18ITRn2RRi5ugP0xr4QVj8B9kVb zwY5wcvoFQj2pVe0YV9A9fvCvnhHLyT25YB5FQD7Eih2h8K+HCh63tgXHS8a R2Pi9a2a6Y3XrJTJ0rzdnUx1i3q0C2M5FQo/q2Ek61BprHElOxOFu4AY9VCG PLQ/VLY8lBhz7ENpNkhja0ryXgr0QOqpth4IVL+vHsg7eiF7oAPmVYAeKFDs DtUDHSh63j2QihfQUFPdUHdmiq0PZchD+3POlocyxFxmzCXcQwXzUKY3BBPk Ic6ceSjX0zWmkF8///a7n/Xp3mE1MXiFRbWexOmXd/pVr14lL4Wy99NJBYhe uE7qoHnl3UkFi91hOqmDRc+zk4LjJZ0mwcI70yQVSi3qert9weaoya//Ou5d DJPx+OIvv0Ufx8vzyc1Ub6/8Of6YpBdn8ce0E0e/ql/8BqtV2UVv3KgtrkeT hdLKy7HSKkpey1zUv1alpN/HLqp5ZS6LpDVJB49DVXVSFQeVlPdb0cjSM31N SpKgYZx0hmknUWLbSskoOTOH1AQqWaJVlr/fqvS1SIVrxFlcFrWGeuDqXP+h ZLpK5QIQ0SUynqlqe75GJD7Q7ycfxR97DyOtpQ/06OOf5paispbo20P6bWY0 Xp59rP9/vtJ3eE6Hp5FqWKubxXTTrL7SuIXexahXjXZi0x/EuSg2SUtssqzf FpnFByImVTcZ9j/XmLRuZPGvkcngr9erCq2z2RjUB202UoP6HNkDjVqs3g82 x58eAvLPpqMg4mnb7pBjV0SqCbuiPS24K6LjIOyK7GKSrohRgboiUqMo+2Od LFX48/Ph1WxZKZFCJ6ovESn7oyYia43OSGl0cQ20T7SI3FufmLVh7e+lJ/p8 YlK4Ha0hg4frE4u2NylB+sREzevC9Ym0mqxP3NdC+0QmDrI+kRAT9ImcCtIn 0hpgV2QTuZ+uSMWm2I7Nhp6dxXGXomcvKo33I5TuryvRMWlrrDzJGwjOkrxJ jeb1FknyBgXsJO9aQL/L2xKwk7zrx9NBvL3/zpG8WwNtLh44kbxJyXsneZOx g0jepIIfydtFGiZ5u4jDJG8HcZTkLZaWkLydxGGSt1hdQvImxWmSNxmUJHmT IdtJ3mQQhORNCwQkedN9QzvJmwzT9PIQyZvuNvU3fiRvUt9G8iYDeZC86Wq0 Q/LO46iN5E0qwCRvUoUjeTOJCEHyZgrNn+RNGrgXkjddJMFJ3rQ5N5J33kby 7mdIAgUkb1qHI3nTBY+SvOncC0PyBmwAJG+mJQlJ3mI1luRNKhIkbz53cJI3 qSUmeWMNmSZ5A3MHjORNCh2W5E2aRknepAhK8gZykyR507MBL5I3L82RvIHE sSRvQMNK8gbCQiRvZLoMkbwBIRnJmysjZ5K3UBgkeYMZ6UfydjciIHm7GxGQ vN2NCEjewN6QlORNStpI3nggG8mbrrM8yRvt8Owkb14hMMmbN2gnedM7IQTJ mwkIkLwZBZTkTcqgJG9ShCd50ytOT5K3YIOgneRNCvAkbzw4SfLGZawkb1yi jeRNd6QwyZtvbTDJm04PRvKGNFiSN52ogCRv0pCQ5I1rsSRvZu0fkuTNxtqN 5C2SxSnZpKwTyZtVFJO8ScWAJG+vtR5SZ31J3vRIEYbkTdoIR/JmzXiRvDl1 P5I3G/dWkjeQ4rskb2C33ULyZpcVFpI33VMCJG9gPUORvJHGjpO8MbUjyfv4 +fj5j/EZ3Qh3InlDW8oYydtvYxkZHbxI3vQ8JjTJmy4pF5I3v4pzIHlD0bSR vKHAcpI3JBuG5M1s6IQheSNGvEne9J4SQvJmFACSN9fCMJI3Ew93kjcXPYzk zWc0w6bmBUKTvHmLJJuarr80yZuvVH65dQCSN2/RK7dwkjd9oNaB5E2/lHcl edOro7AkbzYFAMmbXkCxJG8yOE3y5nu2uvvKfEne0CyKJ3nTB0mkJG9SjSd5 06t4huRNv6RzIXnTm5feJG9SHid5+8hsSN742xyO5O2Zql2SN13JYZI3sr3p SvImtcOSvOnmcUiSN2SZI3mTIjzJ2zU40trA64bWHAhz3dB+li7EdUPyGIWI Qk73tA4UclIQppB7Ha6xUMj5BTlIIRdHbrOQ9aGQk1Z9KeRe54zaKeSy7LZT yN1z251Czo5VThRyr3NW7RRyWSbbKeTumexOIadnF1IKuYuaA4XcxQxDIaeX GQyFHA/cDqP2KXhXCrk4D0kKuYuaA4XcxQxDIWfLjqKQ44EdCj4IhRyomnYK OR64nUIOjJZCCnmrYkMh79+lkDOrMB8KOf3iJiyFHLAFUcg3Ok5uY/cbTLtz MYBCTipAFPK1Qiugy4VCTgo6UshJTQmFXBy5ugP0pJCTVg9OIV9bz8MB92g1 IdFlTwsmutBxEBJd7GISogujAhFdSA2U6GIRuSeiS9be3d4Dh+WziokHXEoH b4OxhNrtsciH2e3JBmmrm1m3rohUE3ZFe1pwV0THQdgV2cUkXRGjAnVFpAba FVlE7qkryqXUvYN1AJ9VTAqPrsgSPFRXpOTbeIBBuiIDZnffstfB2+IG5lyx twxpAaKneu6ZtuLQ0rxfUDi0y/JqtauTtU7xEQQZFxxBkNk1Xr18MlBLo4mu 2quZOTdVDldmGXxdzqMHaio+nUUnxdZ60S7WTJQ5nhkiQPLMaoHtykPyzLqD PNutawDP7G6gzfELV56ZXfJz4JnZY4fyzOwK3jwzsbSEZyYWl/DMpOICnplM Wsgzk4tLeGYydSHPzC7O8szsQTmemT2klWdmDwLyzAiBsDwzom+w8szsYZpe HuWZEd2m/sabZ2bXJ3hm9kB+PDOiGu3wzNS83sIzsytIeGZ2FYBnRiUiEM+M KrQgPDO7gfvimRFFcgieGWHOjWcWt/HMEqiXkfHMCB2AZ0YUvIBnRuReMJ4Z ZwPjmVEtSc4zk6khPDO7Is0zY3JHxDOza7nwzICGzPLMuLkDzDOzCx2cZ2Y3 LeCZ2UUEPDMuNzmeGTEb8OWZMdIAz4xLHMIz4zQonhkXFuWZsdNllGfGCYl5 ZmQZ+fDMJMI4zwzJSG+emaMRGc/M0YiMZ+ZoRMYz4/aGHHhmdkmCZwYGInhm RJ2FeGZQh0fyzBiF8DwzxiDJMyN2QmieGRUQ45lRCgKemV1GwDOzi0A8M2LF 6c8zQzcIrDwzuwDEMwODczwzUIbimYESFp4Z0ZFKeGZMa5PwzIj0wDwzXgPh mRGJCsszsxuS88xALYRnRq39A/PM6Fg788xwWRErzC7ryjOjFV14ZnbFsDwz 97UeUmcD8MyIkSIYz8xuIyjPjDbjyzMj1b15ZnTcbTwzLsWtPDNut93OM6OX FXaeGdFTYjwzbj3D8MzYxi7imQFqR57Z8fPx8x/jM7oR7soz47eUYZ6Zx8Yy Mjr48syIecwBeGZESTnyzJhVnBvPjI8mwTPjAzvxzHjZYDwzakMnGM+MNRKC Z0bsKYE8M0oB45mRLQzmmVHx8OKZkdGDeWZMRvOELkbgADwzxiJH6CLqL8sz YyqVX24dhmfGWPTKLRHPjDhQ68YzI17Ke/DMiNVRcJ4ZnQKMZ0YsoBCemT04 yzNjerZwPDN+FgXxzIiDJA48M7saxDMjVvE8z4x4SefIMyM2L0PwzOzyIp6Z s8w2zwx8mwPwzHxSdYdnRlRyCc+M3d704JnZtYPzzIjmcWCeGW8Z4JnZRSCe mVNwpLVBl6O4owhSJhjRW7kxweyCEiaY+wEVOxOMWdTiTDBZ5DaLQU8mmN1q ACaY+1kdKxNMkN0kE8wxt72YYHR/78oEcz+rZGWCCTKZZII5ZrIXE4wYoR2Y YGI1NyaY2AzPBCOm6jwTDAxsRUM5F7wHE0yWhxwTTKzmxgQTm+GZYHTZMUww MLBDwYdignFVk2SCgYGtTDButJQzwWrF7RvnDROs08oEu/v47UrGkwlmlw7P BONsoUywWid3eWGz32DaRFAmmF0BZYLVCm2sHEcmmF3QnQlm1xQywWSRqztA fyaY3eqnYIL1BvFe19HCnzAPFdtRfKvPwoxqMMBJmua9h1ut48EtPiBRy++H j6L5ZBTpp1RfqurclzrUl3vqPUb9VbWcXb2vbvveLz5eXw3W710HZ9VqeGbC 1X+eqt+e6ku95hDqF/rlXGne0p7ox/euqTTMhFLTJpYT81UcLHofFpNVNTjT D5+dmqBNbPQvzJElNjLJJ8irUTUub65WS3lWpYFjt+7K6xiODEXCI3rZgaPn Gq98O17dXTxSW7y+VdPB8ZrOMlmaV8CTqW5Rj3bxL6dC4Wc1sWQrVJIMitge qtNBWnunY2ntiPo9tna/6AVu7YfKqzCtPUTsDtjaDxG9EK093Ztkto64+zPR lof6ZuxmHwLM9e/MFO8+lMTGHP9QPijaqIHf3G7yfqF3eb/Q3IZ6KqXmN7NR FRVx0Uv6Wb//qHljqXJZLR6ir6LkUTStD2FrfNlpFP08NZvH9e1mZdrgzqp5 ObnFTxBRaRiDcRYP14xB/fKuXP05/ljEQ03k20fy8WpJkmZrNV0xNJJvmGle YcprQYxBNg4XVdkp13F4W63O9asfFY+q1KjDRJqki2rc6W/JKaVRXzMGC6nS qKwu1lmtll3n+jL2zfxcLRGU5oXO8ESc4VXSS6tGs9bT3MFKaQ3FUtXFaIvN uFErNJxxnxBJq2msYjnKNG3yfJ1MfTpdp3O8g1YEdKo81rGqVWbT6vyqmv5Z p08gNO4Nh8m4p6vmcHat+qPq3Nz2Ph/rOHV0BU1ylUS9OIdzbDhM80KjI6up JorUippmOdb4yGIo1buoup08V3rvrqvrc03wOS81N0iXQe5SomXRr/J1hSvP L27G59flO90Wko4WTLpyxXyY3iqOZlpU17ixriR9uV6/k/dum0R6bvq3c9XM RvqshlIue0o4k7ba4UVW9DpKWBfAeTkcVnMz79BZ2dEpT+WF0+9mulvR9yR1 TurTqbqwda9yIW5rw2SHg6p6yoZfeqEzMs3Eza0aDTcs1I1amZhqI6jQnSKu cy1bvh+eb1fs8/nVjS4Q3ewycVO56HV76bo8biPYT50K45ARrcZp2UQ0O9fg nnV0G9lRuR7NPpsoJ52iu87b0WQ5L1dD3a2Vmj+byru1otPPDBFXxbIhF+mK PtSVqaMHguXNdDEfSiKY503SzYSgX6fTIaHpxZaOi4qG9SZZVw/o9bfnq0td vuf6Qnmlq2Shm8xxJnecyR1ncp/pTO4i74w3/d0mcSPd2+UX8k5lNCyT3Q5/ o3mRuA1Pxx75Pnrkmr88nU1PluvDkQaXPIhO+v2d6lUMkjYOO9+lZ3lHjeJZ EqxHt8TEsUen1WQ9+p4W3KOTcZD36IycoEcnlRx7dFJT1qPTUtIe3a4m69EZ HbxHp5LnuDanJeVrc66qDYvdqpZkhVNd0wSgUSOll6amM89HLS4weKlxXHZu 68Vc09mX+j3En7WHkGY1IaobapE71g1hNL8xzclU/RFelE4Lb0qxV8ax8Vsy nkxH5zVbv1Kj6rpEe7rSdrRs/TtBYtO8KkwHu3x3ca5PZJyr3vp8uLy5Pr+Y mN2HNNHpzzI8/UW3KMpmqDavQc7V6D/U6U/XOwUtgzVdyA6bBXS7RTcLmBbm saCl65B4s+C+IuqxWXBfUZZPTen67jA1ZSIIT00ZHXBqSjYV6dT0OLM8ziyP M8vPZ2Yp3iug1dz2Co4d8mfXIcN7BSnyth86N1Bk7U5P72Ej2RYVt8GBURMN Dvta6OBAx0E8OHBy+OBAK7kNDrSmaHBgpISDA6EmGhw4HXhwIJPntu3ASIq3 HZgSEB8JoPVcjgRwitIjAYye+5EAumhcdiaYwpEdCWDE5Kt8ppmAq3yuQruv RJnykK7y7y2i7qv8e4uyeFJJ6zlMKunKGWdlVdZd7/Vser7xMqHru8lNvIbi 81NOB5ufMgmTzU8Ly5W1e5oUtoKFnCeFhJp4UritJZkU2uPgNCmk5GSTQruS +6TQrimeFBJSDpNCi5p4UkjpiCaF1uSJdwwYNacdA0bTqXO36zl27vayEHfu VFolnTulg3fuRMLCdO7w5kPRHeRtdyI//XayLSaOgwOtJhsc9rTgwYGMg3xw YOQEgwOp5Dg4kJqywYGWkg4OdjXZ4MDo4IMDlTzHHQNaUr5jwFU1/KACU5iS gwqMlMNBBbpM+YMKdL47bQdQin4HFcjEuh1UoNPvdFCBKWSHLQy63aJbGEwL 81hm03VIvIVxXxH12MK4ryjLZ7l0fXeY5ZKVUzbLZdIKz3IZHXCWSydMOMs9 TlKPk9TjJPXzmaSKdzBoNbcdjH/gvv2P2iGD2w6JOfNQ0McZEnPmgXkoNawE 9iFtrsM9lHUGsdvpiaTfS5JeN+6EGWbsUXEZZlg1wTBzVwsbZrg4CIcZXg4d Zjgll2GG0xQMM6yUaJgh1QTDDK8DDjNM8lz2QmpJ+y6tdC+E0ZPshXBSgr0Q Vkq8F0IqAnshXL7L90IYRZ+9ECaxLnshXPod9kLYQpbuhXBljO2F8C3Mdb3O 1iHZXsg9RtR1L+QeoyycL7P1XTpf5iqnYC+ETys29eZ1kKk3mzDJ1LsWayPn 8rPUTjeNs7zfDTlJbYuJ+ySVUBNPUneYyoJJqj0OTpNUSk42SbUruU9S7Zri SSoh5TBJtaiJJ6mUjmiSak2e+ySVkHSapJJVTTZJJQpTOkklpBwnqfYyxSap 9nx3naRaFf0nqdbEuk9S7el3nqQShew2SSXarWCSSrUwv4kUUYdcJqn3ElG/ Seq9RNlpkkrUd7dJqr1yiiepVFolk1RKB5+kEgmTT1Lb/CEAk9Ssr6xp/1Lh JqltMXGfpBJq4knqtpZkkmqPg9MklZKTTVLtSu6TVLumeJJKSDlMUi1q4kkq pSOapFqT5z5JJSSdJqlkVZNNUonClE5SCSnHSaq9TLFJqj3fXSepVkX/Sao1 se6TVHv6nSepRCG7TVKJdiuYpFItzG8iRdQhl0nqvUTUb5J6L1F2mqQS9d1t kkpFUDKzpHTwmaW9qQhnlkU+SDstYvXJAzOHaly3qCFXzSEnW+7T2OA307qH 0+5WtPvvW3+5S0Dj1csng2hcTrT3rNVMu6pYlcOV8SV3Xc6jB+YkRHRSPNye nxa9dkdo7xqv76ONAxg15X2ilhWTxg3vezUrLqLaO9oSENzxL3/RsfuXZzRO xstB7VFYJXPLobDxzjxbjIy7tVG5KrXLsuo2qRlyCCO746Or9SEdvzY8p2Om 2QV3Mq3MiUyjNVwzLTeZxuRHbjKtRz9UmIMyzEOdQVoMiu1XFSqeV7O3oyg5 zU+Tf056G6eEp0SgTXHsBNWO2d6uXbZ8FZ3pvuzs3fXybdR4OUQka69st56Q OqdJUTua+beZWkE+jB68HQ43v89P49Nc+2HrxEXcjR7MFyqjr6pyWakHnxoX OOaZ7CR7+DD65zR6c3kT6Uj0dIHGuX5t8+RZ7cqtA8RO+6w+Uel6Pxlpn4OX vy8n6pHo1eMXkeoBBoBCLVH10nhgHN9t/0Qn21/1x0P11YMb457wobt0rbMj XRprD1RJ65505CE+vhPvJA4lnuxnSjEe1/Y8M2WjsyudGWntoTD68ZfXPuLZ rnhnXb61uO4GXNXHd6KebGqPKMs7Wf/F19F3z7/97sWzF1H5Xo1qOkuRJtrr d1TQH376qzjk0xfPVZPOormO6RTqYhqHkS9O3kyutZfNn6KXargdaDeralGD CGjWSWlGfO12Ulk2HdTy1u9auYq6mzx8q5pxtC6wQb/JbiRHv76ZXK2iJNKE lavJcrUEwnxv/ja7iXqXSy1PKtUBq87uq7NR9f5MDUmJ+ifSbepvoscvnz+J RmuHphe/mxqkx4HfZzfRUPWFte/PSI2WZmD64qqcT4ZfAPrPp5PVpLya/JfO sCcvf/7nGAj08vlTPUm7jGp/bXrqPanUOJnH/U70wIyKAzUbeRR1iiLrqPiu qiWS008bt72qJnZPk7QXvfjuv6Jm5jxbILWq9nU7v15dL6LxTE0lJ28vT1TV qPfiTAUBVJ7MpsvZVaW3OK9UmOiXbx//OeqpNUABJUKvRFSpDC+r1lxKsiTu ppt86j6KijRPez08n57rDdcTu4U629cG1Iwx7aRq6YAbeFFdzxa/q6gWavRN Ou/OkqKb9uL43W23ED1Iup3kXRMk0mswZSc2D637K5WyJH9n+sVHkXr8nZqF TVamWqR99S9dOtfVNRKjJ5fV8J0u28k4Wl1OlrfVIrqcTVUh1W6M//oyulCN oHpfTbXrx+WNWou8n+inzPTs9DT66R1Sj56oJnGxqHuXUXVV/t74uF6Zzmo5 r4aT8WSomvCNekTpqtT1i9N+P/p69nb24vnL19GDq/l/fpUVfX3CGEng62p4 s5isfo++WZTX1YfZ4l30PlEznNjkmWmiW+shQueZmWmpUWbjAFn1gxeq60HS /ULPdImaVSQpknsvf1Y9VxI9V/molFQVzL+PHnSaCnime8OHj6KnTRtp+SVs I11bSIuOi4p2VnylpnjDSxUgGupKFpUL9S/dEd0sKl2D6l01JPfa1BbVel26 9s+spremo0UUr1cL1YLfp6oaPFBT2TQukj6cO49fPI0ery6vZtMHq+uH0ctN i1ErmPlcRylGSvOZjrd+eqzX6N+8/Dlalu+r+u2NWlLMFqZdjdToCLWsdUP+ 8vJq9aWq3MvV4maoPUCa1vk9PndYu61+9sOTV3rZrnJH5dJ4MbuO4qqEhvbh Vq8yudavb1TPotubaoPjpYqQXn4up1+uogcX5Sh6+1+TuSret6rlT2+uL9Ra 5eH/NDv8SzXCv9NZUgdG2uk3i6oylk2A6LrpcfN+oTpGDQtDRFhn6cjap87N ixvVg/4+r6L5cKLKdS2JzAaeNJ6/zaRkUan+tnF2G0f1WKg6oPjj+CLpxo/q jR5l7KsEla7H9F3/oSamiEKduNc3F826/TZ6akYf96EGUGsYv+Zqgqv+XDdl OGydBD2J05OSzcvlZvx4C+voXH6luvLo68VkpGrrr+qL+LfogZnTYrPZWujx cnlzXZkZaXTRaP2v89dfn5/Wiro2qKYATQZVnP5+M1m8G5hqo7JWz7JPOnF3 HA2vSjVgmhnr+1UvHXZ6nei7v55cz6ZOwoUWVn+0C79+8bUoI28d1W97pX/w /NW/L9VsP4vyqIg6UTf6F1WPk0TNZ42f+ALPZIuRr9uMKBv/EtLIk10j/7Kx EtLI07sp+RcXI/Xe0Murm7dmVHmp51uv64E3eh+f9rvRg+HD6PGovI6+1pMx QHI+Vcu9l9OXJgGmk5UGGqi2eqNio5KjlmyTYYWs+1Rg3QsObidfqoaaKLz8 8aWswzOhdHehcljQURiF5+OobGKtBubKjGB6Svko0t3xF6qL/0orVpPF3784 jfTjaqDTO/fLR9oh88p4btbZjxqs+6N6O2Og/1NTV2QnRK/7P0ymo9mHwWZ9 i8wAokjvUaxDVs2y/qRKxuYHUnj56tk3z948+e42Ar1GZjSGZZoljJpg30xV Zs9navBdqqm6nvMa9idSa375pq4x71R/N1uVy2ik/z7vnBanyBj3VD9NTNqT OM2b1WCkRmCzShesNbc3CBa/z1ezt4tyfqnmQI9fPgcEJrNoqWI2urlS5qez 2Vw2u9gJXk5Xk+FkbnzYe8iMqnKkVwgeEsPx32WhH8/nV7/rPPzl+WO9l766 bMZd3S7Lhe5qkIpvWlvduRixSWmOW5k3G2aXCO8plIjp8F4Py+nUzO9VZ6N7 v2G5GOnJr0Djx1ndff9vdefddD2mA0US9eNL9cfrs1TvvKwWsyudw7+qb+Ms zgYvX6ffP9L/GCfmHy9+qyeUnfiR+iOPVCcWJY+ghemyWkxmKta9OE+jxz// zbzia1ETa33/9VObFrT2X6gmNoh6aRGfJZ2iUEPOYqJfhf73V818VbXi034c /Xc1zGo7qp/Ww8LyslxsLS3BWJdX2tAgWq1+fx3rGD8/+ynS53960QMd5a+i /KGe/ZWRictjB9nkVja9lc2ksnok6QSNqFbsBo3jK7XMfv76+3WJbe3WqDLr mFdIamRTS8TZOOol/fR7Mz7UnXJ9LFL9M8BaD6mzk+n8ZqX6ojfRm0U5XV6Z g4qvq1WUqkd+v5jpa/9q+DlT0+vl8sw8Xf+JDObPX5rOpyK2Pr03Jt88eRnp 15iq91uqrrjVSKO5ttJ7pPI67xVdwaCnzVyoWcHBEjGIvtsoLzdrW5WgB9up WwvrmBiraNwX1XQmG57qFA9lgeqJ6nM1T319qTql4c3KbLOCy4roQ/muupmv Z9eDCOkpf3j5tR4D4+jn11+bP5Lo58evzB8pIlDP7B8023rLSPUrqiN4nUev oZVK09gH0dDsEG2fCKhXC3qvVTdqaOm8UfthVo50Vurdn+8nX0e/JqbP+E1v FaiCVOse/U+9QfZ//8d3Z//x3cl/fPe//uO74+fj5+Pnz+0zuhFuFn0vmpNF ZiPuwZ1O5WGkz9TNple/I4rrLeWb6c1SaTZv5tY7y+b9W7CNZWR0mJqLGdGL m6vV5EStC1bmn89Onj99tp4t3U5vu6dxXF7NL0toHjOqmj1Mnd4s0++Jm25Y 71wu55U+raWXM89/MkPS8n9GM2VPrbiq+g25+qA3oT9+RErq5bmKsprgqHgP bxcoqqvX+2LLK1V0m32PLrRiN6s4vXbTk/jx5KMaBXVst1UeReZNRloU5t2G IJrDy8l8qeZ0m61u5CXAOvBUJSaJ4//xP6JpuVJFZHJvoPLs6kpXgotKL2qW kZ45LgSyetG73qi90Ada3kd5/NDk6M9PXzxWFrdzVsV5PpwI81T/qFJVC5Cv X5wozXopNtL7Oeav7qP6BUXz2kjNNy5H5UA9+Egfq9QfcCPJHSO92si4xchw bWQ0mE+QMx86XtHrN1mi3/h1VNDHbx5Ht2sMSOHCKCiBnpuCzsk6cclYZ2Ay 7j7SK6+OLhyzrs2heAzVTPeHk6dvTl6/iZ7+8lSvhr59/fgkTzrdr0201Dzw ydMz9auTVz+9kEQvaaLXNdHrmuh1b6OHHNUwGX1dflRN5e83lT40aXbu9NJM zcJQgTTLc5WevKePp65mi2X0QJdclkcvvn4YfTgziz41qTNvqh9FT757/VXS yXrZmWrbZ53skWkBDxLs9Y2xWC+wxlc3apWwvH1FjdRfE94cP1J/pPqPzByQ RSuVX24pgawfd9Ok39nKLZVZcd6351aaZ2nimFsXnrl1YUR0bl2k0b/qvwpz Clv/0dV/9KK/IO/Q10eJn//4zU/6fdZQD0e/m6ycLOpDAeuhfmv8R0b9jbS5 UhPVt6bqDvui2hw6GN2YjaK1YegQsNuZbCCmm+TrS21X1QqaL/mcxibWgyOz 8Er6Rb/X672Llh/KuS6M5pjeRVel+eViMtNHcwYnSXO3dTlQvc9wMVuqD01I MAW3Z9IT4kw6sWSs1OP6yGT0xCwzn9bzqPfJKbRp+W01rRZqmf/qzZOtoHEX 7cvrDjvr/S1a99jm7xPdrz9RH85e/bXuw/VZsLz3btOOTavNMqTRrueNT7aG hO2ZYnaaItOh68mwanaVVY1ZVutN6fqGt5lv6Zsi+jFA7Wo2m+s/S30+/IHu BXvrjQvodNeT12qmuDmFIDvSpeZC55ez1fzq5m39KvY7NUkz2+36H09mi2p9 bn4QxafIwLe8nA8v9db/mvW5p7iZia3ryK08MlLcLC/05eXB1m5SNK0+rItS /XqM9BeMzOXNhfT91c+vv45elKp7fK1GHn3cp5bC3nXwqTpZ1rJIJd+PSTMu bYlD71/qDd3n16ae/zB7qw+uXUZ/vazUyu+Fqfat+7nIhLqu3ifX5XyuNzrz 0/w0PpnMhqsrM2QXJ3FykqQPN5V5qXe8R9cnKlx19W8qAZfl6lS1NqR5fPs8 +pvqGU0//vjJD8tHelipz0OWq9VicnGzqtSXaoi80kcw9TGihcq0equtOYv1 SC1eIr2sk7wPWVv+d/3iVZXIVJXFtaYXbBorIKIFzKhk3qLdDkt6ioXEYX1g XetsxkbdR22kBvV07YG+l1O9H2xGDqTveTYdHU78IJME7OLWP9ZE47AZRV4L /MfKqPowUPl2/lZlU52ocanG7ffxaRIn5iTQU33+9H+fTaHDFfNyoTvW8/mw 3oZQ/1bjvuoeTXe7uVQxmZqVOyDYS7L+ajaLvtEnGZ+tLvXXq/UoEJ/2T1Nk OsUdEVtP3PU7ylf/HiXwttL6WGwdSnf/V7pDPlG96Nu36GGFlshttmP6p/Gv j3+LTv6yE1/1z2/VHEdZfGDs6UuDHx7qr+HoV6vLuJ7hvqneqSnqDzqnmx2W oQbLKOt5PBjng4vxoNKeNh/h4txpub38RmZRd7K7OEBul3dz+8kmt4vWzEbi rucfaqKtJ3aqx/hO/2pr2vd80+qaav0+Pc0CnBbcy2SkndzJ5O4BMrl7mv76 dDeTn24yuduayUjcby71zH042jGk8v47M4ffyXJ3NT0F1aWpN75vJ4+PVC4t J2+n+gSi+kU9RYK27S1m9KZa95E+BHVRqlll/FH/epTHyFJMzdSj5CQeqJVm XfP0F+jhoJ3AaX36RU3z6pti/gWffaqCz4IWfCYreGQaajHTXvA9uOBTn4JP PQpeLchUxWlayPhGrfXr90I6Hs1eQH2pa5Nwffi4HI0WegMNybG6aqY+9boJ nMuTV4+WV7ra3sz1GZf4xYU+v6tTejK6UbO4j6rizkt9o7Z4tt/ydyC789Gv Sb+b/rZhBNyJQBtT4vlUPXtljiG+0xQONTWbzX9XXfLlKnrw5GGU9PudaPZu svi369m0HJ0uP1ycjqqH+3PANukfv3n9dH285Ox9uTi7mlycKRtn7/PNTLWs b/ypR9/nek69qm5nsaPJwmwu758Ut9vaXBruxyf1HDx6u9AD4Fwf89vPjjYo CvvKdL/BtIlczbaOjr9UY285/D16pvcc9f7L/nS3TeH5y/cd865Tf8qj1c1U fW2uMZqRfE+h1RXM+8lool+MzPRRV1XDhsp6FX354y/Pnz5//GW0KtWkfNk8 vl+abYLclYv9qe5+RrVp3p3qxvy8AI1c3QEmqg+8O/l6fDvVjdunukj0f/zl 1Yt6O1HHv87ZZuXzsddZf/F9/Qb/RV0QkeopTnpJtxdFf1W59bQamhsWykg6 KJLoZU272J785XtdRws4pDuI99pF60P7jaf1oTzdhc8sL29Wo9mH6a9pmhS/ Dcy/6xu16kuzAbveJymvVrs6aZtrEYgUxAVHSEF2jaZErmZv32qBB/oW8kPV eczm8+0NO0RArYorvRG90mC6qblqvC+wXXY6mdqkCqGHdzVp33rF2R9k2SDb RvQA+Je7gTZ7Fa74F7vk54B/sccOxb/YFbzxL2JpCf5FLC7Bv0jFBfgXmbQQ /yIXl+BfZOpC/ItdnMW/2INy+Bd7SCv+xR4ExL8QAmHxL0TfYMW/2MM0vTyK fyG6Tf2NN/7Frk/gX+yB/PAvRDXawb/kcWTBv9gVJPgXuwqAf6ESEQj/QhVa EPyL3cB94V+IIjkE/oUw54B/6ZyqfuYO/kUfBEMSKMO/EDoA/oUoeAH+hci9 YPgXzgaGf6Fakhz/IlND8C92RRr/wuSOCP9i13LBvwANmcW/cHMHGP9iFzo4 /sVuWoB/sYsI8C9cbnL4F2I24It/YaQB/AuXOAT/wmlQ+BcuLIp/YafLKP6F ExLjX8gy8sG/SIRx/AuSkd74F0cjMvyLoxEZ/sXRiAz/wu0NOeBf7JIE/gUM ROBfiDoL4V+gDo/EvzAK4fEvjEES/0LshND4Fyoghn+hFAT4F7uMAP9iF4Hw L8SK0x//gm4QWPEvdgEI/wIG5/AvoAyFfwElLPgXoiOV4F+Y1ibBvxDpgfEv vAaCfyESFRb/Yjckx7+AWgj+hVr7B8a/0LF2xr/gsiK0il3WFf9CK7rgX+yK YfEv7ms9pM4GwL8QI0Uw/IvdRlD8C23GF/9CqnvjX+i42/AvXIpb8S/cbrsd /0IvK+z4F6KnxPAv3HqGwb+wjV2EfwHUjviX4+fj5z/GZ3Qj3BX/wm8pw/gX j41lZHTwxb8Q85gD4F+IknLEvzCrODf8Cx9NAv/CB3bCv/CywfAv1IZOMPwL ayQE/oXYUwLxL5QChn8hWxiMf6Hi4YV/IaMH41+YjOaBJozAAfAvjEUOaELU Xxb/wlQqv9w6DP6FseiVWyL8C3Gg1u3yL/FS3uPqLbE6Cg5DoVOAwVCIBRQC Q7EHZ2EoTM8WDobCz6IgGApxkMQBhmJXg2AoxCqeh6EQL+kcYSjE5mUIGIpd XgRDcZbZhqGAb3MAGIpPqu7AUIhKLoGhsNubHjAUu3ZwGArRPA4MQ+EtAzAU uwgEQ/nEQyUGFPnUw+1hk0oiQT51Ut2gHsQo4Ab1sAtKoB7uB3/sUA9mswCH esgit1lke0I97FYDQD3cz0BZoR6C7CahHo657QX1oMdRV6iH+xkwK9RDkMkk 1MMxk72gHsTMxwHqIVZzg3qIzfBQD2IJxEM9wMBWtoNzwXtAPWR5yEE9xGpu UA+xGR7qQZcdA/UAAzsUfCioB1c1SagHGNgK9eBGSznU465iDfXoFK1QD2qF 6An1qKVbmQfBoR6cLRTqUev0XF6E7TeYNhEU6mFXQKEeRiFvhR+4QT3sgu5Q D7umEOohi1zdAfpDPexWPwXUQ1kvBkmxZf2WspH0M4qysaj0NcBdpbSNLARx NrjgCGfDrvHq5ZOBamMTXYNWM/NysByuTH96Xc6jB6pMp7PopNjteCxiTY5z 0A5EgIR21ALbBBQK2pEm6tlBvt0J89COlkCb3QRHaAch+RlAO4jYgdAOQsEX 2iGXFkA75OICaIdYHId2CKVl0A4HcQG0Q6gug3YQ4hy0gwjKQDuIkDZoBxEE g3ZQAkGhHVTfYIN2EGGaXh6EdlDdpv7GF9pB6NuhHUQgL2gHVY12oB1qytIO 7SAUBNAOQoWHdpCJCAPtIAstBLSDMHBP0A6qSA4A7aDMuUE7kjZoR5ogCRRB OygdHtpBFTwO7aByLxS0g7UBQTvIliSGdgjVAGgHoUhCO7jckUA7CC0HaAfS kDloBzt3QKEdhNChoR2EaRzaQYjg0A42NxloBzUb8IR2cNI8tINNHADtYDUI aAcbFoR28NNlENrBCkmhHXQZeUA7RMIwtAPKSF9oh6sREbTD1YgI2uFqRATt YPeG5NAOQtIO7UAD2aEdVJ1FoB1Yh0dBOziF4NAOziAF7aB2QkhoBxkQgnaQ Cji0g5DBoR2ECALtoFac3tAOeIPABu0gBBBoBxqcgXagMgS0A5Voh3ZQHakA 2sG1NgG0g0oPCu0ANABoB5WooNAOwpAY2oFqAdAOcu0fFtrBxNoV2iGQlQAx CFlHaAej6ADtIBSDQjs81npInfWHdlAjRShoB2EjJLSDMeMJ7aDVfaEdTNwt 0A42xW3QDna33QrtYJYVVmgH1VNC0A52PUNDO/jGLoF2IGpHaMfx8/HzH+Mz uhHuCO0AtpRRaIfPxjIyOnhCO6h5THhoB1VSbtAObhXnBO0AommHdgCBXaAd gGwoaAe5oRMK2sEbCQDtoPaUMGgHqQBBO+gWhkI7yHj4QDvo6KHQDi6jWQwF JxAe2sFZZDAUVP3loB1cpfLLrYNAOziLXrklgXZQ79DXN2Gf//jNT4Pbewg6 KyeL+lDAeqjfGv+RUX8j/WExUYvvcqhf8tcd9kW1OXQwujEbRWvD0CFgpyvF SEw3yR/OrudX1QqaL3lcJqbWg6ExJUwKIEwJtWQEMCVEcA5TwvXldYed+2NK gHkjgimhjs7IMSWEGoIpofYtWEwJ9VrSDVNCbdcGwJQQ8hJMibvMFqYEfX/F Y0q8UrWPKaEquQBTwm/oumNKCO3QmBKqeRwWUwJY5jElhMjf9FJeHxDbPhuG hlMVQQ2kk5G+n1jfUrqvsRkim3zyEfqwSaXIJv9gUxknLgo17DhxUQhBARfF 42yVlYvC7cfAXBRh5Db7GH5cFMKqPxfF45iZjYsiyW6Ki+Ka2z5cFGbgduSi eByzs3FRJJlMcVFcM9mHi0JNteRcFLmaExdFboblolBrLpaLgga24THcC96d iyLMQ4aLIldz4qLIzbBcFKbsaC4KGtih4ANxUdiqSXFR0MA2Lgo7Woq5KC2K NRclz9u4KOSS1I+LQr23C81FYW2BXJRGx4+LQoiAXBRCAeSiKIWsGBRtoBjn lYpNcHdRlpIrFUqDX6mwoZ1WKllHTXqDZpRFUJRRhIZXUpN8S3WLpJJ2cZJK rZS2UncAkgobHCCpEBrf1ycKGPgJJEDBTxqBbXoKAz/JuoN0u4uC4Cf7gTa1 0x1+YpP8POAnttjh8BObQgD4iVBaBj8RisvgJzJxEfxEIi2Gn0jFZfATiboY fmITB+AntqA8/MQWkoCf2ILA8BOrQGj4ibVvIOAntjBNL4/DT6zdpv4mAPzE pk/CT2yBfOEn1mq0Az/pFpEVfmJTkMFPbCoQ/MSeiGDwE3uhBYKf2AzcH/zE WiSHgZ9YzbnBT+I2+AnWy0jhJ1YdCH5iLXgR/MSaewHhJ7QNFH5ib0ku8BOJ GgY/sSly8BMyd4TwE5uWG/yEbcgA/ISeOwjgJzahTwA/sZkWwU9sIiL4CZ2b PPzEOhvwh5+Q0hD8hE4cBj+hNWj4CR0Wh58w02UcfkILOcBPiDLyg5/gwhL4 CZ+RAeAnTkak8BMnI1L4iZMRKfyE3htygp/YJEn4CRSIhJ9Y6ywIPwE6PAZ+ QiocAn5CGmTgJ9adEA5+Yg+Iwk/sCiL4iU1GBD+xiYDwE+uKMwT8BNsgIOAn NgEQfgIF5+EnkAwNP4EkrPATa0cqg5+QrU0GP7GmRwA/4TQw+Ik1UaHhJzZD LvATSAuDn9jX/sHhJ1SsPeAnqKwQLGKTdYefUIpu8BObYmj4ietaD6mzQeAn 1pEiIPzEZiMw/IQy4w8/IdQDwE+ouNvhJ3SKLfATeredgp9QywoKfmLtKVH4 Cb2eYeEnTGMXwk9YtSP85Pj5+PmP8RndCHeHn3BbygL4ifPGMjI6+MNPrPOY g8BPrCXlDD8hV3Gu8BMumiT8hAvsCD/hZAPCT+wbOgHhJ4yRMPAT654SDD+x K6DwE6KFCeAn9nh4wk+I6AngJ2RGIzgPUuAg8BPSIo/zsNZfAH5CViq/3DoU /IS06JVbQviJ9UCt83Fv20t5v6PattXRAVAgVApQFIh1AYWhQGzBARQI2bOF RIFwsygQBWI9SOKEArGpgSgQ6yoeQYFYX9I5o0Csm5dhUCA2eSEKxFFmFwUC vc2BUCDuqWpBgVgruQwFwmxveqFAbNoHQIF80sECvhv0SQecAyeVhnj8kZLK QDw+bVJdMRzWLt8Vw2ETlGE4XE/5UBgOcmdAguGQRG6zovbGcNisBsFwuB54 IjAccHYzGA6n3PbEcFCDpjuGw/XAF4HhgDOZwXA4ZbInhsM6zXHCcAjVXDEc QjMIhsO63kEwHFBggsbgWPBeGA5JHvIYDqGaK4ZDaAbBcFBlx2I4oMAOBR8O w0FXTQbDAQUmMBz0aOmC4dhXrDEcRd+C4bAvB70xHNY3SAfAcNC2cAyH1vHG cNhEcAyHTUGA4egOsrhFYfp+Mprove2ZPq2oathQWa+iL3/85fnT54+/jFal mpQvm8dPAUHu1Pz+VDcGNO9OdWN2XgBHru4AE9UH3p18Pb6d6sbtU10k+j/+ 8upFvQem41/nbLPy+djrrL/4vn4J+6IuiEj1FCe9pNuLor+q3HpaDc0heU16 GBRJ9LIGFmxP/oqY7BlPXfvG7algoXqw7Xr4Vp9HGtVwhpM0LfoPtxrXg1uE Q5Kfxg8fRfPJKNJPKXOqyn6pQ30pVH9VLWdX76vb6H3x8fpqsH73PTirVsMz E67+81T99lRfrDYHgb/QL0hL86b8xMDDd68KNdwKVTPns+XEfBUHi54Bjg/O 9MNnpyZoExv9C3NsjI1M8gnyalSNy5ur1VKeVWng2K1HgjqGI0Py8IietBpL o+car/xP//R5/iyvVTserq4OacOgMfL8n5pbGft/d+Mi/ackzvOsk+RZV32f JFnW+acoPmSk1j83uieLon/StYJ6jvv9P+iPZu1EJ/V5o5Po1+j/jdRgqG+3 Li8f/qn452hdP6KTx+u3fuWfNl+u+/7iNOtEv046vc7JfHhypQe9k7fTm9/U omh7+qjPL5x0oq8XN6p5PFZLpemfvptdV+ZejD5lfblazQdnZ0ZeTTBXs9nV 8rRuTePZ4m11Oq1WZ3/601dffRW9fvP41Zvop2+iV88eP41ev9D/eqpPNbx+ 9uTN859+jNRDf6q/fryhZUdP9a7la3PBWF/m3pyIqZdU+t31n36ppqPZInq9 vtJ/R8Nsg765VL3F5exqtBz86fnTf44ev3nz6vnXP795dv7j4xfPos3PNz88 /tZ8+OXxDz8/i/760ys1pL/57tWz199Fb/6Pl82TP79UUX/2VE0Cvnv24/k3 j5//oP7x6vFfz02oP6lpQvSq/HD+SvU3588Wi9ni/JWeG+sfs3Yb6w+djv6z 6Oo/Y/1ZTTarE43PjlRefyh/XzZxOmn+TjpJJ+2kqdLPVHon0/Of5+fm5enW j9HP9Ie+Ue4bK3EM6MdKONcv0Rar89er2fz8id5T3hbOUh0NI1b/GadG+Ker 0bmuEhbhjhIuzKai7tzVyub8tVkanD9ZrYWzfeEMyREd4270uqre7Wfzblb3 EpPhtTCSFUnWT5M87euY96OXsw/V4vyn6fl3hlOxY8BkSdzv3f4ZI1mSFkX2 Jz19NeX4qlotfr+b3cmdXDFlCuRKkjaRfvL78KraUfYox24/+1PSz6M31bVa kpW6SZ4/qa6Wk5vlRjo1+ZGbnCgSOD/ynlIuou/KxehDqWSfPXmicsUsJdVg X+dGGe23GkR502oSlXlPbhaLaro6f6k6DTUZbupho38nUyD9WAn3op/GY30h 7fzn6XC20AtfM3dshGNOuAl9V7hvThqcP3n1pKngm5I0xahDpEYsFcVYP21O dZ7/nzMV6Z22U28ubeKaFpkgxmmcRm8enz+fDhea9UZVPIuwJcZ/Ise9Tuu4 d3Ec9z7LcS/ZasHQuKeGh7Qbx+i414/2+uL7GvfSfn7fI1/XZINg5Ov2Okmm hj504Ovf/ol1x2m38w838GVJig58hfkTH55UgAc/TMaVBlNFLybTsxflxyg+ S3oP0QGxbk4d2OKmOR0HxI3wH21A7P5z9LluYBx/jj/Hn+PP8ef4c/w5/hx/ jj/Hn+PP8ef4c/w5/hx/jj/Hn+PP8ef4c/w5/hx/jj/Hn+PP8ef4c/w5/hx/ jj/Hn+PP8ef4c/w5/vz/7Of/AxLUb4IAIAgA --------------070404010101010005070107-- From owner-xfs@oss.sgi.com Wed Jun 14 07:58:47 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 14 Jun 2006 07:59:11 -0700 (PDT) Received: from moving-picture.com (mpc-26.sohonet.co.uk [193.203.82.251]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5EEwjDW015898 for ; Wed, 14 Jun 2006 07:58:46 -0700 Received: from minion.mpc.local ([172.16.11.112] helo=moving-picture.com) by moving-picture.com with esmtp (Exim 4.43) id 1FqWp9-0002aF-8T; Wed, 14 Jun 2006 15:58:27 +0100 Message-ID: <44902413.20305@moving-picture.com> Date: Wed, 14 Jun 2006 15:58:27 +0100 From: James Pearson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040524 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Sandeen CC: xfs@oss.sgi.com Subject: Re: XFS + software raid + 4k stacks = BOOM? References: <448A98E8.9040109@moving-picture.com> <448F8C8A.4070008@sgi.com> In-Reply-To: <448F8C8A.4070008@sgi.com> 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: 7938 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: james-p@moving-picture.com Precedence: bulk X-list: xfs Content-Length: 613 Lines: 19 Eric Sandeen wrote: >> >> Do you know at which point these remaining issues got resolved? - for >> example, could there be any potential stack problems using RHEL4 (U3) >> with the XFS module from >> ? > > > There were more stack reductions after that. Which is -not- to say that > you -will- have problems with the above... all depends on what you're > doing. But Nathan did more stack work after I put that rpm out. In my case, I would want to do NFS serving with XFS file systems - some of the servers may use software raid as well. James Pearson From owner-xfs@oss.sgi.com Wed Jun 14 09:49:45 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 14 Jun 2006 09:50:07 -0700 (PDT) Received: from soloth.lewis.org (soloth.lewis.org [69.28.69.2]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5EGnhDW011671 for ; Wed, 14 Jun 2006 09:49:44 -0700 Received: from soloth.lewis.org (localhost.localdomain [127.0.0.1]) by soloth.lewis.org (8.12.11/8.12.11) with ESMTP id k5EFJZx7011134; Wed, 14 Jun 2006 11:19:35 -0400 Received: from localhost (jlewis@localhost) by soloth.lewis.org (8.12.11/8.12.11/Submit) with ESMTP id k5EFJZYx011130; Wed, 14 Jun 2006 11:19:35 -0400 X-Authentication-Warning: soloth.lewis.org: jlewis owned process doing -bs Date: Wed, 14 Jun 2006 11:19:35 -0400 (EDT) From: Jon Lewis To: James Pearson cc: Eric Sandeen , xfs@oss.sgi.com Subject: Re: XFS + software raid + 4k stacks = BOOM? In-Reply-To: <44902413.20305@moving-picture.com> Message-ID: References: <448A98E8.9040109@moving-picture.com> <448F8C8A.4070008@sgi.com> <44902413.20305@moving-picture.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-milter-ns-Report: lewis.org; NS 5538 ns2.atlantic.net. [209.208.42.140]; NS 5538 ns1.atlantic.net. [209.208.0.7] X-archive-position: 7939 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jlewis@lewis.org Precedence: bulk X-list: xfs Content-Length: 743 Lines: 18 On Wed, 14 Jun 2006, James Pearson wrote: >> There were more stack reductions after that. Which is -not- to say that >> you -will- have problems with the above... all depends on what you're >> doing. But Nathan did more stack work after I put that rpm out. > > In my case, I would want to do NFS serving with XFS file systems - some of > the servers may use software raid as well. AFAIK, the 2.4 kernel series XFS CVS still doesn't do NFS service of XFS filesystems. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From owner-xfs@oss.sgi.com Wed Jun 14 10:20:35 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 14 Jun 2006 10:20:56 -0700 (PDT) Received: from soloth.lewis.org (soloth.lewis.org [69.28.69.2]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5EHKYDW014836 for ; Wed, 14 Jun 2006 10:20:35 -0700 Received: from soloth.lewis.org (localhost.localdomain [127.0.0.1]) by soloth.lewis.org (8.12.11/8.12.11) with ESMTP id k5EHKC6H012623; Wed, 14 Jun 2006 13:20:12 -0400 Received: from localhost (jlewis@localhost) by soloth.lewis.org (8.12.11/8.12.11/Submit) with ESMTP id k5EHKCsM012619; Wed, 14 Jun 2006 13:20:12 -0400 X-Authentication-Warning: soloth.lewis.org: jlewis owned process doing -bs Date: Wed, 14 Jun 2006 13:20:12 -0400 (EDT) From: Jon Lewis To: Evan Fraser cc: James Pearson , Eric Sandeen , xfs@oss.sgi.com Subject: Re: XFS + software raid + 4k stacks = BOOM? In-Reply-To: <44904063.7010606@dneg.com> Message-ID: References: <448A98E8.9040109@moving-picture.com> <448F8C8A.4070008@sgi.com> <44902413.20305@moving-picture.com> <44904063.7010606@dneg.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-milter-ns-Report: lewis.org; NS 34358 ns1.atlantic.net. [209.208.0.7]; NS 34358 ns2.atlantic.net. [209.208.42.140] X-archive-position: 7940 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jlewis@lewis.org Precedence: bulk X-list: xfs Content-Length: 779 Lines: 17 On Wed, 14 Jun 2006, Evan Fraser wrote: > Hmm, well we've been using XFS on software raid's with a 2.4.29 kernel on > roughly 10 NFS servers for over a year now without problems. Though we are > rolling them up to FC4 as they become available. Using who's kernel source/package and XFS version? Last I looked, the SGI XFS CVS tree [for 2.4.x] was based on 2.4.31. With it, you can export an XFS fs over NFS, but the clients that mount it cannot actually open any files. Trying results in i/o errors. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From owner-xfs@oss.sgi.com Wed Jun 14 10:59:47 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 14 Jun 2006 11:00:10 -0700 (PDT) Received: from jabber.dneg.com (mail.dneg.com [193.203.82.196]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5EHxkDW019185 for ; Wed, 14 Jun 2006 10:59:46 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by jabber.dneg.com (Postfix) with ESMTP id 69C1CB7338; Wed, 14 Jun 2006 17:59:28 +0100 (BST) Received: from jabber.dneg.com ([127.0.0.1]) by localhost (jabber [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01342-03; Wed, 14 Jun 2006 17:59:23 +0100 (BST) Received: from [172.16.11.2] (prague.dneg.com [172.16.11.2]) by jabber.dneg.com (Postfix) with ESMTP id 8F9F2B7350; Wed, 14 Jun 2006 17:59:15 +0100 (BST) Message-ID: <44904063.7010606@dneg.com> Date: Wed, 14 Jun 2006 17:59:15 +0100 From: Evan Fraser User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: Jon Lewis Cc: James Pearson , Eric Sandeen , xfs@oss.sgi.com Subject: Re: XFS + software raid + 4k stacks = BOOM? References: <448A98E8.9040109@moving-picture.com> <448F8C8A.4070008@sgi.com> <44902413.20305@moving-picture.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7941 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: evan@dneg.com Precedence: bulk X-list: xfs Content-Length: 1155 Lines: 35 Hmm, well we've been using XFS on software raid's with a 2.4.29 kernel on roughly 10 NFS servers for over a year now without problems. Though we are rolling them up to FC4 as they become available. Evan. Jon Lewis wrote: > On Wed, 14 Jun 2006, James Pearson wrote: > >>> There were more stack reductions after that. Which is -not- to say >>> that you -will- have problems with the above... all depends on what >>> you're doing. But Nathan did more stack work after I put that rpm out. >> >> In my case, I would want to do NFS serving with XFS file systems - >> some of the servers may use software raid as well. > > AFAIK, the 2.4 kernel series XFS CVS still doesn't do NFS service of XFS > filesystems. > > ---------------------------------------------------------------------- > Jon Lewis | I route > Senior Network Engineer | therefore you are > Atlantic Net | > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > > > -- evan@dneg.com Linux Systems Administrator Double Negative tel: +44 (0)20 7534 4400 fax: +44 (0)20 7534 4452 77 shaftesbury avenue, w1d 5du, London From owner-xfs@oss.sgi.com Wed Jun 14 13:16:02 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 14 Jun 2006 13:16:21 -0700 (PDT) Received: from ruth.realtime.net (ruth.realtime.net [205.238.132.69]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5EKFxDW005225 for ; Wed, 14 Jun 2006 13:16:01 -0700 Received: from [192.168.2.120] (cpe-72-177-24-78.austin.res.rr.com [72.177.24.78]) by realtime.net (Realtime Communications Advanced E-Mail Services V9.2) with ESMTP id 127627060 for multiple; Wed, 14 Jun 2006 13:55:26 -0500 Message-ID: <44905B9F.5000401@GrovesTech.com> Date: Wed, 14 Jun 2006 13:55:27 -0500 From: John Groves User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Question about sparse files Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Server: High Performance Mail Server - http://surgemail.com r=-1092531819 X-Authenticated-User: jg@bga.com X-IsFriend: X-archive-position: 7942 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: John@GrovesTech.com Precedence: bulk X-list: xfs Content-Length: 405 Lines: 11 A question for those who know more about xfs internals than me: If want to create sparse files that XFS can handle efficiently, is there an optimal minimum sparse chunk size? I can look at an data stream for null segments and make them sparse, but I presume I shouldn't make 1 byte sparse extents. File size will range from small to multiple GB, but large files are the norm. Thanks, John Groves From owner-xfs@oss.sgi.com Wed Jun 14 15:14:50 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 14 Jun 2006 15:15:12 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k5EMEbDW028395 for ; Wed, 14 Jun 2006 15:14:49 -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 IAA28115; Thu, 15 Jun 2006 08:14:08 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k5EME6gw916450; Thu, 15 Jun 2006 08:14:06 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k5EME4Nn889832; Thu, 15 Jun 2006 08:14:04 +1000 (EST) Date: Thu, 15 Jun 2006 08:14:04 +1000 From: Nathan Scott To: John Groves Cc: linux-xfs@oss.sgi.com Subject: Re: Question about sparse files Message-ID: <20060615081403.B918399@wobbly.melbourne.sgi.com> References: <44905B9F.5000401@GrovesTech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <44905B9F.5000401@GrovesTech.com>; from John@GrovesTech.com on Wed, Jun 14, 2006 at 01:55:27PM -0500 X-archive-position: 7943 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 625 Lines: 19 Hi John, On Wed, Jun 14, 2006 at 01:55:27PM -0500, John Groves wrote: > A question for those who know more about xfs internals than me: > > If want to create sparse files that XFS can handle efficiently, is there > an optimal minimum sparse chunk size? I can look at an data stream for > null segments and make them sparse, but I presume I shouldn't make 1 > byte sparse extents. File size will range from small to multiple GB, > but large files are the norm. I'd recommend you make your minimum sparse chunk be the filesystem blocksize. You can extract this from the statfs(2) f_bsize field. cheers. -- Nathan From owner-xfs@oss.sgi.com Wed Jun 14 15:27:40 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 14 Jun 2006 15:28:05 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k5EMRPDW031538 for ; Wed, 14 Jun 2006 15:27: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 IAA28433; Thu, 15 Jun 2006 08:26:54 +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 k5EMQngw918703; Thu, 15 Jun 2006 08:26:51 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k5EMQhkv919667; Thu, 15 Jun 2006 08:26:43 +1000 (EST) Date: Thu, 15 Jun 2006 08:26:43 +1000 From: Nathan Scott To: Jon Lewis Cc: James Pearson , Eric Sandeen , xfs@oss.sgi.com Subject: Re: XFS + software raid + 4k stacks = BOOM? Message-ID: <20060615082643.C918399@wobbly.melbourne.sgi.com> References: <448A98E8.9040109@moving-picture.com> <448F8C8A.4070008@sgi.com> <44902413.20305@moving-picture.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jlewis@lewis.org on Wed, Jun 14, 2006 at 11:19:35AM -0400 X-archive-position: 7944 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 991 Lines: 25 On Wed, Jun 14, 2006 at 11:19:35AM -0400, Jon Lewis wrote: > On Wed, 14 Jun 2006, James Pearson wrote: > > >> There were more stack reductions after that. Which is -not- to say that > >> you -will- have problems with the above... all depends on what you're > >> doing. But Nathan did more stack work after I put that rpm out. > > > > In my case, I would want to do NFS serving with XFS file systems - some of > > the servers may use software raid as well. > > AFAIK, the 2.4 kernel series XFS CVS still doesn't do NFS service of XFS > filesystems. There's no 4K stacks option in 2.4. We wait with much anticipation for a community patch to fix the CVS 2.4 NFS mounting issue, preferably from a guy named Jon since he seems to care so much. As I said last time you brought this up, there's not alot of investment in that branch anymore from SGI's POV. Mainline 2.4 doesn't have the problem, so if noone steps up to fix it in CVS, I expect it'll stay broke.. cheers. -- Nathan From owner-xfs@oss.sgi.com Wed Jun 14 16:20:09 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 14 Jun 2006 16:20:30 -0700 (PDT) Received: from omx1.americas.sgi.com (omx1.americas.sgi.com [198.149.16.13]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5ENJuDW012542 for ; Wed, 14 Jun 2006 16:20:08 -0700 Received: from internal-mail-relay1.corp.sgi.com (internal-mail-relay1.corp.sgi.com [198.149.32.52]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id k5EMGCnx001793 for ; Wed, 14 Jun 2006 17:16:12 -0500 Received: from omx2.sgi.com ([198.149.32.25]) by internal-mail-relay1.corp.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id k5EMFp8s12828540 for ; Wed, 14 Jun 2006 15:15:51 -0700 (PDT) Received: from imr2.americas.sgi.com (imr2.americas.sgi.com [198.149.16.18]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id k5F0bKU0012032 for ; Wed, 14 Jun 2006 17:37:20 -0700 Received: from omx2.sgi.com ([198.149.32.25]) by imr2.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id k5EMWt7p34364166 for ; Wed, 14 Jun 2006 15:32:55 -0700 (PDT) Received: from imr2.americas.sgi.com (imr2.americas.sgi.com [198.149.16.18]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id k5F0ahFi011563 for ; Wed, 14 Jun 2006 17:36:44 -0700 Received: from omx2.sgi.com ([198.149.32.25]) by imr2.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id k5EMWJ7p34523857 for ; Wed, 14 Jun 2006 15:32:19 -0700 (PDT) Received: from imr2.americas.sgi.com (imr2.americas.sgi.com [198.149.16.18]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id k5F0a7Ue011464 for ; Wed, 14 Jun 2006 17:36:07 -0700 Received: from [128.162.232.50] (stout.americas.sgi.com [128.162.232.50]) by imr2.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id k5EMVf7p34521701; Wed, 14 Jun 2006 15:31:42 -0700 (PDT) Message-ID: <44908A28.5050506@sgi.com> Date: Wed, 14 Jun 2006 17:14:00 -0500 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Groves CC: linux-xfs@oss.sgi.com Subject: Re: Question about sparse files References: <44905B9F.5000401@GrovesTech.com> In-Reply-To: <44905B9F.5000401@GrovesTech.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7945 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: xfs Content-Length: 824 Lines: 22 John Groves wrote: > A question for those who know more about xfs internals than me: > > If want to create sparse files that XFS can handle efficiently, is there > an optimal minimum sparse chunk size? I can look at an data stream for > null segments and make them sparse, but I presume I shouldn't make 1 > byte sparse extents. No such thing; extents (and holes) are a minimum of one filesystem block, in block multiples. A sparse file has offsets with no written data that span at least 1 complete filesystem block, beginning & ending on a block boundary. zeroed data ranges which are sub-block in size are just zeros written to disk, inside the filesystem block, part of a real extent. -Eric > File size will range from small to multiple GB, > but large files are the norm. > > Thanks, > John Groves > From owner-xfs@oss.sgi.com Wed Jun 14 16:26:12 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 14 Jun 2006 16:26:37 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k5ENPxDW013756 for ; Wed, 14 Jun 2006 16:26:11 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA29685; Thu, 15 Jun 2006 09:25:30 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id ABA0D4A58927; Thu, 15 Jun 2006 09:25:28 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 952969 - remove v1 dirs Message-Id: <20060614232528.ABA0D4A58927@chook.melbourne.sgi.com> Date: Thu, 15 Jun 2006 09:25:28 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 7946 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 12812 Lines: 188 Remove version 1 directory code. Never functioned on Linux, just pure bloat. Date: Thu Jun 15 09:24:19 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: sandeen,tes The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:26251a xfs_trans_space.h - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_trans_space.h.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h xfsidbg.c - 1.301 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfsidbg.c.diff?r1=text&tr1=1.301&r2=text&tr2=1.300&f=h xfs_log.c - 1.322 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_log.c.diff?r1=text&tr1=1.322&r2=text&tr2=1.321&f=h xfs_ialloc.c - 1.189 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_ialloc.c.diff?r1=text&tr1=1.189&r2=text&tr2=1.188&f=h xfs_rw.c - 1.396 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_rw.c.diff?r1=text&tr1=1.396&r2=text&tr2=1.395&f=h xfs_extfree_item.c - 1.64 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_extfree_item.c.diff?r1=text&tr1=1.64&r2=text&tr2=1.63&f=h xfs_buf_item.c - 1.158 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_buf_item.c.diff?r1=text&tr1=1.158&r2=text&tr2=1.157&f=h xfs_trans_inode.c - 1.53 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_trans_inode.c.diff?r1=text&tr1=1.53&r2=text&tr2=1.52&f=h xfs_da_btree.c - 1.171 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_da_btree.c.diff?r1=text&tr1=1.171&r2=text&tr2=1.170&f=h xfs_da_btree.h - 1.65 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_da_btree.h.diff?r1=text&tr1=1.65&r2=text&tr2=1.64&f=h xfs_trans_ail.c - 1.78 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_trans_ail.c.diff?r1=text&tr1=1.78&r2=text&tr2=1.77&f=h xfs_vnodeops.c - 1.679 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vnodeops.c.diff?r1=text&tr1=1.679&r2=text&tr2=1.678&f=h xfs_dir2_block.c - 1.53 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir2_block.c.diff?r1=text&tr1=1.53&r2=text&tr2=1.52&f=h xfs_dir.h - 1.45 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir.h.diff?r1=text&tr1=1.45&r2=text&tr2=1.44&f=h xfs_dir.c - 1.171 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir.c.diff?r1=text&tr1=1.171&r2=text&tr2=1.170&f=h xfs_rtalloc.c - 1.100 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_rtalloc.c.diff?r1=text&tr1=1.100&r2=text&tr2=1.99&f=h xfs_itable.c - 1.139 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_itable.c.diff?r1=text&tr1=1.139&r2=text&tr2=1.138&f=h xfs_ialloc_btree.c - 1.83 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_ialloc_btree.c.diff?r1=text&tr1=1.83&r2=text&tr2=1.82&f=h xfs_inode_item.c - 1.127 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode_item.c.diff?r1=text&tr1=1.127&r2=text&tr2=1.126&f=h xfs_iocore.c - 1.51 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_iocore.c.diff?r1=text&tr1=1.51&r2=text&tr2=1.50&f=h xfs_log_recover.c - 1.312 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_log_recover.c.diff?r1=text&tr1=1.312&r2=text&tr2=1.311&f=h xfs_vfsops.c - 1.508 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vfsops.c.diff?r1=text&tr1=1.508&r2=text&tr2=1.507&f=h xfs_dfrag.c - 1.55 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dfrag.c.diff?r1=text&tr1=1.55&r2=text&tr2=1.54&f=h xfs_iget.c - 1.215 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_iget.c.diff?r1=text&tr1=1.215&r2=text&tr2=1.214&f=h xfs_bmap_btree.c - 1.153 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bmap_btree.c.diff?r1=text&tr1=1.153&r2=text&tr2=1.152&f=h xfs_dir2_sf.c - 1.46 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir2_sf.c.diff?r1=text&tr1=1.46&r2=text&tr2=1.45&f=h xfs_dir_leaf.c - 1.137 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir_leaf.c.diff?r1=text&tr1=1.137&r2=text&tr2=1.136&f=h xfs_dir_leaf.h - 1.49 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir_leaf.h.diff?r1=text&tr1=1.49&r2=text&tr2=1.48&f=h xfs_mount.h - 1.225 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_mount.h.diff?r1=text&tr1=1.225&r2=text&tr2=1.224&f=h xfs_mount.c - 1.383 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_mount.c.diff?r1=text&tr1=1.383&r2=text&tr2=1.382&f=h xfs_btree.c - 1.114 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_btree.c.diff?r1=text&tr1=1.114&r2=text&tr2=1.113&f=h xfs_dir2_data.c - 1.36 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir2_data.c.diff?r1=text&tr1=1.36&r2=text&tr2=1.35&f=h xfs_acl.c - 1.62 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_acl.c.diff?r1=text&tr1=1.62&r2=text&tr2=1.61&f=h xfs_trans_extfree.c - 1.27 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_trans_extfree.c.diff?r1=text&tr1=1.27&r2=text&tr2=1.26&f=h xfs_inode.c - 1.447 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode.c.diff?r1=text&tr1=1.447&r2=text&tr2=1.446&f=h xfs_dir2_trace.c - 1.24 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir2_trace.c.diff?r1=text&tr1=1.24&r2=text&tr2=1.23&f=h xfs_qmops.c - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_qmops.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h xfs_dir2_leaf.c - 1.56 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir2_leaf.c.diff?r1=text&tr1=1.56&r2=text&tr2=1.55&f=h xfs_attr_leaf.c - 1.102 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_attr_leaf.c.diff?r1=text&tr1=1.102&r2=text&tr2=1.101&f=h xfs_trans.c - 1.176 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_trans.c.diff?r1=text&tr1=1.176&r2=text&tr2=1.175&f=h xfs_error.c - 1.54 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_error.c.diff?r1=text&tr1=1.54&r2=text&tr2=1.53&f=h xfs_utils.c - 1.72 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_utils.c.diff?r1=text&tr1=1.72&r2=text&tr2=1.71&f=h xfs_dir_sf.h - 1.31 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir_sf.h.diff?r1=text&tr1=1.31&r2=text&tr2=1.30&f=h xfs_alloc.c - 1.181 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_alloc.c.diff?r1=text&tr1=1.181&r2=text&tr2=1.180&f=h xfs_fsops.c - 1.118 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_fsops.c.diff?r1=text&tr1=1.118&r2=text&tr2=1.117&f=h xfs_dmops.c - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dmops.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h xfs_bmap.c - 1.353 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bmap.c.diff?r1=text&tr1=1.353&r2=text&tr2=1.352&f=h xfs_alloc_btree.c - 1.87 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_alloc_btree.c.diff?r1=text&tr1=1.87&r2=text&tr2=1.86&f=h xfs_trans_buf.c - 1.126 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_trans_buf.c.diff?r1=text&tr1=1.126&r2=text&tr2=1.125&f=h xfs_dir2_node.c - 1.57 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir2_node.c.diff?r1=text&tr1=1.57&r2=text&tr2=1.56&f=h xfs_rename.c - 1.68 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_rename.c.diff?r1=text&tr1=1.68&r2=text&tr2=1.67&f=h xfs_attr.c - 1.138 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_attr.c.diff?r1=text&tr1=1.138&r2=text&tr2=1.137&f=h xfs_dir2.h - 1.19 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir2.h.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h xfs_dir2.c - 1.54 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir2.c.diff?r1=text&tr1=1.54&r2=text&tr2=1.53&f=h xfs_dinode.h - 1.80 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dinode.h.diff?r1=text&tr1=1.80&r2=text&tr2=1.79&f=h quota/xfs_trans_dquot.c - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_trans_dquot.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h quota/xfs_qm_bhv.c - 1.21 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_qm_bhv.c.diff?r1=text&tr1=1.21&r2=text&tr2=1.20&f=h quota/xfs_qm_stats.c - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_qm_stats.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h quota/xfs_qm_syscalls.c - 1.28 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_qm_syscalls.c.diff?r1=text&tr1=1.28&r2=text&tr2=1.27&f=h quota/xfs_dquot_item.c - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_dquot_item.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h quota/xfs_dquot.c - 1.26 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_dquot.c.diff?r1=text&tr1=1.26&r2=text&tr2=1.25&f=h quota/xfs_qm.c - 1.41 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_qm.c.diff?r1=text&tr1=1.41&r2=text&tr2=1.40&f=h xfs_refcache.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_refcache.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h Makefile-linux-2.6 - 1.203 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/Makefile-linux-2.6.diff?r1=text&tr1=1.203&r2=text&tr2=1.202&f=h Makefile-linux-2.4 - 1.216 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/Makefile-linux-2.4.diff?r1=text&tr1=1.216&r2=text&tr2=1.215&f=h xfs_iomap.c - 1.47 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_iomap.c.diff?r1=text&tr1=1.47&r2=text&tr2=1.46&f=h linux-2.6/xfs_lrw.c - 1.248 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_lrw.c.diff?r1=text&tr1=1.248&r2=text&tr2=1.247&f=h linux-2.6/xfs_ioctl.c - 1.136 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_ioctl.c.diff?r1=text&tr1=1.136&r2=text&tr2=1.135&f=h linux-2.6/xfs_vfs.c - 1.73 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_vfs.c.diff?r1=text&tr1=1.73&r2=text&tr2=1.72&f=h linux-2.6/xfs_file.c - 1.141 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_file.c.diff?r1=text&tr1=1.141&r2=text&tr2=1.140&f=h linux-2.6/xfs_super.c - 1.368 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_super.c.diff?r1=text&tr1=1.368&r2=text&tr2=1.367&f=h linux-2.6/xfs_iops.c - 1.251 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_iops.c.diff?r1=text&tr1=1.251&r2=text&tr2=1.250&f=h linux-2.6/xfs_aops.c - 1.131 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_aops.c.diff?r1=text&tr1=1.131&r2=text&tr2=1.130&f=h linux-2.4/xfs_lrw.c - 1.238 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_lrw.c.diff?r1=text&tr1=1.238&r2=text&tr2=1.237&f=h linux-2.4/xfs_ioctl.c - 1.131 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_ioctl.c.diff?r1=text&tr1=1.131&r2=text&tr2=1.130&f=h linux-2.4/xfs_vfs.c - 1.67 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_vfs.c.diff?r1=text&tr1=1.67&r2=text&tr2=1.66&f=h linux-2.4/Makefile - 1.210 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/Makefile.diff?r1=text&tr1=1.210&r2=text&tr2=1.209&f=h linux-2.4/xfs_file.c - 1.128 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_file.c.diff?r1=text&tr1=1.128&r2=text&tr2=1.127&f=h linux-2.4/xfs_super.c - 1.332 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_super.c.diff?r1=text&tr1=1.332&r2=text&tr2=1.331&f=h linux-2.4/xfs_iops.c - 1.226 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_iops.c.diff?r1=text&tr1=1.226&r2=text&tr2=1.225&f=h linux-2.4/xfs_aops.c - 1.104 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_aops.c.diff?r1=text&tr1=1.104&r2=text&tr2=1.103&f=h linux-2.6/xfs_ksyms.c - 1.48 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_ksyms.c.diff?r1=text&tr1=1.48&r2=text&tr2=1.47&f=h linux-2.4/xfs_ksyms.c - 1.43 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_ksyms.c.diff?r1=text&tr1=1.43&r2=text&tr2=1.42&f=h quota/xfs_qm_ksyms.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_qm_ksyms.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h linux-2.6/xfs_export.c - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_export.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h dmapi/xfs_dm_fsops.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/dmapi/xfs_dm_fsops.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h dmapi/xfs_dm_bhv.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/dmapi/xfs_dm_bhv.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h dmapi/xfs_dm.c - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/dmapi/xfs_dm.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h From owner-xfs@oss.sgi.com Wed Jun 14 16:42:36 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 14 Jun 2006 16:42:51 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k5ENgNDW016916 for ; Wed, 14 Jun 2006 16:42:35 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA00140 for ; Thu, 15 Jun 2006 09:42:01 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id BADD24A58927; Thu, 15 Jun 2006 09:41:59 +1000 (EST) To: linux-xfs@oss.sgi.com Subject: PARTIAL TAKE 953338 - radix-tree/list.h Message-Id: <20060614234159.BADD24A58927@chook.melbourne.sgi.com> Date: Thu, 15 Jun 2006 09:41:59 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 7947 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 1028 Lines: 24 Backport a trimmed down 2.6 radix-tree and linked-list implementation for the porters - we have at least two radix-tree users under development, so this will be needed shortly. Date: Thu Jun 15 09:40:35 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: sjv The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:26252a support/list.h - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/support/list.h support/radix-tree.c - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/support/radix-tree.c support/radix-tree.h - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/support/radix-tree.h support/Makefile - 1.22 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/support/Makefile.diff?r1=text&tr1=1.22&r2=text&tr2=1.21&f=h linux-2.4/xfs_linux.h - 1.157 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_linux.h.diff?r1=text&tr1=1.157&r2=text&tr2=1.156&f=h From owner-xfs@oss.sgi.com Wed Jun 14 19:18:35 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 14 Jun 2006 19:18:51 -0700 (PDT) Received: from ruth.realtime.net (ruth.realtime.net [205.238.132.69]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5F2IZDW008779 for ; Wed, 14 Jun 2006 19:18:35 -0700 Received: from [192.168.2.120] (cpe-72-177-24-78.austin.res.rr.com [72.177.24.78]) by realtime.net (Realtime Communications Advanced E-Mail Services V9.2) with ESMTP id 127690175 for multiple; Wed, 14 Jun 2006 19:58:00 -0500 Message-ID: <4490B09F.20903@GrovesTech.com> Date: Wed, 14 Jun 2006 19:58:07 -0500 From: John Groves User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: Question about sparse files References: <44905B9F.5000401@GrovesTech.com> <20060615081403.B918399@wobbly.melbourne.sgi.com> In-Reply-To: <20060615081403.B918399@wobbly.melbourne.sgi.com> X-Server: High Performance Mail Server - http://surgemail.com r=-1092531819 X-Authenticated-User: jg@bga.com X-IsFriend: Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit X-archive-position: 7948 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: John@GrovesTech.com Precedence: bulk X-list: xfs Content-Length: 1192 Lines: 42 Thanks Nathan and Eric. Roger to Eric's point re: holes smaller than the filesystem blocksize (I suppose I could lseek past a small chunk while writing, it just wouldn't be a hole, right?) I presume that my hole must not just be a multiple of the filesystem blocksize -- it should also be blocksize-aligned. A single-block chunk that I lseek past while writing would be two sub-blocksize null sections (but not a hole) unless it's blocksize-aligned. Right? Thanks again! John Nathan Scott wrote: >Hi John, > >On Wed, Jun 14, 2006 at 01:55:27PM -0500, John Groves wrote: > > >>A question for those who know more about xfs internals than me: >> >>If want to create sparse files that XFS can handle efficiently, is there >>an optimal minimum sparse chunk size? I can look at an data stream for >>null segments and make them sparse, but I presume I shouldn't make 1 >>byte sparse extents. File size will range from small to multiple GB, >>but large files are the norm. >> >> > >I'd recommend you make your minimum sparse chunk be the filesystem >blocksize. You can extract this from the statfs(2) f_bsize field. > >cheers. > > > [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Thu Jun 15 02:48:18 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 15 Jun 2006 02:48:32 -0700 (PDT) Received: from mondschein.lichtvoll.de (ms2.lichtvoll.de [194.150.191.235] (may be forged)) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5F9mDDW014076 for ; Thu, 15 Jun 2006 02:48:18 -0700 Received: from localhost (dslb-084-056-099-073.pools.arcor-ip.net [84.56.99.73]) by mondschein.lichtvoll.de (Postfix) with ESMTP id 46C68FA0AA; Thu, 15 Jun 2006 09:44:17 +0200 (CEST) From: Martin Steigerwald To: John Groves Subject: Re: Question about sparse files Date: Thu, 15 Jun 2006 09:44:36 +0200 User-Agent: KMail/1.9.1 References: <44905B9F.5000401@GrovesTech.com> <20060615081403.B918399@wobbly.melbourne.sgi.com> <4490B09F.20903@GrovesTech.com> In-Reply-To: <4490B09F.20903@GrovesTech.com> Cc: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606150944.37471.Martin@lichtvoll.de> X-archive-position: 7949 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Martin@lichtvoll.de Precedence: bulk X-list: xfs Content-Length: 933 Lines: 26 Am Donnerstag 15 Juni 2006 02:58 schrieben Sie: > Thanks Nathan and Eric. Roger to Eric's point re: holes smaller than > the filesystem blocksize (I suppose I could lseek past a small chunk > while writing, it just wouldn't be a hole, right?) Hello John, you can test yourself. xfs_bmap tells you about the holes in a file: martin@deepdance:~/Amiga -> /usr/sbin/xfs_bmap Messages.hardfile Messages.hardfile: 0: [0..18815]: 4650936..4669751 1: [18816..21527]: hole 2: [21528..100863]: 4672464..4751799 3: [100864..183039]: 11899536..11981711 4: [183040..651263]: 13764344..14232567 5: [651264..943615]: 16747816..17040167 6: [943616..1489407]: 18002488..18548279 7: [1489408..2097143]: hole 8: [2097144..2097151]: 18548280..18548287 Regards, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 From owner-xfs@oss.sgi.com Thu Jun 15 17:23:57 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 15 Jun 2006 17:24:25 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k5G0NiDW019274 for ; Thu, 15 Jun 2006 17:23:55 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA00735; Fri, 16 Jun 2006 10:23:12 +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 k5G0NAgw950137; Fri, 16 Jun 2006 10:23:10 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k5G0N6lw949431; Fri, 16 Jun 2006 10:23:06 +1000 (EST) Date: Fri, 16 Jun 2006 10:23:06 +1000 From: Nathan Scott To: John Groves Cc: linux-xfs@oss.sgi.com Subject: Re: Question about sparse files Message-ID: <20060616102306.C915318@wobbly.melbourne.sgi.com> References: <44905B9F.5000401@GrovesTech.com> <20060615081403.B918399@wobbly.melbourne.sgi.com> <4490B09F.20903@GrovesTech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4490B09F.20903@GrovesTech.com>; from John@GrovesTech.com on Wed, Jun 14, 2006 at 07:58:07PM -0500 X-archive-position: 7951 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 564 Lines: 15 On Wed, Jun 14, 2006 at 07:58:07PM -0500, John Groves wrote: > Thanks Nathan and Eric. Roger to Eric's point re: holes smaller than > the filesystem blocksize (I suppose I could lseek past a small chunk > while writing, it just wouldn't be a hole, right?) > > I presume that my hole must not just be a multiple of the filesystem > blocksize -- it should also be blocksize-aligned. A single-block chunk > that I lseek past while writing would be two sub-blocksize null sections > (but not a hole) unless it's blocksize-aligned. Right? Right. -- Nathan From owner-xfs@oss.sgi.com Thu Jun 15 19:15:48 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 15 Jun 2006 19:16:13 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k5G2FZDW000784 for ; Thu, 15 Jun 2006 19:15:47 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA03034; Fri, 16 Jun 2006 12:15:11 +1000 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k5G2ExEo5405112; Fri, 16 Jun 2006 12:14:59 +1000 (AEST) Received: (from tes@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k5G2Eunf5397631; Fri, 16 Jun 2006 12:14:56 +1000 (AEST) Date: Fri, 16 Jun 2006 12:14:56 +1000 (AEST) From: Timothy Shimmin Message-Id: <200606160214.k5G2Eunf5397631@snort.melbourne.sgi.com> To: sgi.bugs.xfs@engr.sgi.com, linux-xfs@oss.sgi.com Subject: TAKE 952214 - fix logprint to handle 32/64bit inode/EFI format items X-archive-position: 7952 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@snort.melbourne.sgi.com Precedence: bulk X-list: xfs Content-Length: 1659 Lines: 36 Fix up logprint so that 32 bit or 64 bit versions of logprint binaries can print a log from an XFS file system on a 64bit or 32bit os. Date: Fri Jun 16 12:13:21 AEST 2006 Workarea: snort.melbourne.sgi.com:/home/tes/isms/xfs-cmds-3264 Inspected by: nathans@sgi.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:26264a xfsprogs/logprint/log_print_all.c - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/logprint/log_print_all.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h - Convert EFI and inode format items from 32/64 bit forms so that they can be decoded and printed. xfsprogs/logprint/logprint.h - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/logprint/logprint.h.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h - Prototypes for efi/inode conversion routines. xfsprogs/logprint/log_misc.c - 1.21 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/logprint/log_misc.c.diff?r1=text&tr1=1.21&r2=text&tr2=1.20&f=h - Convert EFI and inode format items from 32/64 bit forms so that they can be decoded and printed. xfsprogs/include/xfs_extfree_item.h - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_extfree_item.h.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h - Copied from kernel. 32 & 64 bit versions of EFI/EFD format items. xfsprogs/include/xfs_inode_item.h - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_inode_item.h.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h - Copied from kernel. 32 & 64 bit versions of inode item format. From owner-xfs@oss.sgi.com Fri Jun 16 04:40:04 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 16 Jun 2006 04:40:24 -0700 (PDT) Received: from smtp-3.hut.fi (smtp-3.hut.fi [130.233.228.93]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5GBdxDW009366 for ; Fri, 16 Jun 2006 04:40:02 -0700 Received: from localhost (putosiko.hut.fi [130.233.228.114]) by smtp-3.hut.fi (8.13.6/8.12.10) with ESMTP id k5GBdgVR032168; Fri, 16 Jun 2006 14:39:42 +0300 Received: from smtp-3.hut.fi ([130.233.228.93]) by localhost (putosiko.hut.fi [130.233.228.114]) (amavisd-new, port 10024) with LMTP id 32659-11-10; Fri, 16 Jun 2006 14:39:42 +0300 (EEST) Received: from kurp.hut.fi (kurp.hut.fi [130.233.157.234]) by smtp-3.hut.fi (8.13.6/8.12.10) with ESMTP id k5GBcKdP031961; Fri, 16 Jun 2006 14:38:31 +0300 Received: from kurp.hut.fi (jwagner@localhost [127.0.0.1]) by kurp.hut.fi (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k5GBcKCb008586; Fri, 16 Jun 2006 14:38:20 +0300 Received: from localhost (jwagner@localhost) by kurp.hut.fi (8.13.4/8.13.4/Submit) with ESMTP id k5GBcKLN008583; Fri, 16 Jun 2006 14:38:20 +0300 Date: Fri, 16 Jun 2006 14:38:19 +0300 (EEST) From: Jan Wagner To: Nathan Scott cc: xfs@oss.sgi.com Subject: Re: separate log and structure from user data device? In-Reply-To: <20060608104242.I710447@wobbly.melbourne.sgi.com> Message-ID: References: <8630.1149517148@ocs3.ocs.com.au> <20060606101258.B644608@wobbly.melbourne.sgi.com> <20060608104242.I710447@wobbly.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at putosiko.hut.fi X-archive-position: 7954 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jwagner@kurp.hut.fi Precedence: bulk X-list: xfs Content-Length: 3510 Lines: 120 Took a while to get back to XFS testing... On Thu, 8 Jun 2006, Nathan Scott wrote: > On Wed, Jun 07, 2006 at 02:05:57PM +0300, Jan Wagner wrote: > > On Tue, 6 Jun 2006, Nathan Scott wrote: > > Other question, is the below really the correct way to enable realtime for > > a new file? > > Its one way. Also try: > > # xfs_io -fR /mnt/test/realtime -c 'pwrite -b 1m 0 100m' > wrote 104857600/104857600 bytes at offset 0 > 100 MiB, 100 ops; 0:00:01.00 (95.473 MiB/sec and 95.4726 ops/sec) > # xfs_io -f /mnt/test/regular -c 'pwrite -b 1m 0 100m' > wrote 104857600/104857600 bytes at offset 0 > 100 MiB, 100 ops; 0:00:01.00 (67.574 MiB/sec and 67.5735 ops/sec) Thank's for the info! It seems to work, with a small (40MiB/sec) gain: # mkfs.xfs -f -l logdev=/dev/hda6,size=10000b /dev/md0 # mount -t xfs -o logdev=/dev/hda6 /dev/md0 /i1 then test # xfs_io -f /i1/testfile -c 'pwrite -b 4m 0 6g' wrote 6442450944/6442450944 bytes at offset 0 6.000 GiB, 1536 ops; 00:00:25.897914 (237.239 MiB/sec and 59.3098 ops/sec) vs realtime # umount /i1 # mkfs.xfs -f -r rtdev=/dev/md0 /dev/hda6 # mount -t xfs -o rtdev=/dev/md0 /dev/hda6 /i1 with test # xfs_io -fR /i1/testfile -c 'pwrite -b 4m 0 6g' wrote 6442450944/6442450944 bytes at offset 0 6.000 GiB, 1536 ops; 00:00:22.154212 (277.329 MiB/sec and 69.3322 ops/sec) So there indeed is a small gain, and apparently realtime works. Nice! :-) > Or more simply (ie. without create + set-realtime-explicitly)... > > # mkdir /mnt/test/realtime > # xfs_io -c 'chattr +t' -c 'lsattr -v' /mnt/test/realtime > [rt-inherit] /mnt/test/realtime Thanks for the tip also, that would really be the easiest way - there'd be several other code that I would have to edit otherwise. But for some reason at least the above xfs_io command does not work, I get # mkdir /i1/inherit # xfs_io -c 'chattr +t' -c 'lsattr -v' /i1/inherit /i1/inherit: Is a directory I already tried playing around inf xfs_io command line, and checked the other xfs_... helper tools, but there and in their man pages there are only references to file editing, not directory edit. "Is a directory", any ideas? Do I need to get XFS source from elsewhere than the one included in debian kernel 2.6.16? The XFS choices in the kernel config are CONFIG_XFS_FS=m CONFIG_XFS_EXPORT=y # CONFIG_XFS_QUOTA is not set # CONFIG_XFS_SECURITY is not set # CONFIG_XFS_POSIX_ACL is not set CONFIG_XFS_RT=y > > assert( (fid = open(pn, O_WRONLY|O_CREAT|O_DIRECT|O_SYNC|O_LARGEFILE)) != -1 ); > > Thats a shocking use of assert. :) Local coding style here, unfortunately ;-)) > > fsxinfo.fsx_xflags = XFS_XFLAG_REALTIME; > > fsxinfo.fsx_xflags |= ... (to not blow away any other flags you > might have had set on that file). That was one problem, now it seems to work with the test code. Pilot error, yes :) Oh and another question, is it possible that realtime reads are much slower than writes? Or am I again making a mistake somewhere? # xfs_io -fR /i1/testfile -c 'pwrite -b 4m 0 2g' wrote 2147483648/2147483648 bytes at offset 0 2.000 GiB, 512 ops; 00:00:05.645958 (362.737 MiB/sec and 90.6843 ops/sec) write 360MiB/s # xfs_io -fR /i1/testfile -c 'pread -b 4m 2g' read 2147483648/2147483648 bytes at offset 0 2.000 GiB, 512 ops; 00:00:39.156626 (52.303 MiB/sec and 13.0757 ops/sec) # xfs_io -fR /i1/testfile -c 'pread 4m 2g' read 2147483648/2147483648 bytes at offset 4194304 2.000 GiB, 524288 ops; 00:00:27.229922 (75.211 MiB/sec and 19254.1132 ops/sec) read max 75MiB/s thanks again, - Jan From owner-xfs@oss.sgi.com Fri Jun 16 09:35:56 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 16 Jun 2006 09:36:12 -0700 (PDT) Received: from lion.flexserv.de (flexserv.de [213.239.215.214]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5GGZtDW000907 for ; Fri, 16 Jun 2006 09:35:55 -0700 Received: from localhost (localhost [127.0.0.1]) by lion.flexserv.de (Postfix) with ESMTP id 8AD9C14E241 for ; Fri, 16 Jun 2006 16:30:55 +0200 (CEST) Received: from lion.flexserv.de ([127.0.0.1]) by localhost (lion [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 10886-08 for ; Fri, 16 Jun 2006 16:30:55 +0200 (CEST) Received: from changer.flexserv.de (changer.flexserv.de [213.217.69.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "changer.flexserv.de", Issuer "flexserv.de" (verified OK)) by lion.flexserv.de (Postfix) with ESMTP id 2F39A14E240 for ; Fri, 16 Jun 2006 16:30:55 +0200 (CEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by changer.flexserv.de (Postfix) with ESMTP id 58D2E180034D; Fri, 16 Jun 2006 16:30:28 +0200 (CEST) Received: from changer.flexserv.de ([192.168.1.10]) by localhost (changer1 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 06082-06; Fri, 16 Jun 2006 16:30:28 +0200 (CEST) Received: from xserver.flexserv.de (xserver.walki.homelinux.org [192.168.1.240]) by changer.flexserv.de (Postfix) with ESMTP id F007A180033F for ; Fri, 16 Jun 2006 16:30:27 +0200 (CEST) To: linux-xfs@oss.sgi.com Subject: Fwd: Bug: XFS internal error XFS_WANT_CORRUPTED_RETURN Organization: Flexserv From: "Daniel J.Priem" X-GPG-ID: 0x7B196671 X-GPG-FP: A9CE 5788 44D3 A1A2 46B6 A727 53D8 DD4B 7B19 6671 X-message-flag: Formating hard disk. please wait... 10%... 20%... Date: Fri, 16 Jun 2006 16:30:45 +0200 Message-ID: <87zmgdyxyi.fsf@xserver.flexserv.de> User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="===-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" X-archive-position: 7955 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: daniel@flexserv.de Precedence: bulk X-list: xfs Content-Length: 4730 Lines: 136 --===-=-= Content-Type: multipart/mixed; boundary="==-=-=" --==-=-= FYI --==-=-= Content-Type: message/rfc822 Content-Disposition: inline To: linux-kernel@vger.kernel.org Subject: Bug: XFS internal error XFS_WANT_CORRUPTED_RETURN Organization: Flexserv X-Draft-From: ("INBOX.devel.linux.lkml" "") From: daniel+devel.linux.lkml@flexserv.de X-GPG-ID: 0x7B196671 X-GPG-FP: A9CE 5788 44D3 A1A2 46B6 A727 53D8 DD4B 7B19 6671 X-message-flag: Formating hard disk. please wait... 10%... 20%... Date: Fri, 16 Jun 2006 16:09:11 +0200 Message-ID: <878xnx19bs.fsf@xserver.flexserv.de> User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" --=-=-= Running 2.6.17-rc6 same when running it inside a new created partition. No matter if on sda or inside a lvm on sdb Reproducible. Kernel is compiled with debug symbols i think. What additional informatiuon can i get you? Daniel XFS internal error XFS_WANT_CORRUPTED_RETURN at line 298 of file fs/xfs/xfs_alloc.c. Caller 0x0000000000586974 Call Trace: [000000000058646c] xfs_alloc_ag_vextent+0x16c/0x1a0 [0000000000588b84] xfs_alloc_vextent+0x384/0x480 [0000000000595be0] xfs_bmap_btalloc+0x240/0x700 [0000000000598da8] xfs_bmapi+0xc08/0xec0 [00000000005be2ec] xfs_iomap_write_allocate+0x18c/0x3a0 [00000000005bd69c] xfs_iomap+0x27c/0x360 [00000000005da1ac] xfs_map_blocks+0x2c/0x80 [00000000005db33c] xfs_page_state_convert+0x3bc/0x640 [00000000005db638] xfs_vm_writepage+0x78/0x140 [00000000004c71e4] mpage_writepages+0x244/0x3c0 [000000000047ef40] do_writepages+0x60/0x80 [00000000004c5310] __sync_single_inode+0x50/0x240 [00000000004c5590] __writeback_single_inode+0x90/0x180 [00000000004c586c] sync_sb_inodes+0x1ec/0x320 [00000000004c5a80] writeback_inodes+0xe0/0x120 [000000000047ec34] wb_kupdate+0xb4/0x160 XFS internal error XFS_WANT_CORRUPTED_RETURN at line 298 of file fs/xfs/xfs_alloc.c. Caller 0x0000000000586974 Call Trace: [000000000058646c] xfs_alloc_ag_vextent+0x16c/0x1a0 [0000000000588b84] xfs_alloc_vextent+0x384/0x480 [0000000000595be0] xfs_bmap_btalloc+0x240/0x700 [0000000000598da8] xfs_bmapi+0xc08/0xec0 [00000000005be2ec] xfs_iomap_write_allocate+0x18c/0x3a0 [00000000005bd69c] xfs_iomap+0x27c/0x360 [00000000005da1ac] xfs_map_blocks+0x2c/0x80 [00000000005db33c] xfs_page_state_convert+0x3bc/0x640 [00000000005db638] xfs_vm_writepage+0x78/0x140 [00000000004c71e4] mpage_writepages+0x244/0x3c0 [000000000047ef40] do_writepages+0x60/0x80 [00000000004c5310] __sync_single_inode+0x50/0x240 [00000000004c5590] __writeback_single_inode+0x90/0x180 [00000000004c586c] sync_sb_inodes+0x1ec/0x320 [00000000004c5a80] writeback_inodes+0xe0/0x120 [000000000047ec34] wb_kupdate+0xb4/0x160 bilbao:~# bilbao:~# XFS internal error XFS_WANT_CORRUPTED_RETURN at line 298 of file fs/xfs/xfs_alloc.c. Caller 0x0000000000586974 Call Trace: [000000000058646c] xfs_alloc_ag_vextent+0x16c/0x1a0 [0000000000588b84] xfs_alloc_vextent+0x384/0x480 [0000000000595be0] xfs_bmap_btalloc+0x240/0x700 [0000000000598da8] xfs_bmapi+0xc08/0xec0 [00000000005a518c] xfs_dir2_grow_inode+0x8c/0x2c0 [00000000005a69dc] xfs_dir2_sf_to_block+0x7c/0x520 [00000000005abfc0] xfs_dir2_sf_addname+0xe0/0x1a0 [00000000005a4a90] xfs_dir2_createname+0x130/0x160 [00000000005d6c3c] xfs_mkdir+0x3dc/0x660 [00000000005e1d60] xfs_vn_mknod+0x360/0x420 [00000000004aff90] vfs_mkdir+0x90/0x140 [00000000004b00f0] sys_mkdirat+0xb0/0x100 [0000000000406bd4] linux_sparc_syscall32+0x34/0x40 [0000000000010ba8] 0x10ba8 Filesystem "sda2": XFS internal error xfs_trans_cancel at line 1150 of file fs/xfs/xfs_trans.c. Caller 0x00000000005d6abc Call Trace: [00000000005e1d60] xfs_vn_mknod+0x360/0x420 [00000000004aff90] vfs_mkdir+0x90/0x140 [00000000004b00f0] sys_mkdirat+0xb0/0x100 [0000000000406bd4] linux_sparc_syscall32+0x34/0x40 [0000000000010ba8] 0x10ba8 xfs_force_shutdown(sda2,0x8) called from line 1151 of file fs/xfs/xfs_trans.c. Return address = 0x00000000005e57fc Filesystem "sda2": Corruption of in-memory data detected. Shutting down filesystem: sda2 Please umount the filesystem, and rectify the problem(s) --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQBEkruMU9jdS3sZZnERAmD5AJ98Nh6nQ5MAvCod3DFaK0zZdDR5kgCePeRS JlYo2prygmgB36cecnpJ5nM= =cFTF -----END PGP SIGNATURE----- --=-=-=-- --==-=-=-- --===-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQBEksCVU9jdS3sZZnERAsOqAJ4wkM1Qg8uTvgz7MmudKDiziNgqFwCeL/UX pokqLB14zYtcaSk55PjTqUY= =Oozf -----END PGP SIGNATURE----- --===-=-=-- From owner-xfs@oss.sgi.com Fri Jun 16 12:56:52 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 16 Jun 2006 12:57:04 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5GJuoDW031475 for ; Fri, 16 Jun 2006 12:56:51 -0700 Received: by nf-out-0910.google.com with SMTP id c2so603793nfe for ; Fri, 16 Jun 2006 12:56:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:user-agent:mime-version:to:subject:content-type:content-transfer-encoding; b=KuaW7a4xjvmFhHZulU8q8rXpAWtSdyofT4JIOFWEfTxLw+jkKu8bsNOsCjLw7W2KN/o4vCSBEaL8/fsUbPGv9lRQR+KhypwfhWFo3H/4PFXEmj1TZwe72o5YcgP+/Emd1HdhqgfinlayVwdrG2BhG0grmhJNU1P6huuXPjOcSYw= Received: by 10.49.91.12 with SMTP id t12mr2980885nfl; Fri, 16 Jun 2006 11:13:29 -0700 (PDT) Received: from ?192.168.0.3? ( [62.103.236.162]) by mx.gmail.com with ESMTP id p72sm2314359nfc.2006.06.16.11.13.28; Fri, 16 Jun 2006 11:13:29 -0700 (PDT) Message-ID: <4492F5DB.20507@gmail.com> Date: Fri, 16 Jun 2006 21:18:03 +0300 From: Panagiotis Atmatzidis Reply-To: p.atmatzidis@gmail.com User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060530) MIME-Version: 1.0 To: xfs@oss.sgi.com Subject: XFS - bad primary superblock - bad magic number !!! Content-Type: text/plain; charset=ISO-8859-7; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7956 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: p.atmatzidis@gmail.com Precedence: bulk X-list: xfs Content-Length: 863 Lines: 27 Hi there, I have a Gentoo GNU/Linux home file server. This server has a / with reiserFS and 3 hd's with XFS which are used for storage. The 3 HD's are encrypted xfs filelsystems. The filesystems dmsetup links are: enc-a, enc-b, enc-c I had houndreds of hard-reboots for several reasons for ~ 3 years and never had problems with data loss etc. Today though, when I came back.. I saw the Linux server turned off and when I booted the machine I saw the following error msg for enc-a & enc-b. enc-c is alright (files are there and it's mount-able, I see no errors on xfs_repair /dev/mapper/enc-c): #xfs_repair -n /dev/mapper/enc-a Phase 1 - find and verify superblock... bad primary superblock - bad magic number !!! attempting to find secondary superblock... (this one goes for ever without an end until now) is there any way to save this? thank you. From owner-xfs@oss.sgi.com Fri Jun 16 14:27:30 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 16 Jun 2006 14:27:41 -0700 (PDT) Received: from lucidpixels.com (lucidpixels.com [66.45.37.187]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5GLRTDW011775 for ; Fri, 16 Jun 2006 14:27:29 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id 42FB4616D16D; Fri, 16 Jun 2006 17:27:14 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id 3DE50161975FF; Fri, 16 Jun 2006 17:27:14 -0400 (EDT) Date: Fri, 16 Jun 2006 17:27:14 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: xfs@oss.sgi.com cc: linux-raid-owner@vger.kernel.org Subject: Need SW RAID5 & mkfs.xfs help with chunksize & swidth/su respectively Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 7957 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs Content-Length: 3067 Lines: 61 Two questions, a SW RAID and XFS question. SW RAID Question: What is the optimal chunk size for a RAID5 that will be used with XFS? I have 5x400GB Seagate HDDs (ATA/100) w/ 8MB of Cache, each is a master on its own IDE bus. From the mkfs.xfs man page: Otherwise, the size suboption is only needed if the log section of the filesystem should occupy less space than the size of the special file. The size is specified in bytes or blocks, with a b suffix meaning multiplication by the filesystem block size, as described above. The overriding minimum value for size is 512 blocks. With some combinations of filesystem block size, inode size, and directory block size, the minimum log size is larger than 512 blocks. Using the version suboption to specify a version 2 log enables the sunit suboption, and allows the logbsize to be increased beyond 32K. Version 2 logs are automatically selected if a log stripe unit is specified. See sunit and su suboptions, below. The sunit suboption specifies the alignment to be used for log writes. The suboption value has to be specified in 512-byte block units. Use the su suboption to specify the log stripe unit size in bytes. Log writes will be aligned on this bound- ary, and rounded up to this boundary. This gives major improve- ments in performance on some configurations such as software raid5 when the sunit is specified as the filesystem block size. The equivalent byte value must be a multiple of the filesystem block size. Version 2 logs are automatically selected if the log su suboption is specified. The su suboption is an alternative to using sunit. The su sub- option is used to specify the log stripe. The suboption value has to be specified in bytes, (usually using the s or b suf- fixes). This value must be a multiple of the filesystem block size. Version 2 logs are automatically selected if the log su suboption is specified. I have a software raid5 with 5 400GB drives and currently a 512kb chunksize with default mkfs.xfs parameters. p34:~# mdadm --create /dev/md3 --verbose --chunk=512 --level=5 --raid-devices=5 /dev/hda1 /dev/hde1 /dev/hdg1 /dev/hdi1 /dev/hdk1 mdadm: layout defaults to left-symmetric mdadm: size set to 390708736K mdadm: array /dev/md3 started. p34:~# What parameters for the sunit/sw are optimal for my configuration? How exactly do I calculate them? For ext2/ext3 (which I don't use) you use the -stride option and then a number for how many disks the filesystem is split over. For XFS, what is the method to calculate these numbers? Could someone please offer some advice? :) From owner-xfs@oss.sgi.com Fri Jun 16 22:07:45 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 16 Jun 2006 22:08:02 -0700 (PDT) Received: from mail.g-house.de (ns2.g-housing.de [81.169.133.75]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5H57iDW029729 for ; Fri, 16 Jun 2006 22:07:44 -0700 Received: from [62.30.165.31] (helo=62-30-165-31.cable.ubr01.linl.blueyonder.co.uk) by mail.g-house.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1FrT1l-0001E4-UJ; Sat, 17 Jun 2006 07:07:22 +0200 Date: Sat, 17 Jun 2006 06:07:13 +0100 (BST) From: christian X-X-Sender: evil@sheep.housecafe.de To: Panagiotis Atmatzidis cc: xfs@oss.sgi.com Subject: Re: XFS - bad primary superblock - bad magic number !!! In-Reply-To: <4492F5DB.20507@gmail.com> Message-ID: References: <4492F5DB.20507@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 7958 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: evilninja@gmx.net Precedence: bulk X-list: xfs Content-Length: 723 Lines: 26 On Fri, 16 Jun 2006, Panagiotis Atmatzidis wrote: > #xfs_repair -n /dev/mapper/enc-a > Phase 1 - find and verify superblock... > bad primary superblock - bad magic number !!! Maybe the crypto setup failed and /dev/mapper/enc-a has not been decrypted. What does $ dd if=/dev/mapper/enc-a bs=1k count=20 | less or $ dd if=/dev/mapper/enc-a bs=1k count=20 | file - show you? Here I can "less" through something which appears to an XFS header, ater this I can even see filecontents. The 2nd command should show sth. like "SGI XFS filesystem data". And don't forget to use a current kernel/xfsprogs before doing sth. with the FS.... -- BOFH excuse #14: sounds like a Windows problem, try calling Microsoft support From owner-xfs@oss.sgi.com Sat Jun 17 20:18:56 2006 Received: with ECARTIS (v1.0.0; list xfs); Sat, 17 Jun 2006 20:19:13 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k5I3IhDW003225 for ; Sat, 17 Jun 2006 20:18:54 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA25808 for ; Sun, 18 Jun 2006 13:18:18 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 8A30B4A588F9; Sun, 18 Jun 2006 13:18:11 +1000 (EST) To: linux-xfs@oss.sgi.com Subject: TAKE 904196 - Merge up to 2.6.17 Message-Id: <20060618031811.8A30B4A588F9@chook.melbourne.sgi.com> Date: Sun, 18 Jun 2006 13:18:11 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 7960 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 10441 Lines: 136 Date: Sun Jun 18 13:17:41 AEST 2006 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:26275a Makefile - 1.43 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/Makefile.diff?r1=text&tr1=1.43&r2=text&tr2=1.42&f=h arch/alpha/Kconfig - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/alpha/Kconfig.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h arch/arm/mach-sa1100/neponset.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/mach-sa1100/neponset.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h arch/i386/kernel/setup.c - 1.19 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/i386/kernel/setup.c.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h arch/sparc/kernel/smp.c - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/sparc/kernel/smp.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h arch/sparc64/kernel/smp.c - 1.19 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/sparc64/kernel/smp.c.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h arch/sparc64/kernel/sparc64_ksyms.c - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/sparc64/kernel/sparc64_ksyms.c.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h arch/sparc64/kernel/traps.c - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/sparc64/kernel/traps.c.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h arch/x86_64/kernel/io_apic.c - 1.23 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/x86_64/kernel/io_apic.c.diff?r1=text&tr1=1.23&r2=text&tr2=1.22&f=h drivers/cdrom/cdrom.c - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/cdrom/cdrom.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h drivers/char/Makefile - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/char/Makefile.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h drivers/char/n_tty.c - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/char/n_tty.c.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h drivers/net/e1000/e1000_ethtool.c - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/e1000/e1000_ethtool.c.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h drivers/net/e1000/e1000_main.c - 1.20 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/e1000/e1000_main.c.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h drivers/net/tg3.c - 1.25 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/tg3.c.diff?r1=text&tr1=1.25&r2=text&tr2=1.24&f=h drivers/net/tg3.h - 1.19 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/tg3.h.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h drivers/pci/pci-driver.c - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/pci/pci-driver.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h drivers/pci/pci.c - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/pci/pci.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h drivers/video/console/fbcon.c - 1.21 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/video/console/fbcon.c.diff?r1=text&tr1=1.21&r2=text&tr2=1.20&f=h fs/bio.c - 1.19 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/bio.c.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h fs/locks.c - 1.18 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/locks.c.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h include/linux/elevator.h - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/elevator.h.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h include/linux/i2o.h - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/i2o.h.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h kernel/exit.c - 1.34 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/kernel/exit.c.diff?r1=text&tr1=1.34&r2=text&tr2=1.33&f=h mm/shmem.c - 1.19 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/mm/shmem.c.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h mm/vmscan.c - 1.25 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/mm/vmscan.c.diff?r1=text&tr1=1.25&r2=text&tr2=1.24&f=h net/ipv4/ip_forward.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv4/ip_forward.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h net/ipv4/tcp_input.c - 1.18 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv4/tcp_input.c.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h arch/arm/mach-integrator/integrator_cp.c - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/mach-integrator/integrator_cp.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h arch/arm/mach-versatile/core.c - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/mach-versatile/core.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h include/linux/mempolicy.h - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/mempolicy.h.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h arch/arm/mach-imx/irq.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/mach-imx/irq.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/message/i2o/iop.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/message/i2o/iop.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h drivers/message/i2o/exec-osm.c - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/message/i2o/exec-osm.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h include/linux/pci-acpi.h - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/pci-acpi.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/usb/host/ohci-pxa27x.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/host/ohci-pxa27x.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h arch/i386/kernel/acpi/earlyquirk.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/i386/kernel/acpi/earlyquirk.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/acpi/processor_perflib.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/acpi/processor_perflib.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h fs/debugfs/inode.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/debugfs/inode.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h kernel/posix-cpu-timers.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/kernel/posix-cpu-timers.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/message/fusion/mptspi.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/message/fusion/mptspi.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/scsi/sata_mv.c - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/sata_mv.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h net/dccp/ackvec.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/dccp/ackvec.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/arm/mach-pxa/spitz.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/mach-pxa/spitz.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h include/asm-s390/futex.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-s390/futex.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h block/noop-iosched.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/block/noop-iosched.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h block/elevator.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/block/elevator.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h block/deadline-iosched.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/block/deadline-iosched.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h block/cfq-iosched.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/block/cfq-iosched.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h block/as-iosched.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/block/as-iosched.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/powerpc/platforms/pseries/setup.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/powerpc/platforms/pseries/setup.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h include/asm-powerpc/cputable.h - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-powerpc/cputable.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h arch/powerpc/platforms/cell/setup.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/powerpc/platforms/cell/setup.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/powerpc/mm/hash_native_64.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/powerpc/mm/hash_native_64.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/powerpc/kernel/signal_64.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/powerpc/kernel/signal_64.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h arch/powerpc/kernel/signal_32.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/powerpc/kernel/signal_32.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h arch/powerpc/kernel/prom_init.c - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/powerpc/kernel/prom_init.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h drivers/net/sky2.c - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/sky2.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h include/asm-arm/arch-pxa/ohci.h - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-arm/arch-pxa/ohci.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h Documentation/memory-barriers.txt - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/Documentation/memory-barriers.txt.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/arm/mach-ep93xx/ts72xx.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/mach-ep93xx/ts72xx.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/sparc64/kernel/pci_sun4v.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/sparc64/kernel/pci_sun4v.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/net/wireless/bcm43xx/bcm43xx_dma.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/wireless/bcm43xx/bcm43xx_dma.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h From owner-xfs@oss.sgi.com Sun Jun 18 02:26:29 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 18 Jun 2006 02:26:44 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.190]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5I9QRDW019039 for ; Sun, 18 Jun 2006 02:26:28 -0700 Received: by nf-out-0910.google.com with SMTP id o63so990671nfa for ; Sun, 18 Jun 2006 02:26:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=ODFq+TwulHS3bCJAzvyRC41Ad5p31c5TcDcGzQCnbUoOjCyXI+lSg/cpQzT2+RIrMgWCWwP2yQr+93FLsDu3UNYWKk1SWrbstVonNP0zgGUTFXSfdyLBAYp6b3DrgfkkQb/XzKoJIIJDIOcshvo4+bVPt0rfpK+LEEHzZHlukio= Received: by 10.49.15.8 with SMTP id s8mr3926118nfi; Sun, 18 Jun 2006 02:26:12 -0700 (PDT) Received: from ?192.168.0.3? ( [62.103.236.162]) by mx.gmail.com with ESMTP id p43sm2626546nfa.2006.06.18.02.26.10; Sun, 18 Jun 2006 02:26:12 -0700 (PDT) Message-ID: <44951D44.5070701@gmail.com> Date: Sun, 18 Jun 2006 12:30:44 +0300 From: Panagiotis Atmatzidis Reply-To: p.atmatzidis@gmail.com User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060530) MIME-Version: 1.0 To: christian CC: xfs@oss.sgi.com Subject: Re: XFS - bad primary superblock - bad magic number !!! References: <4492F5DB.20507@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7961 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: p.atmatzidis@gmail.com Precedence: bulk X-list: xfs Content-Length: 989 Lines: 34 christian wrote: > On Fri, 16 Jun 2006, Panagiotis Atmatzidis wrote: >> #xfs_repair -n /dev/mapper/enc-a >> Phase 1 - find and verify superblock... >> bad primary superblock - bad magic number !!! > > Maybe the crypto setup failed and /dev/mapper/enc-a has not been > decrypted. What does > > $ dd if=/dev/mapper/enc-a bs=1k count=20 | less > > or > > $ dd if=/dev/mapper/enc-a bs=1k count=20 | file - > > show you? Here I can "less" through something which appears to an XFS > header, ater this I can even see filecontents. The 2nd command should > show sth. like "SGI XFS filesystem data". > > And don't forget to use a current kernel/xfsprogs before doing sth. with > the FS.... > Hello, Thank you for the reply. You are probably right. After the third reboot the 3 filesystems seem to be working as usual (which is fine) and nothing appears to be corrupted in any way. I'm not really sure about what happened but, it could be the encryption. Thank you, Best Regards From owner-xfs@oss.sgi.com Sun Jun 18 03:31:19 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 18 Jun 2006 03:31:34 -0700 (PDT) Received: from lucidpixels.com (lucidpixels.com [66.45.37.187]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5IAVIDW026987 for ; Sun, 18 Jun 2006 03:31:18 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id AD05A6078F9D; Sun, 18 Jun 2006 06:31:02 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id A364916135520; Sun, 18 Jun 2006 06:31:02 -0400 (EDT) Date: Sun, 18 Jun 2006 06:31:02 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: linux-raid@vger.kernel.org cc: linux-kernel@vger.kernel.org, xfs@oss.sgi.com Subject: SW RAID 5 Bug? - Slow After Rebuild (XFS+2.6.16.20) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 7962 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs Content-Length: 5817 Lines: 116 I set a disk faulty and then rebuilt it, afterwards, I got horrible performance, I was using 2.6.16.20 during the tests. The FS I use is XFS. # xfs_info /dev/md3 meta-data=/dev/root isize=256 agcount=16, agsize=1097941 blks = sectsz=512 attr=0 data = bsize=4096 blocks=17567056, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=8577, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 After a raid5 rebuild before reboot: $ cat 448mb.img > /dev/null 0 1 4 25104 64 905560 0 0 4 0 1027 154 0 0 88 12 0 0 4 14580 64 914128 0 0 14344 34 1081 718 0 2 77 21 0 0 4 14516 64 912360 0 0 10312 184 1128 1376 0 3 97 0 0 0 4 15244 64 911884 0 0 12660 0 1045 1248 0 3 97 0 0 0 4 15464 64 911272 0 0 11916 0 1055 1081 0 3 98 0 0 1 4 15100 64 915488 0 0 7844 0 1080 592 0 3 76 21 0 1 4 13840 64 916780 0 0 1268 0 1295 1757 0 1 49 49 0 1 4 13480 64 917188 0 0 388 48 1050 142 0 1 50 49 procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu---- r b swpd free buff cache si so bi bo in cs us sy id wa 0 1 4 14816 64 915896 0 0 492 0 1047 321 0 1 49 49 0 1 4 14504 64 916236 0 0 324 0 1022 108 0 2 50 49 0 1 4 14144 64 916576 0 0 388 0 1021 108 0 1 50 50 0 1 4 13904 64 916848 0 0 256 0 1043 159 0 0 50 49 0 1 4 13728 64 917120 0 0 260 24 1032 102 0 1 50 49 0 0 4 15244 64 913040 0 0 11856 0 1042 1315 0 3 90 7 0 0 4 14564 64 913652 0 0 12288 0 1068 1137 1 3 97 0 0 0 4 15252 64 912972 0 0 12288 0 1054 1128 0 3 97 0 0 0 4 15132 64 913108 0 0 16384 0 1048 1368 0 4 96 0 0 0 4 15372 64 912836 0 0 12288 0 1062 1125 0 3 97 0 0 0 4 15660 64 912632 0 0 12288 0 1065 1093 0 3 97 0 0 0 4 15388 64 912768 0 0 12288 0 1042 1051 0 3 97 0 0 0 4 15028 64 913312 0 0 12288 0 1040 1122 0 3 97 0 With an ftp: 0 1 4 208564 64 723660 0 0 8192 0 1945 495 0 4 53 44 1 0 4 200592 64 731820 0 0 8192 0 1828 459 0 5 52 44 0 0 4 194472 64 737940 0 0 6144 0 1396 220 0 2 50 47 0 1 4 186128 64 746168 0 0 8192 0 1622 377 0 4 51 45 0 1 4 180008 64 752288 0 0 6144 0 1504 339 0 3 51 46 0 1 4 174012 64 758476 0 0 6144 0 1438 229 0 3 51 47 0 1 4 167956 64 764596 0 0 6144 0 1498 263 0 2 51 46 0 1 4 162084 64 770716 0 0 6144 0 1497 326 0 3 51 46 0 1 4 156152 64 776904 0 0 6144 0 1476 293 0 3 51 47 0 1 4 150048 64 783024 0 0 6144 20 1514 273 0 2 51 46 Also note, when I run 'sync' it would take up to 5 minutes!!! And I was not even doing anything on the array. After reboot: `448mb.img' at 161467144 (34%) 42.82M/s eta:7s [Receiving data] `448mb.img' at 283047424 (60%) 45.23M/s eta:4s [Receiving data] `448mb.img' at 406802192 (86%) 46.29M/s eta:1s [Receiving data] Write speed to the RAID5 is also back to normal. 0 0 0 16664 8 928940 0 0 0 44478 1522 19791 1 35 43 21 0 0 0 15304 8 930368 0 0 20 49816 1437 19260 0 21 59 20 0 0 4 16964 8 928324 0 0 20 50388 1410 20059 0 20 47 33 0 0 4 13504 8 931928 0 0 0 46792 1449 16712 0 17 69 15 0 0 4 14952 8 930432 0 0 8 43510 1489 16443 0 16 60 23 0 0 4 16328 8 929072 0 0 36 50316 1498 16972 1 19 59 23 0 1 4 16708 8 928460 0 0 0 45604 1504 17196 0 19 55 26 procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu---- r b swpd free buff cache si so bi bo in cs us sy id wa 0 0 4 16968 8 928120 0 4 0 47640 1584 17821 0 19 57 25 0 0 4 15160 8 929888 0 0 0 40836 1637 15335 0 17 63 19 0 1 4 15372 8 929616 0 0 0 41932 1630 14862 0 17 64 19 Was curious if anyone else had seen this? /dev/md3: Version : 00.90.03 Creation Time : Sun Jun 11 16:52:00 2006 Raid Level : raid5 Array Size : 1562834944 (1490.44 GiB 1600.34 GB) Device Size : 390708736 (372.61 GiB 400.09 GB) Raid Devices : 5 Total Devices : 5 Preferred Minor : 3 Persistence : Superblock is persistent Update Time : Sun Jun 18 06:26:08 2006 State : clean Active Devices : 5 Working Devices : 5 Failed Devices : 0 Spare Devices : 0 Layout : left-symmetric Chunk Size : 512K UUID : 7c9d7547:99200e21:0c0523df:14ed90a3 Events : 0.421994 Number Major Minor RaidDevice State 0 3 1 0 active sync /dev/hda1 1 89 1 1 active sync /dev/hdo1 2 57 1 2 active sync /dev/hdk1 3 88 1 3 active sync /dev/hdm1 4 56 1 4 active sync /dev/hdi1 # mdadm -V mdadm - v1.12.0 - 14 June 2005 From owner-xfs@oss.sgi.com Sun Jun 18 16:50:54 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 18 Jun 2006 16:51:24 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k5INoaDW018998 for ; Sun, 18 Jun 2006 16:50:50 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA13565; Mon, 19 Jun 2006 08:45:54 +1000 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k5IMjbEo7529897; Mon, 19 Jun 2006 08:45:38 +1000 (AEST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k5IMjYam7528123; Mon, 19 Jun 2006 08:45:34 +1000 (AEST) Date: Mon, 19 Jun 2006 08:45:34 +1000 From: David Chinner To: Justin Piszcz Cc: xfs@oss.sgi.com, linux-raid-owner@vger.kernel.org Subject: Re: Need SW RAID5 & mkfs.xfs help with chunksize & swidth/su respectively Message-ID: <20060618224534.GY2114946@melbourne.sgi.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-archive-position: 7963 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 1151 Lines: 39 On Fri, Jun 16, 2006 at 05:27:14PM -0400, Justin Piszcz wrote: > Two questions, a SW RAID and XFS question. > > SW RAID Question: What is the optimal chunk size for a RAID5 that will be > used with XFS? The answer to that is "it depends". It depends on workload, file sizes, write patterns, etc. There is no magic number that will give you the best performance in all cases. > I have 5x400GB Seagate HDDs (ATA/100) w/ 8MB of Cache, > each is a master on its own IDE bus. ... > I have a software raid5 with 5 400GB drives and currently a 512kb > chunksize with default mkfs.xfs parameters. > > p34:~# mdadm --create /dev/md3 --verbose --chunk=512 --level=5 > --raid-devices=5 /dev/hda1 /dev/hde1 /dev/hdg1 /dev/hdi1 /dev/hdk1 > mdadm: layout defaults to left-symmetric > mdadm: size set to 390708736K > mdadm: array /dev/md3 started. > p34:~# > > What parameters for the sunit/sw are optimal for my configuration? How > exactly do I calculate them? stripe unit = MD chunk size stripe width = MD Chunk size * number of data disks in stripe (N-1 for RAID5) Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Sun Jun 18 21:45:51 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 18 Jun 2006 21:46:23 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k5J4jXDW020255 for ; Sun, 18 Jun 2006 21:45:49 -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 OAA20030; Mon, 19 Jun 2006 14:44:56 +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 k5J4irgw1049562; Mon, 19 Jun 2006 14:44:54 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k5J4ioNs1049069; Mon, 19 Jun 2006 14:44:50 +1000 (EST) Date: Mon, 19 Jun 2006 14:44:49 +1000 From: Nathan Scott To: Jan Wagner Cc: xfs@oss.sgi.com Subject: Re: separate log and structure from user data device? Message-ID: <20060619144449.B1047032@wobbly.melbourne.sgi.com> References: <8630.1149517148@ocs3.ocs.com.au> <20060606101258.B644608@wobbly.melbourne.sgi.com> <20060608104242.I710447@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jwagner@kurp.hut.fi on Fri, Jun 16, 2006 at 02:38:19PM +0300 X-archive-position: 7964 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 2260 Lines: 65 On Fri, Jun 16, 2006 at 02:38:19PM +0300, Jan Wagner wrote: > > Or more simply (ie. without create + set-realtime-explicitly)... > > > > # mkdir /mnt/test/realtime > > # xfs_io -c 'chattr +t' -c 'lsattr -v' /mnt/test/realtime > > [rt-inherit] /mnt/test/realtime > > Thanks for the tip also, that would really be the easiest way - there'd be > several other code that I would have to edit otherwise. > > But for some reason at least the above xfs_io command does not work, I get > > # mkdir /i1/inherit > # xfs_io -c 'chattr +t' -c 'lsattr -v' /i1/inherit > /i1/inherit: Is a directory > ... > "Is a directory", any ideas? Oh, your xfs_io is a bit dated, Tim improved the behaviour in this area awhile back. You will need the -r command line option with that version, IIRC. > Do I need to get XFS source from elsewhere than the one included in > debian kernel 2.6.16? Nope, thats fine. > Oh and another question, is it possible that realtime reads are much > slower than writes? Or am I again making a mistake somewhere? Hmm, thats odd. > # xfs_io -fR /i1/testfile -c 'pwrite -b 4m 0 2g' > wrote 2147483648/2147483648 bytes at offset 0 > 2.000 GiB, 512 ops; 00:00:05.645958 (362.737 MiB/sec and 90.6843 ops/sec) > > write 360MiB/s > > # xfs_io -fR /i1/testfile -c 'pread -b 4m 2g' > read 2147483648/2147483648 bytes at offset 0 > 2.000 GiB, 512 ops; 00:00:39.156626 (52.303 MiB/sec and 13.0757 ops/sec) > > # xfs_io -fR /i1/testfile -c 'pread 4m 2g' > read 2147483648/2147483648 bytes at offset 4194304 > 2.000 GiB, 524288 ops; 00:00:27.229922 (75.211 MiB/sec and 19254.1132 > ops/sec) These last two are not what you want, I think, esp. the very last one; the -b option specific the buffer size. In the last case you're using 1k instead of 4m buffers (hence the large number of ops). But the 2nd last case doesn't suffer that - it doesnt give an offset, but looks like xfs_io is defaulting to zero there. Since you're doing buffered reads/writes, your read numbers there may be being influenced by writeout. Try using the pwrite command with -W and/ or unmount+mount between benchmark runs. When I run it locally, reading from disk shows slightly better results than writing (single file, single process, single disk). cheers. -- Nathan From owner-xfs@oss.sgi.com Sun Jun 18 23:52:01 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 18 Jun 2006 23:52:17 -0700 (PDT) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.228]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5J6naDW003823 for ; Sun, 18 Jun 2006 23:52:00 -0700 Received: by wr-out-0506.google.com with SMTP id i28so789129wra for ; Sun, 18 Jun 2006 23:49:23 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=sbT4LDnTUwsefS8GxNb1ZLayYZ+aPCzbv3XGLHuNOIf19kXv0po72v9xfZn59XjC+/3PHma5uQCA6bDNIlDoGS4Sui3qVhFMLkySpAYcA9RaQzfqmjtibvh3dKyOzc4qjdjd/XjW3MJgOn71r8xqXG5bW10LzztcjtrwaLLU+4s= Received: by 10.54.79.17 with SMTP id c17mr5636057wrb; Sun, 18 Jun 2006 22:53:24 -0700 (PDT) Received: by 10.54.102.12 with HTTP; Sun, 18 Jun 2006 22:53:24 -0700 (PDT) Message-ID: <3aa654a40606182253h50f4a3efnb50b3a61663c199b@mail.gmail.com> Date: Sun, 18 Jun 2006 22:53:24 -0700 From: "Avuton Olrich" To: linux-xfs@oss.sgi.com Subject: Re: Crashed twice, once in 2.6.16.20, next in 2.6.17 Cc: "Avuton Olrich" In-Reply-To: <3aa654a40606182249k5d419d97r376a04085b673895@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3aa654a40606182249k5d419d97r376a04085b673895@mail.gmail.com> X-archive-position: 7966 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: avuton@gmail.com Precedence: bulk X-list: xfs Content-Length: 180 Lines: 9 On 6/18/06, Avuton Olrich wrote: ...stuff... Please CC me I'm not on the list. -- avuton -- Anyone who quotes me in their sig is an idiot. -- Rusty Russell. From owner-xfs@oss.sgi.com Mon Jun 19 00:45:13 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 19 Jun 2006 00:45:28 -0700 (PDT) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.226]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5J7jCDW017162 for ; Mon, 19 Jun 2006 00:45:12 -0700 Received: by wr-out-0506.google.com with SMTP id 58so961242wri for ; Mon, 19 Jun 2006 00:44:58 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=SV2PfUu9Lio3E4H5XhNGHORSq0BwPo+dd7QjSsxG+VSDuXFfAD+EYx4q47vUAQnaLKYStpOlIVXoP3aA/NwrtUCKwbPtL3dLmm197X08w9GL0bjjHEevTpG7wvN5fQbkeBw+wePh9S8UJtKaPs2tcUT2hXhmoDFV4zRSrN5zjXA= Received: by 10.54.80.13 with SMTP id d13mr5748930wrb; Mon, 19 Jun 2006 00:44:58 -0700 (PDT) Received: by 10.54.102.12 with HTTP; Mon, 19 Jun 2006 00:44:58 -0700 (PDT) Message-ID: <3aa654a40606190044q43dca571qdc06ee13d82d979@mail.gmail.com> Date: Mon, 19 Jun 2006 00:44:58 -0700 From: "Avuton Olrich" To: "Linux Kernel Mailing List" , linux-xfs@oss.sgi.com Subject: XFS crashed twice, once in 2.6.16.20, next in 2.6.17, reproducable MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-archive-position: 7967 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: avuton@gmail.com Precedence: bulk X-list: xfs Content-Length: 2585 Lines: 58 Didn't make it to the linux-xfs list, it's not working so I'll try by sending it both to the LKML and linux-xfs again. Hello, when trying to recursively delete a directory (same directory twice) from my 500gb hard drive I get a problem. It crashed first in 2.6.16.20, then I upgraded to try to get rid of the issue. This one is from 2.6.17: xfs_da_do_buf: bno 16777216 dir: inode 1507133580 Filesystem "sda1": XFS internal error xfs_da_do_buf(1) at line 2119 of file /usr/src/linux-stable-cold/fs/xfs/xfs_da_btree.c. Caller 0xb01 d9b63 xfs_da_do_buf+0x40e/0x7c7 xfs_da_read_buf+0x30/0x35 xfs_dir2_leafn_lookup_int+0x2f3/0x453 xfs_da_read_buf+0x30/0x35 xfs_dir2_node_removename+0x288/0x47f xfs_dir2_node_removename+0x288/0x47f xfs_dir2_removename+0xce/0xd5 kmem_zone_alloc+0x4d/0x98 xfs_remove+0x2ac/0x444 xfs_vn_unlink+0x17/0x3b xfs_lookup+0x6e/0x78 __capable+0xc/0x1f generic_permission+0x93/0xcc permission+0x98/0xa4 may_delete+0x32/0xe9 vfs_unlink+0x6d/0xa3 do_unlinkat+0x92/0x125 sys_getdents64+0x9c/0xa6 sysenter_past_esp+0x54/0x75 Filesystem "sda1": XFS internal error xfs_trans_cancel at line 1150 of file /usr/src/linux-stable-cold/fs/xfs/xfs_trans.c. Caller 0xb020d2 5e xfs_trans_cancel+0x59/0xe5 xfs_remove+0x41b/0x444 xfs_remove+0x41b/0x444 xfs_vn_unlink+0x17/0x3b xfs_lookup+0x6e/0x78 __capable+0xc/0x1f generic_permission+0x93/0xcc permission+0x98/0xa4 may_delete+0x32/0xe9 vfs_unlink+0x6d/0xa3 do_unlinkat+0x92/0x125 sys_getdents64+0x9c/0xa6 sysenter_past_esp+0x54/0x75 xfs_force_shutdown(sda1,0x8) called from line 1151 of file /usr/src/linux-stable-cold/fs/xfs/xfs_trans.c. Return address = 0xb0218b68 Filesystem "sda1": Corruption of in-memory data detected. Shutting down filesystem: sda1 While trying to xfs_repair I get the following: fatal error -- can't read block 16777216 for directory inode 1507133580 Badblocks has been run on this machine and it was sucessful. I did find an old thread with this, but no solution: http://oss.sgi.com/archives/xfs/2005-02/msg00067.html config: http://olricha.homelinux.net:8080/config.gz Thanks for any help. If I can help at all please let me know. -- avuton -- Anyone who quotes me in their sig is an idiot. -- Rusty Russell. From owner-xfs@oss.sgi.com Mon Jun 19 03:35:58 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 19 Jun 2006 03:36:13 -0700 (PDT) Received: from lion.flexserv.de (flexserv.de [213.239.215.214]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5JAZvDW007974 for ; Mon, 19 Jun 2006 03:35:57 -0700 Received: from localhost (localhost [127.0.0.1]) by lion.flexserv.de (Postfix) with ESMTP id 6817B14E241; Mon, 19 Jun 2006 12:35:32 +0200 (CEST) Received: from lion.flexserv.de ([127.0.0.1]) by localhost (lion [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 21346-07-2; Mon, 19 Jun 2006 12:35:32 +0200 (CEST) Received: from changer.flexserv.de (changer.flexserv.de [213.217.69.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "changer.flexserv.de", Issuer "flexserv.de" (verified OK)) by lion.flexserv.de (Postfix) with ESMTP id 3CB0B14E240; Mon, 19 Jun 2006 12:35:32 +0200 (CEST) Received: from localhost (localhost.localdomain [127.0.0.1]) by changer.flexserv.de (Postfix) with ESMTP id A4DC2180035C; Mon, 19 Jun 2006 12:35:00 +0200 (CEST) Received: from changer.flexserv.de ([192.168.1.10]) by localhost (changer1 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 00515-07-2; Mon, 19 Jun 2006 12:35:00 +0200 (CEST) Received: from xserver.flexserv.de (xserver.walki.homelinux.org [192.168.1.240]) by changer.flexserv.de (Postfix) with ESMTP id 59DF61800357; Mon, 19 Jun 2006 12:35:00 +0200 (CEST) To: "Avuton Olrich" Cc: "Linux Kernel Mailing List" , linux-xfs@oss.sgi.com Subject: Re: XFS crashed twice, once in 2.6.16.20, next in 2.6.17, reproducable Organization: Flexserv In-Reply-To: <3aa654a40606190044q43dca571qdc06ee13d82d979@mail.gmail.com> (Avuton Olrich's message of "Mon, 19 Jun 2006 00:44:58 -0700") References: <3aa654a40606190044q43dca571qdc06ee13d82d979@mail.gmail.com> From: daniel+devel.linux.lkml@flexserv.de X-GPG-ID: 0x7B196671 X-GPG-FP: A9CE 5788 44D3 A1A2 46B6 A727 53D8 DD4B 7B19 6671 X-message-flag: Formating hard disk. please wait... 10%... 20%... Date: Mon, 19 Jun 2006 12:35:25 +0200 Message-ID: <87slm15t76.fsf@xserver.flexserv.de> User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 7968 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: daniel+devel.linux.lkml@flexserv.de Precedence: bulk X-list: xfs Content-Length: 445 Lines: 14 "Avuton Olrich" writes: The same here. after a complete mkfs.xfs under 2.6.17-rc6 it was solved. Same if i boot 2.6.8 mk.xfs, boot into 2.6.16 the xfs get "shreddered" a directly boot from .8 to .17-rc6 works. so i think there was a bug in .16 in the transition of the xfs wich got solved somewhere in the .17.rc? time. > Filesystem "sda1": Corruption of in-memory data detected. Shutting > down filesystem: sda1 Daniel From owner-xfs@oss.sgi.com Mon Jun 19 13:53:56 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 19 Jun 2006 13:54:10 -0700 (PDT) Received: from citi.umich.edu (citi.umich.edu [141.211.133.111]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5JKrtDW014832 for ; Mon, 19 Jun 2006 13:53:56 -0700 Received: by citi.umich.edu (Postfix, from userid 149053) id F21B11BB71; Mon, 19 Jun 2006 15:53:23 -0400 (EDT) Date: Mon, 19 Jun 2006 15:53:23 -0400 From: Martin Murray To: linux-xfs@oss.sgi.com Subject: xfs internal error in fs/xfs/xfs_da_btree.c Message-ID: <20060619195323.GA21165@citi.citi.umich.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-archive-position: 7969 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: murrayma@citi.umich.edu Precedence: bulk X-list: xfs Content-Length: 3449 Lines: 80 Howdy, Didn't think much of this until I saw Avuton Olrich's post. I had the following bug while doing an apt-get upgrade. I rebooted with a linux cdrom and dd'd the entire partition to a spare disk, so that I could debug the error or just in case something went wrong with xfs_repair. xfs_repair did a lot of magic, but the filesystem now works. I still have the backed up disk image, and a good idea which file triggered the bug, if anyone would like me to check anything. This is running 2.6.17-rc6 with John Stultz's timekeeping patches. The drive is a Fujitsu MAW3073NP on an LSI 53c1030. Otherwise, the machine isn't very remarkable. Oh, it is SMP. -Martin Filesystem "sda2": XFS internal error xfs_da_do_buf(2) at line 2213 of file fs/xfs/xfs_da_btree.c. Caller 0xffffffff80368034 Call Trace: [] xfs_corruption_error+0xef/0x110 [] kmem_zone_alloc+0x5b/0xc0 [] xfs_da_buf_make+0x2a/0x150 [] xfs_da_do_buf+0x66f/0x780 [] xfs_da_read_buf+0x24/0x30 [] kmem_zone_alloc+0x5b/0xc0 [] xfs_da_read_buf+0x24/0x30 [] xfs_dir2_leafn_lookup_int+0x2f2/0x4b0 [] xfs_dir2_leafn_lookup_int+0x2f2/0x4b0 [] xfs_da_node_lookup_int+0x1fe/0x2c0 [] xfs_dir2_node_lookup+0x48/0xd0 [] xfs_dir2_isleaf+0x19/0x50 [] xfs_dir2_lookup+0x122/0x160 [] xfs_log_release_iclog+0x10/0x40 [] xfs_dir_lookup_int+0x4b/0x110 [] xfs_rename+0x1d8/0xc90 [] __up_read+0x21/0xd0 [] _spin_unlock_irqrestore+0x16/0x40 [] xfs_iunlock+0x66/0xa0 [] xfs_access+0x4a/0x60 [] xfs_vn_rename+0x4e/0xc0 [] __up_read+0x21/0xd0 [] _spin_unlock_irqrestore+0x16/0x40 [] xfs_iunlock+0x66/0xa0 [] kstrdup+0x4f/0x70 [] vfs_rename+0x216/0x3a0 [] sys_renameat+0x1c9/0x270 [] _spin_lock+0xe/0x70 [] _spin_unlock+0x14/0x40 [] mntput_no_expire+0x1c/0x80 [] system_call+0x7e/0x83 followed after by: Filesystem "sda2": XFS internal error xfs_da_do_buf(2) at line 2213 of file fs/xfs/xfs_da_btree.c. Caller 0xffffffff80368034 Call Trace: [] xfs_corruption_error+0xef/0x110 [] kmem_zone_alloc+0x5b/0xc0 [] xfs_da_buf_make+0x2a/0x150 [] xfs_da_do_buf+0x66f/0x780 [] xfs_da_read_buf+0x24/0x30 [] xfs_bmapi+0x2f1/0x1f50 [] _spin_lock+0xe/0x70 [] xfs_da_read_buf+0x24/0x30 [] xfs_dir2_leaf_getdents+0x448/0x7b0 [] xfs_dir2_leaf_getdents+0x448/0x7b0 [] xfs_dir2_put_dirent64_direct+0x0/0x80 [] xfs_dir2_getdents+0x118/0x160 [] __handle_mm_fault+0x36b/0xa10 [] xfs_readdir+0x61/0xa0 [] xfs_file_readdir+0xdb/0x230 [] filldir64+0x0/0xf0 [] filldir64+0x0/0xf0 [] vfs_readdir+0x73/0xc0 [] sys_getdents64+0x7f/0xd0 [] system_call+0x7e/0x83 From owner-xfs@oss.sgi.com Mon Jun 19 14:39:32 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 19 Jun 2006 14:39:47 -0700 (PDT) Received: from slurp.thebarn.com (cattelan-host201.dsl.visi.com [208.42.117.201]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5JLdVDW019164 for ; Mon, 19 Jun 2006 14:39:32 -0700 Received: from [10.0.0.12] (ease.thebarn.com [10.0.0.12]) (authenticated bits=0) by slurp.thebarn.com (8.13.5/8.13.5) with ESMTP id k5JLdCjM043232; Mon, 19 Jun 2006 16:39:12 -0500 (CDT) (envelope-from cattelan@thebarn.com) Message-ID: <4497197F.8020602@thebarn.com> Date: Mon, 19 Jun 2006 16:39:11 -0500 From: Russell Cattelan User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Martin Murray CC: linux-xfs@oss.sgi.com Subject: Re: xfs internal error in fs/xfs/xfs_da_btree.c References: <20060619195323.GA21165@citi.citi.umich.edu> In-Reply-To: <20060619195323.GA21165@citi.citi.umich.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7970 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: cattelan@thebarn.com Precedence: bulk X-list: xfs Content-Length: 3779 Lines: 93 Martin Murray wrote: >Howdy, Didn't think much of this until I saw Avuton Olrich's post. I had the >following bug while doing an apt-get upgrade. I rebooted with a linux cdrom >and dd'd the entire partition to a spare disk, so that I could debug the error >or just in case something went wrong with xfs_repair. > >xfs_repair did a lot of magic, but the filesystem now works. I still have the >backed up disk image, and a good idea which file triggered the bug, if anyone >would like me to check anything. > > Did you happen to save that output. Or could you re-run on one of your backup images? It looks like one of the sizes on disk is corrupt and xfs it trying to allocate a bunch of memory based on that corrupted size. >This is running 2.6.17-rc6 with John Stultz's timekeeping patches. The drive >is a Fujitsu MAW3073NP on an LSI 53c1030. Otherwise, the machine isn't very >remarkable. Oh, it is SMP. > >-Martin > >Filesystem "sda2": XFS internal error xfs_da_do_buf(2) at line 2213 of file >fs/xfs/xfs_da_btree.c. Caller 0xffffffff80368034 > >Call Trace: > [] xfs_corruption_error+0xef/0x110 > [] kmem_zone_alloc+0x5b/0xc0 > [] xfs_da_buf_make+0x2a/0x150 > [] xfs_da_do_buf+0x66f/0x780 > [] xfs_da_read_buf+0x24/0x30 > [] kmem_zone_alloc+0x5b/0xc0 > [] xfs_da_read_buf+0x24/0x30 > [] xfs_dir2_leafn_lookup_int+0x2f2/0x4b0 > [] xfs_dir2_leafn_lookup_int+0x2f2/0x4b0 > [] xfs_da_node_lookup_int+0x1fe/0x2c0 > [] xfs_dir2_node_lookup+0x48/0xd0 > [] xfs_dir2_isleaf+0x19/0x50 > [] xfs_dir2_lookup+0x122/0x160 > [] xfs_log_release_iclog+0x10/0x40 > [] xfs_dir_lookup_int+0x4b/0x110 > [] xfs_rename+0x1d8/0xc90 > [] __up_read+0x21/0xd0 > [] _spin_unlock_irqrestore+0x16/0x40 > [] xfs_iunlock+0x66/0xa0 > [] xfs_access+0x4a/0x60 > [] xfs_vn_rename+0x4e/0xc0 > [] __up_read+0x21/0xd0 > [] _spin_unlock_irqrestore+0x16/0x40 > [] xfs_iunlock+0x66/0xa0 > [] kstrdup+0x4f/0x70 > [] vfs_rename+0x216/0x3a0 > [] sys_renameat+0x1c9/0x270 > [] _spin_lock+0xe/0x70 > [] _spin_unlock+0x14/0x40 > [] mntput_no_expire+0x1c/0x80 > [] system_call+0x7e/0x83 > > >followed after by: > >Filesystem "sda2": XFS internal error xfs_da_do_buf(2) at line 2213 of file >fs/xfs/xfs_da_btree.c. Caller 0xffffffff80368034 > >Call Trace: > [] xfs_corruption_error+0xef/0x110 > [] kmem_zone_alloc+0x5b/0xc0 > [] xfs_da_buf_make+0x2a/0x150 > [] xfs_da_do_buf+0x66f/0x780 > [] xfs_da_read_buf+0x24/0x30 > [] xfs_bmapi+0x2f1/0x1f50 > [] _spin_lock+0xe/0x70 > [] xfs_da_read_buf+0x24/0x30 > [] xfs_dir2_leaf_getdents+0x448/0x7b0 > [] xfs_dir2_leaf_getdents+0x448/0x7b0 > [] xfs_dir2_put_dirent64_direct+0x0/0x80 > [] xfs_dir2_getdents+0x118/0x160 > [] __handle_mm_fault+0x36b/0xa10 > [] xfs_readdir+0x61/0xa0 > [] xfs_file_readdir+0xdb/0x230 > [] filldir64+0x0/0xf0 > [] filldir64+0x0/0xf0 > [] vfs_readdir+0x73/0xc0 > [] sys_getdents64+0x7f/0xd0 > [] system_call+0x7e/0x83 > > > > From owner-xfs@oss.sgi.com Mon Jun 19 23:11:08 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 19 Jun 2006 23:11:33 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k5K6AqDW024652 for ; Mon, 19 Jun 2006 23:11:04 -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 QAA22760; Tue, 20 Jun 2006 16:10:15 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k5K6AAgw1081697; Tue, 20 Jun 2006 16:10:11 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k5K6A6NU1079814; Tue, 20 Jun 2006 16:10:06 +1000 (EST) Date: Tue, 20 Jun 2006 16:10:06 +1000 From: Nathan Scott To: Avuton Olrich Cc: linux-kernel@vger.kernel.org, xfs@oss.sgi.com Subject: Re: XFS crashed twice, once in 2.6.16.20, next in 2.6.17, reproducable Message-ID: <20060620161006.C1079661@wobbly.melbourne.sgi.com> References: <3aa654a40606190044q43dca571qdc06ee13d82d979@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3aa654a40606190044q43dca571qdc06ee13d82d979@mail.gmail.com>; from avuton@gmail.com on Mon, Jun 19, 2006 at 12:44:58AM -0700 X-archive-position: 7971 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 1482 Lines: 41 On Mon, Jun 19, 2006 at 12:44:58AM -0700, Avuton Olrich wrote: > .. > Hello, when trying to recursively delete a directory (same directory > twice) from my 500gb hard drive I get a problem. It crashed first in > 2.6.16.20, then I upgraded to try to get rid of the issue. This one is > from 2.6.17: How reproducible is it? Is it reproducible even after xfs_repair? If so, can you try Mandy's patch below, to see if it is addressing the root cause of your problem? If problems persist, a reproducible test case would be wonderful, if one can be found.. cheers. -- Nathan Fix nused counter. It's currently getting set to -1 rather than getting decremented by 1. Since nused never reaches 0, the "if (!free->hdr.nused)" check in xfs_dir2_leafn_remove() fails every time and xfs_dir2_shrink_inode() doesn't get called when it should. This causes extra blocks to be left on an empty directory and the directory in unable to be converted back to inline extent mode. Signed-off-by: Mandy Kirkconnell Signed-off-by: Nathan Scott --- a/fs/xfs/xfs_dir2_node.c 2006-06-20 16:00:45.000000000 +1000 +++ b/fs/xfs/xfs_dir2_node.c 2006-06-20 16:00:45.000000000 +1000 @@ -972,7 +972,7 @@ xfs_dir2_leafn_remove( /* * One less used entry in the free table. */ - free->hdr.nused = cpu_to_be32(-1); + be32_add(&free->hdr.nused, -1); xfs_dir2_free_log_header(tp, fbp); /* * If this was the last entry in the table, we can From owner-xfs@oss.sgi.com Mon Jun 19 23:44:28 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 19 Jun 2006 23:44:55 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k5K6iFDW029434 for ; Mon, 19 Jun 2006 23:44:26 -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 QAA23441; Tue, 20 Jun 2006 16:43:45 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k5K6hfgw1074807; Tue, 20 Jun 2006 16:43:41 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k5K6hcS81082562; Tue, 20 Jun 2006 16:43:38 +1000 (EST) Date: Tue, 20 Jun 2006 16:43:38 +1000 From: Nathan Scott To: Avuton Olrich Cc: linux-kernel@vger.kernel.org, xfs@oss.sgi.com Subject: Re: XFS crashed twice, once in 2.6.16.20, next in 2.6.17, reproducable Message-ID: <20060620164338.A1080488@wobbly.melbourne.sgi.com> References: <3aa654a40606190044q43dca571qdc06ee13d82d979@mail.gmail.com> <20060620161006.C1079661@wobbly.melbourne.sgi.com> <3aa654a40606192338v751150fp5645d1d2943316ea@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3aa654a40606192338v751150fp5645d1d2943316ea@mail.gmail.com>; from avuton@gmail.com on Mon, Jun 19, 2006 at 11:38:58PM -0700 X-archive-position: 7972 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 764 Lines: 20 On Mon, Jun 19, 2006 at 11:38:58PM -0700, Avuton Olrich wrote: > On 6/19/06, Nathan Scott wrote: > > If so, can you try Mandy's patch below, to see if it is addressing > > the root cause of your problem? If problems persist, a reproducible > > test case would be wonderful, if one can be found.. > > I'm sorry, the patch doesn't change anything. It never makes it though > the xfs_repair due to the above error. If there's any information I > can get for you please let me know. Oh - thats a kernel patch, not a repair patch, I was more interested in whether the initial corruption could be reproduced. Which version of xfs_repair are you running? (xfs_repair -V) xfsprogs-2.7.18 will resolve your problem, I suspect. cheers. -- Nathan From owner-xfs@oss.sgi.com Mon Jun 19 23:52:59 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 19 Jun 2006 23:53:23 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k5K6qkDW030880 for ; Mon, 19 Jun 2006 23:52:58 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA23691; Tue, 20 Jun 2006 16:52:15 +1000 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k5K6qCgw1080408; Tue, 20 Jun 2006 16:52:13 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k5K6q9jp1080548; Tue, 20 Jun 2006 16:52:09 +1000 (EST) Date: Tue, 20 Jun 2006 16:52:09 +1000 From: Nathan Scott To: Avuton Olrich Cc: linux-kernel@vger.kernel.org, xfs@oss.sgi.com Subject: Re: XFS crashed twice, once in 2.6.16.20, next in 2.6.17, reproducable Message-ID: <20060620165209.C1080488@wobbly.melbourne.sgi.com> References: <3aa654a40606190044q43dca571qdc06ee13d82d979@mail.gmail.com> <20060620161006.C1079661@wobbly.melbourne.sgi.com> <3aa654a40606192338v751150fp5645d1d2943316ea@mail.gmail.com> <20060620164338.A1080488@wobbly.melbourne.sgi.com> <3aa654a40606192350w5c469670t466dfc1344e23a4@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3aa654a40606192350w5c469670t466dfc1344e23a4@mail.gmail.com>; from avuton@gmail.com on Mon, Jun 19, 2006 at 11:50:37PM -0700 X-archive-position: 7973 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 680 Lines: 19 On Mon, Jun 19, 2006 at 11:50:37PM -0700, Avuton Olrich wrote: > On 6/19/06, Nathan Scott wrote: > > Oh - thats a kernel patch, not a repair patch, I was more interested > > in whether the initial corruption could be reproduced. Which version > > of xfs_repair are you running? (xfs_repair -V) xfsprogs-2.7.18 will > > resolve your problem, I suspect. > > OK, I'm running Gentoo's latest: 2.7.11, I can't find 2.7.18 > _anywhere_ although 2.7.13 is in the pre directory on the ftp, is that > the one you're referring to? No - its in CVS (for a long time); I'll go get the ftp area updated, looks like thats been forgotten about again. cheers. -- Nathan From owner-xfs@oss.sgi.com Tue Jun 20 01:16:29 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 20 Jun 2006 01:16:50 -0700 (PDT) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.239]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5K8GSDW018191 for ; Tue, 20 Jun 2006 01:16:29 -0700 Received: by wr-out-0506.google.com with SMTP id i2so677901wra for ; Tue, 20 Jun 2006 01:16:15 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=HXmpwuXfWHgGZ3w/ppHg5cxNGoMAT1nSPWLiA9oevhas0iVOh9Ig8kJdr0P02+AbtNRXrEpAUckJdn9qMX5zHFSe0WAZXI2lnSQ6w+3rnjatgZExWDLmxceKcYEST9kzHtIaq6hN++T5o12tD0/jjiNyxKKndbHK1AzaziPfw+U= Received: by 10.54.80.13 with SMTP id d13mr232489wrb; Mon, 19 Jun 2006 23:38:58 -0700 (PDT) Received: by 10.54.102.12 with HTTP; Mon, 19 Jun 2006 23:38:58 -0700 (PDT) Message-ID: <3aa654a40606192338v751150fp5645d1d2943316ea@mail.gmail.com> Date: Mon, 19 Jun 2006 23:38:58 -0700 From: "Avuton Olrich" To: "Nathan Scott" Subject: Re: XFS crashed twice, once in 2.6.16.20, next in 2.6.17, reproducable Cc: linux-kernel@vger.kernel.org, xfs@oss.sgi.com In-Reply-To: <20060620161006.C1079661@wobbly.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3aa654a40606190044q43dca571qdc06ee13d82d979@mail.gmail.com> <20060620161006.C1079661@wobbly.melbourne.sgi.com> X-archive-position: 7974 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: avuton@gmail.com Precedence: bulk X-list: xfs Content-Length: 3398 Lines: 72 On 6/19/06, Nathan Scott wrote: > On Mon, Jun 19, 2006 at 12:44:58AM -0700, Avuton Olrich wrote: > > .. > > Hello, when trying to recursively delete a directory (same directory > > twice) from my 500gb hard drive I get a problem. It crashed first in > > 2.6.16.20, then I upgraded to try to get rid of the issue. This one is > > from 2.6.17: > > How reproducible is it? Is it reproducible even after xfs_repair? Happens every time I try to remove that inode (directory). xfs_repair ends with a fatal error: Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - ensuring existence of lost+found directory - traversing filesystem starting at / ... rebuilding directory inode 128 fatal error -- can't read block 16777216 for directory inode 1507133580 > If so, can you try Mandy's patch below, to see if it is addressing > the root cause of your problem? If problems persist, a reproducible > test case would be wonderful, if one can be found.. I'm sorry, the patch doesn't change anything. It never makes it though the xfs_repair due to the above error. If there's any information I can get for you please let me know. I'm not sure if it changes anything, but here's the message after the patch: xfs_da_do_buf: bno 16777216 dir: inode 1507133580 Filesystem "sda1": XFS internal error xfs_da_do_buf(1) at line 2119 of file /usr/src/linux-stable-cold/fs/xfs/xfs_da_btree.c. Caller 0xb01d9b63 xfs_da_do_buf+0x40e/0x7c7 xfs_da_read_buf+0x30/0x35 xfs_dir2_leafn_lookup_int+0x2f3/0x453 xfs_da_read_buf+0x30/0x35 xfs_dir2_node_removename+0x288/0x483 xfs_dir2_node_removename+0x288/0x483 xfs_dir2_removename+0xce/0xd5 kmem_zone_alloc+0x4d/0x98 xfs_remove+0x2ac/0x444 xfs_vn_unlink+0x17/0x3b mntput_no_expire+0x11/0x7e link_path_walk+0xaf/0xb9 __capable+0xc/0x1f generic_permission+0x93/0xcc permission+0x98/0xa4 may_delete+0x32/0xe9 vfs_unlink+0x6d/0xa3 do_unlinkat+0x92/0x125 sys_getdents64+0x9c/0xa6 sysenter_past_esp+0x54/0x75 Filesystem "sda1": XFS internal error xfs_trans_cancel at line 1150 of file /usr/src/linux-stable-cold/fs/xfs/xfs_trans.c. Caller 0xb020d262 xfs_trans_cancel+0x59/0xe5 xfs_remove+0x41b/0x444 xfs_remove+0x41b/0x444 xfs_vn_unlink+0x17/0x3b mntput_no_expire+0x11/0x7e link_path_walk+0xaf/0xb9 __capable+0xc/0x1f generic_permission+0x93/0xcc permission+0x98/0xa4 may_delete+0x32/0xe9 vfs_unlink+0x6d/0xa3 do_unlinkat+0x92/0x125 sys_getdents64+0x9c/0xa6 sysenter_past_esp+0x54/0x75 xfs_force_shutdown(sda1,0x8) called from line 1151 of file /usr/src/linux-stable-cold/fs/xfs/xfs_trans.c. Return address = 0xb0218b6c Filesystem "sda1": Corruption of in-memory data detected. Shutting down filesystem: sda1 Please umount the filesystem, and rectify the problem(s) xfs_force_shutdown(sda1,0x1) called from line 338 of file /usr/src/linux-stable-cold/fs/xfs/xfs_rw.c. Return address = 0xb0218b6c -- avuton -- Anyone who quotes me in their sig is an idiot. -- Rusty Russell. From owner-xfs@oss.sgi.com Tue Jun 20 01:20:53 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 20 Jun 2006 01:21:12 -0700 (PDT) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.237]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5K8KqDW018994 for ; Tue, 20 Jun 2006 01:20:53 -0700 Received: by wr-out-0506.google.com with SMTP id i2so678157wra for ; Tue, 20 Jun 2006 01:20:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=kcCPTRumnA6y6EaGyaEoZtz77fRHNi35FLMKvEAaywgGt5GypYWnynQYzJ+GlPKkGQyJftlP6IigAgoX8xCPCu++SeIxAd916n1cAKoxRJSasYLO7ylB1MdJHTd4wrgaaPDeGLGwYQJQ55KltRPDKFiAo1Nq0s0GlvplnfQkRKA= Received: by 10.54.84.1 with SMTP id h1mr344536wrb; Tue, 20 Jun 2006 01:20:39 -0700 (PDT) Received: by 10.54.102.12 with HTTP; Tue, 20 Jun 2006 01:20:39 -0700 (PDT) Message-ID: <3aa654a40606200120v5baf0304ka205f1ad8f136ad9@mail.gmail.com> Date: Tue, 20 Jun 2006 01:20:39 -0700 From: "Avuton Olrich" To: "Nathan Scott" Subject: Re: XFS crashed twice, once in 2.6.16.20, next in 2.6.17, reproducable Cc: linux-kernel@vger.kernel.org, xfs@oss.sgi.com In-Reply-To: <20060620165209.C1080488@wobbly.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3aa654a40606190044q43dca571qdc06ee13d82d979@mail.gmail.com> <20060620161006.C1079661@wobbly.melbourne.sgi.com> <3aa654a40606192338v751150fp5645d1d2943316ea@mail.gmail.com> <20060620164338.A1080488@wobbly.melbourne.sgi.com> <3aa654a40606192350w5c469670t466dfc1344e23a4@mail.gmail.com> <20060620165209.C1080488@wobbly.melbourne.sgi.com> X-archive-position: 7975 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: avuton@gmail.com Precedence: bulk X-list: xfs Content-Length: 2841 Lines: 86 On 6/19/06, Nathan Scott wrote: > On Mon, Jun 19, 2006 at 11:50:37PM -0700, Avuton Olrich wrote: > > On 6/19/06, Nathan Scott wrote: > > > Oh - thats a kernel patch, not a repair patch, I was more interested > > > in whether the initial corruption could be reproduced. Which version > > > of xfs_repair are you running? (xfs_repair -V) xfsprogs-2.7.18 will > > > resolve your problem, I suspect. > > > > OK, I'm running Gentoo's latest: 2.7.11, I can't find 2.7.18 > > _anywhere_ although 2.7.13 is in the pre directory on the ftp, is that > > the one you're referring to? > > No - its in CVS (for a long time); I'll go get the ftp area updated, > looks like thats been forgotten about again. OK, just compiled from CVS HEAD (xfs_repair 2.8.2) and it still fails: If this fix is not yet in the 2.8.x I will wait for 2.7.18 to get on the ftp. Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 entry "/ost+found" at block 0 offset 448 in directory inode 128 references invalid inode 18374686479671623679 clearing inode number in entry at offset 448... entry at block 0 offset 448 in directory inode 128 has illegal name "/ost+found": imap claims a free inode 859505 is in use, correcting imap and clearing inode - 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 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - clear lost+found (if it exists) ... - 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 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - ensuring existence of lost+found directory - traversing filesystem starting at / ... rebuilding directory inode 128 fatal error -- can't read block 16777216 for directory inode 1507133580 -- avuton -- Anyone who quotes me in their sig is an idiot. -- Rusty Russell. From owner-xfs@oss.sgi.com Tue Jun 20 01:29:12 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 20 Jun 2006 01:29:36 -0700 (PDT) Received: from hu-out-0102.google.com (hu-out-0102.google.com [72.14.214.204]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5K8TADW020943 for ; Tue, 20 Jun 2006 01:29:11 -0700 Received: by hu-out-0102.google.com with SMTP id 19so688184hue for ; Tue, 20 Jun 2006 01:28:57 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Pop/CXVgCv0n6XHl9LPl5xvMroqXA5EdS8ooeqbxXEIrypFWeUNevWROEIFok093uW41MQXZ/B0aQKWxxw4KvxGG+RBebNwUwH/qmI38eSXSf3iGKqyDMIWUtXMrJzgzdHths9RpQIS5KBqs1Q/onnFynngwazgn/EDCgiu7Hcg= Received: by 10.54.139.1 with SMTP id m1mr204847wrd; Mon, 19 Jun 2006 23:40:34 -0700 (PDT) Received: by 10.54.102.12 with HTTP; Mon, 19 Jun 2006 23:40:34 -0700 (PDT) Message-ID: <3aa654a40606192340l67d0353fj875767d33d8bd493@mail.gmail.com> Date: Mon, 19 Jun 2006 23:40:34 -0700 From: "Avuton Olrich" To: "Nathan Scott" Subject: Re: XFS crashed twice, once in 2.6.16.20, next in 2.6.17, reproducable Cc: linux-kernel@vger.kernel.org, xfs@oss.sgi.com In-Reply-To: <20060620161006.C1079661@wobbly.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3aa654a40606190044q43dca571qdc06ee13d82d979@mail.gmail.com> <20060620161006.C1079661@wobbly.melbourne.sgi.com> X-archive-position: 7976 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: avuton@gmail.com Precedence: bulk X-list: xfs Content-Length: 928 Lines: 22 On 6/19/06, Nathan Scott wrote: > How reproducible is it? Is it reproducible even after xfs_repair? It happens everytime I try to delete the directory. Also, forgot to mention I ran xfs_check on it and it gave me more information than I had before: More information, ran xfs_check and got the following: missing free index for data block 0 in dir ino 1507133580 missing free index for data block 2 in dir ino 1507133580 missing free index for data block 3 in dir ino 1507133580 missing free index for data block 4 in dir ino 1507133580 missing free index for data block 5 in dir ino 1507133580 missing free index for data block 6 in dir ino 1507133580 missing free index for data block 7 in dir ino 1507133580 missing free index for data block 8 in dir ino 1507133580 missing free index for data block 9 in dir ino 1507133580 -- avuton -- Anyone who quotes me in their sig is an idiot. -- Rusty Russell. From owner-xfs@oss.sgi.com Tue Jun 20 01:45:18 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 20 Jun 2006 01:45:37 -0700 (PDT) Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.227]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5K8jFDW024408 for ; Tue, 20 Jun 2006 01:45:17 -0700 Received: by qb-out-0506.google.com with SMTP id o21so259275qba for ; Tue, 20 Jun 2006 01:44:58 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=kLigxARGnllUi3GgEzoS+vbR0bXAHx28ONxl8AYhxhg8To+CAIAsnA0z+ItIIa1UhERQEnqLXQ74Az38Z7W28RjcwyFikymexuoc4fDmClBSG7cqTgxZsuhZPHnki/Lpccr4pV+Z10dCE5sztqgbtWdBFkFf8RxTdE2q7jCScBE= Received: by 10.54.153.8 with SMTP id a8mr7033751wre; Mon, 19 Jun 2006 23:50:37 -0700 (PDT) Received: by 10.54.102.12 with HTTP; Mon, 19 Jun 2006 23:50:37 -0700 (PDT) Message-ID: <3aa654a40606192350w5c469670t466dfc1344e23a4@mail.gmail.com> Date: Mon, 19 Jun 2006 23:50:37 -0700 From: "Avuton Olrich" To: "Nathan Scott" Subject: Re: XFS crashed twice, once in 2.6.16.20, next in 2.6.17, reproducable Cc: linux-kernel@vger.kernel.org, xfs@oss.sgi.com In-Reply-To: <20060620164338.A1080488@wobbly.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3aa654a40606190044q43dca571qdc06ee13d82d979@mail.gmail.com> <20060620161006.C1079661@wobbly.melbourne.sgi.com> <3aa654a40606192338v751150fp5645d1d2943316ea@mail.gmail.com> <20060620164338.A1080488@wobbly.melbourne.sgi.com> X-archive-position: 7977 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: avuton@gmail.com Precedence: bulk X-list: xfs Content-Length: 543 Lines: 14 On 6/19/06, Nathan Scott wrote: > Oh - thats a kernel patch, not a repair patch, I was more interested > in whether the initial corruption could be reproduced. Which version > of xfs_repair are you running? (xfs_repair -V) xfsprogs-2.7.18 will > resolve your problem, I suspect. OK, I'm running Gentoo's latest: 2.7.11, I can't find 2.7.18 _anywhere_ although 2.7.13 is in the pre directory on the ftp, is that the one you're referring to? -- avuton -- Anyone who quotes me in their sig is an idiot. -- Rusty Russell. From owner-xfs@oss.sgi.com Tue Jun 20 01:57:18 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 20 Jun 2006 01:57:41 -0700 (PDT) Received: from lucidpixels.com (lucidpixels.com [66.45.37.187]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5K8vHDW027116 for ; Tue, 20 Jun 2006 01:57:17 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id CD7CD60E04C6; Tue, 20 Jun 2006 04:57:01 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id C748D16191661; Tue, 20 Jun 2006 04:57:01 -0400 (EDT) Date: Tue, 20 Jun 2006 04:57:01 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: Avuton Olrich cc: Nathan Scott , linux-kernel@vger.kernel.org, xfs@oss.sgi.com Subject: Re: XFS crashed twice, once in 2.6.16.20, next in 2.6.17, reproducable In-Reply-To: <3aa654a40606192340l67d0353fj875767d33d8bd493@mail.gmail.com> Message-ID: References: <3aa654a40606190044q43dca571qdc06ee13d82d979@mail.gmail.com> <20060620161006.C1079661@wobbly.melbourne.sgi.com> <3aa654a40606192340l67d0353fj875767d33d8bd493@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 7978 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs Content-Length: 1071 Lines: 28 Have you checked to make sure you don't have a bad disk? On Mon, 19 Jun 2006, Avuton Olrich wrote: > On 6/19/06, Nathan Scott wrote: >> How reproducible is it? Is it reproducible even after xfs_repair? > It happens everytime I try to delete the directory. > > Also, forgot to mention I ran xfs_check on it and it gave me more > information than I had before: > More information, ran xfs_check and got the following: > missing free index for data block 0 in dir ino 1507133580 > missing free index for data block 2 in dir ino 1507133580 > missing free index for data block 3 in dir ino 1507133580 > missing free index for data block 4 in dir ino 1507133580 > missing free index for data block 5 in dir ino 1507133580 > missing free index for data block 6 in dir ino 1507133580 > missing free index for data block 7 in dir ino 1507133580 > missing free index for data block 8 in dir ino 1507133580 > missing free index for data block 9 in dir ino 1507133580 > > -- > avuton > -- > Anyone who quotes me in their sig is an idiot. -- Rusty Russell. > > From owner-xfs@oss.sgi.com Tue Jun 20 04:34:48 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 20 Jun 2006 04:34:58 -0700 (PDT) Received: from smtp-2.hut.fi (smtp-2.hut.fi [130.233.228.92]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5KBYkDW022419 for ; Tue, 20 Jun 2006 04:34:48 -0700 Received: from localhost (putosiko.hut.fi [130.233.228.114]) by smtp-2.hut.fi (8.13.6/8.12.10) with ESMTP id k5KBYUin012912 for ; Tue, 20 Jun 2006 14:34:30 +0300 Received: from smtp-2.hut.fi ([130.233.228.92]) by localhost (putosiko.hut.fi [130.233.228.114]) (amavisd-new, port 10024) with LMTP id 09008-23 for ; Tue, 20 Jun 2006 14:34:29 +0300 (EEST) Received: from kurp.hut.fi (kurp.hut.fi [130.233.157.234]) by smtp-2.hut.fi (8.13.6/8.12.10) with ESMTP id k5KBYBjp012846 for ; Tue, 20 Jun 2006 14:34:11 +0300 Received: from kurp.hut.fi (jwagner@localhost [127.0.0.1]) by kurp.hut.fi (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k5KBYACZ011928 for ; Tue, 20 Jun 2006 14:34:10 +0300 Received: from localhost (jwagner@localhost) by kurp.hut.fi (8.13.4/8.13.4/Submit) with ESMTP id k5KBYA4L011925 for ; Tue, 20 Jun 2006 14:34:10 +0300 Date: Tue, 20 Jun 2006 14:34:10 +0300 (EEST) From: Jan Wagner To: xfs@oss.sgi.com Subject: Re: separate log and structure from user data device? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at putosiko.hut.fi X-archive-position: 7980 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jwagner@kurp.hut.fi Precedence: bulk X-list: xfs Content-Length: 3643 Lines: 92 On Mon, 19 Jun 2006, Nathan Scott wrote: > On Fri, Jun 16, 2006 at 02:38:19PM +0300, Jan Wagner wrote: > > But for some reason at least the above xfs_io command does not work, I get > > > > # mkdir /i1/inherit > > # xfs_io -c 'chattr +t' -c 'lsattr -v' /i1/inherit > > /i1/inherit: Is a directory > > ... > > "Is a directory", any ideas? > > Oh, your xfs_io is a bit dated, Tim improved the behaviour in this > area awhile back. You will need the -r command line option with that > version, IIRC. Ok, pulled the cvs source for xfsprogs, now the above works 8-)) Quite a nice feature. > > # xfs_io -fR /i1/testfile -c 'pwrite -b 4m 0 2g' > > wrote 2147483648/2147483648 bytes at offset 0 > > 2.000 GiB, 512 ops; 00:00:05.645958 (362.737 MiB/sec and 90.6843 ops/sec) > > > > write 360MiB/s > > > > # xfs_io -fR /i1/testfile -c 'pread -b 4m 2g' > > read 2147483648/2147483648 bytes at offset 0 > > 2.000 GiB, 512 ops; 00:00:39.156626 (52.303 MiB/sec and 13.0757 ops/sec) > > > > # xfs_io -fR /i1/testfile -c 'pread 4m 2g' > > read 2147483648/2147483648 bytes at offset 4194304 > > 2.000 GiB, 524288 ops; 00:00:27.229922 (75.211 MiB/sec and 19254.1132 > > ops/sec) > > These last two are not what you want, I think, esp. the very last one; > the -b option specific the buffer size. In the last case you're using > 1k instead of 4m buffers (hence the large number of ops). But the 2nd > last case doesn't suffer that - it doesnt give an offset, but looks like > xfs_io is defaulting to zero there. > > Since you're doing buffered reads/writes, your read numbers there may be > being influenced by writeout. Try using the pwrite command with -W and/ > or unmount+mount between benchmark runs. Hmm, could be. Now experimented with that also, with 'unmount' + 'mount', and even 'sync', but it still keeps giving the same kind of figures. Also tested on a different PC (Intel 945G, vs earlier nForce4, all software RAID0, same kernel version Debian 2.6.16-7). The realtime inherit bit was set for the /i1 directory. Also tried moving the XFS file system from hda6 to hda1, with the rt subvol still on /dev/md0, to see if that would improve performance, but it did not. jwagner@warp:~/cvs/xfs/xfs-cmds/xfsprogs/io$ ./xfs_io -f /i1/testfile -c 'pwrite -b 4m 0 2g -W'; sync wrote 2147483648/2147483648 bytes at offset 0 2.000 GiB, 512 ops; 0:00:08.00 (235.874 MiB/sec and 58.9685 ops/sec) jwagner@warp:~/cvs/xfs/xfs-cmds/xfsprogs/io$ ./xfs_io -f /i1/testfile -c 'pread 0 2g' read 2147483648/2147483648 bytes at offset 0 2.000 GiB, 524288 ops; 0:00:46.00 (43.653 MiB/sec and 11175.2537 ops/sec) For the pwrite writing xfs_io eats ~50% CPU with ~50% wait. For pread reading the load by xfs_io is only ~1% with wait ~50%. At least per 'top'. Without any realtime subvolume at all, reading is faster than writing. And definitely faster than reading from a realtime subvolume. jwagner@warp:~/cvs/xfs/xfs-cmds/xfsprogs/io# ./xfs_io -f /i1/testfile -c 'pwrite -b 4m 0 2g -W'; sync wrote 2147483648/2147483648 bytes at offset 0 2.000 GiB, 512 ops; 0:00:09.00 (208.292 MiB/sec and 52.0731 ops/sec) jwagner@warp:~/cvs/xfs/xfs-cmds/xfsprogs/io# ./xfs_io -f /i1/testfile -c 'pread 0 2g' read 2147483648/2147483648 bytes at offset 0 2.000 GiB, 524288 ops; 0:00:08.00 (233.079 MiB/sec and 59668.2130 ops/sec) Maybe as you got similar read results for the realtime as I am getting above only for not-realtime, maybe you were using the XFS CVS source in your kernel? (Might have to try that, too...) Anyway, this all is mostly just "FYI". ;-) Will have to experiment more, I guess :-) Thanks again for the pread/pwrite benchmarking tips! - Jan From owner-xfs@oss.sgi.com Tue Jun 20 05:02:49 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 20 Jun 2006 05:03:18 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5KC2lDW026760 for ; Tue, 20 Jun 2006 05:02:48 -0700 Received: by nf-out-0910.google.com with SMTP id c31so1196751nfb for ; Tue, 20 Jun 2006 05:02:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=Jw/iMDL7/eA7gASkc87yuYB0ERDUTdWktCmjf+xTwKbfGV0VmXELK1MTnZLw2KsoWdgHQFPnMP00UQ7xDK12yL0naHfuJhjwTGEzJVK6OyJyuOWu9UlI2DVNB6frBho/NUmTCkNM/oUdzJdgiNkmpxV4JGfPDI2lOjgYqNMHktQ= Received: by 10.49.19.14 with SMTP id w14mr6341798nfi; Tue, 20 Jun 2006 04:04:00 -0700 (PDT) Received: from gmail.com ( [217.67.117.64]) by mx.gmail.com with ESMTP id i1sm645549nfe.2006.06.20.04.03.59; Tue, 20 Jun 2006 04:04:00 -0700 (PDT) Received: by gmail.com (nbSMTP-1.00) for uid 1000 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168/168 bits)) adobriyan@gmail.com; Tue, 20 Jun 2006 15:04:08 +0400 (MSD) Date: Tue, 20 Jun 2006 15:04:06 +0400 From: Alexey Dobriyan To: Andrew Morton Cc: xfs@oss.sgi.com, Nathan Scott Subject: [PATCH -mm] xfs: pass inode to xfs_ioc_space() Message-ID: <20060620110406.GC7337@martell.zuzino.mipt.ru> References: <20060620064131.GA7337@martell.zuzino.mipt.ru> <20060620014555.b127e89d.akpm@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060620014555.b127e89d.akpm@osdl.org> User-Agent: Mutt/1.5.11 X-archive-position: 7981 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: adobriyan@gmail.com Precedence: bulk X-list: xfs Content-Length: 1521 Lines: 58 * There is trivial "inode => vnode => inode" conversion, but only flags and mode of final inode are looked at. Pass original inode instead. * Two occurences of bhv_vnode_t go out. Signed-off-by: Alexey Dobriyan --- Against git://oss.sgi.com:8090/xfs-2.6. Suppose this one is -mm fodder. fs/xfs/linux-2.6/xfs_ioctl.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) --- a/fs/xfs/linux-2.6/xfs_ioctl.c +++ b/fs/xfs/linux-2.6/xfs_ioctl.c @@ -653,7 +653,7 @@ xfs_attrmulti_by_handle( STATIC int xfs_ioc_space( bhv_desc_t *bdp, - bhv_vnode_t *vp, + struct inode *inode, struct file *filp, int flags, unsigned int cmd, @@ -735,7 +735,7 @@ xfs_ioctl( !capable(CAP_SYS_ADMIN)) return -EPERM; - return xfs_ioc_space(bdp, vp, filp, ioflags, cmd, arg); + return xfs_ioc_space(bdp, inode, filp, ioflags, cmd, arg); case XFS_IOC_DIOINFO: { struct dioattr da; @@ -957,7 +957,7 @@ xfs_ioctl( STATIC int xfs_ioc_space( bhv_desc_t *bdp, - bhv_vnode_t *vp, + struct inode *inode, struct file *filp, int ioflags, unsigned int cmd, @@ -967,13 +967,13 @@ xfs_ioc_space( int attr_flags = 0; int error; - if (vp->v_inode.i_flags & (S_IMMUTABLE|S_APPEND)) + if (inode->i_flags & (S_IMMUTABLE|S_APPEND)) return -XFS_ERROR(EPERM); if (!(filp->f_mode & FMODE_WRITE)) return -XFS_ERROR(EBADF); - if (!VN_ISREG(vp)) + if (!S_ISREG(inode->i_mode)) return -XFS_ERROR(EINVAL); if (copy_from_user(&bf, arg, sizeof(bf))) From owner-xfs@oss.sgi.com Tue Jun 20 08:58:52 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 20 Jun 2006 08:59:02 -0700 (PDT) Received: from alpha.netcentrum.cz (alpha.netcentrum.cz [62.84.145.8]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5KFwlDW007652 for ; Tue, 20 Jun 2006 08:58:51 -0700 Received: from wintermute.netcentrum.cz ([62.84.145.125]) by alpha.netcentrum.cz with Microsoft SMTPSVC(5.0.2195.6713); Tue, 20 Jun 2006 17:58:21 +0200 Received: from 62.84.145.125 ([62.84.145.125]) by alpha.office.netcentrum.cz ([62.84.145.8]) with Microsoft Exchange Server HTTP-DAV ; Thu, 18 May 2006 11:07:08 +0000 From: ViNiL To: linux-xfs@oss.sgi.com Message-Id: <200606201758.20400.vladimir.linek@netcentrum.cz> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Date: Tue, 20 Jun 2006 17:58:16 +0200 X-Evolution-Format: text/plain X-Evolution-Account: 1146038826.27537.16@wintermute X-Evolution-Transport: exchange://vladimir.linek;auth=NTLM@alpha.netcentrum.cz/;ad_limit=50;filter_junk_inbox;soap_port=7191;ad_server=alpha.netcentrum.cz;filter_junk;owa_url=http://alpha.netcentrum.cz/exchange;filter;sync_offline X-Evolution-Fcc: exchange://vladimir.linek@alpha.netcentrum.cz/personal/Sent Items Subject: Repeating fs corruption X-UID: 313 X-Length: 10074 Content-Type: multipart/signed; boundary="nextPart3861894.ja569kKQVe"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Jun 2006 15:58:21.0681 (UTC) FILETIME=[5ACEF610:01C69482] X-archive-position: 7982 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: vladimir.linek@netcentrum.cz Precedence: bulk X-list: xfs Content-Length: 8916 Lines: 196 --nextPart3861894.ja569kKQVe Content-Type: multipart/mixed; boundary="Boundary-01=_YsBmEeQv9pjApE+" Content-Transfer-Encoding: 7bit Content-Disposition: inline --Boundary-01=_YsBmEeQv9pjApE+ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello! We run several systems of this configuration, here: OS: Debian Sarge Kernel: vanilla 2.6.16+ (+ Areca driver patch) RAID: Areca ARC-1160 (Raid 6) or 2x 3ware 9500S-8 (Raid 5) + SW RAID 0 HDD: 15x WD or Seagate The partition is about 3.3T and we use no extra options for mount. xfs_info /path meta-data=/path isize=256 agcount=32, agsize=26855466 blks = sectsz=512 data = bsize=4096 blocks=859374912, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=32768, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 The xfs filesystems get corrupted from time to time. Syslog is being filled up with errors, then (sample attached), and the system load goes up (I am not sure, what exactly happens there). So, - the kernel is filling up syslog and the filesystem is still mounted RW - when the system is rebooted, it mounts the xfs, without forcing the check (though there is non-zero value in the fs_passno column in /etc/fstab) - errors are logged again - explicit run of xfs_repair finds and repairs several issues Can anyone explain to me, what (and why is that :-) is going on with the filesystem? Why the corrupted fs is still used? In RW manner??? TIA, ViNiL --Boundary-01=_YsBmEeQv9pjApE+ Content-Type: text/plain; charset="utf-8"; name="xfslog" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=xfslog TWF5IDEwIDIwOjM5OjA4IG1hY2hpbmV4eHgga2VybmVsOiBTR0kgWEZTIHdp dGggbGFyZ2UgYmxvY2sgbnVtYmVycywgbm8gZGVidWcgZW5hYmxlZA0KTWF5 IDEwIDIwOjQyOjU1IG1hY2hpbmV4eHgga2VybmVsOiBYRlMgbW91bnRpbmcg ZmlsZXN5c3RlbSBzZGINCk1heSAxMCAyMDo0Mjo1NSBtYWNoaW5leHh4IGtl cm5lbDogRW5kaW5nIGNsZWFuIFhGUyBtb3VudCBmb3IgZmlsZXN5c3RlbTog c2RiDQpNYXkgMTMgMDg6MTc6MjMgbWFjaGluZXh4eCBrZXJuZWw6IEZpbGVz eXN0ZW0gInNkYiI6IGNvcnJ1cHQgZGlub2RlIDI2ODQzNTgyNDUsIChidHJl ZSBleHRlbnRzKS4gIFVubW91bnQgYW5kIHJ1biB4ZnNfcmVwYWlyLg0KTWF5 IDEzIDA4OjE3OjIzIG1hY2hpbmV4eHgga2VybmVsOiBGaWxlc3lzdGVtICJz ZGIiOiBYRlMgaW50ZXJuYWwgZXJyb3IgeGZzX2JtYXBfcmVhZF9leHRlbnRz KDEpIGF0IGxpbmUgNDUwMSBvZiBmaWxlIGZzL3hmcy94ZnNfYm1hcC5jLiAg Q2FsbGVyIDB4Zjk3MGIwYzANCk1heSAxMyAwODoxNzoyMyBtYWNoaW5leHh4 IGtlcm5lbDogIFtwZzArOTU3NDI0NTcwLzEwNjc2MzU3MTJdIHhmc19ibWFw X3JlYWRfZXh0ZW50cysweDQwOC8weDUxOCBbeGZzXQ0KTWF5IDEzIDA4OjE3 OjIzIG1hY2hpbmV4eHgga2VybmVsOiAgW3BnMCs5NTc1ODc2NDgvMTA2NzYz NTcxMl0geGZzX2lyZWFkX2V4dGVudHMrMHg3Ni8weDEwMyBbeGZzXQ0KTWF5 IDEzIDA4OjE3OjIzIG1hY2hpbmV4eHgga2VybmVsOiAgW3BnMCs5NTc0MTky NjgvMTA2NzYzNTcxMl0geGZzX2JtYXBfZG9fc2VhcmNoX2V4dGVudHMrMHgy YWUvMHg0NTEgW3hmc10NCk1heSAxMyAwODoxNzoyMyBtYWNoaW5leHh4IGtl cm5lbDogIFt0cnlfdG9fd2FrZV91cCs2NjYvNzY5XSB0cnlfdG9fd2FrZV91 cCsweDI5YS8weDMwMQ0KTWF5IDEzIDA4OjE3OjIzIG1hY2hpbmV4eHgga2Vy bmVsOiAgW3BnMCs5NTc1ODc2NDgvMTA2NzYzNTcxMl0geGZzX2lyZWFkX2V4 dGVudHMrMHg3Ni8weDEwMyBbeGZzXQ0KTWF5IDEzIDA4OjE3OjIzIG1hY2hp bmV4eHgga2VybmVsOiAgW3BnMCs5NTc0MTkyNjgvMTA2NzYzNTcxMl0geGZz X2JtYXBfZG9fc2VhcmNoX2V4dGVudHMrMHgyYWUvMHg0NTEgW3hmc10NCk1h eSAxMyAwODoxNzoyMyBtYWNoaW5leHh4IGtlcm5lbDogIFtwZzArOTU3NDI1 NDk2LzEwNjc2MzU3MTJdIHhmc19ibWFwaSsweDI4ZS8weDE4NjcgW3hmc10N Ck1heSAxMyAwODoxNzoyMyBtYWNoaW5leHh4IGtlcm5lbDogIFtlbHZfc2V0 X3JlcXVlc3QrNzAvNzJdIGVsdl9zZXRfcmVxdWVzdCsweDQ2LzB4NDgNCk1h eSAxMyAwODoxNzoyMyBtYWNoaW5leHh4IGtlcm5lbDogIFtnZXRfcmVxdWVz dCs2NTAvNzU0XSBnZXRfcmVxdWVzdCsweDI4YS8weDJmMg0KTWF5IDEzIDA4 OjE3OjIzIG1hY2hpbmV4eHgga2VybmVsOiAgW21lbXBvb2xfYWxsb2MrNTEv MjI0XSBtZW1wb29sX2FsbG9jKzB4MzMvMHhlMA0KTWF5IDEzIDA4OjE3OjIz IG1hY2hpbmV4eHgga2VybmVsOiAgW2dldF9yZXF1ZXN0KzY1MC83NTRdIGdl dF9yZXF1ZXN0KzB4MjhhLzB4MmYyDQpNYXkgMTMgMDg6MTc6MjMgbWFjaGlu ZXh4eCBrZXJuZWw6ICBbX19hc19hZGRfYXJxX3JiKzEyNC8xNTFdIF9fYXNf YWRkX2FycV9yYisweDdjLzB4OTcNCk1heSAxMyAwODoxNzoyMyBtYWNoaW5l eHh4IGtlcm5lbDogIFthc191cGRhdGVfYXJxKzQ2LzEyMF0gYXNfdXBkYXRl X2FycSsweDJlLzB4NzgNCk1heSAxMyAwODoxNzoyMyBtYWNoaW5leHh4IGtl cm5lbDogIFthc19hZGRfcmVxdWVzdCsxNTYvMjM2XSBhc19hZGRfcmVxdWVz dCsweDljLzB4ZWMNCk1heSAxMyAwODoxNzoyMyBtYWNoaW5leHh4IGtlcm5l bDogIFtmaW5kX2J1c2llc3RfZ3JvdXArMjMzLzgwNF0gZmluZF9idXNpZXN0 X2dyb3VwKzB4ZTkvMHgzMjQNCk1heSAxMyAwODoxNzoyMyBtYWNoaW5leHh4 IGtlcm5lbDogIFtwZzArOTU3NjAzMjc0LzEwNjc2MzU3MTJdIHhmc19pb21h cCsweDFhZi8weDU2NCBbeGZzXQ0KTWF5IDEzIDA4OjE3OjIzIG1hY2hpbmV4 eHgga2VybmVsOiAgW21lbXBvb2xfYWxsb2MrNTEvMjI0XSBtZW1wb29sX2Fs bG9jKzB4MzMvMHhlMA0KTWF5IDEzIDA4OjE3OjIzIG1hY2hpbmV4eHgga2Vy bmVsOiAgW3BnMCs5NTc3NDIwNTIvMTA2NzYzNTcxMl0gX19saW52ZnNfZ2V0 X2Jsb2NrKzB4YjcvMHgzN2EgW3hmc10NCk1heSAxMyAwODoxNzoyMyBtYWNo aW5leHh4IGtlcm5lbDogIFtlbHZfc2V0X3JlcXVlc3QrNzAvNzJdIGVsdl9z ZXRfcmVxdWVzdCsweDQ2LzB4NDgNCk1heSAxMyAwODoxNzoyMyBtYWNoaW5l eHh4IGtlcm5lbDogIFtnZXRfcmVxdWVzdCs2NTAvNzU0XSBnZXRfcmVxdWVz dCsweDI4YS8weDJmMg0KTWF5IDEzIDA4OjE3OjIzIG1hY2hpbmV4eHgga2Vy bmVsOiAgW3BnMCs5NTc3NDI4MzAvMTA2NzYzNTcxMl0gbGludmZzX2dldF9i bG9jaysweDQ3LzB4NGIgW3hmc10NCk1heSAxMyAwODoxNzoyMyBtYWNoaW5l eHh4IGtlcm5lbDogIFtkb19tcGFnZV9yZWFkcGFnZSszNjAvMTIyM10gZG9f bXBhZ2VfcmVhZHBhZ2UrMHgxNjgvMHg0YzcNCk1heSAxMyAwODoxNzoyMyBt YWNoaW5leHh4IGtlcm5lbDogIFtyYWRpeF90cmVlX25vZGVfYWxsb2MrMzEv OThdIHJhZGl4X3RyZWVfbm9kZV9hbGxvYysweDFmLzB4NjINCk1heSAxMyAw ODoxNzoyMyBtYWNoaW5leHh4IGtlcm5lbDogIFtyYWRpeF90cmVlX2luc2Vy dCsyMjcvMjY4XSByYWRpeF90cmVlX2luc2VydCsweGUzLzB4MTBjDQpNYXkg MTMgMDg6MTc6MjMgbWFjaGluZXh4eCBrZXJuZWw6ICBbYWRkX3RvX3BhZ2Vf Y2FjaGUrOTMvMTk3XSBhZGRfdG9fcGFnZV9jYWNoZSsweDVkLzB4YzUNCk1h eSAxMyAwODoxNzoyMyBtYWNoaW5leHh4IGtlcm5lbDogIFttcGFnZV9yZWFk cGFnZXMrMTY3LzI5NF0gbXBhZ2VfcmVhZHBhZ2VzKzB4YTcvMHgxMjYNCk1h eSAxMyAwODoxNzoyMyBtYWNoaW5leHh4IGtlcm5lbDogIFtwZzArOTU3NzQy NzU5LzEwNjc2MzU3MTJdIGxpbnZmc19nZXRfYmxvY2srMHgwLzB4NGIgW3hm c10NCk1heSAxMyAwODoxNzoyMyBtYWNoaW5leHh4IGtlcm5lbDogIFtidWZm ZXJlZF9ybXF1ZXVlKzI1NS81MjFdIGJ1ZmZlcmVkX3JtcXVldWUrMHhmZi8w eDIwOQ0KTWF5IDEzIDA4OjE3OjIzIG1hY2hpbmV4eHgga2VybmVsOiAgW3Jl YWRfcGFnZXMrMjQ4LzI1MF0gcmVhZF9wYWdlcysweGY4LzB4ZmENCk1heSAx MyAwODoxNzoyMyBtYWNoaW5leHh4IGtlcm5lbDogIFtwZzArOTU3NzQyNzU5 LzEwNjc2MzU3MTJdIGxpbnZmc19nZXRfYmxvY2srMHgwLzB4NGIgW3hmc10N Ck1heSAxMyAwODoxNzoyMyBtYWNoaW5leHh4IGtlcm5lbDogIFtfX2FsbG9j X3BhZ2VzKzg2Lzc2Ml0gX19hbGxvY19wYWdlcysweDU2LzB4MmZhDQpNYXkg MTMgMDg6MTc6MjMgbWFjaGluZXh4eCBrZXJuZWw6ICBbam91cm5hbF9hZGRf am91cm5hbF9oZWFkKzI3MC8yODhdIGpvdXJuYWxfYWRkX2pvdXJuYWxfaGVh ZCsweDEwZS8weDEyMA0KTWF5IDEzIDA4OjE3OjIzIG1hY2hpbmV4eHgga2Vy bmVsOiAgW19fZG9fcGFnZV9jYWNoZV9yZWFkYWhlYWQrMjM0LzM0NV0gX19k b19wYWdlX2NhY2hlX3JlYWRhaGVhZCsweGVhLzB4MTU5DQpNYXkgMTMgMDg6 MTc6MjMgbWFjaGluZXh4eCBrZXJuZWw6ICBbYmxvY2thYmxlX3BhZ2VfY2Fj aGVfcmVhZGFoZWFkKzg5LzIwMl0gYmxvY2thYmxlX3BhZ2VfY2FjaGVfcmVh ZGFoZWFkKzB4NTkvMHhjYQ0KTWF5IDEzIDA4OjE3OjIzIG1hY2hpbmV4eHgg a2VybmVsOiAgW3BhZ2VfY2FjaGVfcmVhZGFoZWFkKzI5MS80MTZdIHBhZ2Vf Y2FjaGVfcmVhZGFoZWFkKzB4MTIzLzB4MWEwDQpNYXkgMTMgMDg6MTc6MjMg bWFjaGluZXh4eCBrZXJuZWw6ICBbZG9fZ2VuZXJpY19tYXBwaW5nX3JlYWQr MTM4OC8xMzk3XSBkb19nZW5lcmljX21hcHBpbmdfcmVhZCsweDU2Yy8weDU3 NQ0KTWF5IDEzIDA4OjE3OjIzIG1hY2hpbmV4eHgga2VybmVsOiAgW19fZ2Vu ZXJpY19maWxlX2Fpb19yZWFkKzQ5Mi81NTVdIF9fZ2VuZXJpY19maWxlX2Fp b19yZWFkKzB4MWVjLzB4MjJiDQpNYXkgMTMgMDg6MTc6MjMgbWFjaGluZXh4 eCBrZXJuZWw6ICBbZmlsZV9yZWFkX2FjdG9yKzAvMjM2XSBmaWxlX3JlYWRf YWN0b3IrMHgwLzB4ZWMNCk1heSAxMyAwODoxNzoyMyBtYWNoaW5leHh4IGtl cm5lbDogIFtwZzArOTU3NzY4NjE2LzEwNjc2MzU3MTJdIHhmc19yZWFkKzB4 MTNhLzB4MmM5IFt4ZnNdDQpNYXkgMTMgMDg6MTc6MjMgbWFjaGluZXh4eCBr ZXJuZWw6ICBbbG9ja3NfZnJlZV9sb2NrKzEwMi8xNjZdIGxvY2tzX2ZyZWVf bG9jaysweDY2LzB4YTYNCk1heSAxMyAwODoxNzoyMyBtYWNoaW5leHh4IGtl cm5lbDogIFtwZzArOTU3NzUzMjM3LzEwNjc2MzU3MTJdIGxpbnZmc19haW9f cmVhZCsweDhkLzB4OWUgW3hmc10NCk1heSAxMyAwODoxNzoyMyBtYWNoaW5l eHh4IGtlcm5lbDogIFtkb19zeW5jX3JlYWQrMjAzLzI3M10gZG9fc3luY19y ZWFkKzB4Y2IvMHgxMTENCk1heSAxMyAwODoxNzoyMyBtYWNoaW5leHh4IGtl cm5lbDogIFthdXRvcmVtb3ZlX3dha2VfZnVuY3Rpb24rMC84N10gYXV0b3Jl bW92ZV93YWtlX2Z1bmN0aW9uKzB4MC8weDU3DQpNYXkgMTMgMDg6MTc6MjMg bWFjaGluZXh4eCBrZXJuZWw6ICBbZG9fbW1hcF9wZ29mZisxMDg1LzE5MTVd IGRvX21tYXBfcGdvZmYrMHg0M2QvMHg3N2INCk1heSAxMyAwODoxNzoyMyBt YWNoaW5leHh4IGtlcm5lbDogIFt2ZnNfcmVhZCsxNjQvMzY3XSB2ZnNfcmVh ZCsweGE0LzB4MTZmDQpNYXkgMTMgMDg6MTc6MjMgbWFjaGluZXh4eCBrZXJu ZWw6ICBbc3lzX3JlYWQrODEvMTI4XSBzeXNfcmVhZCsweDUxLzB4ODANCk1h eSAxMyAwODoxNzoyMyBtYWNoaW5leHh4IGtlcm5lbDogIFtzeXNjYWxsX2Nh bGwrNy8xMV0gc3lzY2FsbF9jYWxsKzB4Ny8weGINCg== --Boundary-01=_YsBmEeQv9pjApE+-- --nextPart3861894.ja569kKQVe Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQBEmBscbK7iOupfgaIRAksnAJ4v0LJP5TyJyElqhIOwOwNLvxrAjgCfSoux 2rKi0wV9VfrP0qTuCs08xoU= =b1zM -----END PGP SIGNATURE----- --nextPart3861894.ja569kKQVe-- From owner-xfs@oss.sgi.com Tue Jun 20 09:42:24 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 20 Jun 2006 09:42:41 -0700 (PDT) Received: from mail.ural.org ([85.115.166.251]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5KGgEDW015128 for ; Tue, 20 Jun 2006 09:42:23 -0700 Received: from [85.115.165.127] (helo=arietis.arietis.denis) by mail.ural.org with esmtp (Exim 4.44) id 1Fshwn-000LQW-GG for xfs@oss.sgi.com; Tue, 20 Jun 2006 21:15:21 +0600 To: xfs@oss.sgi.com Subject: Unable to handle kernel NULL pointer dereference at virtual address 00000000 From: Denis Nikiforov X-Face: *+^$JI24p+W&}*/&5,zq_}{!]%A@?FR_>1%\Vm2!UJIilEbAb6'3T]fYwX1H"(a9SUn>&CF g^`pe)6euC Date: Tue, 20 Jun 2006 21:15:22 +0600 Message-ID: <87hd2fsvsl.fsf@arietis.arietis> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 7984 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: denis@ural.org Precedence: bulk X-list: xfs Content-Length: 3573 Lines: 70 (transmit-message (Hello *Human*) (Say '( I'd upgraded my computer from Celeron P4 to Athlon 64. And xfs partition couldn't be mounted now ;( How can I fix it? ,----[ dmesg ] | SGI XFS with ACLs, security attributes, realtime, large block numbers, no debug enabled | SGI XFS Quota Management subsystem | XFS mounting filesystem hdb3 | Starting XFS recovery on filesystem: hdb3 (logdev: internal) | Unable to handle kernel NULL pointer dereference at virtual address 00000000 | printing eip: | c013ae82 | *pde = 00000000 | Oops: 0000 [#1] | Modules linked in: xfs exportfs nls_utf8 ntfs dm_mod tsdev usbhid snd_intel8x0 snd_ac97_codec snd_ac97_bus bt878 snd_pcm_oss snd_mixer_oss snd_mpu401 snd_mpu401_uart snd_pcm snd_rawmidi snd_seq_device ehci_hcd ohci_hcd snd_timer ne2k_pci i2c_nforce2 psmouse serio_raw snd snd_page_alloc 8390 forcedeth ide_cd cdrom soundcore usbcore parport_pc parport amd64_agp agpgart rtc analog pcspkr gameport floppy ext3 jbd mbcache ide_disk amd74xx generic ide_core sata_nv libata scsi_mod evdev mousedev bttv video_buf firmware_class compat_ioctl32 i2c_algo_bit v4l2_common btcx_risc ir_common tveeprom i2c_core videodev shpchp pci_hotplug | CPU: 0 | EIP: 0060:[] Not tainted VLI | EFLAGS: 00010256 (2.6.16 #1) | EIP is at page_address+0x8/0x7e | eax: 00000000 ebx: 00000000 ecx: f7bb22d8 edx: f7bb23a0 | esi: c2321240 edi: f7bebd80 ebp: f7bb22d8 esp: f78a5a78 | ds: 007b es: 007b ss: 0068 | Process mount (pid: 3254, threadinfo=f78a4000 task=dfd29030) | Stack: <0>00000010 c2321240 f7bebd80 f7bb22d8 f8c5290e 00000000 c22da800 f8c3eb19 | f7bb22d8 00000010 c011310b 00000000 00000000 00000080 00000002 c22da800 | c2321240 00000000 00000040 00000000 000002d0 00100286 f8c3df81 c23212a4 | Call Trace: | [] xfs_buf_offset+0x35/0x3a [xfs] | [] xlog_recover_do_inode_trans+0x14a/0x718 [xfs] | [] deactivate_task+0x15/0x21 | [] xlog_recover_reorder_trans+0x7d/0xa9 [xfs] | [] xlog_recover_do_trans+0x6b/0xee [xfs] | [] xlog_recover_commit_trans+0x23/0x35 [xfs] | [] xlog_recover_process_data+0x12a/0x1bd [xfs] | [] xlog_do_recovery_pass+0x329/0x90f [xfs] | [] vt_console_print+0x1f7/0x206 | [] xlog_do_log_recovery+0x7e/0xa6 [xfs] | [] xlog_do_recover+0x1d/0x102 [xfs] | [] xlog_recover+0x87/0x98 [xfs] | [] xfs_log_mount+0x8d/0xce [xfs] | [] xfs_mountfs+0x9a8/0xc81 [xfs] | [] xfs_setsize_buftarg_flags+0x31/0x90 [xfs] | [] xfs_readsb+0x6d/0x179 [xfs] | [] xfs_ioinit+0x21/0x26 [xfs] | [] xfs_mount+0x2f3/0x365 [xfs] | [] vfs_mount+0x28/0x2c [xfs] | [] linvfs_fill_super+0x79/0x19d [xfs] | [] snprintf+0x16/0x1a | [] disk_name+0x5c/0x66 | [] get_sb_bdev+0xc9/0x113 | [] __alloc_pages+0x46/0x263 | [] linvfs_get_sb+0x1a/0x1e [xfs] | [] linvfs_fill_super+0x0/0x19d [xfs] | [] do_kern_mount+0x85/0x12a | [] do_new_mount+0x67/0xa4 | [] do_mount+0x172/0x18a | [] sys_stat64+0x10/0x27 | [] copy_mount_options+0x4c/0x99 | [] sys_mount+0x74/0xaf | [] sysenter_past_esp+0x54/0x75 | Code: ff 74 24 0c 52 e8 bc fd ff ff 83 c4 0c c3 8b 44 24 04 69 c0 01 00 37 9e c1 e8 19 8d 04 c5 c0 06 35 c0 c3 55 57 56 53 8b 5c 24 14 <8b> 03 c1 e8 1e 8b 14 85 e8 ad 30 c0 8b 82 10 01 00 00 05 78 03 | <6> `---- -- ))) => t (WBR '(Denis Nikiforov)) From owner-xfs@oss.sgi.com Tue Jun 20 10:02:14 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 20 Jun 2006 10:02:36 -0700 (PDT) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.228]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5KH2DDW017885 for ; Tue, 20 Jun 2006 10:02:14 -0700 Received: by wr-out-0506.google.com with SMTP id i4so1266465wra for ; Tue, 20 Jun 2006 10:02:00 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=FjtFQbsgJ04ppfj2+d1y/Ml8SqYnoXC8cPtZbpOAgY88VIBm+8yU/EjpPYoBiKtzCEPkP3itm3wnTV/aLahbaoRR53x4xjZit/gre0Pn/YdiCgxTSSHSqmAILHEtTJlZSMnxSUVRqXWoalJJf7HviSY5dsowO8eqQkWP5VOvK1w= Received: by 10.54.70.17 with SMTP id s17mr7519200wra; Tue, 20 Jun 2006 10:01:59 -0700 (PDT) Received: by 10.54.101.10 with HTTP; Tue, 20 Jun 2006 10:01:59 -0700 (PDT) Message-ID: <3aa654a40606201001s40fc2bf3j27cd7cb555b02688@mail.gmail.com> Date: Tue, 20 Jun 2006 10:01:59 -0700 From: "Avuton Olrich" To: "Justin Piszcz" Subject: Re: XFS crashed twice, once in 2.6.16.20, next in 2.6.17, reproducable Cc: "Nathan Scott" , linux-kernel@vger.kernel.org, xfs@oss.sgi.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3aa654a40606190044q43dca571qdc06ee13d82d979@mail.gmail.com> <20060620161006.C1079661@wobbly.melbourne.sgi.com> <3aa654a40606192340l67d0353fj875767d33d8bd493@mail.gmail.com> X-archive-position: 7985 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: avuton@gmail.com Precedence: bulk X-list: xfs Content-Length: 284 Lines: 10 On 6/20/06, Justin Piszcz wrote: > Have you checked to make sure you don't have a bad disk? In the initial email I do state that I have run badblocks on this disk sucessfully. -- avuton -- Anyone who quotes me in their sig is an idiot. -- Rusty Russell. From owner-xfs@oss.sgi.com Tue Jun 20 10:16:02 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 20 Jun 2006 10:16:27 -0700 (PDT) Received: from lucidpixels.com (lucidpixels.com [66.45.37.187]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5KHFvDW020840 for ; Tue, 20 Jun 2006 10:16:02 -0700 Received: by lucidpixels.com (Postfix, from userid 1001) id B7FD360E04C9; Tue, 20 Jun 2006 13:15:43 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id B0D2D1615BD6E; Tue, 20 Jun 2006 13:15:43 -0400 (EDT) Date: Tue, 20 Jun 2006 13:15:43 -0400 (EDT) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: Avuton Olrich cc: Nathan Scott , linux-kernel@vger.kernel.org, xfs@oss.sgi.com Subject: Re: XFS crashed twice, once in 2.6.16.20, next in 2.6.17, reproducable In-Reply-To: <3aa654a40606201001s40fc2bf3j27cd7cb555b02688@mail.gmail.com> Message-ID: References: <3aa654a40606190044q43dca571qdc06ee13d82d979@mail.gmail.com> <20060620161006.C1079661@wobbly.melbourne.sgi.com> <3aa654a40606192340l67d0353fj875767d33d8bd493@mail.gmail.com> <3aa654a40606201001s40fc2bf3j27cd7cb555b02688@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 7986 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs Content-Length: 386 Lines: 15 WHat options did you pass to bad blocks? On Tue, 20 Jun 2006, Avuton Olrich wrote: > On 6/20/06, Justin Piszcz wrote: >> Have you checked to make sure you don't have a bad disk? > > In the initial email I do state that I have run badblocks on this disk > sucessfully. > -- > avuton > -- > Anyone who quotes me in their sig is an idiot. -- Rusty Russell. > From owner-xfs@oss.sgi.com Tue Jun 20 10:21:53 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 20 Jun 2006 10:22:13 -0700 (PDT) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.239]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5KHLqDW022314 for ; Tue, 20 Jun 2006 10:21:52 -0700 Received: by wr-out-0506.google.com with SMTP id i2so729658wra for ; Tue, 20 Jun 2006 10:21:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=pMO6XbLeb40Z70AdFAGWfL4Q+CRrPqRjQP+zWAU+ZKgNIs855h5gG8Gle2PYdPbrPlelIE/uE/WeN31WDl1BSPSQHpDw36UJcHzzYpMW3tQeB6nC6+P2dzkcqKOJ5eP3krO2soMnap3vH5OUe4YLYoa2sjZCMx1ZVXETxmi8H20= Received: by 10.54.151.7 with SMTP id y7mr10776wrd; Tue, 20 Jun 2006 10:21:39 -0700 (PDT) Received: by 10.54.101.10 with HTTP; Tue, 20 Jun 2006 10:21:37 -0700 (PDT) Message-ID: <3aa654a40606201021m2dc8723die1559685f056acdd@mail.gmail.com> Date: Tue, 20 Jun 2006 10:21:37 -0700 From: "Avuton Olrich" To: "Justin Piszcz" Subject: Re: XFS crashed twice, once in 2.6.16.20, next in 2.6.17, reproducable Cc: "Nathan Scott" , linux-kernel@vger.kernel.org, xfs@oss.sgi.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3aa654a40606190044q43dca571qdc06ee13d82d979@mail.gmail.com> <20060620161006.C1079661@wobbly.melbourne.sgi.com> <3aa654a40606192340l67d0353fj875767d33d8bd493@mail.gmail.com> <3aa654a40606201001s40fc2bf3j27cd7cb555b02688@mail.gmail.com> X-archive-position: 7987 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: avuton@gmail.com Precedence: bulk X-list: xfs Content-Length: 324 Lines: 10 On 6/20/06, Justin Piszcz wrote: > WHat options did you pass to bad blocks? Just the defaults, but it doesn't matter, someone else is having the same exact issue I am, from the bugzilla entry earlier in this thread. -- avuton -- Anyone who quotes me in their sig is an idiot. -- Rusty Russell. From owner-xfs@oss.sgi.com Tue Jun 20 10:36:08 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 20 Jun 2006 10:36:31 -0700 (PDT) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.173]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5KHa7DW024836 for ; Tue, 20 Jun 2006 10:36:08 -0700 Received: by ug-out-1314.google.com with SMTP id e2so2972487ugf for ; Tue, 20 Jun 2006 10:35:53 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:mime-version:content-type:content-disposition:user-agent; b=kgLw5RJE/3vGz6DOiXZGtmv2h0hRFNtIUmQAzMTLuqOj9D47OhEeT4yvKzvlBg9y3KUB3sZhBXvjLv86ScavBrcHth6ReJiiH1yYlQs1nxleyTL77MDnxt6EVVopnJI1TlBWTfLcx8s0NSj4eDUj2E9vthI7iUX4oB0T4cOBfhc= Received: by 10.66.216.20 with SMTP id o20mr6800101ugg; Tue, 20 Jun 2006 09:34:20 -0700 (PDT) Received: from gmail.com ( [217.67.117.64]) by mx.gmail.com with ESMTP id k30sm7868176ugc.2006.06.20.09.34.18; Tue, 20 Jun 2006 09:34:19 -0700 (PDT) Received: by gmail.com (nbSMTP-1.00) for uid 1000 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168/168 bits)) adobriyan@gmail.com; Tue, 20 Jun 2006 20:34:28 +0400 (MSD) Date: Tue, 20 Jun 2006 20:34:26 +0400 From: Alexey Dobriyan To: Nathan Scott Cc: xfs@oss.sgi.com, linux-fsdevel@vger.kernel.org, Andrew Morton Subject: [PATCH] xfs: remove unused behaviour lock Message-ID: <20060620163426.GA6201@martell.zuzino.mipt.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11 X-archive-position: 7988 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: adobriyan@gmail.com Precedence: bulk X-list: xfs Content-Length: 603 Lines: 27 Also shrink XFS vnode as a side effect. Signed-off-by: Alexey Dobriyan --- fs/xfs/xfs_behavior.h | 3 --- 1 file changed, 3 deletions(-) --- a/fs/xfs/xfs_behavior.h +++ b/fs/xfs/xfs_behavior.h @@ -78,15 +78,12 @@ #define __XFS_BEHAVIOR_H__ * */ -struct bhv_head_lock; - /* * Behavior head. Head of the chain of behaviors. * Contained within each virtualized object data structure. */ typedef struct bhv_head { struct bhv_desc *bh_first; /* first behavior in chain */ - struct bhv_head_lock *bh_lockp; /* pointer to lock info struct */ } bhv_head_t; /* From owner-xfs@oss.sgi.com Tue Jun 20 12:45:15 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 20 Jun 2006 12:45:34 -0700 (PDT) Received: from mondschein.lichtvoll.de (ms2.lichtvoll.de [194.150.191.235] (may be forged)) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5KJjADW015247 for ; Tue, 20 Jun 2006 12:45:15 -0700 Received: from localhost (dslb-084-056-076-063.pools.arcor-ip.net [84.56.76.63]) by mondschein.lichtvoll.de (Postfix) with ESMTP id 88D16FA50F; Tue, 20 Jun 2006 21:43:42 +0200 (CEST) From: Martin Steigerwald To: ViNiL Subject: Re: Repeating fs corruption Date: Tue, 20 Jun 2006 21:44:42 +0200 User-Agent: KMail/1.9.1 Cc: linux-xfs@oss.sgi.com References: <200606201758.20400.vladimir.linek@netcentrum.cz> In-Reply-To: <200606201758.20400.vladimir.linek@netcentrum.cz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606202144.43329.Martin@lichtvoll.de> X-archive-position: 7989 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Martin@lichtvoll.de Precedence: bulk X-list: xfs Content-Length: 1643 Lines: 48 Am Dienstag 20 Juni 2006 17:58 schrieb ViNiL: > Hello! > > We run several systems of this configuration, here: > > OS: Debian Sarge > Kernel: vanilla 2.6.16+ (+ Areca driver patch) [...] > Can anyone explain to me, what (and why is that :-) is going on with > the filesystem? Hello ViNiL, do you use write caching? With kernel 2.6.16 XFS got corrupted three times in one week here with writecache enabled. I filed a bug report about this, and Nathan Scott recommended to deactivate the write cache or to enable the barrier functionality, which should be enabled by default in kernel 2.6.17. http://bugzilla.kernel.org/show_bug.cgi?id=6380 I found no way to query the current status of the write cache. hdparm -i /dev/yourdevice should show the harddisk manufacturers default, for example: WriteCache=enabled hdparm -W0 disabled write caching when device, driver and controller understand the command used to do that. I had 2.6.16 running for a while with disabled write cache and it seemed to work. Currently I run 2.6.15 with disabled write cache again as 2.6.16 had non working sound after resume from disk (sws2). Write barriers seems to be available as mount option "barrier". I did not yet find any documentation. I did not try the write barrier functionality yet. I want to try it with 2.6.17, but I want to wait a little bit longer. Maybe in two weeks or so when some more minor releases for 2.6.17 are out and there a no reports on XFS corruption with 2.6.17 that apply to my situation. Regards, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 From owner-xfs@oss.sgi.com Tue Jun 20 14:22:22 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 20 Jun 2006 14:22:36 -0700 (PDT) Received: from ruth.realtime.net (mercury.realtime.net [205.238.132.86]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5KLMJDW028734 for ; Tue, 20 Jun 2006 14:22:21 -0700 Received: from [192.168.2.120] (cpe-72-177-24-78.austin.res.rr.com [72.177.24.78]) by realtime.net (Realtime Communications Advanced E-Mail Services V9.2) with ESMTP id 670027 for multiple; Tue, 20 Jun 2006 14:02:15 -0500 Message-ID: <44985423.2090803@johngroves.net> Date: Tue, 20 Jun 2006 15:01:39 -0500 From: John Groves Reply-To: jgl@johngroves.net User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Sparse files in the real world Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Server: High Performance Mail Server - http://surgemail.com r=-1092531819 X-Authenticated-User: jg@bga.com X-archive-position: 7990 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jgl@johngroves.net Precedence: bulk X-list: xfs Content-Length: 286 Lines: 8 I am working on a data management subsystem, and would appreciate any insight people could share about real world applications that generate sparse files. Can anybody share information or pointers to applications that generate (and benefit from) sparse files? Thanks, John Groves From owner-xfs@oss.sgi.com Tue Jun 20 18:05:11 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 20 Jun 2006 18:05:36 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k5L14wDW023751 for ; Tue, 20 Jun 2006 18:05:10 -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 LAA20063; Wed, 21 Jun 2006 11:04:27 +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 k5L14Kgw1105432; Wed, 21 Jun 2006 11:04:21 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k5L14GfR1104407; Wed, 21 Jun 2006 11:04:16 +1000 (EST) Date: Wed, 21 Jun 2006 11:04:16 +1000 From: Nathan Scott To: Alexey Dobriyan Cc: xfs@oss.sgi.com, linux-fsdevel@vger.kernel.org, Andrew Morton Subject: Re: [PATCH] xfs: remove unused behaviour lock Message-ID: <20060621110415.C1105458@wobbly.melbourne.sgi.com> References: <20060620163426.GA6201@martell.zuzino.mipt.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20060620163426.GA6201@martell.zuzino.mipt.ru>; from adobriyan@gmail.com on Tue, Jun 20, 2006 at 08:34:26PM +0400 X-archive-position: 7993 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 137 Lines: 8 On Tue, Jun 20, 2006 at 08:34:26PM +0400, Alexey Dobriyan wrote: > Also shrink XFS vnode as a side effect. Thanks, merged. -- Nathan From owner-xfs@oss.sgi.com Tue Jun 20 18:00:49 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 20 Jun 2006 18:01:03 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k5L10ZDW023355 for ; Tue, 20 Jun 2006 18:00:47 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA19978 for ; Wed, 21 Jun 2006 11:00:09 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 7992C4A588FF; Wed, 21 Jun 2006 11:00:07 +1000 (EST) To: linux-xfs@oss.sgi.com Subject: TAKE 904196 - cleanups from Alexey Message-Id: <20060621010007.7992C4A588FF@chook.melbourne.sgi.com> Date: Wed, 21 Jun 2006 11:00:07 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 7991 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 2072 Lines: 62 link(2) on directory is banned in VFS. Signed-off-by: Alexey Dobriyan Date: Tue Jun 20 17:13:34 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: Alexey Dobriyan The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:26293a xfs_vnodeops.c - 1.680 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vnodeops.c.diff?r1=text&tr1=1.680&r2=text&tr2=1.679&f=h - link(2) on directory is banned in VFS. * There is trivial "inode => vnode => inode" conversion, but only flags and mode of final inode are looked at. Pass original inode instead. * Two occurences of bhv_vnode_t go out. Signed-off-by: Alexey Dobriyan Date: Wed Jun 21 10:55:23 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: Alexey Dobriyan The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:26298a linux-2.6/xfs_vnode.h - 1.124 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_vnode.h.diff?r1=text&tr1=1.124&r2=text&tr2=1.123&f=h - * There is trivial "inode => vnode => inode" conversion, but only flags and mode of final inode are looked at. Pass original inode instead. * Two occurences of bhv_vnode_t go out. remove unused behaviour lock - shrink XFS vnode as a side effect. Signed-off-by: Alexey Dobriyan Date: Wed Jun 21 10:59:08 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: Alexey Dobriyan The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:26299a xfs_behavior.h - 1.21 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_behavior.h.diff?r1=text&tr1=1.21&r2=text&tr2=1.20&f=h - remove unused behaviour lock - shrink XFS vnode as a side effect. From owner-xfs@oss.sgi.com Tue Jun 20 18:04:55 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 20 Jun 2006 18:05:24 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k5L14eDW023713 for ; Tue, 20 Jun 2006 18:04:54 -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 LAA20051; Wed, 21 Jun 2006 11:04:07 +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 k5L141gw1105745; Wed, 21 Jun 2006 11:04:03 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k5L13vaJ1069674; Wed, 21 Jun 2006 11:03:57 +1000 (EST) Date: Wed, 21 Jun 2006 11:03:57 +1000 From: Nathan Scott To: Alexey Dobriyan Cc: Andrew Morton , xfs@oss.sgi.com Subject: Re: [PATCH -mm] xfs: pass inode to xfs_ioc_space() Message-ID: <20060621110357.B1105458@wobbly.melbourne.sgi.com> References: <20060620064131.GA7337@martell.zuzino.mipt.ru> <20060620014555.b127e89d.akpm@osdl.org> <20060620110406.GC7337@martell.zuzino.mipt.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20060620110406.GC7337@martell.zuzino.mipt.ru>; from adobriyan@gmail.com on Tue, Jun 20, 2006 at 03:04:06PM +0400 X-archive-position: 7992 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 241 Lines: 9 On Tue, Jun 20, 2006 at 03:04:06PM +0400, Alexey Dobriyan wrote: > * There is trivial "inode => vnode => inode" conversion, but only flags and > mode of final inode are looked at. Pass original inode instead. Thanks, merged. -- Nathan From owner-xfs@oss.sgi.com Tue Jun 20 19:19:33 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 20 Jun 2006 19:19:58 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k5L2JKDW001507 for ; Tue, 20 Jun 2006 19:19:32 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA21871; Wed, 21 Jun 2006 12:18:47 +1000 From: Timothy Shimmin Organization: SGI To: Martin Steigerwald Subject: Re: Repeating fs corruption Date: Wed, 21 Jun 2006 12:18:20 +1000 User-Agent: KMail/1.8.2 Cc: ViNiL , linux-xfs@oss.sgi.com References: <200606201758.20400.vladimir.linek@netcentrum.cz> <200606202144.43329.Martin@lichtvoll.de> In-Reply-To: <200606202144.43329.Martin@lichtvoll.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606211218.21463.tes@sgi.com> X-archive-position: 7994 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs Content-Length: 409 Lines: 15 On Wednesday 21 June 2006 5:44 am, Martin Steigerwald wrote: > Am Dienstag 20 Juni 2006 17:58 schrieb ViNiL: > > > Can anyone explain to me, what (and why is that :-) is going on with > > the filesystem? > > do you use write caching? With kernel 2.6.16 XFS got corrupted three times > in one week here with writecache enabled. > FYI Have you looked at: http://oss.sgi.com/projects/xfs/faq.html#wcache --Tim From owner-xfs@oss.sgi.com Tue Jun 20 19:19:40 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 20 Jun 2006 19:19:58 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k5L2JODW001511 for ; Tue, 20 Jun 2006 19:19:38 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA20153; Wed, 21 Jun 2006 11:08:50 +1000 From: Timothy Shimmin Organization: SGI To: Denis Nikiforov Subject: Re: Unable to handle kernel NULL pointer dereference at virtual address 00000000 Date: Wed, 21 Jun 2006 11:08:24 +1000 User-Agent: KMail/1.8.2 Cc: xfs@oss.sgi.com References: <87hd2fsvsl.fsf@arietis.arietis> In-Reply-To: <87hd2fsvsl.fsf@arietis.arietis> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606211108.25096.tes@sgi.com> X-archive-position: 7995 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs Content-Length: 1048 Lines: 30 Hi Denis, On Wednesday 21 June 2006 1:15 am, Denis Nikiforov wrote: > > I'd upgraded my computer from Celeron P4 to Athlon 64. And xfs partition > couldn't be mounted now ;( How can I fix it? > > ............. > > | XFS mounting filesystem hdb3 > | Starting XFS recovery on filesystem: hdb3 (logdev: internal) > | Unable to handle kernel NULL pointer dereference at virtual address > ............... > | [] xfs_buf_offset+0x35/0x3a [xfs] > | [] xlog_recover_do_inode_trans+0x14a/0x718 [xfs] Your problem is due to a bug in xfs. A kernel from 2006/05/24 onwards will be able to support this filesystem. The problem is that the ondisk format for a few log items in the ondisk log is different on 32 bits versus 64 bit systems. With the newer XFS it can decode both forms. What can you do? You can either mount and unmount the FS on a 32 bit os so that the log is clean and no recovery is needed. Or you can get a new version of XFS. (In the future, xfs_repair will probably be able to replay the log but not yet). --Tim From owner-xfs@oss.sgi.com Tue Jun 20 20:18:04 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 20 Jun 2006 20:18:27 -0700 (PDT) Received: from mail.ural.org ([85.115.166.251]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5L3I1DW009783 for ; Tue, 20 Jun 2006 20:18:03 -0700 Received: from [85.115.165.127] (helo=arietis.arietis.denis) by mail.ural.org with esmtp (Exim 4.44) id 1FstDq-0002EY-C3; Wed, 21 Jun 2006 09:17:42 +0600 To: Timothy Shimmin Cc: xfs@oss.sgi.com Subject: Re: Unable to handle kernel NULL pointer dereference at virtual address 00000000 References: <87hd2fsvsl.fsf@arietis.arietis> <200606211108.25096.tes@sgi.com> From: Denis Nikiforov X-Face: *+^$JI24p+W&}*/&5,zq_}{!]%A@?FR_>1%\Vm2!UJIilEbAb6'3T]fYwX1H"(a9SUn>&CF g^`pe)6euC Date: Wed, 21 Jun 2006 09:17:44 +0600 In-Reply-To: <200606211108.25096.tes@sgi.com> (Timothy Shimmin's message of "Wed, 21 Jun 2006 11:08:24 +1000") Message-ID: <87ejxjurhj.fsf@arietis.arietis> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 7996 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: denis@ural.org Precedence: bulk X-list: xfs Content-Length: 1360 Lines: 38 (transmit-message (Hello 'Timothy) (You-wrote :on "Wed, 21 Jun 2006 11:08:24 +1000") (Say '( TS> Hi Denis, TS> On Wednesday 21 June 2006 1:15 am, Denis Nikiforov wrote: >> >> I'd upgraded my computer from Celeron P4 to Athlon 64. And xfs partition >> couldn't be mounted now ;( How can I fix it? >> >> ............. >> >> | XFS mounting filesystem hdb3 >> | Starting XFS recovery on filesystem: hdb3 (logdev: internal) >> | Unable to handle kernel NULL pointer dereference at virtual address >> ............... >> | [] xfs_buf_offset+0x35/0x3a [xfs] >> | [] xlog_recover_do_inode_trans+0x14a/0x718 [xfs] TS> Your problem is due to a bug in xfs. TS> A kernel from 2006/05/24 onwards will be able to support this filesystem. TS> The problem is that the ondisk format for a few log items in the ondisk log is TS> different on 32 bits versus 64 bit systems. With the newer XFS it can decode TS> both forms. TS> What can you do? TS> You can either mount and unmount the FS on a 32 bit os so that the log is TS> clean and no recovery is needed. TS> Or you can get a new version of XFS. TS> (In the future, xfs_repair will probably be able to replay the log but not TS> yet). 2.6.16-14 is the latest kernel in Debian. And I guess it's old enough. Thanks, I'll wait for a new kernel :) -- ))) => t (WBR '(Denis Nikiforov)) From owner-xfs@oss.sgi.com Tue Jun 20 22:29:11 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 20 Jun 2006 22:29:30 -0700 (PDT) Received: from smtp1.adl2.internode.on.net (smtp1.adl2.internode.on.net [203.16.214.181]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5L5TADW032502 for ; Tue, 20 Jun 2006 22:29:10 -0700 Received: from saturn.flamingspork.com (ppp163-199.static.internode.on.net [150.101.163.199]) by smtp1.adl2.internode.on.net (8.13.6/8.13.5) with ESMTP id k5L4BrY5064568; Wed, 21 Jun 2006 13:41:54 +0930 (CST) (envelope-from stewart@flamingspork.com) Received: from localhost.localdomain (unknown [192.168.1.100]) by saturn.flamingspork.com (Postfix) with ESMTP id 84602C422AD; Wed, 21 Jun 2006 14:11:53 +1000 (EST) Received: by localhost.localdomain (Postfix, from userid 1000) id C966B140BB79; Wed, 21 Jun 2006 14:11:53 +1000 (EST) Subject: Re: Sparse files in the real world From: Stewart Smith To: jgl@johngroves.net Cc: linux-xfs@oss.sgi.com In-Reply-To: <44985423.2090803@johngroves.net> References: <44985423.2090803@johngroves.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-v6vafHpEWkkg+if96VO/" Date: Wed, 21 Jun 2006 14:11:52 +1000 Message-Id: <1150863112.12247.116.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 X-archive-position: 7997 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: stewart@flamingspork.com Precedence: bulk X-list: xfs Content-Length: 1229 Lines: 38 --=-v6vafHpEWkkg+if96VO/ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2006-06-20 at 15:01 -0500, John Groves wrote: > I am working on a data management subsystem, and would appreciate any=20 > insight people could share about real world applications that generate=20 > sparse files. Can anybody share information or pointers to applications= =20 > that generate (and benefit from) sparse files? Virtualization of machines. big file system image, only parts of it are written to. also (mostly testing) database data files. often when running a test suite you'll just want to "generate the x MB file" as quickly as possible and not worry about the overhead during runtime of doing sparse files as you're only going to be writing to a small portion. --=20 Stewart Smith (stewart@flamingspork.com) http://www.flamingspork.com/ --=-v6vafHpEWkkg+if96VO/ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQBEmMcIKglWCUL+FDoRAlOjAKCfO/tapZ0mbyz0496lqxckwtH2zACfQdkc xx77BTY1RV2zgVo170XV3Lg= =ohHy -----END PGP SIGNATURE----- --=-v6vafHpEWkkg+if96VO/-- From owner-xfs@oss.sgi.com Wed Jun 21 02:08:16 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 21 Jun 2006 02:08:39 -0700 (PDT) Received: from mail.software.plasmon.com (gw.plasmon.co.uk [194.130.136.219]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5L98FDW002965 for ; Wed, 21 Jun 2006 02:08:15 -0700 Received: from leuven.devel.pcs ([10.4.2.5] ident=uday) by mail.software.plasmon.com with esmtp (Exim 3.35 #1 (Debian)) id 1FsxPX-0001oZ-00; Wed, 21 Jun 2006 08:46:03 +0100 Message-ID: <4498F93A.7050904@plasmon.co.uk> Date: Wed, 21 Jun 2006 08:46:02 +0100 From: Uday Chitragar User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20060503 Debian/1.7.8-1sarge6 X-Accept-Language: en MIME-Version: 1.0 To: jgl@johngroves.net CC: linux-xfs@oss.sgi.com Subject: Re: Sparse files in the real world References: <44985423.2090803@johngroves.net> In-Reply-To: <44985423.2090803@johngroves.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8000 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: uchitragar@plasmon.co.uk Precedence: bulk X-list: xfs Content-Length: 734 Lines: 24 We are building an Archive Appliance that generates sparse files. Data written to filesystem is migrated to optical disks (UDO). Based on usage policy, the actual files on filesystem are replaced with sparse files. On access of the file (from filesystem clients), the filesystem filter (for XFS) triggers events to restore the actual file from Optical storage onto the filesystem. Regards, Uday Chitragar John Groves wrote: > I am working on a data management subsystem, and would appreciate any > insight people could share about real world applications that generate > sparse files. Can anybody share information or pointers to > applications that generate (and benefit from) sparse files? > > Thanks, > John Groves > > From owner-xfs@oss.sgi.com Wed Jun 21 02:52:14 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 21 Jun 2006 02:52:26 -0700 (PDT) Received: from alpha.netcentrum.cz (alpha.netcentrum.cz [62.84.145.8]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5L9qDDW011384 for ; Wed, 21 Jun 2006 02:52:14 -0700 Received: from wintermute.netcentrum.cz ([62.84.145.125]) by alpha.netcentrum.cz with Microsoft SMTPSVC(5.0.2195.6713); Wed, 21 Jun 2006 11:51:54 +0200 From: ViNiL To: linux-xfs@oss.sgi.com Subject: Re: Repeating fs corruption Date: Wed, 21 Jun 2006 11:51:54 +0200 User-Agent: KMail/1.9.3 References: <200606201758.20400.vladimir.linek@netcentrum.cz> <200606202144.43329.Martin@lichtvoll.de> In-Reply-To: <200606202144.43329.Martin@lichtvoll.de> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4687844.ElQx4miL4j"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200606211151.54376.vladimir.linek@netcentrum.cz> X-OriginalArrivalTime: 21 Jun 2006 09:51:54.0683 (UTC) FILETIME=[53F310B0:01C69518] X-archive-position: 8001 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: vladimir.linek@netcentrum.cz Precedence: bulk X-list: xfs Content-Length: 1128 Lines: 49 --nextPart4687844.ElQx4miL4j Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 20 June 2006 21:44, Martin Steigerwald wrote: > Am Dienstag 20 Juni 2006 17:58 schrieb ViNiL: > > Hello! > > > > We run several systems of this configuration, here: > > > > OS: Debian Sarge > > Kernel: vanilla 2.6.16+ (+ Areca driver patch) > > [...] > > > Can anyone explain to me, what (and why is that :-) is going on with > > the filesystem? > > Hello ViNiL, > > do you use write caching? With kernel 2.6.16 XFS got corrupted three times > in one week here with writecache enabled. Of course, we do use write caching! That is, why we've bought BBU (battery= =20 backup unit) for every RAID card. Are you going to tell me it is just a was= te=20 of money?=20 ViNiL --nextPart4687844.ElQx4miL4j Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQBEmRa6bK7iOupfgaIRAu05AJ9WaLyktU1QTc5X/OY0lZ0gE1hPLACgqlJP K8Hra4xV/4vCeeM9+PD3idY= =S1WJ -----END PGP SIGNATURE----- --nextPart4687844.ElQx4miL4j-- From owner-xfs@oss.sgi.com Wed Jun 21 03:25:06 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 21 Jun 2006 03:25:19 -0700 (PDT) Received: from mondschein.lichtvoll.de (ms2.lichtvoll.de [194.150.191.235] (may be forged)) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5LAP5DW017011 for ; Wed, 21 Jun 2006 03:25:05 -0700 Received: from deepdance.of.teamix.net (blackhole.teamix.net [194.150.191.251]) by mondschein.lichtvoll.de (Postfix) with ESMTP id 4160AFA510; Wed, 21 Jun 2006 12:23:39 +0200 (CEST) From: Martin Steigerwald To: ViNiL Subject: Re: Repeating fs corruption Date: Wed, 21 Jun 2006 12:24:09 +0200 User-Agent: KMail/1.9.1 Cc: linux-xfs@oss.sgi.com References: <200606201758.20400.vladimir.linek@netcentrum.cz> <200606202144.43329.Martin@lichtvoll.de> <200606211151.54376.vladimir.linek@netcentrum.cz> In-Reply-To: <200606211151.54376.vladimir.linek@netcentrum.cz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-6" Content-Disposition: inline Message-Id: <200606211224.09570.Martin@lichtvoll.de> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id k5LAP6DW017014 X-archive-position: 8002 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Martin@lichtvoll.de Precedence: bulk X-list: xfs Content-Length: 1575 Lines: 39 Am Mittwoch 21 Juni 2006 11:51 schrieb ViNiL: > > Hello ViNiL, > > > > do you use write caching? With kernel 2.6.16 XFS got corrupted three > > times in one week here with writecache enabled. > > Of course, we do use write caching! That is, why we've bought BBU > (battery backup unit) for every RAID card. Are you going to tell me it > is just a waste of money? Hello, no. Write caching should work okay, when you use the barrier functionality. From what I understand it should even work when the filesystem is not interrupted abnormally and the harddisk does not loose power before all data is written. But from my experience with three XFS crashes in one week with 2.6.16 and write caching enabled I do not quite yet buy into this cause three completely unrelated kernel crashes seem to be quite unlikely for me. 2.6.16 with write caching off worked stable for over one week. With 2.6.15 instead it seemed to just work fine with write caching as long as the filesystem and harddisk was shutdown in regular way. I suggest you try 2.6.17 with has barrier functionality on by default as soon as you convinced its stable enough for your usage. Until then it might be a good idea to try without write caching and see if that helps. Or revert back to 2.6.15 and see if that helps, but thats probably not worth the trouble. I am no expert on this and YMMV. Maybe an XFS developer can give you feedback that is more accurate than mine. Regards, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 From owner-xfs@oss.sgi.com Wed Jun 21 05:08:16 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 21 Jun 2006 05:08:30 -0700 (PDT) Received: from alpha.netcentrum.cz (alpha.netcentrum.cz [62.84.145.8]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5LC8FDW001486 for ; Wed, 21 Jun 2006 05:08:16 -0700 Received: from wintermute.netcentrum.cz ([62.84.145.125]) by alpha.netcentrum.cz with Microsoft SMTPSVC(5.0.2195.6713); Wed, 21 Jun 2006 14:07:49 +0200 From: ViNiL To: linux-xfs@oss.sgi.com Subject: Re: Repeating fs corruption Date: Wed, 21 Jun 2006 14:07:45 +0200 User-Agent: KMail/1.9.3 References: <200606201758.20400.vladimir.linek@netcentrum.cz> <200606211151.54376.vladimir.linek@netcentrum.cz> <200606211224.09570.Martin@lichtvoll.de> In-Reply-To: <200606211224.09570.Martin@lichtvoll.de> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2901143.snGm6x60sS"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200606211407.49601.vladimir.linek@netcentrum.cz> X-OriginalArrivalTime: 21 Jun 2006 12:07:49.0828 (UTC) FILETIME=[50CB7040:01C6952B] X-archive-position: 8004 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: vladimir.linek@netcentrum.cz Precedence: bulk X-list: xfs Content-Length: 1097 Lines: 43 --nextPart2901143.snGm6x60sS Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 21 June 2006 12:24, Martin Steigerwald wrote: > I suggest you try 2.6.17 with has barrier functionality on by default as > soon as you convinced its stable enough for your usage. Until then it > might be a good idea to try without write caching and see if that helps. > Or revert back to 2.6.15 and see if that helps, but thats probably not > worth the trouble. > > I am no expert on this and YMMV. Maybe an XFS developer can give you > feedback that is more accurate than mine. Thank you for quick reply. We'll give 2.6.17 a chance... --=20 ViNiL Ever since they switched all the crts to lcds at work, I'm not getting any= =20 tan. --nextPart2901143.snGm6x60sS Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQBEmTaVbK7iOupfgaIRAmJ5AJ9anZfNhrt+cges4KpttM+s5KeYhQCgij5f Zg8jFLCd2iyF135PJfYPBNo= =zdJJ -----END PGP SIGNATURE----- --nextPart2901143.snGm6x60sS-- From owner-xfs@oss.sgi.com Wed Jun 21 18:05:16 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 21 Jun 2006 18:05:44 -0700 (PDT) Received: from omx1.americas.sgi.com (omx1.americas.sgi.com [198.149.16.13]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5M155DW012436 for ; Wed, 21 Jun 2006 18:05:16 -0700 Received: from imr2.americas.sgi.com (imr2.americas.sgi.com [198.149.16.18]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id k5M01vnx019208 for ; Wed, 21 Jun 2006 19:01:57 -0500 Received: from omx2.sgi.com ([198.149.32.25]) by imr2.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id k5M0Hm7p36068808 for ; Wed, 21 Jun 2006 17:17:48 -0700 (PDT) Received: from internal-mail-relay1.corp.sgi.com (internal-mail-relay1.corp.sgi.com [198.149.32.52]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id k5M2O7qd030011 for ; Wed, 21 Jun 2006 19:24:07 -0700 Received: from omx2.sgi.com ([198.149.32.25]) by internal-mail-relay1.corp.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id k5M0108s15033014 for ; Wed, 21 Jun 2006 17:01:00 -0700 (PDT) Received: from internal-mail-relay1.corp.sgi.com (internal-mail-relay1.corp.sgi.com [198.149.32.52]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id k5M2NVkY029962 for ; Wed, 21 Jun 2006 19:23:31 -0700 Received: from [192.168.0.13] (cf-vpn-sw-corp-64-9.corp.sgi.com [134.15.64.9]) by internal-mail-relay1.corp.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id k5M00O8s15031170; Wed, 21 Jun 2006 17:00:24 -0700 (PDT) Message-ID: <4499DD8C.8040600@sgi.com> Date: Wed, 21 Jun 2006 19:00:12 -0500 From: Bill Kendall User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051011) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Robin H. Johnson" CC: xfs@oss.sgi.com Subject: Re: [XFSDUMP PATCH] Fixes for parallel compiles References: <20060611195156.GF26475@curie-int.vc.shawcable.net> In-Reply-To: <20060611195156.GF26475@curie-int.vc.shawcable.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8006 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: wkendall@sgi.com Precedence: bulk X-list: xfs Content-Length: 2181 Lines: 64 Hi Robin, Your suggested makefile changes have gone into xfsdump 2.2.39. Thanks, Bill Robin H. Johnson wrote: > Several of the directories in xfsdump are not parallel compile safe, due to > their behavior of deleting and symlinking heads from other directories. > > This patch modifies those Makefiles to have the symlinks be a dependancy of the > source in those directories, ensuring that all of the symlinks will exist > before the actual compiling is started. > > Signed-off-by: Robin H. Johnson > > diff -Nuar --exclude '*.orig' --exclude builddefs.in xfsdump-2.2.33/dump/Makefile xfsdump-2.2.33/dump/Makefile > --- xfsdump-2.2.33/dump/Makefile 2006-01-11 21:06:47.000000000 -0800 > +++ xfsdump-2.2.33/dump/Makefile 2006-06-11 12:36:21.436682241 -0700 > @@ -102,7 +102,9 @@ > install-dev: > > $(COMMINCL) $(COMMON): > - @$(RM) $@; $(LN_S) ../common/$@ $@ > + $(RM) $@; $(LN_S) ../common/$@ $@ > > $(INVINCL) $(INVCOMMON): > - @$(RM) $@; $(LN_S) ../inventory/$@ $@ > + $(RM) $@; $(LN_S) ../inventory/$@ $@ > + > +$(LOCALS): $(LINKS) > diff -Nuar --exclude '*.orig' --exclude builddefs.in xfsdump-2.2.33/invutil/Makefile xfsdump-2.2.33/invutil/Makefile > --- xfsdump-2.2.33/invutil/Makefile 2006-01-11 21:06:48.000000000 -0800 > +++ xfsdump-2.2.33/invutil/Makefile 2006-06-11 12:36:21.438682223 -0700 > @@ -66,7 +66,9 @@ > install-dev: > > $(COMMINCL) $(COMMON): > - @$(RM) $@; $(LN_S) ../common/$@ $@ > + $(RM) $@; $(LN_S) ../common/$@ $@ > > $(INVINCL) $(INVCOMMON): > - @$(RM) $@; $(LN_S) ../inventory/$@ $@ > + $(RM) $@; $(LN_S) ../inventory/$@ $@ > + > +$(LOCALS): $(LINKS) > diff -Nuar --exclude '*.orig' --exclude builddefs.in xfsdump-2.2.33/restore/Makefile xfsdump-2.2.33/restore/Makefile > --- xfsdump-2.2.33/restore/Makefile 2006-01-11 21:06:49.000000000 -0800 > +++ xfsdump-2.2.33/restore/Makefile 2006-06-11 12:36:21.433682268 -0700 > @@ -112,7 +112,9 @@ > install-dev: > > $(COMMINCL) $(COMMON): > - @$(RM) $@; $(LN_S) ../common/$@ $@ > + $(RM) $@; $(LN_S) ../common/$@ $@ > > $(INVINCL) $(INVCOMMON): > - @$(RM) $@; $(LN_S) ../inventory/$@ $@ > + $(RM) $@; $(LN_S) ../inventory/$@ $@ > + > +$(LOCALS): $(LINKS) > From owner-xfs@oss.sgi.com Wed Jun 21 19:57:32 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 21 Jun 2006 19:57:56 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k5M2vJDW027380 for ; Wed, 21 Jun 2006 19: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 MAA23670; Thu, 22 Jun 2006 12:56:47 +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 k5M2uigw1137793; Thu, 22 Jun 2006 12:56:44 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k5M2ue9F1111095; Thu, 22 Jun 2006 12:56:40 +1000 (EST) Date: Thu, 22 Jun 2006 12:56:40 +1000 From: Nathan Scott To: Avuton Olrich Cc: linux-kernel@vger.kernel.org, xfs@oss.sgi.com Subject: Re: XFS crashed twice, once in 2.6.16.20, next in 2.6.17, reproducable Message-ID: <20060622125640.C1135236@wobbly.melbourne.sgi.com> References: <3aa654a40606190044q43dca571qdc06ee13d82d979@mail.gmail.com> <20060620161006.C1079661@wobbly.melbourne.sgi.com> <3aa654a40606192338v751150fp5645d1d2943316ea@mail.gmail.com> <20060620164338.A1080488@wobbly.melbourne.sgi.com> <3aa654a40606192350w5c469670t466dfc1344e23a4@mail.gmail.com> <20060620165209.C1080488@wobbly.melbourne.sgi.com> <3aa654a40606200120v5baf0304ka205f1ad8f136ad9@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3aa654a40606200120v5baf0304ka205f1ad8f136ad9@mail.gmail.com>; from avuton@gmail.com on Tue, Jun 20, 2006 at 01:20:39AM -0700 X-archive-position: 8007 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 1117 Lines: 30 On Tue, Jun 20, 2006 at 01:20:39AM -0700, Avuton Olrich wrote: > On 6/19/06, Nathan Scott wrote: > > No - its in CVS (for a long time); I'll go get the ftp area updated, > > looks like thats been forgotten about again. FWIW, I've updated the ftp area now. > OK, just compiled from CVS HEAD (xfs_repair 2.8.2) and it still fails: Is this a large filesystem? Any chance we can get access to it somehow (e.g. xfs_copy to a sparse file, then send me a pointer to it) to reproduce the problem locally? > fatal error -- can't read block 16777216 for directory inode > 1507133580 Once you save a copy of it for further analysis of xfs_repair, if you can, you can clear out this problem by directly poking at the device using xfs_db in expert mode. "xfs_db -x /dev/xxx"; then "inode 1507133580"; then "write core.mode 0"; and then try another xfs_repair run. Please try capture the fs for us first though (if possible) else we're going to struggle to improve on this aspect of xfs_repair. Send me some private mail if you do manage to grab the fs and put it someplace for me. thanks. -- Nathan From owner-xfs@oss.sgi.com Thu Jun 22 00:40:54 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 22 Jun 2006 00:41:22 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5M7erDW009355 for ; Thu, 22 Jun 2006 00:40:54 -0700 Received: by nf-out-0910.google.com with SMTP id l36so233330nfa for ; Thu, 22 Jun 2006 00:40:37 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:mime-version:content-type:content-disposition:user-agent; b=mNbMBzgHGQ34UY1KRJ/BxELOYlD0VFdhfOWPduLfQZdduLo5Lfq9zhWmaOwhPRlwNCHPG3MXjqWw/YOixBpnRm8MkdY9M6q9boiQCiWEo/JAsk4r6CwACsxaqTJMwWXhvLZHZJtQwuKhRfP59gjrbLNUh2DKfck8tv4c9oEiRYI= Received: by 10.49.85.9 with SMTP id n9mr1312770nfl; Thu, 22 Jun 2006 00:40:36 -0700 (PDT) Received: from gmail.com ( [217.67.117.64]) by mx.gmail.com with ESMTP id r33sm1637839nfc.2006.06.22.00.40.35; Thu, 22 Jun 2006 00:40:36 -0700 (PDT) Received: by gmail.com (nbSMTP-1.00) for uid 1000 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168/168 bits)) adobriyan@gmail.com; Thu, 22 Jun 2006 11:40:53 +0400 (MSD) Date: Thu, 22 Jun 2006 11:40:51 +0400 From: Alexey Dobriyan To: Nathan Scott Cc: xfs@oss.sgi.com, Andrew Morton Subject: [PATCH] xfs: put xfs_trans_t on diet Message-ID: <20060622074051.GA7697@martell.zuzino.mipt.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11 X-archive-position: 8008 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: adobriyan@gmail.com Precedence: bulk X-list: xfs Content-Length: 1454 Lines: 36 * remove ->t_forw, ->t_back -- unused * ->t_ag_freeblks_delta, ->t_ag_flist_delta, ->t_ag_btree_delta are debugging aid -- wrap them in everyone's favourite way. As a result, cut "xfs_trans" slab object size from 592 to 572 bytes here. Signed-off-by: Alexey Dobriyan --- fs/xfs/xfs_trans.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/fs/xfs/xfs_trans.h +++ b/fs/xfs/xfs_trans.h @@ -338,8 +338,6 @@ typedef void (*xfs_trans_callback_t)(str typedef struct xfs_trans { unsigned int t_magic; /* magic number */ xfs_log_callback_t t_logcb; /* log callback struct */ - struct xfs_trans *t_forw; /* async list pointers */ - struct xfs_trans *t_back; /* async list pointers */ unsigned int t_type; /* transaction type */ unsigned int t_log_res; /* amt of log space resvd */ unsigned int t_log_count; /* count for perm log res */ @@ -364,9 +362,11 @@ typedef struct xfs_trans { long t_res_fdblocks_delta; /* on-disk only chg */ long t_frextents_delta;/* superblock freextents chg*/ long t_res_frextents_delta; /* on-disk only chg */ +#ifdef DEBUG long t_ag_freeblks_delta; /* debugging counter */ long t_ag_flist_delta; /* debugging counter */ long t_ag_btree_delta; /* debugging counter */ +#endif long t_dblocks_delta;/* superblock dblocks change */ long t_agcount_delta;/* superblock agcount change */ long t_imaxpct_delta;/* superblock imaxpct change */ From owner-xfs@oss.sgi.com Thu Jun 22 02:30:44 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 22 Jun 2006 02:31:09 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k5M9UVDW025463 for ; Thu, 22 Jun 2006 02:30:43 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA01529; Thu, 22 Jun 2006 19:30:00 +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 k5M9Ttgw1145178; Thu, 22 Jun 2006 19:29:56 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k5M9Tqfi1143119; Thu, 22 Jun 2006 19:29:52 +1000 (EST) Date: Thu, 22 Jun 2006 19:29:52 +1000 From: Nathan Scott To: Alexey Dobriyan Cc: xfs@oss.sgi.com, Andrew Morton Subject: Re: [PATCH] xfs: put xfs_trans_t on diet Message-ID: <20060622192952.A1142412@wobbly.melbourne.sgi.com> References: <20060622074051.GA7697@martell.zuzino.mipt.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20060622074051.GA7697@martell.zuzino.mipt.ru>; from adobriyan@gmail.com on Thu, Jun 22, 2006 at 11:40:51AM +0400 X-archive-position: 8011 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 285 Lines: 10 On Thu, Jun 22, 2006 at 11:40:51AM +0400, Alexey Dobriyan wrote: > * remove ->t_forw, ->t_back -- unused > * ->t_ag_freeblks_delta, ->t_ag_flist_delta, ->t_ag_btree_delta > are debugging aid -- wrap them in everyone's favourite way. Thanks Alexey, looks good - applied. -- Nathan From owner-xfs@oss.sgi.com Thu Jun 22 05:20:10 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 22 Jun 2006 05:20:26 -0700 (PDT) Received: from sipsolutions.net (crystal.sipsolutions.net [195.210.38.204]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5MCK9DW023011 for ; Thu, 22 Jun 2006 05:20:09 -0700 Received: from [131.234.77.218] (helo=dhcp-77-218.uni-paderborn.de) by sipsolutions.net with esmtpsa (TLS-1.0:RSA_ARCFOUR_MD5:16) (Exim 4.62) (envelope-from ) id 1FtN7c-0003HV-4X for linux-xfs@oss.sgi.com; Thu, 22 Jun 2006 12:13:16 +0100 Subject: error xlog_recover_do_inode_trans(1) / bug when recovering From: Johannes Berg To: linux-xfs@oss.sgi.com Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-F4qlgzzCg7SkVZwVz0fo" Date: Thu, 22 Jun 2006 13:12:39 +0200 Message-Id: <1150974759.16258.27.camel@johannes> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 X-archive-position: 8012 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: johannes@sipsolutions.net Precedence: bulk X-list: xfs Content-Length: 10261 Lines: 199 --=-F4qlgzzCg7SkVZwVz0fo Content-Type: multipart/mixed; boundary="=-Ip+PszGGnUUUDUak632e" --=-Ip+PszGGnUUUDUak632e Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi, I got a corrupted xfs device that printed out, when trying to recover: Bad inode magic number, .... Internal error xlog_recover_do_inode_trans(1) ... I don't have all the details transcribed (tooks some pictures with my cell phone but the quality sucks). I did, however, save a copy of the disk via my computer's target-disk mode before running xfs_repair -L on it. It is 7.3 GB (compressed with gzip -3) but I can run analysis on it if anyone is interested, you just need to tell me what to do. Then, after taking the snapshot, I attempted to run xfs_repair -L on it, but it crapped out too and told me: Phase 7 - verify and correct link counts... corrupt dinode 30638, extent total =3D 1, nblocks =3D 0. This is a bug. Please report it to linux-xfs@oss.sgi.com. fatal error -- couldn't map inode 30638, err =3D 990 The whole log is attached. Interestingly, after repair, the kernel was able to mount it again, though I haven't tried a find / on it. johannes --=-Ip+PszGGnUUUDUak632e Content-Disposition: attachment; filename=sdb7.xfs_repair.log.gz Content-Type: application/x-gzip; name=sdb7.xfs_repair.log.gz Content-Transfer-Encoding: base64 H4sICD1smkQCA3NkYjcueGZzX3JlcGFpci5sb2cA7V1rjyu5cf2uX9GwEXgX 2ZltksWXAQNZJwt7gXWyuNkgyKdFj9Qzox2pe6Ju3Yd/fciWNFe6olo8bOVh hIYN+GrqsKpY7Cqymjr6bfHxsftlU79Wy01x1xTfLur333aLBz376bnq6oIV d8XjslkUlfvf+3qzfPxUdNvXevOwaucv9/f3eznu5Lbdsnkqlk1fb5pqVaza p1mx/89d0c2rxo20qrtPXV+vi8dNXXev1bweRl427aIu1tVr54f8jHpst+6v m7bt9yLz523zstcpBoFNUVfz5+K7P50iB31fPWz7YtE2v+uL+aquNl8X1dOy 2DarZfNSL4rVsuu/UPi6aed11xUvTfuh2ensBgudy07Xem/GYtnNWzcdn07R 1VPTFn8oytlDtXDePC3nRbNdP9Sbovz4WNqqaPdjFkoLbgYxN0q3dJ9/Ftz9 pwwJf9XUT1W/fF9/XXTLv9bFHddGW0tWKcuZYpYZGcJdtcUituyEd//2k1L5 6Jz9/ZpOUQI698IXdYq4ORcM0cmu6GQhnfWZTj6qk4WEL+vkcX4KxE9xRacI 6VyU7AudhOikC+tZMq210rbkUrmokmEh3Jn/X9oiEVvkFf9l3JwrRKe6olPF 6dSITn1Fp47TieStvfBlnXH5SSD5SVzJTyIuPxGSn+hKfqK4/ERIfqIr+YlY nE6O6LySnyiYn/SZTiQ/0ZX8RCLOTyQ/EaXVW6I4W5D8RFfyE8XlJ0LyE13J TxSXnwjJT3QlP5GOqrdkgHpLV/ITxeUnQvITXclPZKPqrUTy014YrreyjKq3 Eslb8kreknF5SyJ5S17JWzJuXyWRvCWv5C0Zl7ckkrf2wpd1xuUnieQneSU/ ybj8JJH8JK/kJxmXnySSn+SV/CTj9k8S2T/JK/lJmqh6K5H8JK/kJ2kjz7ff FB/a7cqd3+uu7k/koZPv6TCnqORT8W7I5+p9vWsN1IuEQ/NtHLRXHRw7ao86 EnsSv4kjXw6DOOLO72OORB/vb+MIm+AIG3cktmeQ6AgbHQZyhI87EtuIuE1E xARHxLgjsd2N2zhCCdnsek9k1MHYlsltHJQTIiXHHYntw9zGETXBETXuSGxz 5zaO6AmO6HFHYjtGt3HETHBkvOJHt6Fu48iEii/GK350b+smjtCEik/jFT+6 YXYbRyZUfBqv+NFduNs4MqHi03jFj27t3caRCRWfxit+dL/wNo7Q7c8vNF7x o5uQt3FwQsWn8Yof3dm8jSMTKj6NV/zodultHJlQ8Wm84kf3YG9yfqEJFZ/G K350Y/c2EZlQ8Wm84kd3i2/iiCxvf36R4zuB6Bb0bRycsBOQ4zuB6L72bRyZ sBOQ4zuB6Gb5bRyZsBOQ4zuB6A78bRyhCY6MV/zotv5tHJlQ8eV4xY9+V3Ab RyZUfDle8aNfQNzGkQkVX45X/Oi3GrdxZELFl+MVP/pVyW0cmVDx5XjFd39e rqtX94dque7c53fbrt7/WZKV2hTLbrhgeTBh3m429dwpcbDZouorr/Vlr7Nw AKvsYTiPK4bbnYVyddvtk0CABQGuvoMAhgI4ChAogFCARAEKBWgUgEZaopFW aKQVGmmFRlqhkVZopBUaaYVGWqGRVmikFRppjUZao5HWaKQ1GmmNRlqjkdZo pDUaaY1GWqORNmikDRppg0baoJE2aKQNGmmDRtqgkTZopA0aaYtG2qKRtmik LRppi0baopG2aKQtGmmLRtqCkTZliQIYCuAoQKAAQgESBSgUoFGAQQFopBka aYZGmqGRZmikGRpphkaaoZFmaKQZGmmGRpqjkeZopDkaaY5GmqOR5mikORpp jkaao5HmaKQFGmmBRlqgkRZopAUaaYFGWqCRFmikBRppgUaa0EgTGmlCI01o pAmNNKGRJjTShEYa7ZEZtEdm0B6ZQXtkBu2RGbRHZtAemUF7ZAbtkRm0R2bQ HplBe2QG7ZEZtEdm0B6ZQXtkBu2RGbRHZtAemUF7ZAbtkRm0R2bQHplBe2QG 7ZEZtEdm0B6ZQXtkBu2RGbRHZtAemUF7ZAbtkRm0R2bQHplBe2QG7ZEZtEdm 0B6ZQXtkBu2RGbRHZtAemUF7ZAbtkRm0R2bQHpmx8pwChZ1/xM8/CpjGJZdC WwroYtLv88vzYej8o4BJ6vwjff6Rmc1+bZ+rpqm733/73K7rbw///G2myslU OZkqJ1PlZKqcTJWTqXIyVU6myslUOZkqJ1PlZKqcTJWTqXIyVU6myslUOZkq J1PlZKqcTJWTqXIyVU6myslUOZkqJ1PlZKqcTJWTqXIyVU6myslUOZkqJ1Pl ZKqcTJWTqXIyVU6myslUOZkqJ1PlZKqcTJWTqXIyVU6myslUOZkqJ1PlZKqc TJWTqXIyVU6myslUOZkqJ1PlZKqcTJWTqXIyVU6myslUOZkqJ1PlZKqcv2Wq HJxe5iLgZblaVatVcfdv//qOFYvF/1XJddUcOfe370+WzJJZ8v+P5FFi/m8j /fprvWn9Rx7y/bt3//Lu98XPz/UxDZgbp3hfrbbVw6ou1nVfDaVn7ox8qv3V lqLy+OLD83L+XDR1veiKvp091IUzfVV9qhf3RfGXdtv0RX86cN/uRYY/uDG+ GbzZNutBetkXD7WrcPVsU99ttk3jvfg8JW7UHx6LT+22qDa1Aw3muSHXAVXf +H83biLqmf/D3Y9F+9r7qz5OflF3/aZ9s2Ewoeod6LV3nu11zf657d3oz1V/ kPfGHCBr58K88jd8/C2e7W7ou7vidVX7GHwebbBt1j5+ORM7P4tFuxt12d3H Vesf/2fWxXc/fv/u52nrYtk5J5262X766oX7927OTiPywY3qPl3c/28T0/mh h3tdmZAuE9JlQrpMSJcJ6TIhXSaky4R0mZAuE9JlQrpMSJcJ6TIhXSakuz0h 3fBlrN63JibQ0X0e5EZkdFMY6KZ7ZK94NHaunkI5N9ny00FAurkpHHPTLWfJ lrPZFFK5BMvZyCAgodwUFrnpcy6SLRezKbRx0y0nOOdc71pM4Ymb7pFMjoWc TSGGm265SrZczaYwwU23XCdbrmdTqN+mW26SLQ/UVoDrbbrlybVVBGorQO42 2XJKrq0UqK0Am9t0y5NrKwVqK0DfNt3y5NpKgdoK8LVNtzy5tlKgtgIEbdMt p1vv5ylQWwFGtukeJddWCtRWgIJtuuXJtZUCtRXgXJtueXJtpUBtBUjWJu/n Kbm2UqC2Aqxq0+c8ubZSoLYCNGqTLZflrffzMlBzAd606R4l11wZqLkAUdp0 y5NrrgzUXIAZbbrlyTVXBmouQIU23XJKtjxQWwHus+mWJ9dWGaitANnZdMuT a6sM1FaA3Wy65cm1VQZqK0BnNt3y5NoqA7UV4C+bbnlybZWB2ooQlu2pyobL g5mtLLOVZbayzFaW2coyW1lmK8tsZZmtLLOVZbayzFaW2coyW1lmK8tsZZmt LLOVZbayzFaW2coyW1lmK8tsZZmtLLOVZbayzFZ2ja3sjB+DnX/Ezz8KmMYl l0JbCuhi0u/zy/Nh6PyjgEnq/CN9/pE5/8gG3AvE2W3HNRM2NEvOJ5Khvt1V jIUxqiwTMCwBwxMwIgFDCRiZgFEJGJ2AMQmYhHWQsEYVS1gHLGEdsEvrgMQl DKmgP5xrMjyIUWTDa2fAyIuYUDoL5LOQ36wstWKm1KFUKbTPbAmg0P7hOoil gFJ8Cu0lroMoBSRTQCoFpFNAJgWUsiJsyoqwKSvCpqwIm7IibKCMuzxx/llo 5TCtS/fwisDg/m4dsUD1D70HYFxaN5QNZQd/3FE8CHJJ3e2bKAhySciYAP9Y U39YfXqjGTvc7uo+k76RE54/124QT3222L6ulvOq3w/8BanZ4WLZ9vVIsP7Y 100/cKCdSu+I0lZt1//9jnbtq+WjJ/CrP3q6tK+LL6TfbNiTpQ1eem3jNr1R pTkjNp+K36yWD0/9C78v7x6WzW+Kqj/s64r28dH/oid3JyU/p4ulv7DWOszu RhsTptjUj26SGjdzu9k9/nr0QeXg1o4kz/9xfyHPDbgzwCk8UuRt3Ru2bF66 efVa36/bI7PKN2kpVNAsWV42S/AEs5yiI7N+qpqnZrnpt81TyCy3rkJWCSUu W0WEW+X0HBn1w39Wq+2yDxrEDW6QTjCImyOD3lXNy7L55YdmVYetkhy3KmFN OT1HVv1jtX7YLBdP9S9/rD4FzdIKNuvo7BNvlj5eUv9Rr1bth5dm+ViHjHI5 usStYrhVXtHxomq275cvYYs4vsqlSLGIHy/zf39e9vVzu+kuzBPhS11SilV0 vNb/qfrQtU3YIo0vcylTLNKn67yZby9YZBNWuEqxyB4v8b/U7rmrghYxnrC6 ExKUV3Q8R+2mWv3y52rz0G43IcOoVAmp3OCGeUVHht0/Vi/13ape3L+09/P1 Ijxp4fxJaqQmU0pKYCcJtL7bscfe15tNG5w1E3wEjSztSFVOyKDm+Ansnl0G vWzThcm6YlTKbJ1M1uNy1deby2bxMmWuErKoU3RkVrVYbNxO96FtX0Zs0ylT lvBU8l3iOtm9b+qn7araHJ63Urmd5n4P71mN97YaUQplZkdfpGh2+93Pm+Id 9puBD9mTOs89dbQb4G3z+3dP87Z5vP+4Xv3GK+5cbekHtuHPjktSSo5kIjv7 dev3Ok9FeMwvp3AY76C/aZv6/jW8k7ywPKThbGSHK83U9fH9e/d/ft5U8xe3 eOdd8IFSF0yzY1MlEvZvTtNx+mmCm0kVTjr+GMJHzEmoauok7cyfq83da+W2 uH1999r/8sd39+36MWShMMFSwohZPhJMnhBMp+rKA8WkO54ZEXikuOVa8nL8 mdrD90+VsKZUR4+WtpKdDrA7714cQZzAmQq1BMa8MaqUpG3IGyoF92xMY97s 4Ttb+EmOCLwrGZtVLTQXmgUMYca/v6Er07rH7+f11JQRvZwpYm6lhPS63a3y X2sc03vAh7Jk4NXQLV/zjHil3LHKt44CXgl3eHKby3GvDvgor8yoJf56reKh Baak1VJcs2SP31miVWxclbZuaTIe0CvdqUhpfk3vDh9a2SNqNbPWMhtaTuSm 1HeIR9Ue8FEPlH07AW9f/AnqQgnWklyW4eOnuC+q8OcRv0y6h9FGk0opSiO4 CgW9dHmZruw7DvjdLND4LLDRgBjD/PftQ0+ClOQq7pV0fcBHPQmMHSLidtSv wdIfbidZTsJyMXYySjnW7npKoZc8oab03nS6Z/f84mJirFTG35wY2RmcrabP Q56V8MNwo7WBMaE04zoQRK38C74rD/PbAKEojioWlgyJ0OpxwzF/efuK4v0A Uc8zo7dDxvrCWT88hy6ju9wydrQwSQf+o83ar8Hug1OcaBElHFrdoEcW9eHD KoV7azEmJXS3vbrjLe3m02sf7Le7neqIWWrsSJJiluXhJ1/uX8NI99mmftgu V4viuz8Vz3W1qDe7X4zp/S/bnKKH7/gHf8NHvb1K2f++Tds0/ml4v+w/BcYY HhMns9vSto/u02rVL9d18bDs/Xf/vQHddr2uDjPUHQ1RN912cH94pePnyg9x 9MbnbXaPQP2mGogJHOzo53u6vtoMxrg5+3Z4NbSfjeENUOhgNiZA7iA9indn ztnxpR/lv+vL1O4d2Fkt8G/ymS48gULjM87Y2Afp6OHdiiO3w1A8bvw38WgF LtGStZLixj9IA/YP9cIdoSPt34uPCfm+zLiR7igcbyGXVkhNKtLCg/iVMOzS 16jQcB4eXy27fcaYjFCjf2ayhNYalYZ0/FobxOMVlJZJKilysb2JxysQsetM mIj4qfi5c4ej0t8Jj1N/kI4e3pB0pxsZN/peGIy7Jo7EXRM/T9vVyv+U3LJ7 djum03pylNf9Lxlum6rvq7mX67YPQw0LA6pVd2nIdft+Z163L2Nv9xf8j/Qd 1ZmhQ3QmVTBTGrfF3A9zAgmLM08rGS9OpYTEPVFirDhJZSwibm0ZLy7dVpkD 4loJwsQlJq4wcQOJS8x2hUykK/VAmPy9H4GJEyauMXFgIl2tsgIRlyUiLgRk jDtCaUjcKkwcGd1GPnwu0b5VPr97SMAoHMOBMLBSuzQIyfNSgPKEyfMSlAft 4ag9EpQHVp6r6qVC5N0WkzFQnoNriCyZEsZYoXGMRnyRsoTm1qhSIbH2fVUg uXNjDPIseHkCx7cEymPj2xKpfZp0yUB5YNehSnf4YJi8lYi8JYbKG1AemH+3 W+WKgfIclBeYPFKTvbwpQXnQfkOQvCiR/T9xNlDFQgBkRncAQgEKBOgSAhhs hzAACAVIFKBAgOAoAHVaoE4L1GkBO61RgEEBFgQQOq2EzhKhTktwaWgGPUCC SewB8gBCARoFGBRgQYBAZ0kwFMBRADqthE4rodNK6LRKdFolOq0SnFaDLm+D Lm+D1QcPUChAowCDAsBIG/QBMugDZNAHyAg00ugTZwQaaYFGWqCRFmikBRpp g8bBoHEwaBwMGgcLOg2dJXcAhgI4ChAoAJxWi24dwO6NiG3fHANgHyQKUChA owCDAtDVytHAcTRwaAWyaAWyaAWyaAWyYAXi0sAAjgIECpAoAFveXIFl1wEw H0iBcSCFNREcwJQoAPLBCkkoANvo+kscmAbJVIkCoEhbg73McADwwOEA4CwZ 8DjgAQIFEAqQKEChAPDlhJGcK5sA0mWJgoQVlqEgzY3lKMjVJCi5+UsmBD0k HqGgjLtDKBihYYSBERZFWHiuLIMRHEYIGEEwAou54QyMoEcYGIFF0ArB0LeY rnKWArpI5EqnIijl7RAKRhjYF/+NIEyPO39DFWWHIBhhYIRFvbelMUzAKMY1 1INQ1ipZIitTi7Jk0Klrh9AoArkltkcIGEEoQsJzZWEdFppdzcpS4giLIqDa u0MA9YRLNnzPDlvxXHImInuTZyiCUaZUSqAooYRE+iBclcoQstHdI3AdYH3h RpZcIOe/PQKwTLizlufrRBFIRhJCkzDo5tihdAnPmb9baKVOQxkYZRW8FSdm beztoTMUeCeQuMtukZcETlCeUlOloEjAKOeVAeu1HO7/GAGj/DZPpaCIUJQk QcbAKGMtug9xR08pS/TenjT+NzpLjaNib5Eco4w7HROHUSRZaWGUAxFy+0z7 RWgNiBAMtMyhuJXMwCh/vQnWRW4xodFV/gttUG7330nX0Iu7HQKJzw6hDIyw KAK5k7pHCBgBzxVy03+PgOfKQJ7L6N3/57XlUP7JNDDK+i9qINYpVgqpYYRF EcgO3SOsRnt9DsXdiRGeM+VO8kIkodJ0WRhFShtolSrpNukaRaDf1nAoRdDV UI9w5UDDCIsiGIMRCkbAfjCDIjjmhyHoGz17hIYRBkZYEEHwCwJhXM4k5Ka4 85xH3rU+1mONpbj7OicoB0LzjKHSX2SzOMr/9hryrbSByl9jCAldtN0hkL6L RygHwry3nPzv+cEoxZjSLAFl0LzpUMYIJHu4paMpsvd2pMehFOfo95o8140l w2CY1m4uEmEShxlp0RO0/347MyWTOMzvLTgOGwh9cBiZyNsSpzDJS/TIPvA6 CM0lDiMt4dcAXJWlsbBvHuaSdYK24etkF2A7chhd3BXv683y8dPA67JnSipW y+ZlR4M00Mz4j7evvRv9mHN0T/Pft3218sQ137yxK/2hKO+L4ufnZVe4/1bF w/bpfvbTqvYaN/Vru+k967+3Z9lsP959fOz+oe26++5peT9v1/ez2WPlxxy4 W4u7gZBptWh+1xeef+bUhs3Gs6zZcvZfrtRQKStEAQA= --=-Ip+PszGGnUUUDUak632e-- --=-F4qlgzzCg7SkVZwVz0fo Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- iQIVAwUARJp7JaVg1VMiehFYAQLXDRAAiyQt7XxeWVOAZguDYHxVLsaYE0Fv+pGL 3EJ0qYEZ87OjonbfqPD8eMHI3fsuLC3qrJIaj5I3RZp8qqmvwPSDqxZHL4gT+Agf kIoSv03yLdBvIljD+CLC1XyM0P2QFJyERglxrGxsDmzBDERWea4ny27xmXSX6LYp qmnun3Hu6oeqNp1l9rXTC+cV38jNFpKPcUO0GjmeUOcrUakz9k+WjhVa6Cp6fVGN MTS9OlHxkRVRRHSmhQLooX9LLqhf8SUg/KvzXOaLSagLLa7zfjJLEtYBI/9r88Fn STpvBK9ppLPvJoAwDTXTtnOBsbQUtkiOw4WU8Jy15BRnyKglgn+kKNwvhwc+3ePu gwTaC9ZWTHlHt8M2j3PrM1B5aWt+DTbXqzXf6320FrbrIfhzyIYAEKVQcorURaOX Smi4KyTixmEKSuV136bkhWdbLsF3Dd/3rGuKSvuDQI/RuBuMqbyjcRpvzs9nfyQS 79vEaLHpwPEYgzp4LEJSeT9SPyT0N0J24vi8a/lcfqO2DLPb0oL4Bio1Da7Y+y4u 5Ko4oCFSiZzE6OulfDrKGVkfnBgqfT+0d46dX0U2TQH+vtpv5ikhHhHc9j2Ev0Lr lHx61EZ6WQdbDdrnZj3peOFhWuQcz1u9jv72Wt8oAs4KByv7g7vTj/OFk5SWwGf+ SjP1Xy1qoKE= =Y9AJ -----END PGP SIGNATURE----- --=-F4qlgzzCg7SkVZwVz0fo-- From owner-xfs@oss.sgi.com Thu Jun 22 06:45:40 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 22 Jun 2006 06:45:58 -0700 (PDT) Received: from omx1.americas.sgi.com (omx1.americas.sgi.com [198.149.16.13]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5MDjTDW004622 for ; Thu, 22 Jun 2006 06:45:40 -0700 Received: from omx2.sgi.com ([198.149.32.25]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id k5MDj5nx025382 for ; Thu, 22 Jun 2006 08:45:05 -0500 Received: from spindle.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id k5MG7fQa004111 for ; Thu, 22 Jun 2006 09:07:41 -0700 Received: from [127.0.0.1] (sshgate.corp.sgi.com [198.149.36.12]) by spindle.corp.sgi.com (SGI-8.12.5/8.12.9/generic_config-1.2) with ESMTP id k5MDiOnB42623262; Thu, 22 Jun 2006 06:44:24 -0700 (PDT) Message-ID: <449A9EB7.9010305@sgi.com> Date: Thu, 22 Jun 2006 08:44:23 -0500 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060516) MIME-Version: 1.0 To: Nathan Scott , xfs@oss.sgi.com Subject: Re: [PATCH] xfs: put xfs_trans_t on diet References: <20060622074051.GA7697@martell.zuzino.mipt.ru> <20060622192952.A1142412@wobbly.melbourne.sgi.com> In-Reply-To: <20060622192952.A1142412@wobbly.melbourne.sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8014 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: xfs Content-Length: 1132 Lines: 34 Nathan Scott wrote: > On Thu, Jun 22, 2006 at 11:40:51AM +0400, Alexey Dobriyan wrote: > >> * remove ->t_forw, ->t_back -- unused >> * ->t_ag_freeblks_delta, ->t_ag_flist_delta, ->t_ag_btree_delta >> are debugging aid -- wrap them in everyone's favourite way. >> > > Thanks Alexey, looks good - applied. > > -- > Nathan > > Then you'll probably also want this for the cvs tree: Index: xfs-GUT-clean/xfsidbg.c =================================================================== --- xfs-GUT-clean.orig/xfsidbg.c +++ xfs-GUT-clean/xfsidbg.c @@ -7412,9 +7412,11 @@ xfsidbg_xtp(xfs_trans_t *tp) tp->t_fdblocks_delta, tp->t_res_fdblocks_delta); kdb_printf("rt delta %ld res rt delta %ld\n", tp->t_frextents_delta, tp->t_res_frextents_delta); +#ifdef DEBUG kdb_printf("ag freeblks delta %ld ag flist delta %ld ag btree delta %ld\n", tp->t_ag_freeblks_delta, tp->t_ag_flist_delta, tp->t_ag_btree_delta); +#endif kdb_printf("dblocks delta %ld agcount delta %ld imaxpct delta %ld\n", tp->t_dblocks_delta, tp->t_agcount_delta, tp->t_imaxpct_delta); kdb_printf("rextsize delta %ld rbmblocks delta %ld\n", From owner-xfs@oss.sgi.com Thu Jun 22 06:51:56 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 22 Jun 2006 06:52:13 -0700 (PDT) Received: from omx1.americas.sgi.com (omx1.americas.sgi.com [198.149.16.13]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5MDpeDW006227 for ; Thu, 22 Jun 2006 06:51:56 -0700 Received: from internal-mail-relay1.corp.sgi.com (internal-mail-relay1.corp.sgi.com [198.149.32.52]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id k5MDpFnx026727 for ; Thu, 22 Jun 2006 08:51:15 -0500 Received: from omx2.sgi.com ([198.149.32.25]) by internal-mail-relay1.corp.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id k5MDoq8s15290229 for ; Thu, 22 Jun 2006 06:50:52 -0700 (PDT) Received: from spindle.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id k5MGDTkP005186 for ; Thu, 22 Jun 2006 09:13:29 -0700 Received: from [127.0.0.1] (sshgate.corp.sgi.com [198.149.36.12]) by spindle.corp.sgi.com (SGI-8.12.5/8.12.9/generic_config-1.2) with ESMTP id k5MDoHnB42614324; Thu, 22 Jun 2006 06:50:17 -0700 (PDT) Message-ID: <449AA019.9060804@sgi.com> Date: Thu, 22 Jun 2006 08:50:17 -0500 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060516) MIME-Version: 1.0 To: Nathan Scott CC: Alexey Dobriyan , xfs@oss.sgi.com Subject: Re: [PATCH] xfs: put xfs_trans_t on diet References: <20060622074051.GA7697@martell.zuzino.mipt.ru> <20060622192952.A1142412@wobbly.melbourne.sgi.com> In-Reply-To: <20060622192952.A1142412@wobbly.melbourne.sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8015 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: xfs Content-Length: 1631 Lines: 48 Nathan Scott wrote: > On Thu, Jun 22, 2006 at 11:40:51AM +0400, Alexey Dobriyan wrote: > >> * remove ->t_forw, ->t_back -- unused >> * ->t_ag_freeblks_delta, ->t_ag_flist_delta, ->t_ag_btree_delta >> are debugging aid -- wrap them in everyone's favourite way. >> > > Thanks Alexey, looks good - applied. > > -- > Nathan > > oops actually make that: (this only for trees w/ kdb of course, this file doesn't exist upstream) Index: xfs-GUT-clean/xfsidbg.c =================================================================== --- xfs-GUT-clean.orig/xfsidbg.c +++ xfs-GUT-clean/xfsidbg.c @@ -7394,8 +7394,7 @@ xfsidbg_xtp(xfs_trans_t *tp) kdb_printf("flags "); printflags(tp->t_flags, xtp_flags,"xtp"); kdb_printf("\n"); - kdb_printf("callback 0x%p forw 0x%p back 0x%p\n", - &tp->t_logcb, tp->t_forw, tp->t_back); + kdb_printf("callback 0x%p\n", &tp->t_logcb); kdb_printf("log res %d block res %d block res used %d\n", tp->t_log_res, tp->t_blk_res, tp->t_blk_res_used); kdb_printf("rt res %d rt res used %d\n", tp->t_rtx_res, @@ -7412,9 +7411,11 @@ xfsidbg_xtp(xfs_trans_t *tp) tp->t_fdblocks_delta, tp->t_res_fdblocks_delta); kdb_printf("rt delta %ld res rt delta %ld\n", tp->t_frextents_delta, tp->t_res_frextents_delta); +#ifdef DEBUG kdb_printf("ag freeblks delta %ld ag flist delta %ld ag btree delta %ld\n", tp->t_ag_freeblks_delta, tp->t_ag_flist_delta, tp->t_ag_btree_delta); +#endif kdb_printf("dblocks delta %ld agcount delta %ld imaxpct delta %ld\n", tp->t_dblocks_delta, tp->t_agcount_delta, tp->t_imaxpct_delta); kdb_printf("rextsize delta %ld rbmblocks delta %ld\n", From owner-xfs@oss.sgi.com Thu Jun 22 14:00:01 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 22 Jun 2006 14:00:32 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k5MKxmDW016049 for ; Thu, 22 Jun 2006 14:00:00 -0700 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id GAA18292; Fri, 23 Jun 2006 06:59:09 +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 k5MKx6gw1160401; Fri, 23 Jun 2006 06:59:07 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k5MKx3OX1160627; Fri, 23 Jun 2006 06:59:03 +1000 (EST) Date: Fri, 23 Jun 2006 06:59:03 +1000 From: Nathan Scott To: Eric Sandeen Cc: Alexey Dobriyan , xfs@oss.sgi.com Subject: Re: [PATCH] xfs: put xfs_trans_t on diet Message-ID: <20060623065903.B1158981@wobbly.melbourne.sgi.com> References: <20060622074051.GA7697@martell.zuzino.mipt.ru> <20060622192952.A1142412@wobbly.melbourne.sgi.com> <449AA019.9060804@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <449AA019.9060804@sgi.com>; from sandeen@sgi.com on Thu, Jun 22, 2006 at 08:50:17AM -0500 X-archive-position: 8017 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 362 Lines: 14 On Thu, Jun 22, 2006 at 08:50:17AM -0500, Eric Sandeen wrote: > oops actually make that: > > (this only for trees w/ kdb of course, this file doesn't exist upstream) Your first patch was right here - I fixed up the initial KDB issue along with Alexeys initial change, but only built a DEBUG kernel so overlooked the non-DEBUG piece. Thanks Eric. -- Nathan From owner-xfs@oss.sgi.com Thu Jun 22 16:34:27 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 22 Jun 2006 16:34:42 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k5MNYCDW009923 for ; Thu, 22 Jun 2006 16:34:26 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA22425 for ; Fri, 23 Jun 2006 09:33:45 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 68F1E4A58927; Fri, 23 Jun 2006 09:33:38 +1000 (EST) To: linux-xfs@oss.sgi.com Subject: TAKE 904196 - build fix Message-Id: <20060622233338.68F1E4A58927@chook.melbourne.sgi.com> Date: Fri, 23 Jun 2006 09:33:38 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 8018 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 444 Lines: 14 Build fix for non-debug builds with KDB enabled. Date: Fri Jun 23 09:33:11 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: sandeen The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:26321a xfsidbg.c - 1.304 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfsidbg.c.diff?r1=text&tr1=1.304&r2=text&tr2=1.303&f=h From owner-xfs@oss.sgi.com Thu Jun 22 16:57:29 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 22 Jun 2006 16:57:45 -0700 (PDT) Received: from mondschein.lichtvoll.de (ms2.lichtvoll.de [194.150.191.235] (may be forged)) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5MNvQDW014287 for ; Thu, 22 Jun 2006 16:57:26 -0700 Received: from localhost (dslb-084-056-075-135.pools.arcor-ip.net [84.56.75.135]) by mondschein.lichtvoll.de (Postfix) with ESMTP id 61124FA511 for ; Fri, 23 Jun 2006 01:55:42 +0200 (CEST) From: Martin Steigerwald To: linux-xfs@oss.sgi.com Subject: xfs crash with linux 2.6.15.7 and disabled write caches (long) User-Agent: KMail/1.9.1 MIME-Version: 1.0 Content-Disposition: inline Date: Fri, 23 Jun 2006 01:56:03 +0200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200606230156.04907.Martin@lichtvoll.de> X-archive-position: 8020 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Martin@lichtvoll.de Precedence: bulk X-list: xfs Content-Length: 105506 Lines: 2204 Hello, now I had a xfs crash with linux 2.6.15.7 and disabled write caches. I put together all debug information I could get, but now the text is too large for bugzilla@SGI (even when I cut out some larger cmd outputs and log snippets). Thus I will firstly report it here. Since its kernel 2.6.15.7 it might not be relevant for bug reporting anymore. If you want, I try to make a bug report out of it by seperating it to pieces... but not this night... I decided to try kernel 2.6.17 now sooner than I planned (its compiling right now). I will try it with disabled write caches first. Does that seem stable I will make a backup, enable write caches and see how it goes... Ok, here is the whole story of that fifth XFS crash in this year... Hello, now I had yet another XFS crash after those 3 crashes in one week with enabled write cache (kernel bug #6380 !!!) and once with kernel 2.6.15.7 with CONFIG_REGPARM and SWS2. Now I have kernel 2.6.15.7 with SWS2 again without CONFIG_REGPARM - 2.6.16 had non working sound after resume. This is the one kernel I had the least XFS crashes with (besides maybe even earlier kernels like 2.6.11). I am using a IBM ThinkPad T23 with 384 MB RAM. 128MB have been in there and I added an additional 256 Kingston IBM TP 23 RAM. I am using Debian Etch/Sid/Experimental (I think I have nothing from experimental installed at the moment tough). Since I heard about the write cache issues I have used XFS without writecache: ---------------------------------------------------------- deepdance:~ # cat /mnt/bak1/debian/etc/hdparm.conf [...] /dev/hda { mult_sect_io = 16 write_cache = off dma = on apm = 0 acoustic_management = 128 io32_support = 3 keep_settings_over_reset = on interrupt_unmask = on } ---------------------------------------------------------- But today even that most reliable kernel crashed down badly: I was using my KDE desktop like usual as suddenly IO stopped completely. I was able to switch between applications windows, but some windows where not refreshed anymore. I was able to enter a commend in KDE?s console, after return nothing happened. I pressed Ctrl-Alt-F1 to login to a tty, but after entering root as login name nothing happened. I waited a while - nothing happened. No harddisk access. The machine was strangely silent (fan was off as well). Then I switched it off by pressing the power button for long enough. I booted into SUSE 10.1 in order to examine the situation. I upgraded SUSE 10.0 to 10.1 this week. Since it uses ---------------------------------------------------------- deepdance:~ # cat /proc/version Linux version 2.6.16.13-4-default (geeko@buildhost) (gcc version 4.1.0 (SUSE Linux)) #1 Wed May 3 04:53:23 UTC 2006 ---------------------------------------------------------- I made an init script that disabled the write cache. Only strange thing is some bogus output of hdparm there: ---------------------------------------------------------- deepdance:~ # hdparm -W0 /dev/hda /dev/hda: setting drive write-caching to 0 (off) HDIO_SET_WCACHE(wcache) failed: Success ---------------------------------------------------------- This output is showed while booting SUSE which shows that my init script is being started. Already on boot it showed that my debian root partition cannot be mounted anymore. I tried it manually afterwards and got this in my /var/log/messages: ---------------------------------------------------------- Jun 22 21:37:08 deepdance kernel: XFS mounting filesystem hda5 Jun 22 21:37:08 deepdance kernel: Filesystem "hda5": XFS internal error xlog_clear_stale_blocks(2) at line 1237 of file fs/xfs/xfs_log_recover.c. Caller 0xd8cf021f Jun 22 21:37:08 deepdance kernel: [] xlog_find_tail+0x940/0xa53 [xfs] Jun 22 21:37:08 deepdance kernel: [] xlog_recover+0x15/0x20a [xfs] Jun 22 21:37:08 deepdance kernel: [] __alloc_pages+0x66/0x296 Jun 22 21:37:08 deepdance kernel: [] xlog_recover+0x15/0x20a [xfs] Jun 22 21:37:08 deepdance kernel: [] xfs_buf_get_empty+0x2a/0x33 [xfs] Jun 22 21:37:08 deepdance kernel: [] xfs_log_mount+0x445/0x488 [xfs] Jun 22 21:37:08 deepdance kernel: [] xfs_mountfs+0xa63/0xe66 [xfs] Jun 22 21:37:08 deepdance kernel: [] xfs_readsb+0x491/0x538 [xfs] Jun 22 21:37:08 deepdance kernel: [] xfs_setsize_buftarg_flags+0x2a/0x89 [xfs] Jun 22 21:37:08 deepdance kernel: [] kmem_alloc+0x5a/0xaf [xfs] Jun 22 21:37:08 deepdance kernel: [] xfs_mount+0x770/0x838 [xfs] Jun 22 21:37:08 deepdance kernel: [] xfs_mount+0x0/0x838 [xfs] Jun 22 21:37:08 deepdance kernel: [] vfs_mount+0x17/0x1a [xfs] Jun 22 21:37:09 deepdance kernel: [] linvfs_fill_super+0x76/0x1b2 [xfs] Jun 22 21:37:09 deepdance kernel: [] snprintf+0x1c/0x1f Jun 22 21:37:09 deepdance kernel: [] disk_name+0x56/0x60 Jun 22 21:37:09 deepdance kernel: [] get_sb_bdev+0xd5/0x11d Jun 22 21:37:09 deepdance kernel: [] __alloc_pages+0x66/0x296 Jun 22 21:37:09 deepdance kernel: [] linvfs_get_sb+0xe/0x11 [xfs] Jun 22 21:37:09 deepdance kernel: [] linvfs_fill_super+0x0/0x1b2 [xfs] Jun 22 21:37:09 deepdance kernel: [] do_kern_mount+0x86/0x12b Jun 22 21:37:09 deepdance kernel: [] do_mount+0x645/0x69f Jun 22 21:37:09 deepdance kernel: [] mntput_no_expire+0x11/0x59 Jun 22 21:37:09 deepdance kernel: [] link_path_walk+0xaf/0xb9 Jun 22 21:37:09 deepdance kernel: [] dput+0x31/0x122 Jun 22 21:37:09 deepdance kernel: [] mntput_no_expire+0x11/0x59 Jun 22 21:37:09 deepdance kernel: [] __handle_mm_fault+0x733/0x75b Jun 22 21:37:09 deepdance kernel: [] get_page_from_freelist+0x6f/0x29d Jun 22 21:37:09 deepdance kernel: [] do_page_fault+0x17b/0x53c Jun 22 21:37:09 deepdance kernel: [] copy_mount_options+0x26/0x109 Jun 22 21:37:09 deepdance kernel: [] sys_mount+0x64/0x97 Jun 22 21:37:09 deepdance kernel: [] syscall_call+0x7/0xb Jun 22 21:37:09 deepdance kernel: XFS: failed to locate log tail Jun 22 21:37:09 deepdance kernel: XFS: log mount/recovery failed: error 990 Jun 22 21:37:09 deepdance kernel: XFS: log mount failed Jun 22 21:37:10 deepdance kernel: XFS mounting filesystem hda5 Jun 22 21:37:10 deepdance kernel: Filesystem "hda5": XFS internal error xlog_clear_stale_blocks(2) at line 1237 of file fs/xfs/xfs_log_recover.c. Caller 0xd8cf021f Jun 22 21:37:10 deepdance kernel: [] xlog_find_tail+0x940/0xa53 [xfs] Jun 22 21:37:10 deepdance kernel: [] xlog_recover+0x15/0x20a [xfs] Jun 22 21:37:10 deepdance kernel: [] schedule+0x4c1/0x52e Jun 22 21:37:10 deepdance kernel: [] xlog_recover+0x15/0x20a [xfs] Jun 22 21:37:10 deepdance kernel: [] xfs_buf_get_empty+0x2a/0x33 [xfs] Jun 22 21:37:10 deepdance kernel: [] xfs_log_mount+0x445/0x488 [xfs] Jun 22 21:37:10 deepdance kernel: [] xfs_mountfs+0xa63/0xe66 [xfs] Jun 22 21:37:10 deepdance kernel: [] xfs_readsb+0x491/0x538 [xfs] Jun 22 21:37:10 deepdance kernel: [] xfs_setsize_buftarg_flags+0x2a/0x89 [xfs] Jun 22 21:37:10 deepdance kernel: [] kmem_alloc+0x5a/0xaf [xfs] Jun 22 21:37:10 deepdance kernel: [] xfs_mount+0x770/0x838 [xfs] Jun 22 21:37:10 deepdance kernel: [] xfs_mount+0x0/0x838 [xfs] Jun 22 21:37:10 deepdance kernel: [] vfs_mount+0x17/0x1a [xfs] Jun 22 21:37:10 deepdance kernel: [] linvfs_fill_super+0x76/0x1b2 [xfs] Jun 22 21:37:10 deepdance kernel: [] snprintf+0x1c/0x1f Jun 22 21:37:10 deepdance kernel: [] disk_name+0x56/0x60 Jun 22 21:37:10 deepdance kernel: [] get_sb_bdev+0xd5/0x11d Jun 22 21:37:10 deepdance kernel: [] __alloc_pages+0x66/0x296 Jun 22 21:37:10 deepdance kernel: [] linvfs_get_sb+0xe/0x11 [xfs] Jun 22 21:37:10 deepdance kernel: [] linvfs_fill_super+0x0/0x1b2 [xfs] Jun 22 21:37:10 deepdance kernel: [] do_kern_mount+0x86/0x12b Jun 22 21:37:10 deepdance kernel: [] do_mount+0x645/0x69f Jun 22 21:37:10 deepdance kernel: [] mntput_no_expire+0x11/0x59 Jun 22 21:37:10 deepdance kernel: [] link_path_walk+0xaf/0xb9 Jun 22 21:37:10 deepdance kernel: [] dput+0x31/0x122 Jun 22 21:37:10 deepdance kernel: [] mntput_no_expire+0x11/0x59 Jun 22 21:37:10 deepdance kernel: [] __handle_mm_fault+0x733/0x75b Jun 22 21:37:10 deepdance kernel: [] get_page_from_freelist+0x6f/0x29d Jun 22 21:37:10 deepdance kernel: [] do_page_fault+0x17b/0x53c Jun 22 21:37:10 deepdance kernel: [] copy_mount_options+0x26/0x109 Jun 22 21:37:10 deepdance kernel: [] sys_mount+0x64/0x97 Jun 22 21:37:10 deepdance kernel: [] syscall_call+0x7/0xb Jun 22 21:37:10 deepdance kernel: XFS: failed to locate log tail Jun 22 21:37:11 deepdance kernel: XFS: log mount/recovery failed: error 990 Jun 22 21:37:11 deepdance kernel: XFS: log mount failed ---------------------------------------------------------- I tried to check it deepdance:~ # xfs_check /dev/hda5 ERROR: The filesystem has valuable metadata changes in a log which needs to be replayed. Mount the filesystem to replay the log, and unmount it before re-running xfs_check. If you are unable to mount the filesystem, then use the xfs_repair -L option to destroy the log and attempt a repair. Note that destroying the log may cause corruption -- please attempt a mount of the filesystem before doing this. and my debian home partition /dev/hda8 which - lucky me - seems to be fine. Ok, so it seems I have to use "xfs_repair -L" again - which gave lots of output (I used xfsprogs 2.7.11 SUSE 10.1 binary package built from xfsprogs-2.7.11-18.src.rpm): ---------------------------------------------------------- deepdance:~ # xfs_repair -L /dev/hda5 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 - agno = 1 bad magic number 0xde85 on inode 4696704 bad version number 0x33 on inode 4696704 bad inode format in inode 4696704 bad magic number 0x5050 on inode 4696705 bad version number 0xffffffa5 on inode 4696705 bad inode format in inode 4696705 bad magic number 0xa7f3 on inode 4696706 bad version number 0xffffff9c on inode 4696706 bad (negative) size -3304726038600961885 on inode 4696706 bad magic number 0xb065 on inode 4696707 bad version number 0x24 on inode 4696707 bad (negative) size -9029802015504088694 on inode 4696707 bad magic number 0x34fb on inode 4696708 bad version number 0x2 on inode 4696708 bad inode format in inode 4696708 bad magic number 0xe9bb on inode 4696709 bad version number 0xffffffa6 on inode 4696709 bad (negative) size -7499079139829868559 on inode 4696709 bad magic number 0x5622 on inode 4696710 bad version number 0x57 on inode 4696710 bad inode format in inode 4696710 bad magic number 0xd2c1 on inode 4696711 bad version number 0x47 on inode 4696711 bad (negative) size -6164552464929284699 on inode 4696711 bad magic number 0x6ed9 on inode 4696712 bad version number 0x34 on inode 4696712 bad (negative) size -4938527813517352204 on inode 4696712 bad magic number 0x212e on inode 4696713 bad version number 0xffffffaa on inode 4696713 bad (negative) size -3317934298250532183 on inode 4696713 bad magic number 0x2988 on inode 4696714 bad version number 0x6b on inode 4696714 bad inode format in inode 4696714 bad magic number 0x9344 on inode 4696715 bad version number 0xfffffff2 on inode 4696715 bad (negative) size -3087606033020300044 on inode 4696715 bad magic number 0x701 on inode 4696716 bad version number 0xffffffd2 on inode 4696716 bad inode format in inode 4696716 bad magic number 0xc2ff on inode 4696717 bad version number 0xffffffdc on inode 4696717 bad (negative) size -2638220079859594521 on inode 4696717 bad magic number 0xf9f4 on inode 4696718 bad version number 0xffffffe9 on inode 4696718 bad inode format in inode 4696718 bad magic number 0x8f95 on inode 4696719 bad version number 0x69 on inode 4696719 bad inode format in inode 4696719 bad magic number 0xa3e0 on inode 4696720 bad version number 0x74 on inode 4696720 bad (negative) size -1450867304098734345 on inode 4696720 bad magic number 0xd311 on inode 4696721 bad version number 0x12 on inode 4696721 bad inode format in inode 4696721 bad magic number 0x9f4a on inode 4696722 bad version number 0x24 on inode 4696722 bad inode format in inode 4696722 bad magic number 0x9ebd on inode 4696723 bad version number 0x68 on inode 4696723 bad (negative) size -7993413996180667903 on inode 4696723 bad magic number 0xf713 on inode 4696724 bad version number 0xffffffe0 on inode 4696724 bad inode format in inode 4696724 bad magic number 0xaf97 on inode 4696725 bad version number 0xffffffc5 on inode 4696725 bad (negative) size -3508248750937534140 on inode 4696725 bad magic number 0x5509 on inode 4696726 bad version number 0xffffffa2 on inode 4696726 bad inode format in inode 4696726 bad magic number 0x388c on inode 4696727 bad version number 0x5b on inode 4696727 bad (negative) size -3079579163917115419 on inode 4696727 bad magic number 0xfd51 on inode 4696728 bad version number 0x0 on inode 4696728 bad (negative) size -1699996839080917064 on inode 4696728 bad magic number 0xbd1d on inode 4696729 bad version number 0xffffffd0 on inode 4696729 bad (negative) size -3890821399028612504 on inode 4696729 bad magic number 0xab6 on inode 4696730 bad version number 0xffffffa7 on inode 4696730 bad inode format in inode 4696730 bad magic number 0xa93 on inode 4696731 bad version number 0x1f on inode 4696731 bad inode format in inode 4696731 bad magic number 0x28e0 on inode 4696732 bad version number 0x4b on inode 4696732 bad inode format in inode 4696732 bad magic number 0xe2de on inode 4696733 bad version number 0xffffff95 on inode 4696733 bad inode format in inode 4696733 bad magic number 0x4606 on inode 4696734 bad version number 0x59 on inode 4696734 bad (negative) size -4974402844452071491 on inode 4696734 bad magic number 0xfd48 on inode 4696735 bad version number 0xf on inode 4696735 bad (negative) size -1154894484287551647 on inode 4696735 bad magic number 0xde85 on inode 4696704, resetting magic number bad version number 0x33 on inode 4696704, resetting version number bad inode format in inode 4696704 cleared inode 4696704 bad magic number 0x5050 on inode 4696705, resetting magic number bad version number 0xffffffa5 on inode 4696705, resetting version number bad inode format in inode 4696705 cleared inode 4696705 bad magic number 0xa7f3 on inode 4696706, resetting magic number bad version number 0xffffff9c on inode 4696706, resetting version number bad (negative) size -3304726038600961885 on inode 4696706 cleared inode 4696706 bad magic number 0xb065 on inode 4696707, resetting magic number bad version number 0x24 on inode 4696707, resetting version number bad (negative) size -9029802015504088694 on inode 4696707 cleared inode 4696707 bad magic number 0x34fb on inode 4696708, resetting magic number bad version number 0x2 on inode 4696708, resetting version number bad inode format in inode 4696708 cleared inode 4696708 bad magic number 0xe9bb on inode 4696709, resetting magic number bad version number 0xffffffa6 on inode 4696709, resetting version number bad (negative) size -7499079139829868559 on inode 4696709 cleared inode 4696709 bad magic number 0x5622 on inode 4696710, resetting magic number bad version number 0x57 on inode 4696710, resetting version number bad inode format in inode 4696710 cleared inode 4696710 bad magic number 0xd2c1 on inode 4696711, resetting magic number bad version number 0x47 on inode 4696711, resetting version number bad (negative) size -6164552464929284699 on inode 4696711 cleared inode 4696711 bad magic number 0x6ed9 on inode 4696712, resetting magic number bad version number 0x34 on inode 4696712, resetting version number bad (negative) size -4938527813517352204 on inode 4696712 cleared inode 4696712 bad magic number 0x212e on inode 4696713, resetting magic number bad version number 0xffffffaa on inode 4696713, resetting version number bad (negative) size -3317934298250532183 on inode 4696713 cleared inode 4696713 bad magic number 0x2988 on inode 4696714, resetting magic number bad version number 0x6b on inode 4696714, resetting version number bad inode format in inode 4696714 cleared inode 4696714 bad magic number 0x9344 on inode 4696715, resetting magic number bad version number 0xfffffff2 on inode 4696715, resetting version number bad (negative) size -3087606033020300044 on inode 4696715 cleared inode 4696715 bad magic number 0x701 on inode 4696716, resetting magic number bad version number 0xffffffd2 on inode 4696716, resetting version number bad inode format in inode 4696716 cleared inode 4696716 bad magic number 0xc2ff on inode 4696717, resetting magic number bad version number 0xffffffdc on inode 4696717, resetting version number bad (negative) size -2638220079859594521 on inode 4696717 cleared inode 4696717 bad magic number 0xf9f4 on inode 4696718, resetting magic number bad version number 0xffffffe9 on inode 4696718, resetting version number bad inode format in inode 4696718 cleared inode 4696718 bad magic number 0x8f95 on inode 4696719, resetting magic number bad version number 0x69 on inode 4696719, resetting version number bad inode format in inode 4696719 cleared inode 4696719 bad magic number 0xa3e0 on inode 4696720, resetting magic number bad version number 0x74 on inode 4696720, resetting version number bad (negative) size -1450867304098734345 on inode 4696720 cleared inode 4696720 bad magic number 0xd311 on inode 4696721, resetting magic number bad version number 0x12 on inode 4696721, resetting version number bad inode format in inode 4696721 cleared inode 4696721 bad magic number 0x9f4a on inode 4696722, resetting magic number bad version number 0x24 on inode 4696722, resetting version number bad inode format in inode 4696722 cleared inode 4696722 bad magic number 0x9ebd on inode 4696723, resetting magic number bad version number 0x68 on inode 4696723, resetting version number bad (negative) size -7993413996180667903 on inode 4696723 cleared inode 4696723 bad magic number 0xf713 on inode 4696724, resetting magic number bad version number 0xffffffe0 on inode 4696724, resetting version number bad inode format in inode 4696724 cleared inode 4696724 bad magic number 0xaf97 on inode 4696725, resetting magic number bad version number 0xffffffc5 on inode 4696725, resetting version number bad (negative) size -3508248750937534140 on inode 4696725 cleared inode 4696725 bad magic number 0x5509 on inode 4696726, resetting magic number bad version number 0xffffffa2 on inode 4696726, resetting version number bad inode format in inode 4696726 cleared inode 4696726 bad magic number 0x388c on inode 4696727, resetting magic number bad version number 0x5b on inode 4696727, resetting version number bad (negative) size -3079579163917115419 on inode 4696727 cleared inode 4696727 bad magic number 0xfd51 on inode 4696728, resetting magic number bad version number 0x0 on inode 4696728, resetting version number bad (negative) size -1699996839080917064 on inode 4696728 cleared inode 4696728 bad magic number 0xbd1d on inode 4696729, resetting magic number bad version number 0xffffffd0 on inode 4696729, resetting version number bad (negative) size -3890821399028612504 on inode 4696729 cleared inode 4696729 bad magic number 0xab6 on inode 4696730, resetting magic number bad version number 0xffffffa7 on inode 4696730, resetting version number bad inode format in inode 4696730 cleared inode 4696730 bad magic number 0xa93 on inode 4696731, resetting magic number bad version number 0x1f on inode 4696731, resetting version number bad inode format in inode 4696731 cleared inode 4696731 bad magic number 0x28e0 on inode 4696732, resetting magic number bad version number 0x4b on inode 4696732, resetting version number bad inode format in inode 4696732 cleared inode 4696732 bad magic number 0xe2de on inode 4696733, resetting magic number bad version number 0xffffff95 on inode 4696733, resetting version number bad inode format in inode 4696733 cleared inode 4696733 bad magic number 0x4606 on inode 4696734, resetting magic number bad version number 0x59 on inode 4696734, resetting version number bad (negative) size -4974402844452071491 on inode 4696734 cleared inode 4696734 bad magic number 0xfd48 on inode 4696735, resetting magic number bad version number 0xf on inode 4696735, resetting version number bad (negative) size -1154894484287551647 on inode 4696735 cleared inode 4696735 bad magic number 0xb13c on inode 4696736 bad version number 0x6a on inode 4696736 bad (negative) size -6067877356172665065 on inode 4696736 bad magic number 0xa387 on inode 4696737 bad version number 0x63 on inode 4696737 bad inode format in inode 4696737 bad magic number 0x36a6 on inode 4696738 bad version number 0x5c on inode 4696738 bad inode format in inode 4696738 bad magic number 0x437b on inode 4696739 bad version number 0x3c on inode 4696739 bad inode format in inode 4696739 bad magic number 0x4b0c on inode 4696740 bad version number 0x53 on inode 4696740 bad inode format in inode 4696740 bad magic number 0x8f5e on inode 4696741 bad version number 0x1a on inode 4696741 bad (negative) size -3560507284276483071 on inode 4696741 bad magic number 0x691 on inode 4696742 bad version number 0xb on inode 4696742 bad (negative) size -7699644483040772577 on inode 4696742 bad magic number 0x1f4f on inode 4696743 bad version number 0x32 on inode 4696743 bad (negative) size -3795684244588147964 on inode 4696743 bad magic number 0x7db3 on inode 4696744 bad version number 0xffffffb2 on inode 4696744 bad inode format in inode 4696744 bad magic number 0x938c on inode 4696745 bad version number 0xffffffa7 on inode 4696745 bad inode format in inode 4696745 bad magic number 0x37d on inode 4696746 bad version number 0x6e on inode 4696746 bad (negative) size -1446506858424628510 on inode 4696746 bad magic number 0x533a on inode 4696747 bad version number 0xffffffa3 on inode 4696747 bad (negative) size -1886515669733000777 on inode 4696747 bad magic number 0x8d65 on inode 4696748 bad version number 0x7f on inode 4696748 bad inode format in inode 4696748 bad magic number 0x27 on inode 4696749 bad version number 0xffffff80 on inode 4696749 bad (negative) size -4744216041070046827 on inode 4696749 bad magic number 0x16f4 on inode 4696750 bad version number 0x37 on inode 4696750 bad inode format in inode 4696750 bad magic number 0xe955 on inode 4696751 bad version number 0xffffff9e on inode 4696751 bad (negative) size -1550740798515273378 on inode 4696751 bad magic number 0x38dc on inode 4696752 bad version number 0xffffffba on inode 4696752 bad (negative) size -2340396726233627969 on inode 4696752 bad magic number 0x8117 on inode 4696753 bad version number 0x71 on inode 4696753 bad inode format in inode 4696753 bad magic number 0x751f on inode 4696754 bad version number 0xffffff9d on inode 4696754 bad (negative) size -6226648631829528984 on inode 4696754 bad magic number 0x7e on inode 4696755 bad version number 0xb on inode 4696755 bad inode format in inode 4696755 bad magic number 0xcda9 on inode 4696756 bad version number 0xfffffff1 on inode 4696756 bad (negative) size -823713179867214811 on inode 4696756 bad magic number 0x3e94 on inode 4696757 bad version number 0x2a on inode 4696757 bad inode format in inode 4696757 bad magic number 0xbaab on inode 4696758 bad version number 0x19 on inode 4696758 bad inode format in inode 4696758 bad magic number 0x62c0 on inode 4696759 bad version number 0x54 on inode 4696759 bad (negative) size -371148556173109535 on inode 4696759 bad magic number 0xd6e6 on inode 4696760 bad version number 0xffffffcc on inode 4696760 bad inode format in inode 4696760 bad magic number 0x19f9 on inode 4696761 bad version number 0xfffffff6 on inode 4696761 bad (negative) size -7304896733083342809 on inode 4696761 bad magic number 0xfafa on inode 4696762 bad version number 0x11 on inode 4696762 bad inode format in inode 4696762 bad magic number 0xd3dc on inode 4696763 bad version number 0x26 on inode 4696763 bad (negative) size -3799282727092362742 on inode 4696763 bad magic number 0x3210 on inode 4696764 bad version number 0xffffffe7 on inode 4696764 bad inode format in inode 4696764 bad magic number 0x58f8 on inode 4696765 bad version number 0x7a on inode 4696765 bad inode format in inode 4696765 bad magic number 0xc48 on inode 4696766 bad version number 0xffffff8d on inode 4696766 bad (negative) size -6450620229579682741 on inode 4696766 bad magic number 0xabf8 on inode 4696767 bad version number 0xffffffee on inode 4696767 bad inode format in inode 4696767 bad magic number 0xf4fd on inode 4696768 bad version number 0x1f on inode 4696768 bad (negative) size -5722478984897843614 on inode 4696768 bad magic number 0xc580 on inode 4696769 bad version number 0xffffffb4 on inode 4696769 bad inode format in inode 4696769 bad magic number 0x1b51 on inode 4696770 bad version number 0x35 on inode 4696770 bad inode format in inode 4696770 bad magic number 0x5d24 on inode 4696771 bad version number 0x1f on inode 4696771 bad (negative) size -5683859702116249421 on inode 4696771 bad magic number 0x14f5 on inode 4696772 bad version number 0x4d on inode 4696772 bad (negative) size -311643612940354232 on inode 4696772 bad magic number 0x8ea5 on inode 4696773 bad version number 0xffffffe7 on inode 4696773 bad inode format in inode 4696773 bad magic number 0x80b1 on inode 4696774 bad version number 0x65 on inode 4696774 bad (negative) size -3790813618268958614 on inode 4696774 bad magic number 0x7208 on inode 4696775 bad version number 0xfffffff0 on inode 4696775 bad (negative) size -3406109375177770919 on inode 4696775 bad magic number 0x59cd on inode 4696776 bad version number 0xffffffe2 on inode 4696776 bad inode format in inode 4696776 bad magic number 0xd7bd on inode 4696777 bad version number 0x75 on inode 4696777 bad (negative) size -1189253915011459876 on inode 4696777 bad magic number 0x6171 on inode 4696778 bad version number 0x2e on inode 4696778 bad (negative) size -6808579463096945452 on inode 4696778 bad magic number 0x7af6 on inode 4696779 bad version number 0xffffff95 on inode 4696779 bad (negative) size -1046546913787507572 on inode 4696779 bad magic number 0x8881 on inode 4696780 bad version number 0x3e on inode 4696780 bad (negative) size -767704932530482497 on inode 4696780 bad magic number 0xaa62 on inode 4696781 bad version number 0x1d on inode 4696781 bad (negative) size -5061776730388747229 on inode 4696781 bad magic number 0x7e7d on inode 4696782 bad version number 0xffffffaa on inode 4696782 bad inode format in inode 4696782 bad magic number 0x9229 on inode 4696783 bad version number 0x5c on inode 4696783 bad inode format in inode 4696783 bad magic number 0x3ed4 on inode 4696784 bad version number 0x1f on inode 4696784 bad inode format in inode 4696784 bad magic number 0xd78d on inode 4696785 bad version number 0xffffffe4 on inode 4696785 bad inode format in inode 4696785 bad magic number 0x5ffc on inode 4696786 bad version number 0x48 on inode 4696786 bad inode format in inode 4696786 bad magic number 0xfa74 on inode 4696787 bad version number 0x13 on inode 4696787 bad inode format in inode 4696787 bad magic number 0xa687 on inode 4696788 bad version number 0xffffffe8 on inode 4696788 bad (negative) size -7507601401752548810 on inode 4696788 bad magic number 0x50e5 on inode 4696789 bad version number 0x0 on inode 4696789 bad (negative) size -656492944168048008 on inode 4696789 bad magic number 0x510a on inode 4696790 bad version number 0xffffffec on inode 4696790 bad inode format in inode 4696790 bad magic number 0xf75e on inode 4696791 bad version number 0xfffffffd on inode 4696791 bad (negative) size -2901734608197468161 on inode 4696791 bad magic number 0x73c on inode 4696792 bad version number 0x58 on inode 4696792 bad inode format in inode 4696792 bad magic number 0xbb78 on inode 4696793 bad version number 0x23 on inode 4696793 bad (negative) size -6708369051675684128 on inode 4696793 bad magic number 0x7b28 on inode 4696794 bad version number 0xffffffea on inode 4696794 bad (negative) size -1009334496659050217 on inode 4696794 bad magic number 0x4d69 on inode 4696795 bad version number 0xffffff82 on inode 4696795 bad (negative) size -2049145665214535079 on inode 4696795 bad magic number 0x6c82 on inode 4696796 bad version number 0x5a on inode 4696796 bad (negative) size -957831111172492491 on inode 4696796 bad magic number 0x47b4 on inode 4696797 bad version number 0x31 on inode 4696797 bad (negative) size -7899234391782770088 on inode 4696797 bad magic number 0x4034 on inode 4696798 bad version number 0xffffffaa on inode 4696798 bad (negative) size -8778317362636542198 on inode 4696798 bad magic number 0xd5b on inode 4696799 bad version number 0xffffffd3 on inode 4696799 bad inode format in inode 4696799 bad magic number 0xc756 on inode 4696832 bad version number 0x69 on inode 4696832 bad (negative) size -8487689457889539543 on inode 4696832 bad magic number 0xfb73 on inode 4696833 bad version number 0xffffff87 on inode 4696833 bad (negative) size -2435633300700215500 on inode 4696833 bad magic number 0xb62d on inode 4696834 bad version number 0x2f on inode 4696834 bad inode format in inode 4696834 bad magic number 0xb34d on inode 4696835 bad version number 0x52 on inode 4696835 bad (negative) size -6889481188966490062 on inode 4696835 bad magic number 0xb2d9 on inode 4696836 bad version number 0x37 on inode 4696836 bad inode format in inode 4696836 bad magic number 0xbdd7 on inode 4696837 bad version number 0xffffffaf on inode 4696837 bad inode format in inode 4696837 bad magic number 0xa151 on inode 4696838 bad version number 0x1a on inode 4696838 bad inode format in inode 4696838 bad magic number 0x7dbd on inode 4696839 bad version number 0xfffffff8 on inode 4696839 bad (negative) size -6560157850196179200 on inode 4696839 bad magic number 0x97d3 on inode 4696840 bad version number 0x33 on inode 4696840 bad (negative) size -7787105825959941577 on inode 4696840 bad magic number 0xd7ae on inode 4696841 bad version number 0xb on inode 4696841 bad inode format in inode 4696841 bad magic number 0xc1a9 on inode 4696842 bad version number 0x53 on inode 4696842 bad (negative) size -2958217973308288664 on inode 4696842 bad magic number 0xc2a1 on inode 4696843 bad version number 0xffffff91 on inode 4696843 bad (negative) size -7376067000055535784 on inode 4696843 bad magic number 0x7bac on inode 4696844 bad version number 0x33 on inode 4696844 bad (negative) size -3706553989636156139 on inode 4696844 bad magic number 0x6452 on inode 4696845 bad version number 0x19 on inode 4696845 bad inode format in inode 4696845 bad magic number 0x5cf1 on inode 4696846 bad version number 0xffffffc2 on inode 4696846 bad (negative) size -7733755121575070301 on inode 4696846 bad magic number 0x8261 on inode 4696847 bad version number 0x53 on inode 4696847 bad inode format in inode 4696847 bad magic number 0x48e5 on inode 4696848 bad version number 0xf on inode 4696848 bad inode format in inode 4696848 bad magic number 0x2c25 on inode 4696849 bad version number 0x1d on inode 4696849 bad inode format in inode 4696849 bad magic number 0x5ef6 on inode 4696850 bad version number 0x6 on inode 4696850 bad inode format in inode 4696850 bad magic number 0x2ba3 on inode 4696851 bad version number 0x2a on inode 4696851 bad (negative) size -5684323540944629986 on inode 4696851 bad magic number 0x232 on inode 4696852 bad version number 0x6f on inode 4696852 bad (negative) size -71952616007791776 on inode 4696852 bad magic number 0x7690 on inode 4696853 bad version number 0x12 on inode 4696853 bad (negative) size -4823993805931009936 on inode 4696853 bad magic number 0xbd64 on inode 4696854 bad version number 0x2b on inode 4696854 bad (negative) size -6582397123660611335 on inode 4696854 bad magic number 0x3ea7 on inode 4696855 bad version number 0x7e on inode 4696855 bad (negative) size -8124608134174992440 on inode 4696855 bad magic number 0x5a9f on inode 4696856 bad version number 0x53 on inode 4696856 bad inode format in inode 4696856 bad magic number 0x1169 on inode 4696857 bad version number 0x71 on inode 4696857 bad inode format in inode 4696857 bad magic number 0x2bfe on inode 4696858 bad version number 0xffffffe9 on inode 4696858 bad (negative) size -6531012913831338205 on inode 4696858 bad magic number 0xeadc on inode 4696859 bad version number 0xffffff83 on inode 4696859 bad inode format in inode 4696859 bad magic number 0x3847 on inode 4696860 bad version number 0x52 on inode 4696860 bad (negative) size -5339233611634993493 on inode 4696860 bad magic number 0x6654 on inode 4696861 bad version number 0x18 on inode 4696861 bad (negative) size -6007487599903059365 on inode 4696861 bad magic number 0x368f on inode 4696862 bad version number 0x53 on inode 4696862 bad (negative) size -198511522378221350 on inode 4696862 bad magic number 0xfb6f on inode 4696863 bad version number 0xffffffb6 on inode 4696863 bad (negative) size -8042657965090581671 on inode 4696863 bad magic number 0x7556 on inode 4696864 bad version number 0xffffffc4 on inode 4696864 bad inode format in inode 4696864 bad magic number 0x7fcd on inode 4696865 bad version number 0x71 on inode 4696865 bad (negative) size -5633020866773444807 on inode 4696865 bad magic number 0xcd93 on inode 4696866 bad version number 0x1e on inode 4696866 bad inode format in inode 4696866 bad magic number 0xcdc5 on inode 4696867 bad version number 0xffffff80 on inode 4696867 bad inode format in inode 4696867 bad magic number 0x2891 on inode 4696868 bad version number 0x45 on inode 4696868 bad (negative) size -3545994611041057744 on inode 4696868 bad magic number 0xd7fd on inode 4696869 bad version number 0xffffffed on inode 4696869 bad inode format in inode 4696869 bad magic number 0x324c on inode 4696870 bad version number 0xffffffa4 on inode 4696870 bad inode format in inode 4696870 bad magic number 0x68 on inode 4696871 bad version number 0xffffffaa on inode 4696871 bad inode format in inode 4696871 bad magic number 0x6ded on inode 4696872 bad version number 0x2e on inode 4696872 bad inode format in inode 4696872 bad magic number 0x2484 on inode 4696873 bad version number 0xffffffa6 on inode 4696873 bad (negative) size -5883074587242442542 on inode 4696873 bad magic number 0x6463 on inode 4696874 bad version number 0x32 on inode 4696874 bad inode format in inode 4696874 bad magic number 0x2685 on inode 4696875 bad version number 0x1e on inode 4696875 bad inode format in inode 4696875 bad magic number 0x4c88 on inode 4696876 bad version number 0xffffffc5 on inode 4696876 bad (negative) size -2260471454543785599 on inode 4696876 bad magic number 0x85f8 on inode 4696877 bad version number 0x49 on inode 4696877 bad inode format in inode 4696877 bad magic number 0xe47d on inode 4696878 bad version number 0xffffffff on inode 4696878 bad inode format in inode 4696878 bad magic number 0x5401 on inode 4696879 bad version number 0xffffff93 on inode 4696879 bad (negative) size -8260358628900342415 on inode 4696879 bad magic number 0x32b on inode 4696880 bad version number 0xffffffec on inode 4696880 bad inode format in inode 4696880 bad magic number 0x59e1 on inode 4696881 bad version number 0x43 on inode 4696881 bad (negative) size -423399967766959799 on inode 4696881 bad magic number 0xfdab on inode 4696882 bad version number 0xffffffb4 on inode 4696882 bad (negative) size -6389879617698923924 on inode 4696882 bad magic number 0xabae on inode 4696883 bad version number 0x62 on inode 4696883 bad inode format in inode 4696883 bad magic number 0x40ab on inode 4696884 bad version number 0xffffffe1 on inode 4696884 bad (negative) size -3103283135321250110 on inode 4696884 bad magic number 0x284 on inode 4696885 bad version number 0xffffff90 on inode 4696885 bad (negative) size -1048583899049117828 on inode 4696885 bad magic number 0x63e4 on inode 4696886 bad version number 0x22 on inode 4696886 bad (negative) size -6237535588733841922 on inode 4696886 bad magic number 0xe22a on inode 4696887 bad version number 0x79 on inode 4696887 bad inode format in inode 4696887 bad magic number 0x6d3a on inode 4696888 bad version number 0xffffffa5 on inode 4696888 bad (negative) size -7782518352701664186 on inode 4696888 bad magic number 0x47fe on inode 4696889 bad version number 0xffffff81 on inode 4696889 bad (negative) size -7670873397812622770 on inode 4696889 bad magic number 0xb716 on inode 4696890 bad version number 0xb on inode 4696890 bad (negative) size -1977202013709318114 on inode 4696890 bad magic number 0xbf9a on inode 4696891 bad version number 0xffffff99 on inode 4696891 bad inode format in inode 4696891 bad magic number 0x23c6 on inode 4696892 bad version number 0x5b on inode 4696892 bad (negative) size -581318567581208715 on inode 4696892 bad magic number 0x994d on inode 4696893 bad version number 0xffffffc7 on inode 4696893 bad (negative) size -7970079813221372720 on inode 4696893 bad magic number 0x3049 on inode 4696894 bad version number 0x57 on inode 4696894 bad (negative) size -2106523635837440192 on inode 4696894 bad magic number 0xf on inode 4696895 bad version number 0x25 on inode 4696895 bad (negative) size -651442907403340256 on inode 4696895 bad magic number 0x5b44 on inode 4741440 bad version number 0x6b on inode 4741440 bad inode format in inode 4741440 bad magic number 0x0 on inode 4741441 bad version number 0x0 on inode 4741441 bad magic number 0x0 on inode 4741442 bad version number 0x0 on inode 4741442 bad magic number 0x0 on inode 4741443 bad version number 0x0 on inode 4741443 bad magic number 0x0 on inode 4741444 bad version number 0x0 on inode 4741444 bad magic number 0x0 on inode 4741445 bad version number 0x0 on inode 4741445 bad magic number 0x0 on inode 4741446 bad version number 0x0 on inode 4741446 bad magic number 0x0 on inode 4741447 bad version number 0x0 on inode 4741447 bad magic number 0x0 on inode 4741448 bad version number 0x0 on inode 4741448 bad magic number 0x0 on inode 4741449 bad version number 0x0 on inode 4741449 bad magic number 0x0 on inode 4741450 bad version number 0x0 on inode 4741450 bad magic number 0x0 on inode 4741451 bad version number 0x0 on inode 4741451 bad magic number 0x0 on inode 4741452 bad version number 0x0 on inode 4741452 bad magic number 0x0 on inode 4741453 bad version number 0x0 on inode 4741453 bad magic number 0x0 on inode 4741454 bad version number 0x0 on inode 4741454 bad magic number 0x0 on inode 4741455 bad version number 0x0 on inode 4741455 bad magic number 0xe52f on inode 4741456 bad version number 0x51 on inode 4741456 bad (negative) size -5054255942920167661 on inode 4741456 bad magic number 0x7c72 on inode 4741457 bad version number 0x2a on inode 4741457 bad inode format in inode 4741457 bad magic number 0x9e15 on inode 4741458 bad version number 0x67 on inode 4741458 bad inode format in inode 4741458 bad magic number 0xbf3e on inode 4741459 bad version number 0xffffffac on inode 4741459 bad (negative) size -5687184310110077733 on inode 4741459 bad magic number 0x4d0 on inode 4741460 bad version number 0xffffffd4 on inode 4741460 bad (negative) size -1781620305818635922 on inode 4741460 bad magic number 0xd3da on inode 4741461 bad version number 0x6d on inode 4741461 bad inode format in inode 4741461 bad magic number 0x2800 on inode 4741462 bad version number 0xffffff8c on inode 4741462 bad (negative) size -9037296471894110488 on inode 4741462 bad magic number 0x16d3 on inode 4741463 bad version number 0x2b on inode 4741463 bad inode format in inode 4741463 bad magic number 0x365a on inode 4741464 bad version number 0x5c on inode 4741464 bad inode format in inode 4741464 bad magic number 0xb2fc on inode 4741465 bad version number 0xffffffd2 on inode 4741465 bad (negative) size -1929400731465064095 on inode 4741465 bad magic number 0x9eb8 on inode 4741466 bad version number 0x38 on inode 4741466 bad inode format in inode 4741466 bad magic number 0x5874 on inode 4741467 bad version number 0x55 on inode 4741467 bad (negative) size -7671672394197834114 on inode 4741467 bad magic number 0x7d46 on inode 4741468 bad version number 0xd on inode 4741468 bad (negative) size -6903090978179456443 on inode 4741468 bad magic number 0x71b6 on inode 4741469 bad version number 0xffffffaa on inode 4741469 bad (negative) size -623813037168375523 on inode 4741469 bad magic number 0xdc89 on inode 4741470 bad version number 0xffffffa4 on inode 4741470 bad (negative) size -6061616813969730972 on inode 4741470 bad magic number 0xf05 on inode 4741471 bad version number 0x40 on inode 4741471 bad (negative) size -798100747247050899 on inode 4741471 bad magic number 0x5b44 on inode 4741440, resetting magic number bad version number 0x6b on inode 4741440, resetting version number bad inode format in inode 4741440 cleared inode 4741440 bad magic number 0x0 on inode 4741441, resetting magic number bad version number 0x0 on inode 4741441, resetting version number imap claims a free inode 4741441 is in use, correcting imap and clearing inode cleared inode 4741441 bad magic number 0x0 on inode 4741442, resetting magic number bad version number 0x0 on inode 4741442, resetting version number imap claims a free inode 4741442 is in use, correcting imap and clearing inode cleared inode 4741442 bad magic number 0x0 on inode 4741443, resetting magic number bad version number 0x0 on inode 4741443, resetting version number imap claims a free inode 4741443 is in use, correcting imap and clearing inode cleared inode 4741443 bad magic number 0x0 on inode 4741444, resetting magic number bad version number 0x0 on inode 4741444, resetting version number imap claims a free inode 4741444 is in use, correcting imap and clearing inode cleared inode 4741444 bad magic number 0x0 on inode 4741445, resetting magic number bad version number 0x0 on inode 4741445, resetting version number imap claims a free inode 4741445 is in use, correcting imap and clearing inode cleared inode 4741445 bad magic number 0x0 on inode 4741446, resetting magic number bad version number 0x0 on inode 4741446, resetting version number imap claims a free inode 4741446 is in use, correcting imap and clearing inode cleared inode 4741446 bad magic number 0x0 on inode 4741447, resetting magic number bad version number 0x0 on inode 4741447, resetting version number imap claims a free inode 4741447 is in use, correcting imap and clearing inode cleared inode 4741447 bad magic number 0x0 on inode 4741448, resetting magic number bad version number 0x0 on inode 4741448, resetting version number imap claims a free inode 4741448 is in use, correcting imap and clearing inode cleared inode 4741448 bad magic number 0x0 on inode 4741449, resetting magic number bad version number 0x0 on inode 4741449, resetting version number imap claims a free inode 4741449 is in use, correcting imap and clearing inode cleared inode 4741449 bad magic number 0x0 on inode 4741450, resetting magic number bad version number 0x0 on inode 4741450, resetting version number imap claims a free inode 4741450 is in use, correcting imap and clearing inode cleared inode 4741450 bad magic number 0x0 on inode 4741451, resetting magic number bad version number 0x0 on inode 4741451, resetting version number imap claims a free inode 4741451 is in use, correcting imap and clearing inode cleared inode 4741451 bad magic number 0x0 on inode 4741452, resetting magic number bad version number 0x0 on inode 4741452, resetting version number imap claims a free inode 4741452 is in use, correcting imap and clearing inode cleared inode 4741452 bad magic number 0x0 on inode 4741453, resetting magic number bad version number 0x0 on inode 4741453, resetting version number imap claims a free inode 4741453 is in use, correcting imap and clearing inode cleared inode 4741453 bad magic number 0x0 on inode 4741454, resetting magic number bad version number 0x0 on inode 4741454, resetting version number imap claims a free inode 4741454 is in use, correcting imap and clearing inode cleared inode 4741454 bad magic number 0x0 on inode 4741455, resetting magic number bad version number 0x0 on inode 4741455, resetting version number imap claims a free inode 4741455 is in use, correcting imap and clearing inode cleared inode 4741455 bad magic number 0xe52f on inode 4741456, resetting magic number bad version number 0x51 on inode 4741456, resetting version number bad (negative) size -5054255942920167661 on inode 4741456 cleared inode 4741456 bad magic number 0x7c72 on inode 4741457, resetting magic number bad version number 0x2a on inode 4741457, resetting version number bad inode format in inode 4741457 cleared inode 4741457 bad magic number 0x9e15 on inode 4741458, resetting magic number bad version number 0x67 on inode 4741458, resetting version number bad inode format in inode 4741458 cleared inode 4741458 bad magic number 0xbf3e on inode 4741459, resetting magic number bad version number 0xffffffac on inode 4741459, resetting version number bad (negative) size -5687184310110077733 on inode 4741459 cleared inode 4741459 bad magic number 0x4d0 on inode 4741460, resetting magic number bad version number 0xffffffd4 on inode 4741460, resetting version number bad (negative) size -1781620305818635922 on inode 4741460 cleared inode 4741460 bad magic number 0xd3da on inode 4741461, resetting magic number bad version number 0x6d on inode 4741461, resetting version number bad inode format in inode 4741461 cleared inode 4741461 bad magic number 0x2800 on inode 4741462, resetting magic number bad version number 0xffffff8c on inode 4741462, resetting version number bad (negative) size -9037296471894110488 on inode 4741462 cleared inode 4741462 bad magic number 0x16d3 on inode 4741463, resetting magic number bad version number 0x2b on inode 4741463, resetting version number bad inode format in inode 4741463 cleared inode 4741463 bad magic number 0x365a on inode 4741464, resetting magic number bad version number 0x5c on inode 4741464, resetting version number bad inode format in inode 4741464 cleared inode 4741464 bad magic number 0xb2fc on inode 4741465, resetting magic number bad version number 0xffffffd2 on inode 4741465, resetting version number bad (negative) size -1929400731465064095 on inode 4741465 cleared inode 4741465 bad magic number 0x9eb8 on inode 4741466, resetting magic number bad version number 0x38 on inode 4741466, resetting version number bad inode format in inode 4741466 cleared inode 4741466 bad magic number 0x5874 on inode 4741467, resetting magic number bad version number 0x55 on inode 4741467, resetting version number bad (negative) size -7671672394197834114 on inode 4741467 cleared inode 4741467 bad magic number 0x7d46 on inode 4741468, resetting magic number bad version number 0xd on inode 4741468, resetting version number bad (negative) size -6903090978179456443 on inode 4741468 cleared inode 4741468 bad magic number 0x71b6 on inode 4741469, resetting magic number bad version number 0xffffffaa on inode 4741469, resetting version number bad (negative) size -623813037168375523 on inode 4741469 cleared inode 4741469 bad magic number 0xdc89 on inode 4741470, resetting magic number bad version number 0xffffffa4 on inode 4741470, resetting version number bad (negative) size -6061616813969730972 on inode 4741470 cleared inode 4741470 bad magic number 0xf05 on inode 4741471, resetting magic number bad version number 0x40 on inode 4741471, resetting version number bad (negative) size -798100747247050899 on inode 4741471 cleared inode 4741471 - 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 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - clear lost+found (if it exists) ... - check for inodes claiming duplicate blocks... - agno = 0 entry "ER" at block 0 offset 48 in directory inode 403216 references non-existent inode 4696835 clearing inode number in entry at offset 48... entry "cgi-examples" at block 0 offset 48 in directory inode 411522 references non-existent inode 4696880 clearing inode number in entry at offset 48... entry "examples" at block 0 offset 48 in directory inode 411564 references non-existent inode 4696891 clearing inode number in entry at offset 48... - agno = 1 entry "X-Debian-Apps-System-kde_system_guard.desktop" at block 2 offset 2968 in directory inode 4206355 references free inode 4696704 clearing inode number in entry at offset 2968... entry "X-Debian-Apps-System-kde_system_guard_-_process_table.desktop" at block 2 offset 3024 in directory inode 4206355 references free inode 4696705 clearing inode number in entry at offset 3024... entry "X-Debian-Apps-System-kde_sysv-init_editor.desktop" at block 2 offset 3096 in directory inode 4206355 references free inode 4696706 clearing inode number in entry at offset 3096... entry "X-Debian-Apps-System-kde_task_scheduler.desktop" at block 2 offset 3160 in directory inode 4206355 references free inode 4696707 clearing inode number in entry at offset 3160... entry "X-Debian-Apps-System-kde_user_manager.desktop" at block 2 offset 3224 in directory inode 4206355 references free inode 4696708 clearing inode number in entry at offset 3224... entry "X-Debian-Apps-System-kdiskfree.desktop" at block 2 offset 3280 in directory inode 4206355 references free inode 4696709 clearing inode number in entry at offset 3280... entry "X-Debian-Apps-System-keditbookmarks.desktop" at block 2 offset 3336 in directory inode 4206355 references free inode 4696710 clearing inode number in entry at offset 3336... entry "X-Debian-Apps-System-kfind.desktop" at block 2 offset 3392 in directory inode 4206355 references free inode 4696711 clearing inode number in entry at offset 3392... entry "X-Debian-Apps-System-kfloppy.desktop" at block 2 offset 3440 in directory inode 4206355 references free inode 4696712 clearing inode number in entry at offset 3440... entry "X-Debian-Apps-System-kicker.desktop" at block 2 offset 3488 in directory inode 4206355 references free inode 4696713 clearing inode number in entry at offset 3488... entry "X-Debian-Apps-System-kinfocenter.desktop" at block 2 offset 3536 in directory inode 4206355 references free inode 4696714 clearing inode number in entry at offset 3536... entry "X-Debian-Apps-System-kjobviewer.desktop" at block 2 offset 3592 in directory inode 4206355 references free inode 4696715 clearing inode number in entry at offset 3592... entry "X-Debian-Apps-System-kmenuedit.desktop" at block 2 offset 3648 in directory inode 4206355 references free inode 4696716 clearing inode number in entry at offset 3648... entry "X-Debian-Apps-System-konqueror.desktop" at block 2 offset 3704 in directory inode 4206355 references free inode 4696717 clearing inode number in entry at offset 3704... entry "X-Debian-Apps-System-kpersonalizer.desktop" at block 2 offset 3760 in directory inode 4206355 references free inode 4696718 clearing inode number in entry at offset 3760... entry "X-Debian-Apps-System-kprinter.desktop" at block 2 offset 3816 in directory inode 4206355 references free inode 4696719 clearing inode number in entry at offset 3816... entry "X-Debian-Apps-System-kwikdisk.desktop" at block 2 offset 3864 in directory inode 4206355 references free inode 4696720 clearing inode number in entry at offset 3864... entry "X-Debian-Apps-System-Language-Environment-belarusian_environment.desktop" at block 2 offset 3912 in directory inode 4206355 references free inode 4696721 clearing inode number in entry at offset 3912... entry "X-Debian-Apps-System-Language-Environment-bulgarian_environment.desktop" at block 2 offset 4000 in directory inode 4206355 references free inode 4696722 clearing inode number in entry at offset 4000... entry "X-Debian-Apps-System-Language-Environment-catalan_environment.desktop" at block 3 offset 16 in directory inode 4206355 references free inode 4696723 clearing inode number in entry at offset 16... entry "X-Debian-Apps-System-Language-Environment-danish_environment.desktop" at block 3 offset 96 in directory inode 4206355 references free inode 4696724 clearing inode number in entry at offset 96... entry "X-Debian-Apps-System-Language-Environment-french_environment.desktop" at block 3 offset 176 in directory inode 4206355 references free inode 4696725 clearing inode number in entry at offset 176... entry "X-Debian-Apps-System-Language-Environment-german_environment.desktop" at block 3 offset 256 in directory inode 4206355 references free inode 4696726 clearing inode number in entry at offset 256... entry "X-Debian-Apps-System-Language-Environment-japanese_environment.desktop" at block 3 offset 336 in directory inode 4206355 references free inode 4696727 clearing inode number in entry at offset 336... entry "X-Debian-Apps-System-Language-Environment-korean_environment.desktop" at block 3 offset 424 in directory inode 4206355 references free inode 4696728 clearing inode number in entry at offset 424... entry "X-Debian-Apps-System-Language-Environment-lithuanian_environment.desktop" at block 3 offset 504 in directory inode 4206355 references free inode 4696729 clearing inode number in entry at offset 504... entry "X-Debian-Apps-System-Language-Environment-macedonian_environment.desktop" at block 3 offset 592 in directory inode 4206355 references free inode 4696730 clearing inode number in entry at offset 592... entry "X-Debian-Apps-System-Language-Environment-native_language_environment.desktop" at block 3 offset 680 in directory inode 4206355 references free inode 4696731 clearing inode number in entry at offset 680... entry "X-Debian-Apps-System-Language-Environment-native_language_environment_-_remove.desktop" at block 3 offset 768 in directory inode 4206355 references free inode 4696732 clearing inode number in entry at offset 768... entry "X-Debian-Apps-System-Language-Environment-polish_environment.desktop" at block 3 offset 872 in directory inode 4206355 references free inode 4696733 clearing inode number in entry at offset 872... entry "X-Debian-Apps-System-Language-Environment-russian_environment.desktop" at block 3 offset 952 in directory inode 4206355 references free inode 4696734 clearing inode number in entry at offset 952... entry "X-Debian-Apps-System-Language-Environment-serbian_environment.desktop" at block 3 offset 1032 in directory inode 4206355 references free inode 4696735 clearing inode number in entry at offset 1032... entry "X-Debian-Apps-System-Language-Environment-spanish_environment.desktop" at block 3 offset 1112 in directory inode 4206355 references non-existent inode 4696747 clearing inode number in entry at offset 1112... entry "X-Debian-Apps-System-Language-Environment-thai_environment.desktop" at block 3 offset 1192 in directory inode 4206355 references non-existent inode 4696748 clearing inode number in entry at offset 1192... entry "X-Debian-Apps-System-Language-Environment-turkish_environment.desktop" at block 3 offset 1272 in directory inode 4206355 references non-existent inode 4696749 clearing inode number in entry at offset 1272... entry "X-Debian-Apps-System-Language-Environment-ukrainian_environment.desktop" at block 3 offset 1352 in directory inode 4206355 references non-existent inode 4696750 clearing inode number in entry at offset 1352... entry "X-Debian-Apps-System-nautilus.desktop" at block 3 offset 1440 in directory inode 4206355 references non-existent inode 4696751 clearing inode number in entry at offset 1440... entry "X-Debian-Apps-System-print_notification_icon.desktop" at block 3 offset 1488 in directory inode 4206355 references non-existent inode 4696752 clearing inode number in entry at offset 1488... entry "X-Debian-Apps-System-pstree.desktop" at block 3 offset 1552 in directory inode 4206355 references non-existent inode 4696753 clearing inode number in entry at offset 1552... entry "X-Debian-Apps-System-qt3_assistant.desktop" at block 3 offset 1600 in directory inode 4206355 references non-existent inode 4696754 clearing inode number in entry at offset 1600... entry "X-Debian-Apps-System-reportbug.desktop" at block 3 offset 1656 in directory inode 4206355 references non-existent inode 4696755 clearing inode number in entry at offset 1656... entry "X-Debian-Apps-System-run_as_different_user_(gksu).desktop" at block 3 offset 1712 in directory inode 4206355 references non-existent inode 4696756 clearing inode number in entry at offset 1712... entry "X-Debian-Apps-System-sun_java_5.0_plugin_control_panel.desktop" at block 3 offset 1784 in directory inode 4206355 references non-existent inode 4696757 clearing inode number in entry at offset 1784... entry "X-Debian-Apps-System-sun_java_5.0_policy_tool.desktop" at block 3 offset 1864 in directory inode 4206355 references non-existent inode 4696758 clearing inode number in entry at offset 1864... entry "X-Debian-Apps-System-task_selector.desktop" at block 3 offset 1928 in directory inode 4206355 references non-existent inode 4696759 clearing inode number in entry at offset 1928... entry "X-Debian-Apps-System-texconfig.desktop" at block 3 offset 1984 in directory inode 4206355 references non-existent inode 4696760 clearing inode number in entry at offset 1984... entry "X-Debian-Apps-System-top.desktop" at block 3 offset 2040 in directory inode 4206355 references non-existent inode 4696761 clearing inode number in entry at offset 2040... entry "X-Debian-Apps-System-x-terminal_as_root_(gksu).desktop" at block 3 offset 2088 in directory inode 4206355 references non-existent inode 4696762 clearing inode number in entry at offset 2088... entry "X-Debian-Apps-Technical-debtags-edit.desktop" at block 3 offset 2160 in directory inode 4206355 references non-existent inode 4696763 clearing inode number in entry at offset 2160... entry "X-Debian-Apps-Text-freemind.desktop" at block 3 offset 2216 in directory inode 4206355 references non-existent inode 4696764 clearing inode number in entry at offset 2216... entry "X-Debian-Apps-Text-gnome_dictionary.desktop" at block 3 offset 2264 in directory inode 4206355 references non-existent inode 4696765 clearing inode number in entry at offset 2264... entry "X-Debian-Apps-Text-info_browser.desktop" at block 3 offset 2320 in directory inode 4206355 references non-existent inode 4696766 clearing inode number in entry at offset 2320... entry "X-Debian-Apps-Text-kbabel.desktop" at block 3 offset 2376 in directory inode 4206355 references non-existent inode 4696767 clearing inode number in entry at offset 2376... entry "X-Debian-Apps-Text-kbabel_catalog_manager.desktop" at block 3 offset 2424 in directory inode 4206355 references non-existent inode 4696768 clearing inode number in entry at offset 2424... entry "X-Debian-Apps-Text-kbabel_dictionary.desktop" at block 3 offset 2488 in directory inode 4206355 references non-existent inode 4696769 clearing inode number in entry at offset 2488... entry "X-Debian-Apps-Text-kxsldbg.desktop" at block 3 offset 2544 in directory inode 4206355 references non-existent inode 4696770 clearing inode number in entry at offset 2544... entry "X-Debian-Apps-Text-xdialog.desktop" at block 3 offset 2592 in directory inode 4206355 references non-existent inode 4696771 clearing inode number in entry at offset 2592... entry "X-Debian-Apps-Tools-ark.desktop" at block 3 offset 2640 in directory inode 4206355 references non-existent inode 4696772 clearing inode number in entry at offset 2640... entry "X-Debian-Apps-Tools-driconf.desktop" at block 3 offset 2688 in directory inode 4206355 references non-existent inode 4696773 clearing inode number in entry at offset 2688... entry "X-Debian-Apps-Tools-dvdisaster.desktop" at block 3 offset 2736 in directory inode 4206355 references non-existent inode 4696774 clearing inode number in entry at offset 2736... entry "X-Debian-Apps-Tools-file-roller.desktop" at block 3 offset 2792 in directory inode 4206355 references non-existent inode 4696775 clearing inode number in entry at offset 2792... entry "X-Debian-Apps-Tools-gnomepgp.desktop" at block 3 offset 2848 in directory inode 4206355 references non-existent inode 4696776 clearing inode number in entry at offset 2848... entry "X-Debian-Apps-Tools-gnome_screenshot_tool.desktop" at block 3 offset 2896 in directory inode 4206355 references non-existent inode 4696777 clearing inode number in entry at offset 2896... entry "X-Debian-Apps-Tools-gnome_search_tool.desktop" at block 3 offset 2960 in directory inode 4206355 references non-existent inode 4696778 clearing inode number in entry at offset 2960... entry "X-Debian-Apps-Tools-gnucash.desktop" at block 3 offset 3016 in directory inode 4206355 references non-existent inode 4696779 clearing inode number in entry at offset 3016... entry "X-Debian-Apps-Tools-k3b.desktop" at block 3 offset 3064 in directory inode 4206355 references non-existent inode 4696780 clearing inode number in entry at offset 3064... entry "X-Debian-Apps-Tools-kaddressbook.desktop" at block 3 offset 3112 in directory inode 4206355 references non-existent inode 4696781 clearing inode number in entry at offset 3112... entry "X-Debian-Apps-Tools-kalarm.desktop" at block 3 offset 3168 in directory inode 4206355 references non-existent inode 4696782 clearing inode number in entry at offset 3168... entry "X-Debian-Apps-Tools-kandy.desktop" at block 3 offset 3216 in directory inode 4206355 references non-existent inode 4696783 clearing inode number in entry at offset 3216... entry "X-Debian-Apps-Tools-karm.desktop" at block 3 offset 3264 in directory inode 4206355 references non-existent inode 4696784 clearing inode number in entry at offset 3264... entry "X-Debian-Apps-Tools-kcharselect.desktop" at block 3 offset 3312 in directory inode 4206355 references non-existent inode 4696785 clearing inode number in entry at offset 3312... entry "X-Debian-Apps-Tools-kdissert.desktop" at block 3 offset 3368 in directory inode 4206355 references non-existent inode 4696786 clearing inode number in entry at offset 3368... entry "X-Debian-Apps-Tools-kgpg.desktop" at block 3 offset 3416 in directory inode 4206355 references non-existent inode 4696787 clearing inode number in entry at offset 3416... entry "X-Debian-Apps-Tools-khexedit.desktop" at block 3 offset 3464 in directory inode 4206355 references non-existent inode 4696788 clearing inode number in entry at offset 3464... entry "X-Debian-Apps-Tools-kitchensync.desktop" at block 3 offset 3512 in directory inode 4206355 references non-existent inode 4696789 clearing inode number in entry at offset 3512... entry "X-Debian-Apps-Tools-kivio.desktop" at block 3 offset 3568 in directory inode 4206355 references non-existent inode 4696790 clearing inode number in entry at offset 3568... entry "X-Debian-Apps-Tools-kjots.desktop" at block 3 offset 3616 in directory inode 4206355 references non-existent inode 4696791 clearing inode number in entry at offset 3616... entry "X-Debian-Apps-Tools-klipper.desktop" at block 3 offset 3664 in directory inode 4206355 references non-existent inode 4696792 clearing inode number in entry at offset 3664... entry "X-Debian-Apps-Tools-kmag.desktop" at block 3 offset 3712 in directory inode 4206355 references non-existent inode 4696793 clearing inode number in entry at offset 3712... entry "X-Debian-Apps-Tools-kmousetool.desktop" at block 3 offset 3760 in directory inode 4206355 references non-existent inode 4696794 clearing inode number in entry at offset 3760... entry "X-Debian-Apps-Tools-kmouth.desktop" at block 3 offset 3816 in directory inode 4206355 references non-existent inode 4696795 clearing inode number in entry at offset 3816... entry "X-Debian-Apps-Tools-kmymoney.desktop" at block 3 offset 3864 in directory inode 4206355 references non-existent inode 4696796 clearing inode number in entry at offset 3864... entry "X-Debian-Apps-Tools-knotes.desktop" at block 3 offset 3912 in directory inode 4206355 references non-existent inode 4696797 clearing inode number in entry at offset 3912... entry "X-Debian-Apps-Tools-koffice_workspace.desktop" at block 3 offset 3960 in directory inode 4206355 references non-existent inode 4696798 clearing inode number in entry at offset 3960... entry "X-Debian-Apps-Tools-kommander_editor.desktop" at block 3 offset 4016 in directory inode 4206355 references non-existent inode 4696799 clearing inode number in entry at offset 4016... entry "X-Debian-Apps-Tools-kontact.desktop" at block 4 offset 16 in directory inode 4206355 references non-existent inode 4696837 clearing inode number in entry at offset 16... entry "X-Debian-Apps-Tools-korganizer.desktop" at block 4 offset 64 in directory inode 4206355 references non-existent inode 4696841 clearing inode number in entry at offset 64... entry "X-Debian-Apps-Tools-kpager.desktop" at block 4 offset 120 in directory inode 4206355 references non-existent inode 4696845 clearing inode number in entry at offset 120... entry "X-Debian-Apps-Tools-kpalmdoc.desktop" at block 4 offset 168 in directory inode 4206355 references non-existent inode 4696846 clearing inode number in entry at offset 168... entry "X-Debian-Apps-Tools-kpilot.desktop" at block 4 offset 216 in directory inode 4206355 references non-existent inode 4696847 clearing inode number in entry at offset 216... entry "X-Debian-Apps-Tools-kpresenter.desktop" at block 4 offset 264 in directory inode 4206355 references non-existent inode 4696848 clearing inode number in entry at offset 264... entry "X-Debian-Apps-Tools-kregexpeditor.desktop" at block 4 offset 320 in directory inode 4206355 references non-existent inode 4696849 clearing inode number in entry at offset 320... entry "X-Debian-Apps-Tools-ksayit.desktop" at block 4 offset 376 in directory inode 4206355 references non-existent inode 4696850 clearing inode number in entry at offset 376... entry "X-Debian-Apps-Tools-ksync.desktop" at block 4 offset 424 in directory inode 4206355 references non-existent inode 4696851 clearing inode number in entry at offset 424... entry "X-Debian-Apps-Tools-kthesaurus.desktop" at block 4 offset 472 in directory inode 4206355 references non-existent inode 4696852 clearing inode number in entry at offset 472... entry "X-Debian-Apps-Tools-ktimer.desktop" at block 4 offset 528 in directory inode 4206355 references non-existent inode 4696853 clearing inode number in entry at offset 528... entry "X-Debian-Apps-Tools-ktip.desktop" at block 4 offset 576 in directory inode 4206355 references non-existent inode 4696854 clearing inode number in entry at offset 576... entry "X-Debian-Apps-Tools-ktnef.desktop" at block 4 offset 624 in directory inode 4206355 references non-existent inode 4696855 clearing inode number in entry at offset 624... entry "X-Debian-Apps-Tools-kugar.desktop" at block 4 offset 672 in directory inode 4206355 references non-existent inode 4696856 clearing inode number in entry at offset 672... entry "X-Debian-Apps-Tools-kugar_designer.desktop" at block 4 offset 720 in directory inode 4206355 references non-existent inode 4696857 clearing inode number in entry at offset 720... entry "X-Debian-Apps-Tools-kwatchgnupg.desktop" at block 4 offset 776 in directory inode 4206355 references non-existent inode 4696858 clearing inode number in entry at offset 776... entry "X-Debian-Apps-Tools-mc.desktop" at block 4 offset 832 in directory inode 4206355 references non-existent inode 4696859 clearing inode number in entry at offset 832... entry "X-Debian-Apps-Tools-movixmaker-2.desktop" at block 4 offset 880 in directory inode 4206355 references non-existent inode 4696860 clearing inode number in entry at offset 880... entry "X-Debian-Apps-Tools-mtink.desktop" at block 4 offset 936 in directory inode 4206355 references non-existent inode 4696861 clearing inode number in entry at offset 936... entry "X-Debian-Apps-Tools-mtinkc.desktop" at block 4 offset 984 in directory inode 4206355 references non-existent inode 4696862 clearing inode number in entry at offset 984... entry "X-Debian-Apps-Tools-multisynk.desktop" at block 4 offset 1032 in directory inode 4206355 references non-existent inode 4696863 clearing inode number in entry at offset 1032... entry "X-Debian-Apps-Tools-planner.desktop" at block 4 offset 1080 in directory inode 4206355 references non-existent inode 4696864 clearing inode number in entry at offset 1080... entry "X-Debian-Apps-Tools-superkaramba.desktop" at block 4 offset 1128 in directory inode 4206355 references non-existent inode 4696865 clearing inode number in entry at offset 1128... entry "X-Debian-Apps-Tools-texfind.desktop" at block 4 offset 1184 in directory inode 4206355 references non-existent inode 4696866 clearing inode number in entry at offset 1184... entry "X-Debian-Apps-Tools-the_gnu_privacy_assistant.desktop" at block 4 offset 1232 in directory inode 4206355 references non-existent inode 4696867 clearing inode number in entry at offset 1232... entry "X-Debian-Apps-Tools-unison_2.13.16_(gtk).desktop" at block 4 offset 1296 in directory inode 4206355 references non-existent inode 4696868 clearing inode number in entry at offset 1296... entry "X-Debian-Apps-Tools-wordnet.desktop" at block 4 offset 1360 in directory inode 4206355 references non-existent inode 4696869 clearing inode number in entry at offset 1360... entry "X-Debian-Apps-Tools-worker.desktop" at block 4 offset 1408 in directory inode 4206355 references non-existent inode 4696870 clearing inode number in entry at offset 1408... entry "X-Debian-Apps-Viewers-digikam.desktop" at block 4 offset 1456 in directory inode 4206355 references non-existent inode 4696871 clearing inode number in entry at offset 1456... entry "X-Debian-Apps-Viewers-evince.desktop" at block 4 offset 1504 in directory inode 4206355 references non-existent inode 4696872 clearing inode number in entry at offset 1504... entry "X-Debian-Apps-Viewers-eye_of_gnome.desktop" at block 4 offset 1552 in directory inode 4206355 references non-existent inode 4696873 clearing inode number in entry at offset 1552... entry "X-Debian-Apps-Viewers-gnome_ghostscript_viewer.desktop" at block 4 offset 1608 in directory inode 4206355 references non-existent inode 4696874 clearing inode number in entry at offset 1608... entry "X-Debian-Apps-Viewers-gwenview.desktop" at block 4 offset 1680 in directory inode 4206355 references non-existent inode 4696875 clearing inode number in entry at offset 1680... entry "X-Debian-Apps-Viewers-imagemagick.desktop" at block 4 offset 1736 in directory inode 4206355 references non-existent inode 4696876 clearing inode number in entry at offset 1736... entry "X-Debian-Apps-Viewers-kdvi.desktop" at block 4 offset 1792 in directory inode 4206355 references non-existent inode 4696881 clearing inode number in entry at offset 1792... entry "X-Debian-Apps-Viewers-kghostview.desktop" at block 4 offset 1840 in directory inode 4206355 references free inode 4741440 clearing inode number in entry at offset 1840... entry "X-Debian-Apps-Viewers-kview.desktop" at block 4 offset 1896 in directory inode 4206355 references free inode 4741441 clearing inode number in entry at offset 1896... entry "X-Debian-Apps-Viewers-mplayer.desktop" at block 4 offset 1944 in directory inode 4206355 references free inode 4741442 clearing inode number in entry at offset 1944... entry "kdeprint_uploadsmb.png" in shortform directory 4659682 references non-existent inode 4696843 junking entry "kdeprint_uploadsmb.png" in directory inode 4659682 entry "fdl-notice.docbook" at block 0 offset 88 in directory inode 4665754 references non-existent inode 4696844 clearing inode number in entry at offset 88... entry "gpl-notice.docbook" at block 0 offset 160 in directory inode 4665754 references non-existent inode 4696877 clearing inode number in entry at offset 160... entry "help-menu.docbook" at block 0 offset 232 in directory inode 4665754 references non-existent inode 4696889 clearing inode number in entry at offset 232... entry "install-compile.docbook" at block 0 offset 312 in directory inode 4665754 references non-existent inode 4696890 clearing inode number in entry at offset 312... entry "install-intro.docbook" at block 0 offset 392 in directory inode 4665754 references non-existent inode 4696893 clearing inode number in entry at offset 392... entry "gs.defoma" in shortform directory 4678175 references non-existent inode 4696838 junking entry "gs.defoma" in directory inode 4678175 entry "libwmf0.2-7.defoma" in shortform directory 4678175 references non-existent inode 4696839 junking entry "libwmf0.2-7.defoma" in directory inode 4678175 entry "AUTHORS" in shortform directory 4725602 references free inode 4741458 junking entry "AUTHORS" in directory inode 4725602 entry "NEWS.gz" in shortform directory 4725602 references free inode 4741459 junking entry "NEWS.gz" in directory inode 4725602 entry "README" in shortform directory 4725602 references free inode 4741460 junking entry "README" in directory inode 4725602 entry "changelog.Debian.gz" in shortform directory 4725602 references free inode 4741461 junking entry "changelog.Debian.gz" in directory inode 4725602 entry "changelog.gz" in shortform directory 4725602 references free inode 4741462 junking entry "changelog.gz" in directory inode 4725602 entry "copyright" in shortform directory 4725602 references free inode 4741463 junking entry "copyright" in directory inode 4725602 entry "AUTHORS" in shortform directory 4725610 references free inode 4741465 junking entry "AUTHORS" in directory inode 4725610 entry "TODO" in shortform directory 4725610 references free inode 4741466 junking entry "TODO" in directory inode 4725610 entry "changelog.Debian.gz" in shortform directory 4725610 references free inode 4741467 junking entry "changelog.Debian.gz" in directory inode 4725610 entry "changelog.gz" in shortform directory 4725610 references free inode 4741468 junking entry "changelog.gz" in directory inode 4725610 entry "copyright" in shortform directory 4725610 references free inode 4741469 junking entry "copyright" in directory inode 4725610 entry "AUTHORS" in shortform directory 4725613 references free inode 4741470 junking entry "AUTHORS" in directory inode 4725613 entry "changelog.gz" in shortform directory 4725613 references free inode 4741471 junking entry "changelog.gz" in directory inode 4725613 entry "BINDINGS" at block 0 offset 80 in directory inode 4725620 references non-existent inode 4696832 clearing inode number in entry at offset 80... entry "MANUAL.gz" at block 0 offset 344 in directory inode 4725620 references non-existent inode 4696842 clearing inode number in entry at offset 344... entry "changelog.Debian.gz" at block 0 offset 720 in directory inode 4725620 references non-existent inode 4696736 clearing inode number in entry at offset 720... entry "changelog.gz" at block 0 offset 784 in directory inode 4725620 references non-existent inode 4696834 clearing inode number in entry at offset 784... entry "copyright" at block 0 offset 840 in directory inode 4725620 references non-existent inode 4696833 clearing inode number in entry at offset 840... entry "NEWS.gz" in shortform directory 4742534 references free inode 4741445 junking entry "NEWS.gz" in directory inode 4742534 entry "changelog.Debian.gz" in shortform directory 4742534 references free inode 4741446 junking entry "changelog.Debian.gz" in directory inode 4742534 entry "changelog.gz" in shortform directory 4742534 references free inode 4741444 junking entry "changelog.gz" in directory inode 4742534 entry "copyright" in shortform directory 4742534 references free inode 4741443 junking entry "copyright" in directory inode 4742534 entry "test-bad-si-3.1.7.xml" at block 0 offset 696 in directory inode 4742539 references non-existent inode 4696840 clearing inode number in entry at offset 696... entry "libc_47.html" at block 0 offset 2512 in directory inode 4747821 references free inode 4741447 clearing inode number in entry at offset 2512... entry "libc_48.html" at block 0 offset 2568 in directory inode 4747821 references free inode 4741448 clearing inode number in entry at offset 2568... - agno = 2 - agno = 3 - agno = 4 - agno = 5 entry "akregator" at block 0 offset 3664 in directory inode 23038736 references non-existent inode 4696879 clearing inode number in entry at offset 3664... entry "apt-doc" at block 1 offset 64 in directory inode 23038736 references non-existent inode 4696887 clearing inode number in entry at offset 64... entry "apt-utils" at block 1 offset 312 in directory inode 23038736 references non-existent inode 4696888 clearing inode number in entry at offset 312... entry "base-files" at block 1 offset 784 in directory inode 23038736 references non-existent inode 4696892 clearing inode number in entry at offset 784... - agno = 6 - agno = 7 - agno = 8 entry "inst22" at block 0 offset 224 in directory inode 34157084 references free inode 4741449 clearing inode number in entry at offset 224... entry "x11" at block 0 offset 552 in directory inode 34157084 references free inode 4741464 clearing inode number in entry at offset 552... - agno = 9 entry "programs" at block 0 offset 184 in directory inode 38609570 references non-existent inode 4696886 clearing inode number in entry at offset 184... - agno = 10 - agno = 11 entry "template" at block 0 offset 152 in directory inode 46427728 references non-existent inode 4696878 clearing inode number in entry at offset 152... - agno = 12 - agno = 13 entry "ja" in shortform directory 54773957 references non-existent inode 4696836 junking entry "ja" in directory inode 54773957 - agno = 14 - agno = 15 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - ensuring existence of lost+found directory - traversing filesystem starting at / ... rebuilding directory inode 4206355 rebuilding directory inode 23038736 rebuilding directory inode 4747821 rebuilding directory inode 4742539 rebuilding directory inode 34157084 rebuilding directory inode 4725620 rebuilding directory inode 411564 rebuilding directory inode 411522 rebuilding directory inode 38609570 rebuilding directory inode 46427728 rebuilding directory inode 403216 rebuilding directory inode 4665754 - traversal finished ... - traversing all unattached subtrees ... - traversals finished ... - moving disconnected inodes to lost+found ... disconnected inode 251, moving to lost+found disconnected inode 94417, moving to lost+found disconnected inode 94419, moving to lost+found disconnected inode 109353, moving to lost+found disconnected inode 109359, moving to lost+found disconnected inode 4725600, moving to lost+found disconnected inode 4725601, moving to lost+found disconnected inode 4725603, moving to lost+found disconnected inode 4725604, moving to lost+found disconnected inode 4725605, moving to lost+found disconnected inode 4725606, moving to lost+found disconnected inode 4725607, moving to lost+found disconnected inode 4725608, moving to lost+found disconnected inode 4725609, moving to lost+found disconnected inode 4725621, moving to lost+found disconnected inode 4725622, moving to lost+found disconnected inode 4725623, moving to lost+found disconnected inode 4725624, moving to lost+found disconnected inode 4725625, moving to lost+found disconnected inode 4725626, moving to lost+found disconnected inode 4725627, moving to lost+found disconnected inode 4725628, moving to lost+found disconnected inode 4725629, moving to lost+found disconnected inode 4725630, moving to lost+found disconnected inode 4725631, moving to lost+found disconnected inode 4725632, moving to lost+found disconnected inode 4725633, moving to lost+found disconnected inode 4725634, moving to lost+found disconnected inode 4725635, moving to lost+found disconnected inode 4725636, moving to lost+found disconnected inode 4725637, moving to lost+found disconnected inode 4725638, moving to lost+found disconnected inode 4725639, moving to lost+found disconnected inode 4725640, moving to lost+found disconnected inode 4725641, moving to lost+found disconnected inode 4725642, moving to lost+found disconnected inode 4725643, moving to lost+found disconnected inode 4725644, moving to lost+found disconnected inode 4725645, moving to lost+found disconnected inode 4725646, moving to lost+found disconnected inode 4725647, moving to lost+found disconnected inode 4725648, moving to lost+found disconnected inode 4725649, moving to lost+found disconnected inode 4725650, moving to lost+found disconnected inode 4725651, moving to lost+found disconnected inode 4725652, moving to lost+found disconnected inode 4725653, moving to lost+found disconnected inode 4725654, moving to lost+found disconnected inode 4725655, moving to lost+found disconnected inode 4725656, moving to lost+found disconnected inode 4725657, moving to lost+found disconnected inode 4725658, moving to lost+found disconnected inode 4725659, moving to lost+found disconnected inode 4725660, moving to lost+found disconnected inode 4725661, moving to lost+found disconnected inode 4725662, moving to lost+found disconnected inode 4725663, moving to lost+found disconnected inode 4742536, moving to lost+found disconnected inode 4742540, moving to lost+found disconnected inode 4742541, moving to lost+found disconnected inode 4742542, moving to lost+found disconnected inode 4742543, moving to lost+found disconnected inode 4742544, moving to lost+found disconnected dir inode 8635560, moving to lost+found disconnected dir inode 8635561, moving to lost+found disconnected inode 12586306, moving to lost+found disconnected inode 12586307, moving to lost+found disconnected inode 12586309, moving to lost+found disconnected dir inode 12849074, moving to lost+found disconnected dir inode 17184050, moving to lost+found disconnected dir inode 23070842, moving to lost+found disconnected inode 29473796, moving to lost+found disconnected inode 29841064, moving to lost+found disconnected inode 62914737, moving to lost+found disconnected inode 62914800, moving to lost+found disconnected inode 62916146, moving to lost+found disconnected inode 62928033, moving to lost+found disconnected inode 62928034, moving to lost+found disconnected inode 62928035, moving to lost+found disconnected inode 62928044, moving to lost+found disconnected inode 62928090, moving to lost+found disconnected inode 63309058, moving to lost+found disconnected inode 63309059, moving to lost+found disconnected inode 63309060, moving to lost+found disconnected inode 63309061, moving to lost+found disconnected inode 63309062, moving to lost+found disconnected inode 63309063, moving to lost+found disconnected inode 63309064, moving to lost+found disconnected inode 63309065, moving to lost+found Phase 7 - verify and correct link counts... resetting inode 403216 nlinks from 8 to 7 resetting inode 411522 nlinks from 9 to 8 resetting inode 411564 nlinks from 3 to 2 resetting inode 23038736 nlinks from 2156 to 2152 resetting inode 34157084 nlinks from 27 to 25 resetting inode 38609570 nlinks from 14 to 13 resetting inode 46427728 nlinks from 9 to 8 resetting inode 54773957 nlinks from 7 to 6 done ---------------------------------------------------------- That seemed way to much damage to me to repair it manually so I just did mkfs.xfs /dev/hda5 and started restoring my backup from 12 days ago via rsync which is currently running. Before that I put the barrier option in /etc/fstab on SUSE 10.1 additional to disabling write caching with hdparm (see above), since as written it uses a 2.6.16 kernel: LABEL=debian /mnt/debian xfs defaults,barrier 0 0 LABEL=home /mnt/debian-home xfs defaults,barrier 0 0 Since I didn?t yet find any documentation about it, I do not know whether thats correct. I copied /var/log/syslog from my debian partition to a save place before... and in the end it showed what happened as the kernel crashed down - not that I understand much of it: ---------------------------------------------------------- Jun 22 21:24:59 deepdance ntpd[28179]: adjusting local clock by 57.926997s Jun 22 21:29:14 deepdance ntpd[28179]: adjusting local clock by 57.606572s Jun 22 21:32:02 deepdance kernel: Unable to handle kernel paging request at virtual address 7558c487 Jun 22 21:32:02 deepdance kernel: printing eip: Jun 22 21:32:02 deepdance kernel: c0247b57 Jun 22 21:32:02 deepdance kernel: *pde = 00000000 Jun 22 21:32:02 deepdance kernel: Oops: 0000 [#1] Jun 22 21:32:02 deepdance kernel: PREEMPT Jun 22 21:32:02 deepdance kernel: Modules linked in: button appletalk ipx p8022 psnap llc savage drm binfmt_misc ipv6 fan ac battery ibm_acpi nls_cp850 nls_iso8859_15 dm_mod tun usblp usb_storage ntfs vfat msdos fat reiserfs udf smbfs uinput smapi rtcmosram thinkpad snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_seq_device sg scsi_mod speedstep_ich speedstep_lib cpufreq_ondemand cpufreq_userspace genrtc nvram usbhid ehci_hcd ohci_hcd pcmcia firmware_class hw_random snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm snd_timer ide_cd cdrom snd snd_page_alloc e100 mii uhci_hcd intel_agp agpgart usbcore yenta_socket rsrc_nonstatic pcmcia_core joydev evdev Jun 22 21:32:02 deepdance kernel: CPU: 0 Jun 22 21:32:02 deepdance kernel: EIP: 0060:[] Not tainted VLI Jun 22 21:32:02 deepdance kernel: EFLAGS: 00010a16 (2.6.15.7-tp23-sws2-2.2) Jun 22 21:32:02 deepdance kernel: EIP is at xfs_ail_insert+0x27/0x90 Jun 22 21:32:02 deepdance kernel: eax: d7c47414 ebx: c990308c ecx: d3431c64 edx: 7558c47b Jun 22 21:32:02 deepdance kernel: esi: c990308c edi: 00000025 ebp: 00000e4a esp: d7c85e34 Jun 22 21:32:02 deepdance kernel: ds: 007b es: 007b ss: 0068 Jun 22 21:32:02 deepdance kernel: Process xfslogd/0 (pid: 116, threadinfo=d7c84000 task=d7c50090) Jun 22 21:32:02 deepdance kernel: Stack: c990308c d7c47414 00000e4a 00000025 c024780d d7c47414 c990308c d7c47400 Jun 22 21:32:02 deepdance kernel: 00000000 c7949834 00000025 c990308c 00000025 c7002e1c c02473c0 d7c47400 Jun 22 21:32:02 deepdance kernel: c990308c 00000e4a 00000025 00000000 d7c47400 00000000 d7c84000 00000000 Jun 22 21:32:02 deepdance kernel: Call Trace: Jun 22 21:32:02 deepdance kernel: [] xfs_trans_update_ail+0x5d/0x140 Jun 22 21:32:02 deepdance kernel: [] xfs_trans_chunk_committed+0x50/0x140 Jun 22 21:32:02 deepdance kernel: [] xfs_trans_committed+0x52/0x110 Jun 22 21:32:02 deepdance kernel: [] xlog_state_do_callback+0x145/0x2e0 Jun 22 21:32:02 deepdance kernel: [] xlog_state_done_syncing+0x75/0xb0 Jun 22 21:32:02 deepdance kernel: [] xlog_iodone+0x4c/0xe0 Jun 22 21:32:02 deepdance kernel: [] worker_thread+0x1fd/0x2f0 Jun 22 21:32:02 deepdance kernel: [] pagebuf_iodone_work+0x0/0x50 Jun 22 21:32:02 deepdance kernel: [] default_wake_function+0x0/0x20 Jun 22 21:32:02 deepdance kernel: [] worker_thread+0x0/0x2f0 Jun 22 21:32:02 deepdance kernel: [] kthread+0xcd/0xe0 Jun 22 21:32:02 deepdance kernel: [] kthread+0x0/0xe0 Jun 22 21:32:02 deepdance kernel: [] kernel_thread_helper+0x5/0xc Jun 22 21:32:02 deepdance kernel: Code: 18 c3 89 f6 83 ec 10 8b 44 24 14 89 74 24 04 8b 74 24 18 89 1c 24 89 7c 24 08 89 6c 24 0c 8b 50 04 39 c2 74 46 8b 7e 0c 8b 6e 08 <39> 7a 0c 8b 4a 08 74 32 72 0f 8b 52 04 39 d0 75 ef 90 8d b4 26 Jun 22 21:32:02 deepdance kernel: <6>note: xfslogd/0[116] exited with preempt_count 1 ---------------------------------------------------------- So XFS died once again. This time with disabled write caches. I have no idea what happened... I start to wonder whether the hardware has problems, but I highly doubt it. smartctl reports only successful online and offline tests (it runs regarily here). And I also ran memtest86 not too long ago. I can do it again, of course. I wondered whether that bad magic stuff in the xfs_repair output can be related to bad memory. But then the machine usually works nicely with that kernel. Once more thing might be relevant. I did an xfs_check on my debian root partition before with SUSE 10.1, cause I had a crash that apparently didn?t crash XFS. It just showed some "agi unlinked bucket stuff" like it sometimes does. I still ran xfs_repair on it. It showed two errors while reading AGs or linked lists - unfortunately I do not remember the exact wording and I did not copy the error message. I did an xfs_check again which reported that all is fine now (no output). Just to make sure I can xfs_repair again and the two error messages didn?t appear anymore. This may be somehow related to this new bad XFS crash. Ok, thats all I have which is probably still quite much. Maybe you can give me a hint what happened. I wanted to wait a little more before trying kernel 2.6.17, but I think I will switch over to it this weekend. Seems that 2.6.15.7 is not as stable as I thought and hoped for. Maybe 2.6.17 does better. I hope sound will work after resume from suspend to disk. To be on the safe side, I will use plain vanilla for now without sws2 and without CONFIG_REGPARM even when thats really enabled by default no for 2.6.17. I know 2.6.15.7 is not the most recent kernel, thats why I report this to the XFS bugzilla instead. This may still give you valuable information about a possible XFS misbehavior. Otherwise feel free to close this bug report, I can always reopen it, should such thing ever happen again. I really hope that my bad luck with XFS will be over soon. Actually I already considered switching to ext3 due to those XFS crashes. Still I like XFS quite much. It works absolutely reliably on about 10 workstations in our company with kernels from 2.6.8, 2.6.11, 2.6.14 upto 2.6.16rc1 and is really fast. I just add some hardware information: ---------------------------------------------------------- deepdance:~ # lspci 00:00.0 Host bridge: Intel Corporation 82830 830 Chipset Host Bridge (rev 04) 00:01.0 PCI bridge: Intel Corporation 82830 830 Chipset AGP Bridge (rev 04) 00:1d.0 USB Controller: Intel Corporation 82801CA/CAM USB (Hub #1) (rev 02) 00:1d.1 USB Controller: Intel Corporation 82801CA/CAM USB (Hub #2) (rev 02) 00:1d.2 USB Controller: Intel Corporation 82801CA/CAM USB (Hub #3) (rev 02) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 42) 00:1f.0 ISA bridge: Intel Corporation 82801CAM ISA Bridge (LPC) (rev 02) 00:1f.1 IDE interface: Intel Corporation 82801CAM IDE U100 (rev 02) 00:1f.3 SMBus: Intel Corporation 82801CA/CAM SMBus Controller (rev 02) 00:1f.5 Multimedia audio controller: Intel Corporation 82801CA/CAM AC'97 Audio Controller (rev 02) 01:00.0 VGA compatible controller: S3 Inc. SuperSavage IX/C SDR (rev 05) 02:00.0 CardBus bridge: Texas Instruments PCI1420 02:00.1 CardBus bridge: Texas Instruments PCI1420 02:02.0 Communication controller: Agere Systems WinModem 56k (rev 01) 02:08.0 Ethernet controller: Intel Corporation 82801CAM (ICH3) PRO/100 VE (LOM) Ethernet Controller (rev 42) 03:00.0 USB Controller: NEC Corporation USB (rev 43) 03:00.1 USB Controller: NEC Corporation USB (rev 43) 03:00.2 USB Controller: NEC Corporation USB 2.0 (rev 04) ---------------------------------------------------------- ---------------------------------------------------------- deepdance:~ # lspci -vvn 00:00.0 Class 0600: 8086:3575 (rev 04) Subsystem: 1014:021d Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 00:01.0 Class 0604: 8086:3576 (rev 04) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- 00:1d.0 Class 0c03: 8086:2482 (rev 02) Subsystem: 1014:0220 Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B- 00:1f.0 Class 0601: 8086:248c (rev 02) Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- Region 1: I/O ports at Region 2: I/O ports at Region 3: I/O ports at Region 4: I/O ports at 1860 [size=16] Region 5: Memory at 20000000 (32-bit, non-prefetchable) [size=1K] 00:1f.3 Class 0c05: 8086:2483 (rev 02) Subsystem: 1014:0220 Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- 02:00.0 Class 0607: 104c:ac51 Subsystem: 1014:023b Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Reset- 16bInt- PostWrite+ 16-bit legacy interface ports at 0001 02:00.1 Class 0607: 104c:ac51 Subsystem: 1014:023b Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Reset+ 16bInt+ PostWrite+ 16-bit legacy interface ports at 0001 02:02.0 Class 0780: 11c1:0449 (rev 01) Subsystem: 1468:0410 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- ; Thu, 22 Jun 2006 17:52:41 -0700 Received: from localhost (dslb-084-056-068-211.pools.arcor-ip.net [84.56.68.211]) by mondschein.lichtvoll.de (Postfix) with ESMTP id 66637FA50F for ; Fri, 23 Jun 2006 00:49:05 +0200 (CEST) From: Martin Steigerwald To: xfs@oss.sgi.com Subject: xfs crash with linux 2.6.15.7 and disabled write caches (long) Date: Fri, 23 Jun 2006 00:49:25 +0200 User-Agent: KMail/1.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606230049.27767.Martin@lichtvoll.de> X-archive-position: 8021 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Martin@lichtvoll.de Precedence: bulk X-list: xfs Content-Length: 105582 Lines: 2205 Hello, now I had a xfs crash with linux 2.6.15.7 and disabled write caches. I put together all debug information I could get, but now the text is too large for bugzilla@SGI (even when I cut out some larger cmd outputs and log snippets). Thus I will firstly report it here. Since its kernel 2.6.15.7 it might not be relevant for bug reporting anymore. If you want, I try to make a bug report out of it by seperating it to pieces... but not this night... I decided to try kernel 2.6.17 now sooner than I planned (its compiling right now, plain vanilla 2.6.17.1, this time even without software suspend 2 patches). I will try it with disabled write caches first. Does that seem stable I will make a backup, enable write caches and see how it goes... Ok, here is the whole story of that fifth XFS crash in this year... Hello, now I had yet another XFS crash after those 3 crashes in one week with enabled write cache (kernel bug #6380 !!!) and once with kernel 2.6.15.7 with CONFIG_REGPARM and SWS2. Now I have kernel 2.6.15.7 with SWS2 again without CONFIG_REGPARM - 2.6.16 had non working sound after resume. This is the one kernel I had the least XFS crashes with (besides maybe even earlier kernels like 2.6.11). I am using a IBM ThinkPad T23 with 384 MB RAM. 128MB have been in there and I added an additional 256 Kingston IBM TP 23 RAM. I am using Debian Etch/Sid/Experimental (I think I have nothing from experimental installed at the moment tough). Since I heard about the write cache issues I have used XFS without writecache: ---------------------------------------------------------- deepdance:~ # cat /mnt/bak1/debian/etc/hdparm.conf [...] /dev/hda { mult_sect_io = 16 write_cache = off dma = on apm = 0 acoustic_management = 128 io32_support = 3 keep_settings_over_reset = on interrupt_unmask = on } ---------------------------------------------------------- But today even that most reliable kernel crashed down badly: I was using my KDE desktop like usual as suddenly IO stopped completely. I was able to switch between applications windows, but some windows where not refreshed anymore. I was able to enter a commend in KDE?s console, after return nothing happened. I pressed Ctrl-Alt-F1 to login to a tty, but after entering root as login name nothing happened. I waited a while - nothing happened. No harddisk access. The machine was strangely silent (fan was off as well). Then I switched it off by pressing the power button for long enough. I booted into SUSE 10.1 in order to examine the situation. I upgraded SUSE 10.0 to 10.1 this week. Since it uses ---------------------------------------------------------- deepdance:~ # cat /proc/version Linux version 2.6.16.13-4-default (geeko@buildhost) (gcc version 4.1.0 (SUSE Linux)) #1 Wed May 3 04:53:23 UTC 2006 ---------------------------------------------------------- I made an init script that disabled the write cache. Only strange thing is some bogus output of hdparm there: ---------------------------------------------------------- deepdance:~ # hdparm -W0 /dev/hda /dev/hda: setting drive write-caching to 0 (off) HDIO_SET_WCACHE(wcache) failed: Success ---------------------------------------------------------- This output is showed while booting SUSE which shows that my init script is being started. Already on boot it showed that my debian root partition cannot be mounted anymore. I tried it manually afterwards and got this in my /var/log/messages: ---------------------------------------------------------- Jun 22 21:37:08 deepdance kernel: XFS mounting filesystem hda5 Jun 22 21:37:08 deepdance kernel: Filesystem "hda5": XFS internal error xlog_clear_stale_blocks(2) at line 1237 of file fs/xfs/xfs_log_recover.c. Caller 0xd8cf021f Jun 22 21:37:08 deepdance kernel: [] xlog_find_tail+0x940/0xa53 [xfs] Jun 22 21:37:08 deepdance kernel: [] xlog_recover+0x15/0x20a [xfs] Jun 22 21:37:08 deepdance kernel: [] __alloc_pages+0x66/0x296 Jun 22 21:37:08 deepdance kernel: [] xlog_recover+0x15/0x20a [xfs] Jun 22 21:37:08 deepdance kernel: [] xfs_buf_get_empty+0x2a/0x33 [xfs] Jun 22 21:37:08 deepdance kernel: [] xfs_log_mount+0x445/0x488 [xfs] Jun 22 21:37:08 deepdance kernel: [] xfs_mountfs+0xa63/0xe66 [xfs] Jun 22 21:37:08 deepdance kernel: [] xfs_readsb+0x491/0x538 [xfs] Jun 22 21:37:08 deepdance kernel: [] xfs_setsize_buftarg_flags+0x2a/0x89 [xfs] Jun 22 21:37:08 deepdance kernel: [] kmem_alloc+0x5a/0xaf [xfs] Jun 22 21:37:08 deepdance kernel: [] xfs_mount+0x770/0x838 [xfs] Jun 22 21:37:08 deepdance kernel: [] xfs_mount+0x0/0x838 [xfs] Jun 22 21:37:08 deepdance kernel: [] vfs_mount+0x17/0x1a [xfs] Jun 22 21:37:09 deepdance kernel: [] linvfs_fill_super+0x76/0x1b2 [xfs] Jun 22 21:37:09 deepdance kernel: [] snprintf+0x1c/0x1f Jun 22 21:37:09 deepdance kernel: [] disk_name+0x56/0x60 Jun 22 21:37:09 deepdance kernel: [] get_sb_bdev+0xd5/0x11d Jun 22 21:37:09 deepdance kernel: [] __alloc_pages+0x66/0x296 Jun 22 21:37:09 deepdance kernel: [] linvfs_get_sb+0xe/0x11 [xfs] Jun 22 21:37:09 deepdance kernel: [] linvfs_fill_super+0x0/0x1b2 [xfs] Jun 22 21:37:09 deepdance kernel: [] do_kern_mount+0x86/0x12b Jun 22 21:37:09 deepdance kernel: [] do_mount+0x645/0x69f Jun 22 21:37:09 deepdance kernel: [] mntput_no_expire+0x11/0x59 Jun 22 21:37:09 deepdance kernel: [] link_path_walk+0xaf/0xb9 Jun 22 21:37:09 deepdance kernel: [] dput+0x31/0x122 Jun 22 21:37:09 deepdance kernel: [] mntput_no_expire+0x11/0x59 Jun 22 21:37:09 deepdance kernel: [] __handle_mm_fault+0x733/0x75b Jun 22 21:37:09 deepdance kernel: [] get_page_from_freelist+0x6f/0x29d Jun 22 21:37:09 deepdance kernel: [] do_page_fault+0x17b/0x53c Jun 22 21:37:09 deepdance kernel: [] copy_mount_options+0x26/0x109 Jun 22 21:37:09 deepdance kernel: [] sys_mount+0x64/0x97 Jun 22 21:37:09 deepdance kernel: [] syscall_call+0x7/0xb Jun 22 21:37:09 deepdance kernel: XFS: failed to locate log tail Jun 22 21:37:09 deepdance kernel: XFS: log mount/recovery failed: error 990 Jun 22 21:37:09 deepdance kernel: XFS: log mount failed Jun 22 21:37:10 deepdance kernel: XFS mounting filesystem hda5 Jun 22 21:37:10 deepdance kernel: Filesystem "hda5": XFS internal error xlog_clear_stale_blocks(2) at line 1237 of file fs/xfs/xfs_log_recover.c. Caller 0xd8cf021f Jun 22 21:37:10 deepdance kernel: [] xlog_find_tail+0x940/0xa53 [xfs] Jun 22 21:37:10 deepdance kernel: [] xlog_recover+0x15/0x20a [xfs] Jun 22 21:37:10 deepdance kernel: [] schedule+0x4c1/0x52e Jun 22 21:37:10 deepdance kernel: [] xlog_recover+0x15/0x20a [xfs] Jun 22 21:37:10 deepdance kernel: [] xfs_buf_get_empty+0x2a/0x33 [xfs] Jun 22 21:37:10 deepdance kernel: [] xfs_log_mount+0x445/0x488 [xfs] Jun 22 21:37:10 deepdance kernel: [] xfs_mountfs+0xa63/0xe66 [xfs] Jun 22 21:37:10 deepdance kernel: [] xfs_readsb+0x491/0x538 [xfs] Jun 22 21:37:10 deepdance kernel: [] xfs_setsize_buftarg_flags+0x2a/0x89 [xfs] Jun 22 21:37:10 deepdance kernel: [] kmem_alloc+0x5a/0xaf [xfs] Jun 22 21:37:10 deepdance kernel: [] xfs_mount+0x770/0x838 [xfs] Jun 22 21:37:10 deepdance kernel: [] xfs_mount+0x0/0x838 [xfs] Jun 22 21:37:10 deepdance kernel: [] vfs_mount+0x17/0x1a [xfs] Jun 22 21:37:10 deepdance kernel: [] linvfs_fill_super+0x76/0x1b2 [xfs] Jun 22 21:37:10 deepdance kernel: [] snprintf+0x1c/0x1f Jun 22 21:37:10 deepdance kernel: [] disk_name+0x56/0x60 Jun 22 21:37:10 deepdance kernel: [] get_sb_bdev+0xd5/0x11d Jun 22 21:37:10 deepdance kernel: [] __alloc_pages+0x66/0x296 Jun 22 21:37:10 deepdance kernel: [] linvfs_get_sb+0xe/0x11 [xfs] Jun 22 21:37:10 deepdance kernel: [] linvfs_fill_super+0x0/0x1b2 [xfs] Jun 22 21:37:10 deepdance kernel: [] do_kern_mount+0x86/0x12b Jun 22 21:37:10 deepdance kernel: [] do_mount+0x645/0x69f Jun 22 21:37:10 deepdance kernel: [] mntput_no_expire+0x11/0x59 Jun 22 21:37:10 deepdance kernel: [] link_path_walk+0xaf/0xb9 Jun 22 21:37:10 deepdance kernel: [] dput+0x31/0x122 Jun 22 21:37:10 deepdance kernel: [] mntput_no_expire+0x11/0x59 Jun 22 21:37:10 deepdance kernel: [] __handle_mm_fault+0x733/0x75b Jun 22 21:37:10 deepdance kernel: [] get_page_from_freelist+0x6f/0x29d Jun 22 21:37:10 deepdance kernel: [] do_page_fault+0x17b/0x53c Jun 22 21:37:10 deepdance kernel: [] copy_mount_options+0x26/0x109 Jun 22 21:37:10 deepdance kernel: [] sys_mount+0x64/0x97 Jun 22 21:37:10 deepdance kernel: [] syscall_call+0x7/0xb Jun 22 21:37:10 deepdance kernel: XFS: failed to locate log tail Jun 22 21:37:11 deepdance kernel: XFS: log mount/recovery failed: error 990 Jun 22 21:37:11 deepdance kernel: XFS: log mount failed ---------------------------------------------------------- I tried to check it deepdance:~ # xfs_check /dev/hda5 ERROR: The filesystem has valuable metadata changes in a log which needs to be replayed. Mount the filesystem to replay the log, and unmount it before re-running xfs_check. If you are unable to mount the filesystem, then use the xfs_repair -L option to destroy the log and attempt a repair. Note that destroying the log may cause corruption -- please attempt a mount of the filesystem before doing this. and my debian home partition /dev/hda8 which - lucky me - seems to be fine. Ok, so it seems I have to use "xfs_repair -L" again - which gave lots of output (I used xfsprogs 2.7.11 SUSE 10.1 binary package built from xfsprogs-2.7.11-18.src.rpm): ---------------------------------------------------------- deepdance:~ # xfs_repair -L /dev/hda5 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 - agno = 1 bad magic number 0xde85 on inode 4696704 bad version number 0x33 on inode 4696704 bad inode format in inode 4696704 bad magic number 0x5050 on inode 4696705 bad version number 0xffffffa5 on inode 4696705 bad inode format in inode 4696705 bad magic number 0xa7f3 on inode 4696706 bad version number 0xffffff9c on inode 4696706 bad (negative) size -3304726038600961885 on inode 4696706 bad magic number 0xb065 on inode 4696707 bad version number 0x24 on inode 4696707 bad (negative) size -9029802015504088694 on inode 4696707 bad magic number 0x34fb on inode 4696708 bad version number 0x2 on inode 4696708 bad inode format in inode 4696708 bad magic number 0xe9bb on inode 4696709 bad version number 0xffffffa6 on inode 4696709 bad (negative) size -7499079139829868559 on inode 4696709 bad magic number 0x5622 on inode 4696710 bad version number 0x57 on inode 4696710 bad inode format in inode 4696710 bad magic number 0xd2c1 on inode 4696711 bad version number 0x47 on inode 4696711 bad (negative) size -6164552464929284699 on inode 4696711 bad magic number 0x6ed9 on inode 4696712 bad version number 0x34 on inode 4696712 bad (negative) size -4938527813517352204 on inode 4696712 bad magic number 0x212e on inode 4696713 bad version number 0xffffffaa on inode 4696713 bad (negative) size -3317934298250532183 on inode 4696713 bad magic number 0x2988 on inode 4696714 bad version number 0x6b on inode 4696714 bad inode format in inode 4696714 bad magic number 0x9344 on inode 4696715 bad version number 0xfffffff2 on inode 4696715 bad (negative) size -3087606033020300044 on inode 4696715 bad magic number 0x701 on inode 4696716 bad version number 0xffffffd2 on inode 4696716 bad inode format in inode 4696716 bad magic number 0xc2ff on inode 4696717 bad version number 0xffffffdc on inode 4696717 bad (negative) size -2638220079859594521 on inode 4696717 bad magic number 0xf9f4 on inode 4696718 bad version number 0xffffffe9 on inode 4696718 bad inode format in inode 4696718 bad magic number 0x8f95 on inode 4696719 bad version number 0x69 on inode 4696719 bad inode format in inode 4696719 bad magic number 0xa3e0 on inode 4696720 bad version number 0x74 on inode 4696720 bad (negative) size -1450867304098734345 on inode 4696720 bad magic number 0xd311 on inode 4696721 bad version number 0x12 on inode 4696721 bad inode format in inode 4696721 bad magic number 0x9f4a on inode 4696722 bad version number 0x24 on inode 4696722 bad inode format in inode 4696722 bad magic number 0x9ebd on inode 4696723 bad version number 0x68 on inode 4696723 bad (negative) size -7993413996180667903 on inode 4696723 bad magic number 0xf713 on inode 4696724 bad version number 0xffffffe0 on inode 4696724 bad inode format in inode 4696724 bad magic number 0xaf97 on inode 4696725 bad version number 0xffffffc5 on inode 4696725 bad (negative) size -3508248750937534140 on inode 4696725 bad magic number 0x5509 on inode 4696726 bad version number 0xffffffa2 on inode 4696726 bad inode format in inode 4696726 bad magic number 0x388c on inode 4696727 bad version number 0x5b on inode 4696727 bad (negative) size -3079579163917115419 on inode 4696727 bad magic number 0xfd51 on inode 4696728 bad version number 0x0 on inode 4696728 bad (negative) size -1699996839080917064 on inode 4696728 bad magic number 0xbd1d on inode 4696729 bad version number 0xffffffd0 on inode 4696729 bad (negative) size -3890821399028612504 on inode 4696729 bad magic number 0xab6 on inode 4696730 bad version number 0xffffffa7 on inode 4696730 bad inode format in inode 4696730 bad magic number 0xa93 on inode 4696731 bad version number 0x1f on inode 4696731 bad inode format in inode 4696731 bad magic number 0x28e0 on inode 4696732 bad version number 0x4b on inode 4696732 bad inode format in inode 4696732 bad magic number 0xe2de on inode 4696733 bad version number 0xffffff95 on inode 4696733 bad inode format in inode 4696733 bad magic number 0x4606 on inode 4696734 bad version number 0x59 on inode 4696734 bad (negative) size -4974402844452071491 on inode 4696734 bad magic number 0xfd48 on inode 4696735 bad version number 0xf on inode 4696735 bad (negative) size -1154894484287551647 on inode 4696735 bad magic number 0xde85 on inode 4696704, resetting magic number bad version number 0x33 on inode 4696704, resetting version number bad inode format in inode 4696704 cleared inode 4696704 bad magic number 0x5050 on inode 4696705, resetting magic number bad version number 0xffffffa5 on inode 4696705, resetting version number bad inode format in inode 4696705 cleared inode 4696705 bad magic number 0xa7f3 on inode 4696706, resetting magic number bad version number 0xffffff9c on inode 4696706, resetting version number bad (negative) size -3304726038600961885 on inode 4696706 cleared inode 4696706 bad magic number 0xb065 on inode 4696707, resetting magic number bad version number 0x24 on inode 4696707, resetting version number bad (negative) size -9029802015504088694 on inode 4696707 cleared inode 4696707 bad magic number 0x34fb on inode 4696708, resetting magic number bad version number 0x2 on inode 4696708, resetting version number bad inode format in inode 4696708 cleared inode 4696708 bad magic number 0xe9bb on inode 4696709, resetting magic number bad version number 0xffffffa6 on inode 4696709, resetting version number bad (negative) size -7499079139829868559 on inode 4696709 cleared inode 4696709 bad magic number 0x5622 on inode 4696710, resetting magic number bad version number 0x57 on inode 4696710, resetting version number bad inode format in inode 4696710 cleared inode 4696710 bad magic number 0xd2c1 on inode 4696711, resetting magic number bad version number 0x47 on inode 4696711, resetting version number bad (negative) size -6164552464929284699 on inode 4696711 cleared inode 4696711 bad magic number 0x6ed9 on inode 4696712, resetting magic number bad version number 0x34 on inode 4696712, resetting version number bad (negative) size -4938527813517352204 on inode 4696712 cleared inode 4696712 bad magic number 0x212e on inode 4696713, resetting magic number bad version number 0xffffffaa on inode 4696713, resetting version number bad (negative) size -3317934298250532183 on inode 4696713 cleared inode 4696713 bad magic number 0x2988 on inode 4696714, resetting magic number bad version number 0x6b on inode 4696714, resetting version number bad inode format in inode 4696714 cleared inode 4696714 bad magic number 0x9344 on inode 4696715, resetting magic number bad version number 0xfffffff2 on inode 4696715, resetting version number bad (negative) size -3087606033020300044 on inode 4696715 cleared inode 4696715 bad magic number 0x701 on inode 4696716, resetting magic number bad version number 0xffffffd2 on inode 4696716, resetting version number bad inode format in inode 4696716 cleared inode 4696716 bad magic number 0xc2ff on inode 4696717, resetting magic number bad version number 0xffffffdc on inode 4696717, resetting version number bad (negative) size -2638220079859594521 on inode 4696717 cleared inode 4696717 bad magic number 0xf9f4 on inode 4696718, resetting magic number bad version number 0xffffffe9 on inode 4696718, resetting version number bad inode format in inode 4696718 cleared inode 4696718 bad magic number 0x8f95 on inode 4696719, resetting magic number bad version number 0x69 on inode 4696719, resetting version number bad inode format in inode 4696719 cleared inode 4696719 bad magic number 0xa3e0 on inode 4696720, resetting magic number bad version number 0x74 on inode 4696720, resetting version number bad (negative) size -1450867304098734345 on inode 4696720 cleared inode 4696720 bad magic number 0xd311 on inode 4696721, resetting magic number bad version number 0x12 on inode 4696721, resetting version number bad inode format in inode 4696721 cleared inode 4696721 bad magic number 0x9f4a on inode 4696722, resetting magic number bad version number 0x24 on inode 4696722, resetting version number bad inode format in inode 4696722 cleared inode 4696722 bad magic number 0x9ebd on inode 4696723, resetting magic number bad version number 0x68 on inode 4696723, resetting version number bad (negative) size -7993413996180667903 on inode 4696723 cleared inode 4696723 bad magic number 0xf713 on inode 4696724, resetting magic number bad version number 0xffffffe0 on inode 4696724, resetting version number bad inode format in inode 4696724 cleared inode 4696724 bad magic number 0xaf97 on inode 4696725, resetting magic number bad version number 0xffffffc5 on inode 4696725, resetting version number bad (negative) size -3508248750937534140 on inode 4696725 cleared inode 4696725 bad magic number 0x5509 on inode 4696726, resetting magic number bad version number 0xffffffa2 on inode 4696726, resetting version number bad inode format in inode 4696726 cleared inode 4696726 bad magic number 0x388c on inode 4696727, resetting magic number bad version number 0x5b on inode 4696727, resetting version number bad (negative) size -3079579163917115419 on inode 4696727 cleared inode 4696727 bad magic number 0xfd51 on inode 4696728, resetting magic number bad version number 0x0 on inode 4696728, resetting version number bad (negative) size -1699996839080917064 on inode 4696728 cleared inode 4696728 bad magic number 0xbd1d on inode 4696729, resetting magic number bad version number 0xffffffd0 on inode 4696729, resetting version number bad (negative) size -3890821399028612504 on inode 4696729 cleared inode 4696729 bad magic number 0xab6 on inode 4696730, resetting magic number bad version number 0xffffffa7 on inode 4696730, resetting version number bad inode format in inode 4696730 cleared inode 4696730 bad magic number 0xa93 on inode 4696731, resetting magic number bad version number 0x1f on inode 4696731, resetting version number bad inode format in inode 4696731 cleared inode 4696731 bad magic number 0x28e0 on inode 4696732, resetting magic number bad version number 0x4b on inode 4696732, resetting version number bad inode format in inode 4696732 cleared inode 4696732 bad magic number 0xe2de on inode 4696733, resetting magic number bad version number 0xffffff95 on inode 4696733, resetting version number bad inode format in inode 4696733 cleared inode 4696733 bad magic number 0x4606 on inode 4696734, resetting magic number bad version number 0x59 on inode 4696734, resetting version number bad (negative) size -4974402844452071491 on inode 4696734 cleared inode 4696734 bad magic number 0xfd48 on inode 4696735, resetting magic number bad version number 0xf on inode 4696735, resetting version number bad (negative) size -1154894484287551647 on inode 4696735 cleared inode 4696735 bad magic number 0xb13c on inode 4696736 bad version number 0x6a on inode 4696736 bad (negative) size -6067877356172665065 on inode 4696736 bad magic number 0xa387 on inode 4696737 bad version number 0x63 on inode 4696737 bad inode format in inode 4696737 bad magic number 0x36a6 on inode 4696738 bad version number 0x5c on inode 4696738 bad inode format in inode 4696738 bad magic number 0x437b on inode 4696739 bad version number 0x3c on inode 4696739 bad inode format in inode 4696739 bad magic number 0x4b0c on inode 4696740 bad version number 0x53 on inode 4696740 bad inode format in inode 4696740 bad magic number 0x8f5e on inode 4696741 bad version number 0x1a on inode 4696741 bad (negative) size -3560507284276483071 on inode 4696741 bad magic number 0x691 on inode 4696742 bad version number 0xb on inode 4696742 bad (negative) size -7699644483040772577 on inode 4696742 bad magic number 0x1f4f on inode 4696743 bad version number 0x32 on inode 4696743 bad (negative) size -3795684244588147964 on inode 4696743 bad magic number 0x7db3 on inode 4696744 bad version number 0xffffffb2 on inode 4696744 bad inode format in inode 4696744 bad magic number 0x938c on inode 4696745 bad version number 0xffffffa7 on inode 4696745 bad inode format in inode 4696745 bad magic number 0x37d on inode 4696746 bad version number 0x6e on inode 4696746 bad (negative) size -1446506858424628510 on inode 4696746 bad magic number 0x533a on inode 4696747 bad version number 0xffffffa3 on inode 4696747 bad (negative) size -1886515669733000777 on inode 4696747 bad magic number 0x8d65 on inode 4696748 bad version number 0x7f on inode 4696748 bad inode format in inode 4696748 bad magic number 0x27 on inode 4696749 bad version number 0xffffff80 on inode 4696749 bad (negative) size -4744216041070046827 on inode 4696749 bad magic number 0x16f4 on inode 4696750 bad version number 0x37 on inode 4696750 bad inode format in inode 4696750 bad magic number 0xe955 on inode 4696751 bad version number 0xffffff9e on inode 4696751 bad (negative) size -1550740798515273378 on inode 4696751 bad magic number 0x38dc on inode 4696752 bad version number 0xffffffba on inode 4696752 bad (negative) size -2340396726233627969 on inode 4696752 bad magic number 0x8117 on inode 4696753 bad version number 0x71 on inode 4696753 bad inode format in inode 4696753 bad magic number 0x751f on inode 4696754 bad version number 0xffffff9d on inode 4696754 bad (negative) size -6226648631829528984 on inode 4696754 bad magic number 0x7e on inode 4696755 bad version number 0xb on inode 4696755 bad inode format in inode 4696755 bad magic number 0xcda9 on inode 4696756 bad version number 0xfffffff1 on inode 4696756 bad (negative) size -823713179867214811 on inode 4696756 bad magic number 0x3e94 on inode 4696757 bad version number 0x2a on inode 4696757 bad inode format in inode 4696757 bad magic number 0xbaab on inode 4696758 bad version number 0x19 on inode 4696758 bad inode format in inode 4696758 bad magic number 0x62c0 on inode 4696759 bad version number 0x54 on inode 4696759 bad (negative) size -371148556173109535 on inode 4696759 bad magic number 0xd6e6 on inode 4696760 bad version number 0xffffffcc on inode 4696760 bad inode format in inode 4696760 bad magic number 0x19f9 on inode 4696761 bad version number 0xfffffff6 on inode 4696761 bad (negative) size -7304896733083342809 on inode 4696761 bad magic number 0xfafa on inode 4696762 bad version number 0x11 on inode 4696762 bad inode format in inode 4696762 bad magic number 0xd3dc on inode 4696763 bad version number 0x26 on inode 4696763 bad (negative) size -3799282727092362742 on inode 4696763 bad magic number 0x3210 on inode 4696764 bad version number 0xffffffe7 on inode 4696764 bad inode format in inode 4696764 bad magic number 0x58f8 on inode 4696765 bad version number 0x7a on inode 4696765 bad inode format in inode 4696765 bad magic number 0xc48 on inode 4696766 bad version number 0xffffff8d on inode 4696766 bad (negative) size -6450620229579682741 on inode 4696766 bad magic number 0xabf8 on inode 4696767 bad version number 0xffffffee on inode 4696767 bad inode format in inode 4696767 bad magic number 0xf4fd on inode 4696768 bad version number 0x1f on inode 4696768 bad (negative) size -5722478984897843614 on inode 4696768 bad magic number 0xc580 on inode 4696769 bad version number 0xffffffb4 on inode 4696769 bad inode format in inode 4696769 bad magic number 0x1b51 on inode 4696770 bad version number 0x35 on inode 4696770 bad inode format in inode 4696770 bad magic number 0x5d24 on inode 4696771 bad version number 0x1f on inode 4696771 bad (negative) size -5683859702116249421 on inode 4696771 bad magic number 0x14f5 on inode 4696772 bad version number 0x4d on inode 4696772 bad (negative) size -311643612940354232 on inode 4696772 bad magic number 0x8ea5 on inode 4696773 bad version number 0xffffffe7 on inode 4696773 bad inode format in inode 4696773 bad magic number 0x80b1 on inode 4696774 bad version number 0x65 on inode 4696774 bad (negative) size -3790813618268958614 on inode 4696774 bad magic number 0x7208 on inode 4696775 bad version number 0xfffffff0 on inode 4696775 bad (negative) size -3406109375177770919 on inode 4696775 bad magic number 0x59cd on inode 4696776 bad version number 0xffffffe2 on inode 4696776 bad inode format in inode 4696776 bad magic number 0xd7bd on inode 4696777 bad version number 0x75 on inode 4696777 bad (negative) size -1189253915011459876 on inode 4696777 bad magic number 0x6171 on inode 4696778 bad version number 0x2e on inode 4696778 bad (negative) size -6808579463096945452 on inode 4696778 bad magic number 0x7af6 on inode 4696779 bad version number 0xffffff95 on inode 4696779 bad (negative) size -1046546913787507572 on inode 4696779 bad magic number 0x8881 on inode 4696780 bad version number 0x3e on inode 4696780 bad (negative) size -767704932530482497 on inode 4696780 bad magic number 0xaa62 on inode 4696781 bad version number 0x1d on inode 4696781 bad (negative) size -5061776730388747229 on inode 4696781 bad magic number 0x7e7d on inode 4696782 bad version number 0xffffffaa on inode 4696782 bad inode format in inode 4696782 bad magic number 0x9229 on inode 4696783 bad version number 0x5c on inode 4696783 bad inode format in inode 4696783 bad magic number 0x3ed4 on inode 4696784 bad version number 0x1f on inode 4696784 bad inode format in inode 4696784 bad magic number 0xd78d on inode 4696785 bad version number 0xffffffe4 on inode 4696785 bad inode format in inode 4696785 bad magic number 0x5ffc on inode 4696786 bad version number 0x48 on inode 4696786 bad inode format in inode 4696786 bad magic number 0xfa74 on inode 4696787 bad version number 0x13 on inode 4696787 bad inode format in inode 4696787 bad magic number 0xa687 on inode 4696788 bad version number 0xffffffe8 on inode 4696788 bad (negative) size -7507601401752548810 on inode 4696788 bad magic number 0x50e5 on inode 4696789 bad version number 0x0 on inode 4696789 bad (negative) size -656492944168048008 on inode 4696789 bad magic number 0x510a on inode 4696790 bad version number 0xffffffec on inode 4696790 bad inode format in inode 4696790 bad magic number 0xf75e on inode 4696791 bad version number 0xfffffffd on inode 4696791 bad (negative) size -2901734608197468161 on inode 4696791 bad magic number 0x73c on inode 4696792 bad version number 0x58 on inode 4696792 bad inode format in inode 4696792 bad magic number 0xbb78 on inode 4696793 bad version number 0x23 on inode 4696793 bad (negative) size -6708369051675684128 on inode 4696793 bad magic number 0x7b28 on inode 4696794 bad version number 0xffffffea on inode 4696794 bad (negative) size -1009334496659050217 on inode 4696794 bad magic number 0x4d69 on inode 4696795 bad version number 0xffffff82 on inode 4696795 bad (negative) size -2049145665214535079 on inode 4696795 bad magic number 0x6c82 on inode 4696796 bad version number 0x5a on inode 4696796 bad (negative) size -957831111172492491 on inode 4696796 bad magic number 0x47b4 on inode 4696797 bad version number 0x31 on inode 4696797 bad (negative) size -7899234391782770088 on inode 4696797 bad magic number 0x4034 on inode 4696798 bad version number 0xffffffaa on inode 4696798 bad (negative) size -8778317362636542198 on inode 4696798 bad magic number 0xd5b on inode 4696799 bad version number 0xffffffd3 on inode 4696799 bad inode format in inode 4696799 bad magic number 0xc756 on inode 4696832 bad version number 0x69 on inode 4696832 bad (negative) size -8487689457889539543 on inode 4696832 bad magic number 0xfb73 on inode 4696833 bad version number 0xffffff87 on inode 4696833 bad (negative) size -2435633300700215500 on inode 4696833 bad magic number 0xb62d on inode 4696834 bad version number 0x2f on inode 4696834 bad inode format in inode 4696834 bad magic number 0xb34d on inode 4696835 bad version number 0x52 on inode 4696835 bad (negative) size -6889481188966490062 on inode 4696835 bad magic number 0xb2d9 on inode 4696836 bad version number 0x37 on inode 4696836 bad inode format in inode 4696836 bad magic number 0xbdd7 on inode 4696837 bad version number 0xffffffaf on inode 4696837 bad inode format in inode 4696837 bad magic number 0xa151 on inode 4696838 bad version number 0x1a on inode 4696838 bad inode format in inode 4696838 bad magic number 0x7dbd on inode 4696839 bad version number 0xfffffff8 on inode 4696839 bad (negative) size -6560157850196179200 on inode 4696839 bad magic number 0x97d3 on inode 4696840 bad version number 0x33 on inode 4696840 bad (negative) size -7787105825959941577 on inode 4696840 bad magic number 0xd7ae on inode 4696841 bad version number 0xb on inode 4696841 bad inode format in inode 4696841 bad magic number 0xc1a9 on inode 4696842 bad version number 0x53 on inode 4696842 bad (negative) size -2958217973308288664 on inode 4696842 bad magic number 0xc2a1 on inode 4696843 bad version number 0xffffff91 on inode 4696843 bad (negative) size -7376067000055535784 on inode 4696843 bad magic number 0x7bac on inode 4696844 bad version number 0x33 on inode 4696844 bad (negative) size -3706553989636156139 on inode 4696844 bad magic number 0x6452 on inode 4696845 bad version number 0x19 on inode 4696845 bad inode format in inode 4696845 bad magic number 0x5cf1 on inode 4696846 bad version number 0xffffffc2 on inode 4696846 bad (negative) size -7733755121575070301 on inode 4696846 bad magic number 0x8261 on inode 4696847 bad version number 0x53 on inode 4696847 bad inode format in inode 4696847 bad magic number 0x48e5 on inode 4696848 bad version number 0xf on inode 4696848 bad inode format in inode 4696848 bad magic number 0x2c25 on inode 4696849 bad version number 0x1d on inode 4696849 bad inode format in inode 4696849 bad magic number 0x5ef6 on inode 4696850 bad version number 0x6 on inode 4696850 bad inode format in inode 4696850 bad magic number 0x2ba3 on inode 4696851 bad version number 0x2a on inode 4696851 bad (negative) size -5684323540944629986 on inode 4696851 bad magic number 0x232 on inode 4696852 bad version number 0x6f on inode 4696852 bad (negative) size -71952616007791776 on inode 4696852 bad magic number 0x7690 on inode 4696853 bad version number 0x12 on inode 4696853 bad (negative) size -4823993805931009936 on inode 4696853 bad magic number 0xbd64 on inode 4696854 bad version number 0x2b on inode 4696854 bad (negative) size -6582397123660611335 on inode 4696854 bad magic number 0x3ea7 on inode 4696855 bad version number 0x7e on inode 4696855 bad (negative) size -8124608134174992440 on inode 4696855 bad magic number 0x5a9f on inode 4696856 bad version number 0x53 on inode 4696856 bad inode format in inode 4696856 bad magic number 0x1169 on inode 4696857 bad version number 0x71 on inode 4696857 bad inode format in inode 4696857 bad magic number 0x2bfe on inode 4696858 bad version number 0xffffffe9 on inode 4696858 bad (negative) size -6531012913831338205 on inode 4696858 bad magic number 0xeadc on inode 4696859 bad version number 0xffffff83 on inode 4696859 bad inode format in inode 4696859 bad magic number 0x3847 on inode 4696860 bad version number 0x52 on inode 4696860 bad (negative) size -5339233611634993493 on inode 4696860 bad magic number 0x6654 on inode 4696861 bad version number 0x18 on inode 4696861 bad (negative) size -6007487599903059365 on inode 4696861 bad magic number 0x368f on inode 4696862 bad version number 0x53 on inode 4696862 bad (negative) size -198511522378221350 on inode 4696862 bad magic number 0xfb6f on inode 4696863 bad version number 0xffffffb6 on inode 4696863 bad (negative) size -8042657965090581671 on inode 4696863 bad magic number 0x7556 on inode 4696864 bad version number 0xffffffc4 on inode 4696864 bad inode format in inode 4696864 bad magic number 0x7fcd on inode 4696865 bad version number 0x71 on inode 4696865 bad (negative) size -5633020866773444807 on inode 4696865 bad magic number 0xcd93 on inode 4696866 bad version number 0x1e on inode 4696866 bad inode format in inode 4696866 bad magic number 0xcdc5 on inode 4696867 bad version number 0xffffff80 on inode 4696867 bad inode format in inode 4696867 bad magic number 0x2891 on inode 4696868 bad version number 0x45 on inode 4696868 bad (negative) size -3545994611041057744 on inode 4696868 bad magic number 0xd7fd on inode 4696869 bad version number 0xffffffed on inode 4696869 bad inode format in inode 4696869 bad magic number 0x324c on inode 4696870 bad version number 0xffffffa4 on inode 4696870 bad inode format in inode 4696870 bad magic number 0x68 on inode 4696871 bad version number 0xffffffaa on inode 4696871 bad inode format in inode 4696871 bad magic number 0x6ded on inode 4696872 bad version number 0x2e on inode 4696872 bad inode format in inode 4696872 bad magic number 0x2484 on inode 4696873 bad version number 0xffffffa6 on inode 4696873 bad (negative) size -5883074587242442542 on inode 4696873 bad magic number 0x6463 on inode 4696874 bad version number 0x32 on inode 4696874 bad inode format in inode 4696874 bad magic number 0x2685 on inode 4696875 bad version number 0x1e on inode 4696875 bad inode format in inode 4696875 bad magic number 0x4c88 on inode 4696876 bad version number 0xffffffc5 on inode 4696876 bad (negative) size -2260471454543785599 on inode 4696876 bad magic number 0x85f8 on inode 4696877 bad version number 0x49 on inode 4696877 bad inode format in inode 4696877 bad magic number 0xe47d on inode 4696878 bad version number 0xffffffff on inode 4696878 bad inode format in inode 4696878 bad magic number 0x5401 on inode 4696879 bad version number 0xffffff93 on inode 4696879 bad (negative) size -8260358628900342415 on inode 4696879 bad magic number 0x32b on inode 4696880 bad version number 0xffffffec on inode 4696880 bad inode format in inode 4696880 bad magic number 0x59e1 on inode 4696881 bad version number 0x43 on inode 4696881 bad (negative) size -423399967766959799 on inode 4696881 bad magic number 0xfdab on inode 4696882 bad version number 0xffffffb4 on inode 4696882 bad (negative) size -6389879617698923924 on inode 4696882 bad magic number 0xabae on inode 4696883 bad version number 0x62 on inode 4696883 bad inode format in inode 4696883 bad magic number 0x40ab on inode 4696884 bad version number 0xffffffe1 on inode 4696884 bad (negative) size -3103283135321250110 on inode 4696884 bad magic number 0x284 on inode 4696885 bad version number 0xffffff90 on inode 4696885 bad (negative) size -1048583899049117828 on inode 4696885 bad magic number 0x63e4 on inode 4696886 bad version number 0x22 on inode 4696886 bad (negative) size -6237535588733841922 on inode 4696886 bad magic number 0xe22a on inode 4696887 bad version number 0x79 on inode 4696887 bad inode format in inode 4696887 bad magic number 0x6d3a on inode 4696888 bad version number 0xffffffa5 on inode 4696888 bad (negative) size -7782518352701664186 on inode 4696888 bad magic number 0x47fe on inode 4696889 bad version number 0xffffff81 on inode 4696889 bad (negative) size -7670873397812622770 on inode 4696889 bad magic number 0xb716 on inode 4696890 bad version number 0xb on inode 4696890 bad (negative) size -1977202013709318114 on inode 4696890 bad magic number 0xbf9a on inode 4696891 bad version number 0xffffff99 on inode 4696891 bad inode format in inode 4696891 bad magic number 0x23c6 on inode 4696892 bad version number 0x5b on inode 4696892 bad (negative) size -581318567581208715 on inode 4696892 bad magic number 0x994d on inode 4696893 bad version number 0xffffffc7 on inode 4696893 bad (negative) size -7970079813221372720 on inode 4696893 bad magic number 0x3049 on inode 4696894 bad version number 0x57 on inode 4696894 bad (negative) size -2106523635837440192 on inode 4696894 bad magic number 0xf on inode 4696895 bad version number 0x25 on inode 4696895 bad (negative) size -651442907403340256 on inode 4696895 bad magic number 0x5b44 on inode 4741440 bad version number 0x6b on inode 4741440 bad inode format in inode 4741440 bad magic number 0x0 on inode 4741441 bad version number 0x0 on inode 4741441 bad magic number 0x0 on inode 4741442 bad version number 0x0 on inode 4741442 bad magic number 0x0 on inode 4741443 bad version number 0x0 on inode 4741443 bad magic number 0x0 on inode 4741444 bad version number 0x0 on inode 4741444 bad magic number 0x0 on inode 4741445 bad version number 0x0 on inode 4741445 bad magic number 0x0 on inode 4741446 bad version number 0x0 on inode 4741446 bad magic number 0x0 on inode 4741447 bad version number 0x0 on inode 4741447 bad magic number 0x0 on inode 4741448 bad version number 0x0 on inode 4741448 bad magic number 0x0 on inode 4741449 bad version number 0x0 on inode 4741449 bad magic number 0x0 on inode 4741450 bad version number 0x0 on inode 4741450 bad magic number 0x0 on inode 4741451 bad version number 0x0 on inode 4741451 bad magic number 0x0 on inode 4741452 bad version number 0x0 on inode 4741452 bad magic number 0x0 on inode 4741453 bad version number 0x0 on inode 4741453 bad magic number 0x0 on inode 4741454 bad version number 0x0 on inode 4741454 bad magic number 0x0 on inode 4741455 bad version number 0x0 on inode 4741455 bad magic number 0xe52f on inode 4741456 bad version number 0x51 on inode 4741456 bad (negative) size -5054255942920167661 on inode 4741456 bad magic number 0x7c72 on inode 4741457 bad version number 0x2a on inode 4741457 bad inode format in inode 4741457 bad magic number 0x9e15 on inode 4741458 bad version number 0x67 on inode 4741458 bad inode format in inode 4741458 bad magic number 0xbf3e on inode 4741459 bad version number 0xffffffac on inode 4741459 bad (negative) size -5687184310110077733 on inode 4741459 bad magic number 0x4d0 on inode 4741460 bad version number 0xffffffd4 on inode 4741460 bad (negative) size -1781620305818635922 on inode 4741460 bad magic number 0xd3da on inode 4741461 bad version number 0x6d on inode 4741461 bad inode format in inode 4741461 bad magic number 0x2800 on inode 4741462 bad version number 0xffffff8c on inode 4741462 bad (negative) size -9037296471894110488 on inode 4741462 bad magic number 0x16d3 on inode 4741463 bad version number 0x2b on inode 4741463 bad inode format in inode 4741463 bad magic number 0x365a on inode 4741464 bad version number 0x5c on inode 4741464 bad inode format in inode 4741464 bad magic number 0xb2fc on inode 4741465 bad version number 0xffffffd2 on inode 4741465 bad (negative) size -1929400731465064095 on inode 4741465 bad magic number 0x9eb8 on inode 4741466 bad version number 0x38 on inode 4741466 bad inode format in inode 4741466 bad magic number 0x5874 on inode 4741467 bad version number 0x55 on inode 4741467 bad (negative) size -7671672394197834114 on inode 4741467 bad magic number 0x7d46 on inode 4741468 bad version number 0xd on inode 4741468 bad (negative) size -6903090978179456443 on inode 4741468 bad magic number 0x71b6 on inode 4741469 bad version number 0xffffffaa on inode 4741469 bad (negative) size -623813037168375523 on inode 4741469 bad magic number 0xdc89 on inode 4741470 bad version number 0xffffffa4 on inode 4741470 bad (negative) size -6061616813969730972 on inode 4741470 bad magic number 0xf05 on inode 4741471 bad version number 0x40 on inode 4741471 bad (negative) size -798100747247050899 on inode 4741471 bad magic number 0x5b44 on inode 4741440, resetting magic number bad version number 0x6b on inode 4741440, resetting version number bad inode format in inode 4741440 cleared inode 4741440 bad magic number 0x0 on inode 4741441, resetting magic number bad version number 0x0 on inode 4741441, resetting version number imap claims a free inode 4741441 is in use, correcting imap and clearing inode cleared inode 4741441 bad magic number 0x0 on inode 4741442, resetting magic number bad version number 0x0 on inode 4741442, resetting version number imap claims a free inode 4741442 is in use, correcting imap and clearing inode cleared inode 4741442 bad magic number 0x0 on inode 4741443, resetting magic number bad version number 0x0 on inode 4741443, resetting version number imap claims a free inode 4741443 is in use, correcting imap and clearing inode cleared inode 4741443 bad magic number 0x0 on inode 4741444, resetting magic number bad version number 0x0 on inode 4741444, resetting version number imap claims a free inode 4741444 is in use, correcting imap and clearing inode cleared inode 4741444 bad magic number 0x0 on inode 4741445, resetting magic number bad version number 0x0 on inode 4741445, resetting version number imap claims a free inode 4741445 is in use, correcting imap and clearing inode cleared inode 4741445 bad magic number 0x0 on inode 4741446, resetting magic number bad version number 0x0 on inode 4741446, resetting version number imap claims a free inode 4741446 is in use, correcting imap and clearing inode cleared inode 4741446 bad magic number 0x0 on inode 4741447, resetting magic number bad version number 0x0 on inode 4741447, resetting version number imap claims a free inode 4741447 is in use, correcting imap and clearing inode cleared inode 4741447 bad magic number 0x0 on inode 4741448, resetting magic number bad version number 0x0 on inode 4741448, resetting version number imap claims a free inode 4741448 is in use, correcting imap and clearing inode cleared inode 4741448 bad magic number 0x0 on inode 4741449, resetting magic number bad version number 0x0 on inode 4741449, resetting version number imap claims a free inode 4741449 is in use, correcting imap and clearing inode cleared inode 4741449 bad magic number 0x0 on inode 4741450, resetting magic number bad version number 0x0 on inode 4741450, resetting version number imap claims a free inode 4741450 is in use, correcting imap and clearing inode cleared inode 4741450 bad magic number 0x0 on inode 4741451, resetting magic number bad version number 0x0 on inode 4741451, resetting version number imap claims a free inode 4741451 is in use, correcting imap and clearing inode cleared inode 4741451 bad magic number 0x0 on inode 4741452, resetting magic number bad version number 0x0 on inode 4741452, resetting version number imap claims a free inode 4741452 is in use, correcting imap and clearing inode cleared inode 4741452 bad magic number 0x0 on inode 4741453, resetting magic number bad version number 0x0 on inode 4741453, resetting version number imap claims a free inode 4741453 is in use, correcting imap and clearing inode cleared inode 4741453 bad magic number 0x0 on inode 4741454, resetting magic number bad version number 0x0 on inode 4741454, resetting version number imap claims a free inode 4741454 is in use, correcting imap and clearing inode cleared inode 4741454 bad magic number 0x0 on inode 4741455, resetting magic number bad version number 0x0 on inode 4741455, resetting version number imap claims a free inode 4741455 is in use, correcting imap and clearing inode cleared inode 4741455 bad magic number 0xe52f on inode 4741456, resetting magic number bad version number 0x51 on inode 4741456, resetting version number bad (negative) size -5054255942920167661 on inode 4741456 cleared inode 4741456 bad magic number 0x7c72 on inode 4741457, resetting magic number bad version number 0x2a on inode 4741457, resetting version number bad inode format in inode 4741457 cleared inode 4741457 bad magic number 0x9e15 on inode 4741458, resetting magic number bad version number 0x67 on inode 4741458, resetting version number bad inode format in inode 4741458 cleared inode 4741458 bad magic number 0xbf3e on inode 4741459, resetting magic number bad version number 0xffffffac on inode 4741459, resetting version number bad (negative) size -5687184310110077733 on inode 4741459 cleared inode 4741459 bad magic number 0x4d0 on inode 4741460, resetting magic number bad version number 0xffffffd4 on inode 4741460, resetting version number bad (negative) size -1781620305818635922 on inode 4741460 cleared inode 4741460 bad magic number 0xd3da on inode 4741461, resetting magic number bad version number 0x6d on inode 4741461, resetting version number bad inode format in inode 4741461 cleared inode 4741461 bad magic number 0x2800 on inode 4741462, resetting magic number bad version number 0xffffff8c on inode 4741462, resetting version number bad (negative) size -9037296471894110488 on inode 4741462 cleared inode 4741462 bad magic number 0x16d3 on inode 4741463, resetting magic number bad version number 0x2b on inode 4741463, resetting version number bad inode format in inode 4741463 cleared inode 4741463 bad magic number 0x365a on inode 4741464, resetting magic number bad version number 0x5c on inode 4741464, resetting version number bad inode format in inode 4741464 cleared inode 4741464 bad magic number 0xb2fc on inode 4741465, resetting magic number bad version number 0xffffffd2 on inode 4741465, resetting version number bad (negative) size -1929400731465064095 on inode 4741465 cleared inode 4741465 bad magic number 0x9eb8 on inode 4741466, resetting magic number bad version number 0x38 on inode 4741466, resetting version number bad inode format in inode 4741466 cleared inode 4741466 bad magic number 0x5874 on inode 4741467, resetting magic number bad version number 0x55 on inode 4741467, resetting version number bad (negative) size -7671672394197834114 on inode 4741467 cleared inode 4741467 bad magic number 0x7d46 on inode 4741468, resetting magic number bad version number 0xd on inode 4741468, resetting version number bad (negative) size -6903090978179456443 on inode 4741468 cleared inode 4741468 bad magic number 0x71b6 on inode 4741469, resetting magic number bad version number 0xffffffaa on inode 4741469, resetting version number bad (negative) size -623813037168375523 on inode 4741469 cleared inode 4741469 bad magic number 0xdc89 on inode 4741470, resetting magic number bad version number 0xffffffa4 on inode 4741470, resetting version number bad (negative) size -6061616813969730972 on inode 4741470 cleared inode 4741470 bad magic number 0xf05 on inode 4741471, resetting magic number bad version number 0x40 on inode 4741471, resetting version number bad (negative) size -798100747247050899 on inode 4741471 cleared inode 4741471 - 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 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - clear lost+found (if it exists) ... - check for inodes claiming duplicate blocks... - agno = 0 entry "ER" at block 0 offset 48 in directory inode 403216 references non-existent inode 4696835 clearing inode number in entry at offset 48... entry "cgi-examples" at block 0 offset 48 in directory inode 411522 references non-existent inode 4696880 clearing inode number in entry at offset 48... entry "examples" at block 0 offset 48 in directory inode 411564 references non-existent inode 4696891 clearing inode number in entry at offset 48... - agno = 1 entry "X-Debian-Apps-System-kde_system_guard.desktop" at block 2 offset 2968 in directory inode 4206355 references free inode 4696704 clearing inode number in entry at offset 2968... entry "X-Debian-Apps-System-kde_system_guard_-_process_table.desktop" at block 2 offset 3024 in directory inode 4206355 references free inode 4696705 clearing inode number in entry at offset 3024... entry "X-Debian-Apps-System-kde_sysv-init_editor.desktop" at block 2 offset 3096 in directory inode 4206355 references free inode 4696706 clearing inode number in entry at offset 3096... entry "X-Debian-Apps-System-kde_task_scheduler.desktop" at block 2 offset 3160 in directory inode 4206355 references free inode 4696707 clearing inode number in entry at offset 3160... entry "X-Debian-Apps-System-kde_user_manager.desktop" at block 2 offset 3224 in directory inode 4206355 references free inode 4696708 clearing inode number in entry at offset 3224... entry "X-Debian-Apps-System-kdiskfree.desktop" at block 2 offset 3280 in directory inode 4206355 references free inode 4696709 clearing inode number in entry at offset 3280... entry "X-Debian-Apps-System-keditbookmarks.desktop" at block 2 offset 3336 in directory inode 4206355 references free inode 4696710 clearing inode number in entry at offset 3336... entry "X-Debian-Apps-System-kfind.desktop" at block 2 offset 3392 in directory inode 4206355 references free inode 4696711 clearing inode number in entry at offset 3392... entry "X-Debian-Apps-System-kfloppy.desktop" at block 2 offset 3440 in directory inode 4206355 references free inode 4696712 clearing inode number in entry at offset 3440... entry "X-Debian-Apps-System-kicker.desktop" at block 2 offset 3488 in directory inode 4206355 references free inode 4696713 clearing inode number in entry at offset 3488... entry "X-Debian-Apps-System-kinfocenter.desktop" at block 2 offset 3536 in directory inode 4206355 references free inode 4696714 clearing inode number in entry at offset 3536... entry "X-Debian-Apps-System-kjobviewer.desktop" at block 2 offset 3592 in directory inode 4206355 references free inode 4696715 clearing inode number in entry at offset 3592... entry "X-Debian-Apps-System-kmenuedit.desktop" at block 2 offset 3648 in directory inode 4206355 references free inode 4696716 clearing inode number in entry at offset 3648... entry "X-Debian-Apps-System-konqueror.desktop" at block 2 offset 3704 in directory inode 4206355 references free inode 4696717 clearing inode number in entry at offset 3704... entry "X-Debian-Apps-System-kpersonalizer.desktop" at block 2 offset 3760 in directory inode 4206355 references free inode 4696718 clearing inode number in entry at offset 3760... entry "X-Debian-Apps-System-kprinter.desktop" at block 2 offset 3816 in directory inode 4206355 references free inode 4696719 clearing inode number in entry at offset 3816... entry "X-Debian-Apps-System-kwikdisk.desktop" at block 2 offset 3864 in directory inode 4206355 references free inode 4696720 clearing inode number in entry at offset 3864... entry "X-Debian-Apps-System-Language-Environment-belarusian_environment.desktop" at block 2 offset 3912 in directory inode 4206355 references free inode 4696721 clearing inode number in entry at offset 3912... entry "X-Debian-Apps-System-Language-Environment-bulgarian_environment.desktop" at block 2 offset 4000 in directory inode 4206355 references free inode 4696722 clearing inode number in entry at offset 4000... entry "X-Debian-Apps-System-Language-Environment-catalan_environment.desktop" at block 3 offset 16 in directory inode 4206355 references free inode 4696723 clearing inode number in entry at offset 16... entry "X-Debian-Apps-System-Language-Environment-danish_environment.desktop" at block 3 offset 96 in directory inode 4206355 references free inode 4696724 clearing inode number in entry at offset 96... entry "X-Debian-Apps-System-Language-Environment-french_environment.desktop" at block 3 offset 176 in directory inode 4206355 references free inode 4696725 clearing inode number in entry at offset 176... entry "X-Debian-Apps-System-Language-Environment-german_environment.desktop" at block 3 offset 256 in directory inode 4206355 references free inode 4696726 clearing inode number in entry at offset 256... entry "X-Debian-Apps-System-Language-Environment-japanese_environment.desktop" at block 3 offset 336 in directory inode 4206355 references free inode 4696727 clearing inode number in entry at offset 336... entry "X-Debian-Apps-System-Language-Environment-korean_environment.desktop" at block 3 offset 424 in directory inode 4206355 references free inode 4696728 clearing inode number in entry at offset 424... entry "X-Debian-Apps-System-Language-Environment-lithuanian_environment.desktop" at block 3 offset 504 in directory inode 4206355 references free inode 4696729 clearing inode number in entry at offset 504... entry "X-Debian-Apps-System-Language-Environment-macedonian_environment.desktop" at block 3 offset 592 in directory inode 4206355 references free inode 4696730 clearing inode number in entry at offset 592... entry "X-Debian-Apps-System-Language-Environment-native_language_environment.desktop" at block 3 offset 680 in directory inode 4206355 references free inode 4696731 clearing inode number in entry at offset 680... entry "X-Debian-Apps-System-Language-Environment-native_language_environment_-_remove.desktop" at block 3 offset 768 in directory inode 4206355 references free inode 4696732 clearing inode number in entry at offset 768... entry "X-Debian-Apps-System-Language-Environment-polish_environment.desktop" at block 3 offset 872 in directory inode 4206355 references free inode 4696733 clearing inode number in entry at offset 872... entry "X-Debian-Apps-System-Language-Environment-russian_environment.desktop" at block 3 offset 952 in directory inode 4206355 references free inode 4696734 clearing inode number in entry at offset 952... entry "X-Debian-Apps-System-Language-Environment-serbian_environment.desktop" at block 3 offset 1032 in directory inode 4206355 references free inode 4696735 clearing inode number in entry at offset 1032... entry "X-Debian-Apps-System-Language-Environment-spanish_environment.desktop" at block 3 offset 1112 in directory inode 4206355 references non-existent inode 4696747 clearing inode number in entry at offset 1112... entry "X-Debian-Apps-System-Language-Environment-thai_environment.desktop" at block 3 offset 1192 in directory inode 4206355 references non-existent inode 4696748 clearing inode number in entry at offset 1192... entry "X-Debian-Apps-System-Language-Environment-turkish_environment.desktop" at block 3 offset 1272 in directory inode 4206355 references non-existent inode 4696749 clearing inode number in entry at offset 1272... entry "X-Debian-Apps-System-Language-Environment-ukrainian_environment.desktop" at block 3 offset 1352 in directory inode 4206355 references non-existent inode 4696750 clearing inode number in entry at offset 1352... entry "X-Debian-Apps-System-nautilus.desktop" at block 3 offset 1440 in directory inode 4206355 references non-existent inode 4696751 clearing inode number in entry at offset 1440... entry "X-Debian-Apps-System-print_notification_icon.desktop" at block 3 offset 1488 in directory inode 4206355 references non-existent inode 4696752 clearing inode number in entry at offset 1488... entry "X-Debian-Apps-System-pstree.desktop" at block 3 offset 1552 in directory inode 4206355 references non-existent inode 4696753 clearing inode number in entry at offset 1552... entry "X-Debian-Apps-System-qt3_assistant.desktop" at block 3 offset 1600 in directory inode 4206355 references non-existent inode 4696754 clearing inode number in entry at offset 1600... entry "X-Debian-Apps-System-reportbug.desktop" at block 3 offset 1656 in directory inode 4206355 references non-existent inode 4696755 clearing inode number in entry at offset 1656... entry "X-Debian-Apps-System-run_as_different_user_(gksu).desktop" at block 3 offset 1712 in directory inode 4206355 references non-existent inode 4696756 clearing inode number in entry at offset 1712... entry "X-Debian-Apps-System-sun_java_5.0_plugin_control_panel.desktop" at block 3 offset 1784 in directory inode 4206355 references non-existent inode 4696757 clearing inode number in entry at offset 1784... entry "X-Debian-Apps-System-sun_java_5.0_policy_tool.desktop" at block 3 offset 1864 in directory inode 4206355 references non-existent inode 4696758 clearing inode number in entry at offset 1864... entry "X-Debian-Apps-System-task_selector.desktop" at block 3 offset 1928 in directory inode 4206355 references non-existent inode 4696759 clearing inode number in entry at offset 1928... entry "X-Debian-Apps-System-texconfig.desktop" at block 3 offset 1984 in directory inode 4206355 references non-existent inode 4696760 clearing inode number in entry at offset 1984... entry "X-Debian-Apps-System-top.desktop" at block 3 offset 2040 in directory inode 4206355 references non-existent inode 4696761 clearing inode number in entry at offset 2040... entry "X-Debian-Apps-System-x-terminal_as_root_(gksu).desktop" at block 3 offset 2088 in directory inode 4206355 references non-existent inode 4696762 clearing inode number in entry at offset 2088... entry "X-Debian-Apps-Technical-debtags-edit.desktop" at block 3 offset 2160 in directory inode 4206355 references non-existent inode 4696763 clearing inode number in entry at offset 2160... entry "X-Debian-Apps-Text-freemind.desktop" at block 3 offset 2216 in directory inode 4206355 references non-existent inode 4696764 clearing inode number in entry at offset 2216... entry "X-Debian-Apps-Text-gnome_dictionary.desktop" at block 3 offset 2264 in directory inode 4206355 references non-existent inode 4696765 clearing inode number in entry at offset 2264... entry "X-Debian-Apps-Text-info_browser.desktop" at block 3 offset 2320 in directory inode 4206355 references non-existent inode 4696766 clearing inode number in entry at offset 2320... entry "X-Debian-Apps-Text-kbabel.desktop" at block 3 offset 2376 in directory inode 4206355 references non-existent inode 4696767 clearing inode number in entry at offset 2376... entry "X-Debian-Apps-Text-kbabel_catalog_manager.desktop" at block 3 offset 2424 in directory inode 4206355 references non-existent inode 4696768 clearing inode number in entry at offset 2424... entry "X-Debian-Apps-Text-kbabel_dictionary.desktop" at block 3 offset 2488 in directory inode 4206355 references non-existent inode 4696769 clearing inode number in entry at offset 2488... entry "X-Debian-Apps-Text-kxsldbg.desktop" at block 3 offset 2544 in directory inode 4206355 references non-existent inode 4696770 clearing inode number in entry at offset 2544... entry "X-Debian-Apps-Text-xdialog.desktop" at block 3 offset 2592 in directory inode 4206355 references non-existent inode 4696771 clearing inode number in entry at offset 2592... entry "X-Debian-Apps-Tools-ark.desktop" at block 3 offset 2640 in directory inode 4206355 references non-existent inode 4696772 clearing inode number in entry at offset 2640... entry "X-Debian-Apps-Tools-driconf.desktop" at block 3 offset 2688 in directory inode 4206355 references non-existent inode 4696773 clearing inode number in entry at offset 2688... entry "X-Debian-Apps-Tools-dvdisaster.desktop" at block 3 offset 2736 in directory inode 4206355 references non-existent inode 4696774 clearing inode number in entry at offset 2736... entry "X-Debian-Apps-Tools-file-roller.desktop" at block 3 offset 2792 in directory inode 4206355 references non-existent inode 4696775 clearing inode number in entry at offset 2792... entry "X-Debian-Apps-Tools-gnomepgp.desktop" at block 3 offset 2848 in directory inode 4206355 references non-existent inode 4696776 clearing inode number in entry at offset 2848... entry "X-Debian-Apps-Tools-gnome_screenshot_tool.desktop" at block 3 offset 2896 in directory inode 4206355 references non-existent inode 4696777 clearing inode number in entry at offset 2896... entry "X-Debian-Apps-Tools-gnome_search_tool.desktop" at block 3 offset 2960 in directory inode 4206355 references non-existent inode 4696778 clearing inode number in entry at offset 2960... entry "X-Debian-Apps-Tools-gnucash.desktop" at block 3 offset 3016 in directory inode 4206355 references non-existent inode 4696779 clearing inode number in entry at offset 3016... entry "X-Debian-Apps-Tools-k3b.desktop" at block 3 offset 3064 in directory inode 4206355 references non-existent inode 4696780 clearing inode number in entry at offset 3064... entry "X-Debian-Apps-Tools-kaddressbook.desktop" at block 3 offset 3112 in directory inode 4206355 references non-existent inode 4696781 clearing inode number in entry at offset 3112... entry "X-Debian-Apps-Tools-kalarm.desktop" at block 3 offset 3168 in directory inode 4206355 references non-existent inode 4696782 clearing inode number in entry at offset 3168... entry "X-Debian-Apps-Tools-kandy.desktop" at block 3 offset 3216 in directory inode 4206355 references non-existent inode 4696783 clearing inode number in entry at offset 3216... entry "X-Debian-Apps-Tools-karm.desktop" at block 3 offset 3264 in directory inode 4206355 references non-existent inode 4696784 clearing inode number in entry at offset 3264... entry "X-Debian-Apps-Tools-kcharselect.desktop" at block 3 offset 3312 in directory inode 4206355 references non-existent inode 4696785 clearing inode number in entry at offset 3312... entry "X-Debian-Apps-Tools-kdissert.desktop" at block 3 offset 3368 in directory inode 4206355 references non-existent inode 4696786 clearing inode number in entry at offset 3368... entry "X-Debian-Apps-Tools-kgpg.desktop" at block 3 offset 3416 in directory inode 4206355 references non-existent inode 4696787 clearing inode number in entry at offset 3416... entry "X-Debian-Apps-Tools-khexedit.desktop" at block 3 offset 3464 in directory inode 4206355 references non-existent inode 4696788 clearing inode number in entry at offset 3464... entry "X-Debian-Apps-Tools-kitchensync.desktop" at block 3 offset 3512 in directory inode 4206355 references non-existent inode 4696789 clearing inode number in entry at offset 3512... entry "X-Debian-Apps-Tools-kivio.desktop" at block 3 offset 3568 in directory inode 4206355 references non-existent inode 4696790 clearing inode number in entry at offset 3568... entry "X-Debian-Apps-Tools-kjots.desktop" at block 3 offset 3616 in directory inode 4206355 references non-existent inode 4696791 clearing inode number in entry at offset 3616... entry "X-Debian-Apps-Tools-klipper.desktop" at block 3 offset 3664 in directory inode 4206355 references non-existent inode 4696792 clearing inode number in entry at offset 3664... entry "X-Debian-Apps-Tools-kmag.desktop" at block 3 offset 3712 in directory inode 4206355 references non-existent inode 4696793 clearing inode number in entry at offset 3712... entry "X-Debian-Apps-Tools-kmousetool.desktop" at block 3 offset 3760 in directory inode 4206355 references non-existent inode 4696794 clearing inode number in entry at offset 3760... entry "X-Debian-Apps-Tools-kmouth.desktop" at block 3 offset 3816 in directory inode 4206355 references non-existent inode 4696795 clearing inode number in entry at offset 3816... entry "X-Debian-Apps-Tools-kmymoney.desktop" at block 3 offset 3864 in directory inode 4206355 references non-existent inode 4696796 clearing inode number in entry at offset 3864... entry "X-Debian-Apps-Tools-knotes.desktop" at block 3 offset 3912 in directory inode 4206355 references non-existent inode 4696797 clearing inode number in entry at offset 3912... entry "X-Debian-Apps-Tools-koffice_workspace.desktop" at block 3 offset 3960 in directory inode 4206355 references non-existent inode 4696798 clearing inode number in entry at offset 3960... entry "X-Debian-Apps-Tools-kommander_editor.desktop" at block 3 offset 4016 in directory inode 4206355 references non-existent inode 4696799 clearing inode number in entry at offset 4016... entry "X-Debian-Apps-Tools-kontact.desktop" at block 4 offset 16 in directory inode 4206355 references non-existent inode 4696837 clearing inode number in entry at offset 16... entry "X-Debian-Apps-Tools-korganizer.desktop" at block 4 offset 64 in directory inode 4206355 references non-existent inode 4696841 clearing inode number in entry at offset 64... entry "X-Debian-Apps-Tools-kpager.desktop" at block 4 offset 120 in directory inode 4206355 references non-existent inode 4696845 clearing inode number in entry at offset 120... entry "X-Debian-Apps-Tools-kpalmdoc.desktop" at block 4 offset 168 in directory inode 4206355 references non-existent inode 4696846 clearing inode number in entry at offset 168... entry "X-Debian-Apps-Tools-kpilot.desktop" at block 4 offset 216 in directory inode 4206355 references non-existent inode 4696847 clearing inode number in entry at offset 216... entry "X-Debian-Apps-Tools-kpresenter.desktop" at block 4 offset 264 in directory inode 4206355 references non-existent inode 4696848 clearing inode number in entry at offset 264... entry "X-Debian-Apps-Tools-kregexpeditor.desktop" at block 4 offset 320 in directory inode 4206355 references non-existent inode 4696849 clearing inode number in entry at offset 320... entry "X-Debian-Apps-Tools-ksayit.desktop" at block 4 offset 376 in directory inode 4206355 references non-existent inode 4696850 clearing inode number in entry at offset 376... entry "X-Debian-Apps-Tools-ksync.desktop" at block 4 offset 424 in directory inode 4206355 references non-existent inode 4696851 clearing inode number in entry at offset 424... entry "X-Debian-Apps-Tools-kthesaurus.desktop" at block 4 offset 472 in directory inode 4206355 references non-existent inode 4696852 clearing inode number in entry at offset 472... entry "X-Debian-Apps-Tools-ktimer.desktop" at block 4 offset 528 in directory inode 4206355 references non-existent inode 4696853 clearing inode number in entry at offset 528... entry "X-Debian-Apps-Tools-ktip.desktop" at block 4 offset 576 in directory inode 4206355 references non-existent inode 4696854 clearing inode number in entry at offset 576... entry "X-Debian-Apps-Tools-ktnef.desktop" at block 4 offset 624 in directory inode 4206355 references non-existent inode 4696855 clearing inode number in entry at offset 624... entry "X-Debian-Apps-Tools-kugar.desktop" at block 4 offset 672 in directory inode 4206355 references non-existent inode 4696856 clearing inode number in entry at offset 672... entry "X-Debian-Apps-Tools-kugar_designer.desktop" at block 4 offset 720 in directory inode 4206355 references non-existent inode 4696857 clearing inode number in entry at offset 720... entry "X-Debian-Apps-Tools-kwatchgnupg.desktop" at block 4 offset 776 in directory inode 4206355 references non-existent inode 4696858 clearing inode number in entry at offset 776... entry "X-Debian-Apps-Tools-mc.desktop" at block 4 offset 832 in directory inode 4206355 references non-existent inode 4696859 clearing inode number in entry at offset 832... entry "X-Debian-Apps-Tools-movixmaker-2.desktop" at block 4 offset 880 in directory inode 4206355 references non-existent inode 4696860 clearing inode number in entry at offset 880... entry "X-Debian-Apps-Tools-mtink.desktop" at block 4 offset 936 in directory inode 4206355 references non-existent inode 4696861 clearing inode number in entry at offset 936... entry "X-Debian-Apps-Tools-mtinkc.desktop" at block 4 offset 984 in directory inode 4206355 references non-existent inode 4696862 clearing inode number in entry at offset 984... entry "X-Debian-Apps-Tools-multisynk.desktop" at block 4 offset 1032 in directory inode 4206355 references non-existent inode 4696863 clearing inode number in entry at offset 1032... entry "X-Debian-Apps-Tools-planner.desktop" at block 4 offset 1080 in directory inode 4206355 references non-existent inode 4696864 clearing inode number in entry at offset 1080... entry "X-Debian-Apps-Tools-superkaramba.desktop" at block 4 offset 1128 in directory inode 4206355 references non-existent inode 4696865 clearing inode number in entry at offset 1128... entry "X-Debian-Apps-Tools-texfind.desktop" at block 4 offset 1184 in directory inode 4206355 references non-existent inode 4696866 clearing inode number in entry at offset 1184... entry "X-Debian-Apps-Tools-the_gnu_privacy_assistant.desktop" at block 4 offset 1232 in directory inode 4206355 references non-existent inode 4696867 clearing inode number in entry at offset 1232... entry "X-Debian-Apps-Tools-unison_2.13.16_(gtk).desktop" at block 4 offset 1296 in directory inode 4206355 references non-existent inode 4696868 clearing inode number in entry at offset 1296... entry "X-Debian-Apps-Tools-wordnet.desktop" at block 4 offset 1360 in directory inode 4206355 references non-existent inode 4696869 clearing inode number in entry at offset 1360... entry "X-Debian-Apps-Tools-worker.desktop" at block 4 offset 1408 in directory inode 4206355 references non-existent inode 4696870 clearing inode number in entry at offset 1408... entry "X-Debian-Apps-Viewers-digikam.desktop" at block 4 offset 1456 in directory inode 4206355 references non-existent inode 4696871 clearing inode number in entry at offset 1456... entry "X-Debian-Apps-Viewers-evince.desktop" at block 4 offset 1504 in directory inode 4206355 references non-existent inode 4696872 clearing inode number in entry at offset 1504... entry "X-Debian-Apps-Viewers-eye_of_gnome.desktop" at block 4 offset 1552 in directory inode 4206355 references non-existent inode 4696873 clearing inode number in entry at offset 1552... entry "X-Debian-Apps-Viewers-gnome_ghostscript_viewer.desktop" at block 4 offset 1608 in directory inode 4206355 references non-existent inode 4696874 clearing inode number in entry at offset 1608... entry "X-Debian-Apps-Viewers-gwenview.desktop" at block 4 offset 1680 in directory inode 4206355 references non-existent inode 4696875 clearing inode number in entry at offset 1680... entry "X-Debian-Apps-Viewers-imagemagick.desktop" at block 4 offset 1736 in directory inode 4206355 references non-existent inode 4696876 clearing inode number in entry at offset 1736... entry "X-Debian-Apps-Viewers-kdvi.desktop" at block 4 offset 1792 in directory inode 4206355 references non-existent inode 4696881 clearing inode number in entry at offset 1792... entry "X-Debian-Apps-Viewers-kghostview.desktop" at block 4 offset 1840 in directory inode 4206355 references free inode 4741440 clearing inode number in entry at offset 1840... entry "X-Debian-Apps-Viewers-kview.desktop" at block 4 offset 1896 in directory inode 4206355 references free inode 4741441 clearing inode number in entry at offset 1896... entry "X-Debian-Apps-Viewers-mplayer.desktop" at block 4 offset 1944 in directory inode 4206355 references free inode 4741442 clearing inode number in entry at offset 1944... entry "kdeprint_uploadsmb.png" in shortform directory 4659682 references non-existent inode 4696843 junking entry "kdeprint_uploadsmb.png" in directory inode 4659682 entry "fdl-notice.docbook" at block 0 offset 88 in directory inode 4665754 references non-existent inode 4696844 clearing inode number in entry at offset 88... entry "gpl-notice.docbook" at block 0 offset 160 in directory inode 4665754 references non-existent inode 4696877 clearing inode number in entry at offset 160... entry "help-menu.docbook" at block 0 offset 232 in directory inode 4665754 references non-existent inode 4696889 clearing inode number in entry at offset 232... entry "install-compile.docbook" at block 0 offset 312 in directory inode 4665754 references non-existent inode 4696890 clearing inode number in entry at offset 312... entry "install-intro.docbook" at block 0 offset 392 in directory inode 4665754 references non-existent inode 4696893 clearing inode number in entry at offset 392... entry "gs.defoma" in shortform directory 4678175 references non-existent inode 4696838 junking entry "gs.defoma" in directory inode 4678175 entry "libwmf0.2-7.defoma" in shortform directory 4678175 references non-existent inode 4696839 junking entry "libwmf0.2-7.defoma" in directory inode 4678175 entry "AUTHORS" in shortform directory 4725602 references free inode 4741458 junking entry "AUTHORS" in directory inode 4725602 entry "NEWS.gz" in shortform directory 4725602 references free inode 4741459 junking entry "NEWS.gz" in directory inode 4725602 entry "README" in shortform directory 4725602 references free inode 4741460 junking entry "README" in directory inode 4725602 entry "changelog.Debian.gz" in shortform directory 4725602 references free inode 4741461 junking entry "changelog.Debian.gz" in directory inode 4725602 entry "changelog.gz" in shortform directory 4725602 references free inode 4741462 junking entry "changelog.gz" in directory inode 4725602 entry "copyright" in shortform directory 4725602 references free inode 4741463 junking entry "copyright" in directory inode 4725602 entry "AUTHORS" in shortform directory 4725610 references free inode 4741465 junking entry "AUTHORS" in directory inode 4725610 entry "TODO" in shortform directory 4725610 references free inode 4741466 junking entry "TODO" in directory inode 4725610 entry "changelog.Debian.gz" in shortform directory 4725610 references free inode 4741467 junking entry "changelog.Debian.gz" in directory inode 4725610 entry "changelog.gz" in shortform directory 4725610 references free inode 4741468 junking entry "changelog.gz" in directory inode 4725610 entry "copyright" in shortform directory 4725610 references free inode 4741469 junking entry "copyright" in directory inode 4725610 entry "AUTHORS" in shortform directory 4725613 references free inode 4741470 junking entry "AUTHORS" in directory inode 4725613 entry "changelog.gz" in shortform directory 4725613 references free inode 4741471 junking entry "changelog.gz" in directory inode 4725613 entry "BINDINGS" at block 0 offset 80 in directory inode 4725620 references non-existent inode 4696832 clearing inode number in entry at offset 80... entry "MANUAL.gz" at block 0 offset 344 in directory inode 4725620 references non-existent inode 4696842 clearing inode number in entry at offset 344... entry "changelog.Debian.gz" at block 0 offset 720 in directory inode 4725620 references non-existent inode 4696736 clearing inode number in entry at offset 720... entry "changelog.gz" at block 0 offset 784 in directory inode 4725620 references non-existent inode 4696834 clearing inode number in entry at offset 784... entry "copyright" at block 0 offset 840 in directory inode 4725620 references non-existent inode 4696833 clearing inode number in entry at offset 840... entry "NEWS.gz" in shortform directory 4742534 references free inode 4741445 junking entry "NEWS.gz" in directory inode 4742534 entry "changelog.Debian.gz" in shortform directory 4742534 references free inode 4741446 junking entry "changelog.Debian.gz" in directory inode 4742534 entry "changelog.gz" in shortform directory 4742534 references free inode 4741444 junking entry "changelog.gz" in directory inode 4742534 entry "copyright" in shortform directory 4742534 references free inode 4741443 junking entry "copyright" in directory inode 4742534 entry "test-bad-si-3.1.7.xml" at block 0 offset 696 in directory inode 4742539 references non-existent inode 4696840 clearing inode number in entry at offset 696... entry "libc_47.html" at block 0 offset 2512 in directory inode 4747821 references free inode 4741447 clearing inode number in entry at offset 2512... entry "libc_48.html" at block 0 offset 2568 in directory inode 4747821 references free inode 4741448 clearing inode number in entry at offset 2568... - agno = 2 - agno = 3 - agno = 4 - agno = 5 entry "akregator" at block 0 offset 3664 in directory inode 23038736 references non-existent inode 4696879 clearing inode number in entry at offset 3664... entry "apt-doc" at block 1 offset 64 in directory inode 23038736 references non-existent inode 4696887 clearing inode number in entry at offset 64... entry "apt-utils" at block 1 offset 312 in directory inode 23038736 references non-existent inode 4696888 clearing inode number in entry at offset 312... entry "base-files" at block 1 offset 784 in directory inode 23038736 references non-existent inode 4696892 clearing inode number in entry at offset 784... - agno = 6 - agno = 7 - agno = 8 entry "inst22" at block 0 offset 224 in directory inode 34157084 references free inode 4741449 clearing inode number in entry at offset 224... entry "x11" at block 0 offset 552 in directory inode 34157084 references free inode 4741464 clearing inode number in entry at offset 552... - agno = 9 entry "programs" at block 0 offset 184 in directory inode 38609570 references non-existent inode 4696886 clearing inode number in entry at offset 184... - agno = 10 - agno = 11 entry "template" at block 0 offset 152 in directory inode 46427728 references non-existent inode 4696878 clearing inode number in entry at offset 152... - agno = 12 - agno = 13 entry "ja" in shortform directory 54773957 references non-existent inode 4696836 junking entry "ja" in directory inode 54773957 - agno = 14 - agno = 15 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - ensuring existence of lost+found directory - traversing filesystem starting at / ... rebuilding directory inode 4206355 rebuilding directory inode 23038736 rebuilding directory inode 4747821 rebuilding directory inode 4742539 rebuilding directory inode 34157084 rebuilding directory inode 4725620 rebuilding directory inode 411564 rebuilding directory inode 411522 rebuilding directory inode 38609570 rebuilding directory inode 46427728 rebuilding directory inode 403216 rebuilding directory inode 4665754 - traversal finished ... - traversing all unattached subtrees ... - traversals finished ... - moving disconnected inodes to lost+found ... disconnected inode 251, moving to lost+found disconnected inode 94417, moving to lost+found disconnected inode 94419, moving to lost+found disconnected inode 109353, moving to lost+found disconnected inode 109359, moving to lost+found disconnected inode 4725600, moving to lost+found disconnected inode 4725601, moving to lost+found disconnected inode 4725603, moving to lost+found disconnected inode 4725604, moving to lost+found disconnected inode 4725605, moving to lost+found disconnected inode 4725606, moving to lost+found disconnected inode 4725607, moving to lost+found disconnected inode 4725608, moving to lost+found disconnected inode 4725609, moving to lost+found disconnected inode 4725621, moving to lost+found disconnected inode 4725622, moving to lost+found disconnected inode 4725623, moving to lost+found disconnected inode 4725624, moving to lost+found disconnected inode 4725625, moving to lost+found disconnected inode 4725626, moving to lost+found disconnected inode 4725627, moving to lost+found disconnected inode 4725628, moving to lost+found disconnected inode 4725629, moving to lost+found disconnected inode 4725630, moving to lost+found disconnected inode 4725631, moving to lost+found disconnected inode 4725632, moving to lost+found disconnected inode 4725633, moving to lost+found disconnected inode 4725634, moving to lost+found disconnected inode 4725635, moving to lost+found disconnected inode 4725636, moving to lost+found disconnected inode 4725637, moving to lost+found disconnected inode 4725638, moving to lost+found disconnected inode 4725639, moving to lost+found disconnected inode 4725640, moving to lost+found disconnected inode 4725641, moving to lost+found disconnected inode 4725642, moving to lost+found disconnected inode 4725643, moving to lost+found disconnected inode 4725644, moving to lost+found disconnected inode 4725645, moving to lost+found disconnected inode 4725646, moving to lost+found disconnected inode 4725647, moving to lost+found disconnected inode 4725648, moving to lost+found disconnected inode 4725649, moving to lost+found disconnected inode 4725650, moving to lost+found disconnected inode 4725651, moving to lost+found disconnected inode 4725652, moving to lost+found disconnected inode 4725653, moving to lost+found disconnected inode 4725654, moving to lost+found disconnected inode 4725655, moving to lost+found disconnected inode 4725656, moving to lost+found disconnected inode 4725657, moving to lost+found disconnected inode 4725658, moving to lost+found disconnected inode 4725659, moving to lost+found disconnected inode 4725660, moving to lost+found disconnected inode 4725661, moving to lost+found disconnected inode 4725662, moving to lost+found disconnected inode 4725663, moving to lost+found disconnected inode 4742536, moving to lost+found disconnected inode 4742540, moving to lost+found disconnected inode 4742541, moving to lost+found disconnected inode 4742542, moving to lost+found disconnected inode 4742543, moving to lost+found disconnected inode 4742544, moving to lost+found disconnected dir inode 8635560, moving to lost+found disconnected dir inode 8635561, moving to lost+found disconnected inode 12586306, moving to lost+found disconnected inode 12586307, moving to lost+found disconnected inode 12586309, moving to lost+found disconnected dir inode 12849074, moving to lost+found disconnected dir inode 17184050, moving to lost+found disconnected dir inode 23070842, moving to lost+found disconnected inode 29473796, moving to lost+found disconnected inode 29841064, moving to lost+found disconnected inode 62914737, moving to lost+found disconnected inode 62914800, moving to lost+found disconnected inode 62916146, moving to lost+found disconnected inode 62928033, moving to lost+found disconnected inode 62928034, moving to lost+found disconnected inode 62928035, moving to lost+found disconnected inode 62928044, moving to lost+found disconnected inode 62928090, moving to lost+found disconnected inode 63309058, moving to lost+found disconnected inode 63309059, moving to lost+found disconnected inode 63309060, moving to lost+found disconnected inode 63309061, moving to lost+found disconnected inode 63309062, moving to lost+found disconnected inode 63309063, moving to lost+found disconnected inode 63309064, moving to lost+found disconnected inode 63309065, moving to lost+found Phase 7 - verify and correct link counts... resetting inode 403216 nlinks from 8 to 7 resetting inode 411522 nlinks from 9 to 8 resetting inode 411564 nlinks from 3 to 2 resetting inode 23038736 nlinks from 2156 to 2152 resetting inode 34157084 nlinks from 27 to 25 resetting inode 38609570 nlinks from 14 to 13 resetting inode 46427728 nlinks from 9 to 8 resetting inode 54773957 nlinks from 7 to 6 done ---------------------------------------------------------- That seemed way to much damage to me to repair it manually so I just did mkfs.xfs /dev/hda5 and started restoring my backup from 12 days ago via rsync which is currently running. Before that I put the barrier option in /etc/fstab on SUSE 10.1 additional to disabling write caching with hdparm (see above), since as written it uses a 2.6.16 kernel: LABEL=debian /mnt/debian xfs defaults,barrier 0 0 LABEL=home /mnt/debian-home xfs defaults,barrier 0 0 Since I didn?t yet find any documentation about it, I do not know whether thats correct. I copied /var/log/syslog from my debian partition to a save place before... and in the end it showed what happened as the kernel crashed down - not that I understand much of it: ---------------------------------------------------------- Jun 22 21:24:59 deepdance ntpd[28179]: adjusting local clock by 57.926997s Jun 22 21:29:14 deepdance ntpd[28179]: adjusting local clock by 57.606572s Jun 22 21:32:02 deepdance kernel: Unable to handle kernel paging request at virtual address 7558c487 Jun 22 21:32:02 deepdance kernel: printing eip: Jun 22 21:32:02 deepdance kernel: c0247b57 Jun 22 21:32:02 deepdance kernel: *pde = 00000000 Jun 22 21:32:02 deepdance kernel: Oops: 0000 [#1] Jun 22 21:32:02 deepdance kernel: PREEMPT Jun 22 21:32:02 deepdance kernel: Modules linked in: button appletalk ipx p8022 psnap llc savage drm binfmt_misc ipv6 fan ac battery ibm_acpi nls_cp850 nls_iso8859_15 dm_mod tun usblp usb_storage ntfs vfat msdos fat reiserfs udf smbfs uinput smapi rtcmosram thinkpad snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_seq_device sg scsi_mod speedstep_ich speedstep_lib cpufreq_ondemand cpufreq_userspace genrtc nvram usbhid ehci_hcd ohci_hcd pcmcia firmware_class hw_random snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm snd_timer ide_cd cdrom snd snd_page_alloc e100 mii uhci_hcd intel_agp agpgart usbcore yenta_socket rsrc_nonstatic pcmcia_core joydev evdev Jun 22 21:32:02 deepdance kernel: CPU: 0 Jun 22 21:32:02 deepdance kernel: EIP: 0060:[] Not tainted VLI Jun 22 21:32:02 deepdance kernel: EFLAGS: 00010a16 (2.6.15.7-tp23-sws2-2.2) Jun 22 21:32:02 deepdance kernel: EIP is at xfs_ail_insert+0x27/0x90 Jun 22 21:32:02 deepdance kernel: eax: d7c47414 ebx: c990308c ecx: d3431c64 edx: 7558c47b Jun 22 21:32:02 deepdance kernel: esi: c990308c edi: 00000025 ebp: 00000e4a esp: d7c85e34 Jun 22 21:32:02 deepdance kernel: ds: 007b es: 007b ss: 0068 Jun 22 21:32:02 deepdance kernel: Process xfslogd/0 (pid: 116, threadinfo=d7c84000 task=d7c50090) Jun 22 21:32:02 deepdance kernel: Stack: c990308c d7c47414 00000e4a 00000025 c024780d d7c47414 c990308c d7c47400 Jun 22 21:32:02 deepdance kernel: 00000000 c7949834 00000025 c990308c 00000025 c7002e1c c02473c0 d7c47400 Jun 22 21:32:02 deepdance kernel: c990308c 00000e4a 00000025 00000000 d7c47400 00000000 d7c84000 00000000 Jun 22 21:32:02 deepdance kernel: Call Trace: Jun 22 21:32:02 deepdance kernel: [] xfs_trans_update_ail+0x5d/0x140 Jun 22 21:32:02 deepdance kernel: [] xfs_trans_chunk_committed+0x50/0x140 Jun 22 21:32:02 deepdance kernel: [] xfs_trans_committed+0x52/0x110 Jun 22 21:32:02 deepdance kernel: [] xlog_state_do_callback+0x145/0x2e0 Jun 22 21:32:02 deepdance kernel: [] xlog_state_done_syncing+0x75/0xb0 Jun 22 21:32:02 deepdance kernel: [] xlog_iodone+0x4c/0xe0 Jun 22 21:32:02 deepdance kernel: [] worker_thread+0x1fd/0x2f0 Jun 22 21:32:02 deepdance kernel: [] pagebuf_iodone_work+0x0/0x50 Jun 22 21:32:02 deepdance kernel: [] default_wake_function+0x0/0x20 Jun 22 21:32:02 deepdance kernel: [] worker_thread+0x0/0x2f0 Jun 22 21:32:02 deepdance kernel: [] kthread+0xcd/0xe0 Jun 22 21:32:02 deepdance kernel: [] kthread+0x0/0xe0 Jun 22 21:32:02 deepdance kernel: [] kernel_thread_helper+0x5/0xc Jun 22 21:32:02 deepdance kernel: Code: 18 c3 89 f6 83 ec 10 8b 44 24 14 89 74 24 04 8b 74 24 18 89 1c 24 89 7c 24 08 89 6c 24 0c 8b 50 04 39 c2 74 46 8b 7e 0c 8b 6e 08 <39> 7a 0c 8b 4a 08 74 32 72 0f 8b 52 04 39 d0 75 ef 90 8d b4 26 Jun 22 21:32:02 deepdance kernel: <6>note: xfslogd/0[116] exited with preempt_count 1 ---------------------------------------------------------- So XFS died once again. This time with disabled write caches. I have no idea what happened... I start to wonder whether the hardware has problems, but I highly doubt it. smartctl reports only successful online and offline tests (it runs regarily here). And I also ran memtest86 not too long ago. I can do it again, of course. I wondered whether that bad magic stuff in the xfs_repair output can be related to bad memory. But then the machine usually works nicely with that kernel. Once more thing might be relevant. I did an xfs_check on my debian root partition before with SUSE 10.1, cause I had a crash that apparently didn?t crash XFS. It just showed some "agi unlinked bucket stuff" like it sometimes does. I still ran xfs_repair on it. It showed two errors while reading AGs or linked lists - unfortunately I do not remember the exact wording and I did not copy the error message. I did an xfs_check again which reported that all is fine now (no output). Just to make sure I can xfs_repair again and the two error messages didn?t appear anymore. This may be somehow related to this new bad XFS crash. Ok, thats all I have which is probably still quite much. Maybe you can give me a hint what happened. I wanted to wait a little more before trying kernel 2.6.17, but I think I will switch over to it this weekend. Seems that 2.6.15.7 is not as stable as I thought and hoped for. Maybe 2.6.17 does better. I hope sound will work after resume from suspend to disk. To be on the safe side, I will use plain vanilla for now without sws2 and without CONFIG_REGPARM even when thats really enabled by default no for 2.6.17. I know 2.6.15.7 is not the most recent kernel, thats why I report this to the XFS bugzilla instead. This may still give you valuable information about a possible XFS misbehavior. Otherwise feel free to close this bug report, I can always reopen it, should such thing ever happen again. I really hope that my bad luck with XFS will be over soon. Actually I already considered switching to ext3 due to those XFS crashes. Still I like XFS quite much. It works absolutely reliably on about 10 workstations in our company with kernels from 2.6.8, 2.6.11, 2.6.14 upto 2.6.16rc1 and is really fast. I just add some hardware information: ---------------------------------------------------------- deepdance:~ # lspci 00:00.0 Host bridge: Intel Corporation 82830 830 Chipset Host Bridge (rev 04) 00:01.0 PCI bridge: Intel Corporation 82830 830 Chipset AGP Bridge (rev 04) 00:1d.0 USB Controller: Intel Corporation 82801CA/CAM USB (Hub #1) (rev 02) 00:1d.1 USB Controller: Intel Corporation 82801CA/CAM USB (Hub #2) (rev 02) 00:1d.2 USB Controller: Intel Corporation 82801CA/CAM USB (Hub #3) (rev 02) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 42) 00:1f.0 ISA bridge: Intel Corporation 82801CAM ISA Bridge (LPC) (rev 02) 00:1f.1 IDE interface: Intel Corporation 82801CAM IDE U100 (rev 02) 00:1f.3 SMBus: Intel Corporation 82801CA/CAM SMBus Controller (rev 02) 00:1f.5 Multimedia audio controller: Intel Corporation 82801CA/CAM AC'97 Audio Controller (rev 02) 01:00.0 VGA compatible controller: S3 Inc. SuperSavage IX/C SDR (rev 05) 02:00.0 CardBus bridge: Texas Instruments PCI1420 02:00.1 CardBus bridge: Texas Instruments PCI1420 02:02.0 Communication controller: Agere Systems WinModem 56k (rev 01) 02:08.0 Ethernet controller: Intel Corporation 82801CAM (ICH3) PRO/100 VE (LOM) Ethernet Controller (rev 42) 03:00.0 USB Controller: NEC Corporation USB (rev 43) 03:00.1 USB Controller: NEC Corporation USB (rev 43) 03:00.2 USB Controller: NEC Corporation USB 2.0 (rev 04) ---------------------------------------------------------- ---------------------------------------------------------- deepdance:~ # lspci -vvn 00:00.0 Class 0600: 8086:3575 (rev 04) Subsystem: 1014:021d Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 00:01.0 Class 0604: 8086:3576 (rev 04) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- 00:1d.0 Class 0c03: 8086:2482 (rev 02) Subsystem: 1014:0220 Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B- 00:1f.0 Class 0601: 8086:248c (rev 02) Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- Region 1: I/O ports at Region 2: I/O ports at Region 3: I/O ports at Region 4: I/O ports at 1860 [size=16] Region 5: Memory at 20000000 (32-bit, non-prefetchable) [size=1K] 00:1f.3 Class 0c05: 8086:2483 (rev 02) Subsystem: 1014:0220 Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- 02:00.0 Class 0607: 104c:ac51 Subsystem: 1014:023b Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Reset- 16bInt- PostWrite+ 16-bit legacy interface ports at 0001 02:00.1 Class 0607: 104c:ac51 Subsystem: 1014:023b Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Reset+ 16bInt+ PostWrite+ 16-bit legacy interface ports at 0001 02:02.0 Class 0780: 11c1:0449 (rev 01) Subsystem: 1468:0410 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- ; Fri, 23 Jun 2006 00:14:28 -0700 Received: from localhost (dslb-084-056-085-198.pools.arcor-ip.net [84.56.85.198]) by mondschein.lichtvoll.de (Postfix) with ESMTP id 8962CFA510 for ; Fri, 23 Jun 2006 09:12:41 +0200 (CEST) From: Martin Steigerwald To: linux-xfs@oss.sgi.com Subject: Re: xfs crash with linux 2.6.15.7 and disabled write caches (long) Date: Fri, 23 Jun 2006 09:12:35 +0200 User-Agent: KMail/1.9.1 References: <200606230156.04907.Martin@lichtvoll.de> In-Reply-To: <200606230156.04907.Martin@lichtvoll.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606230912.35640.Martin@lichtvoll.de> X-archive-position: 8022 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Martin@lichtvoll.de Precedence: bulk X-list: xfs Content-Length: 1641 Lines: 43 Am Freitag 23 Juni 2006 01:56 schrieb Martin Steigerwald: > Hello, > > now I had a xfs crash with linux 2.6.15.7 and disabled write caches. I > put together all debug information I could get, but now the text is too > large for bugzilla@SGI (even when I cut out some larger cmd outputs and > log snippets). Hello, sorry for posting last mail twice. I thought I entered the wrong mailing list address (xfs@oss.sgi.com) first as I read a mailing list mail with linux-xfs@oss.sgi.com instead. I am now running: root@deepdance:~ -> cat /proc/version Linux version 2.6.17.1-tp23-sws-2.2.5.3 (root@deepdance) (gcc-Version 4.0.4 20060507 (prerelease) (Debian 4.0.3-3)) #1 PREEMPT Fri Jun 23 02:05:35 CEST 2006 I intended to use plain vanilla without sws2 first, but new sws1 seems to actually need that user-space stuff for doing suspend. Well at least it didnt work here and I read that user space stuff is still experimental, thus I decided to use what worked for me. Things seem to be fine so far, but there is a message once on every boot which may indicicate at a harddrive failure. I doubt it - since I did not found it in pre 2.6.17 logs -, but it might be the case. I filed a kernel bug report about this which also contains some diagnostic data about the harddisk: http://bugzilla.kernel.org/show_bug.cgi?id=6737 I am still using disabled write caches for a while. Then I will do a new backup and enable them and see what happens. Okay, and now I will do a backup, too. Better safe than sorry. Regards, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 From owner-xfs@oss.sgi.com Fri Jun 23 01:06:19 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 23 Jun 2006 01:06:29 -0700 (PDT) Received: from mail.software.plasmon.com (gw.plasmon.co.uk [194.130.136.219]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5N86DDW000392 for ; Fri, 23 Jun 2006 01:06:19 -0700 Received: from leuven.devel.pcs ([10.4.2.5] ident=uday) by mail.software.plasmon.com with esmtp (Exim 3.35 #1 (Debian)) id 1Ftgfa-0004t3-00; Fri, 23 Jun 2006 09:05:38 +0100 Message-ID: <449BA0D0.2060701@plasmon.co.uk> Date: Fri, 23 Jun 2006 09:05:36 +0100 From: Uday Chitragar User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20060503 Debian/1.7.8-1sarge6 X-Accept-Language: en MIME-Version: 1.0 To: mingz@ele.uri.edu CC: jgl@johngroves.net, linux-xfs@oss.sgi.com Subject: Re: Sparse files in the real world References: <44985423.2090803@johngroves.net> <4498F93A.7050904@plasmon.co.uk> <1150896043.4123.57.camel@localhost.localdomain> In-Reply-To: <1150896043.4123.57.camel@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8023 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: uchitragar@plasmon.co.uk Precedence: bulk X-list: xfs Content-Length: 1186 Lines: 56 In short, file system filter are kernel modules. They intercept every request being processed by XFS. Good news is, we are in the process of making it open :) Regards, Uday Chitragar Ming Zhang wrote: >On Wed, 2006-06-21 at 08:46 +0100, Uday Chitragar wrote: > > >>We are building an Archive Appliance that generates sparse files. >> >>Data written to filesystem is migrated to optical disks (UDO). >>Based on usage policy, the actual files on filesystem are replaced with >>sparse files. >>On access of the file (from filesystem clients), the filesystem filter >>(for XFS) triggers events to restore the actual file from Optical >>storage onto the filesystem. >> >> > >this trigger sounds interesting. could you describe it a bit more? >thanks! > > > > > > >>Regards, >>Uday Chitragar >> >>John Groves wrote: >> >> >> >>>I am working on a data management subsystem, and would appreciate any >>>insight people could share about real world applications that generate >>>sparse files. Can anybody share information or pointers to >>>applications that generate (and benefit from) sparse files? >>> >>>Thanks, >>>John Groves >>> >>> >>> >>> >> >> > > > From owner-xfs@oss.sgi.com Fri Jun 23 04:38:51 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 23 Jun 2006 04:39:02 -0700 (PDT) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.198]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5NBcoDW031727 for ; Fri, 23 Jun 2006 04:38:51 -0700 Received: by nz-out-0102.google.com with SMTP id 4so712887nzn for ; Fri, 23 Jun 2006 04:38:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=R97hhXn22Cg0B/7L4aITFfAHm7AZBBs+D9fvepsMaBcTEamE31HY7PFFXt7zzbeVTnWDjTqY5e7ccXK6YMbTW7bnci6Zt6Gqruxwe6jpCfXuSaFXdkmv+giNH40CZSZO+yiLFkfkZQPv8GWLIpoi7fRZZxb2ztl//mX/f2Df+bQ= Received: by 10.36.135.5 with SMTP id i5mr3558130nzd; Fri, 23 Jun 2006 03:33:59 -0700 (PDT) Received: by 10.36.178.20 with HTTP; Fri, 23 Jun 2006 03:33:59 -0700 (PDT) Message-ID: Date: Fri, 23 Jun 2006 12:33:59 +0200 From: "Artur Iwaniuk" To: linux-xfs@oss.sgi.com Subject: xfs xrash MIME-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit X-archive-position: 8024 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: aiwaniuk@gmail.com Precedence: bulk X-list: xfs Content-Length: 1595 Lines: 77 hello all recently i've faced xfs crash on my md RAID5 (ap. 700GB). strange thing is that RAID5 did not have any problems (no device have faled, no resync needed). when i am trying to mount filesystem: XFS: totally zeroed log XFS: failed to read root inode mars root # xfs_repair -v /dev/md1 Phase 1 - find and verify superblock... couldn't verify primary superblock - not enough secondary superblocks with matchinggeometry !!! attempting to find secondary superblock... ...................................................... and so on and on..... and at the end claims that he could not verify superblock. however mars root # xfs_db /dev/md1 xfs_db: cannot read root inode (22) xfs_db: cannot read realtime bitmap inode (22) xfs_db> sb xfs_db> p magicnum = 0x58465342 blocksize = 4096 dblocks = 175827264 rblocks = 0 rextents = 0 uuid = 6d21ce99-4cff-43d1-b4aa-fbe2c70ae094 logstart = 134217735 rootino = 256 rbmino = 257 rsumino = 258 rextsize = 80 agblocks = 5494608 agcount = 32 rbmblocks = 0 logblocks = 16384inopblock = 16 fname = "\000\000\000\000\000\000\000\000\000\000\000\000" blocklog = 12 sectlog = 12 inodelog = 8 inopblog = 4 agblklog = 23 rextslog = 0 inprogress = 0 imax_pct = 25 icount = 4192640 ifree = 61340 fdblocks = 7311352 frextents = 0 uquotino = 0 gquotino = 0 qflags = 0 flags = 0 shared_vn = 0 inoalignmt = 2 unit = 16 width = 80 dirblklog = 0 logsectlog = 12 logsectsize = 4096 logsunit = 4096 features2 = 0 xfs_db> values seems to be valid. my question: is there any chance to get back my data from that filesystem ? [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Fri Jun 23 04:56:17 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 23 Jun 2006 04:56:29 -0700 (PDT) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.194]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5NBuGDW001520 for ; Fri, 23 Jun 2006 04:56:16 -0700 Received: by nz-out-0102.google.com with SMTP id 4so716174nzn for ; Fri, 23 Jun 2006 04:56:01 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=hmf8AdU5u0yZZHe4koi6J7ZpAB7CFJAD08fTBljB5ag67WJjV3Vg1/5mPg/nVfYmj8Jvokt2YluP2wChI5u/M1iSvwCZnh70qebM7EFdMoRzxm0TvwBE8GNhnHHJIvyLtMosqMBxSDGLDJuBAba2pAAtjCIwv4DmAxhufzv+MzA= Received: by 10.36.220.10 with SMTP id s10mr3606822nzg; Fri, 23 Jun 2006 03:50:37 -0700 (PDT) Received: by 10.36.178.20 with HTTP; Fri, 23 Jun 2006 03:50:37 -0700 (PDT) Message-ID: Date: Fri, 23 Jun 2006 12:50:37 +0200 From: "Artur Iwaniuk" To: xfs@oss.sgi.com Subject: xfs crash MIME-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit X-archive-position: 8025 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: aiwaniuk@gmail.com Precedence: bulk X-list: xfs Content-Length: 1595 Lines: 77 hello all recently i've faced xfs crash on my md RAID5 (ap. 700GB). strange thing is that RAID5 did not have any problems (no device have faled, no resync needed). when i am trying to mount filesystem: XFS: totally zeroed log XFS: failed to read root inode mars root # xfs_repair -v /dev/md1 Phase 1 - find and verify superblock... couldn't verify primary superblock - not enough secondary superblocks with matchinggeometry !!! attempting to find secondary superblock... ...................................................... and so on and on..... and at the end claims that he could not verify superblock. however mars root # xfs_db /dev/md1 xfs_db: cannot read root inode (22) xfs_db: cannot read realtime bitmap inode (22) xfs_db> sb xfs_db> p magicnum = 0x58465342 blocksize = 4096 dblocks = 175827264 rblocks = 0 rextents = 0 uuid = 6d21ce99-4cff-43d1-b4aa-fbe2c70ae094 logstart = 134217735 rootino = 256 rbmino = 257 rsumino = 258 rextsize = 80 agblocks = 5494608 agcount = 32 rbmblocks = 0 logblocks = 16384inopblock = 16 fname = "\000\000\000\000\000\000\000\000\000\000\000\000" blocklog = 12 sectlog = 12 inodelog = 8 inopblog = 4 agblklog = 23 rextslog = 0 inprogress = 0 imax_pct = 25 icount = 4192640 ifree = 61340 fdblocks = 7311352 frextents = 0 uquotino = 0 gquotino = 0 qflags = 0 flags = 0 shared_vn = 0 inoalignmt = 2 unit = 16 width = 80 dirblklog = 0 logsectlog = 12 logsectsize = 4096 logsunit = 4096 features2 = 0 xfs_db> values seems to be valid. my question: is there any chance to get back my data from that filesystem ? [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Fri Jun 23 06:02:55 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 23 Jun 2006 06:03:08 -0700 (PDT) Received: from orca.ele.uri.edu (orca.ele.uri.edu [131.128.51.63]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5ND2tDW009499 for ; Fri, 23 Jun 2006 06:02:55 -0700 Received: from [192.168.1.4] (c-71-232-42-50.hsd1.ma.comcast.net [71.232.42.50]) (authenticated bits=0) by orca.ele.uri.edu (8.13.4/8.13.4) with ESMTP id k5ND2Zab013591 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 23 Jun 2006 09:02:36 -0400 Subject: Re: Sparse files in the real world From: Ming Zhang Reply-To: mingz@ele.uri.edu To: Uday Chitragar Cc: jgl@johngroves.net, linux-xfs@oss.sgi.com In-Reply-To: <449BA0D0.2060701@plasmon.co.uk> References: <44985423.2090803@johngroves.net> <4498F93A.7050904@plasmon.co.uk> <1150896043.4123.57.camel@localhost.localdomain> <449BA0D0.2060701@plasmon.co.uk> Content-Type: text/plain Date: Fri, 23 Jun 2006 09:02:30 -0400 Message-Id: <1151067750.12561.23.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 (2.6.1-1.fc5.2) Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.52 on 131.128.51.63 X-archive-position: 8026 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mingz@ele.uri.edu Precedence: bulk X-list: xfs Content-Length: 1633 Lines: 67 On Fri, 2006-06-23 at 09:05 +0100, Uday Chitragar wrote: > In short, file system filter are kernel modules. They intercept every > request being processed by XFS. > Good news is, we are in the process of making it open :) ic. so this is like a kernel module written by your company for XFS and it intercept and redirect the processing if need. if this work with VFS, then it is general for all FS or still only for XFS? making it open source? sounds interesting. please keep us updated on this. > > Regards, > Uday Chitragar > > > Ming Zhang wrote: > > >On Wed, 2006-06-21 at 08:46 +0100, Uday Chitragar wrote: > > > > > >>We are building an Archive Appliance that generates sparse files. > >> > >>Data written to filesystem is migrated to optical disks (UDO). > >>Based on usage policy, the actual files on filesystem are replaced with > >>sparse files. > >>On access of the file (from filesystem clients), the filesystem filter > >>(for XFS) triggers events to restore the actual file from Optical > >>storage onto the filesystem. > >> > >> > > > >this trigger sounds interesting. could you describe it a bit more? > >thanks! > > > > > > > > > > > > > >>Regards, > >>Uday Chitragar > >> > >>John Groves wrote: > >> > >> > >> > >>>I am working on a data management subsystem, and would appreciate any > >>>insight people could share about real world applications that generate > >>>sparse files. Can anybody share information or pointers to > >>>applications that generate (and benefit from) sparse files? > >>> > >>>Thanks, > >>>John Groves > >>> > >>> > >>> > >>> > >> > >> > > > > > > > From owner-xfs@oss.sgi.com Fri Jun 23 06:14:27 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 23 Jun 2006 06:14:40 -0700 (PDT) Received: from mail.software.plasmon.com (gw.plasmon.co.uk [194.130.136.219]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5NDEQDW011501 for ; Fri, 23 Jun 2006 06:14:27 -0700 Received: from leuven.devel.pcs ([10.4.2.5] ident=uday) by mail.software.plasmon.com with esmtp (Exim 3.35 #1 (Debian)) id 1FtlTe-0005lw-00; Fri, 23 Jun 2006 14:13:38 +0100 Message-ID: <449BE901.90400@plasmon.co.uk> Date: Fri, 23 Jun 2006 14:13:37 +0100 From: Uday Chitragar User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20060503 Debian/1.7.8-1sarge6 X-Accept-Language: en MIME-Version: 1.0 To: mingz@ele.uri.edu CC: jgl@johngroves.net, linux-xfs@oss.sgi.com Subject: Re: Sparse files in the real world References: <44985423.2090803@johngroves.net> <4498F93A.7050904@plasmon.co.uk> <1150896043.4123.57.camel@localhost.localdomain> <449BA0D0.2060701@plasmon.co.uk> <1151067750.12561.23.camel@localhost.localdomain> In-Reply-To: <1151067750.12561.23.camel@localhost.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 8027 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: uchitragar@plasmon.co.uk Precedence: bulk X-list: xfs Content-Length: 200 Lines: 8 > If this work with VFS, then it is general for all FS or still only for XFS? Yes the filter itself is general for all FS in theory. I will certainly post to this group when source is available. From owner-xfs@oss.sgi.com Fri Jun 23 06:16:04 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 23 Jun 2006 06:16:15 -0700 (PDT) Received: from orca.ele.uri.edu (orca.ele.uri.edu [131.128.51.63]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5NDG4DW011912 for ; Fri, 23 Jun 2006 06:16:04 -0700 Received: from [192.168.1.4] (c-71-232-42-50.hsd1.ma.comcast.net [71.232.42.50]) (authenticated bits=0) by orca.ele.uri.edu (8.13.4/8.13.4) with ESMTP id k5NDFlpQ019311 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 23 Jun 2006 09:15:47 -0400 Subject: Re: Sparse files in the real world From: Ming Zhang Reply-To: mingz@ele.uri.edu To: Uday Chitragar Cc: jgl@johngroves.net, linux-xfs@oss.sgi.com In-Reply-To: <449BE901.90400@plasmon.co.uk> References: <44985423.2090803@johngroves.net> <4498F93A.7050904@plasmon.co.uk> <1150896043.4123.57.camel@localhost.localdomain> <449BA0D0.2060701@plasmon.co.uk> <1151067750.12561.23.camel@localhost.localdomain> <449BE901.90400@plasmon.co.uk> Content-Type: text/plain Date: Fri, 23 Jun 2006 09:15:41 -0400 Message-Id: <1151068541.12561.25.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 (2.6.1-1.fc5.2) Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.52 on 131.128.51.63 X-archive-position: 8028 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mingz@ele.uri.edu Precedence: bulk X-list: xfs Content-Length: 288 Lines: 17 On Fri, 2006-06-23 at 14:13 +0100, Uday Chitragar wrote: > > If this work with VFS, then it is general for all FS or still only for XFS? > Yes the filter itself is general for all FS in theory. ic. > > I will certainly post to this group when source is available. > thx. > > > From owner-xfs@oss.sgi.com Fri Jun 23 07:44:33 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 23 Jun 2006 07:44:57 -0700 (PDT) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5NEiUDW024463 for ; Fri, 23 Jun 2006 07:44:33 -0700 Received: from hch by pentafluge.infradead.org with local (Exim 4.62 #1 (Red Hat Linux)) id 1FtlqN-00070W-G8; Fri, 23 Jun 2006 14:37:07 +0100 Date: Fri, 23 Jun 2006 14:37:07 +0100 From: Christoph Hellwig To: Uday Chitragar Cc: mingz@ele.uri.edu, jgl@johngroves.net, linux-xfs@oss.sgi.com Subject: Re: Sparse files in the real world Message-ID: <20060623133707.GA26094@infradead.org> References: <44985423.2090803@johngroves.net> <4498F93A.7050904@plasmon.co.uk> <1150896043.4123.57.camel@localhost.localdomain> <449BA0D0.2060701@plasmon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <449BA0D0.2060701@plasmon.co.uk> User-Agent: Mutt/1.4.2.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 8029 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs Content-Length: 434 Lines: 9 On Fri, Jun 23, 2006 at 09:05:36AM +0100, Uday Chitragar wrote: > In short, file system filter are kernel modules. They intercept every > request being processed by XFS. In the Unix world we normally call that a stackable filesystem, filter driver is the windows temrinology. There's a few subtle issues left that make implementing them correctly very hard. We're addressing those issues at the VFS level for ecryptfs currently. From owner-xfs@oss.sgi.com Fri Jun 23 09:20:16 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 23 Jun 2006 09:20:31 -0700 (PDT) Received: from sipsolutions.net (crystal.sipsolutions.net [195.210.38.204]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5NGKDDW010506 for ; Fri, 23 Jun 2006 09:20:14 -0700 Received: from [84.135.235.191] (helo=johannes.berg) by sipsolutions.net with esmtpsa (TLS-1.0:RSA_ARCFOUR_MD5:16) (Exim 4.62) (envelope-from ) id 1FtnAo-0004k9-Uy for xfs@oss.sgi.com; Fri, 23 Jun 2006 16:02:20 +0100 Subject: error xlog_recover_do_inode_trans(1) / bug when recovering From: Johannes Berg To: xfs@oss.sgi.com Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-ogl8kgQbnf6+xbdP2JFl" Date: Fri, 23 Jun 2006 17:02:14 +0200 Message-Id: <1151074934.7608.43.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 X-archive-position: 8030 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: johannes@sipsolutions.net Precedence: bulk X-list: xfs Content-Length: 10394 Lines: 202 --=-ogl8kgQbnf6+xbdP2JFl Content-Type: multipart/mixed; boundary="=-sUQe/EUEnFfmuTVZr/gj" --=-sUQe/EUEnFfmuTVZr/gj Content-Type: text/plain Content-Transfer-Encoding: quoted-printable [previously sent to linux-xfs but didn't go through, then I noticed the list address was changed, sorry if it shows up] Hi, I got a corrupted xfs device that printed out, when trying to recover: Bad inode magic number, .... Internal error xlog_recover_do_inode_trans(1) ... I don't have all the details transcribed (tooks some pictures with my cell phone but the quality sucks). I did, however, save a copy of the disk via my computer's target-disk mode before running xfs_repair -L on it. It is 7.3 GB (compressed with gzip -3) but I can run analysis on it if anyone is interested, you just need to tell me what to do. Then, after taking the snapshot, I attempted to run xfs_repair -L on it, but it crapped out too and told me: Phase 7 - verify and correct link counts... corrupt dinode 30638, extent total =3D 1, nblocks =3D 0. This is a bug. Please report it to linux-xfs@oss.sgi.com. fatal error -- couldn't map inode 30638, err =3D 990 The whole log is attached. Interestingly, after repair, the kernel was able to mount it again, but lots of bad things happen in some directories. johannes --=-sUQe/EUEnFfmuTVZr/gj Content-Disposition: attachment; filename=sdb7.xfs_repair.log.gz Content-Type: application/x-gzip; name=sdb7.xfs_repair.log.gz Content-Transfer-Encoding: base64 H4sICD1smkQCA3NkYjcueGZzX3JlcGFpci5sb2cA7V1rjyu5cf2uX9GwEXgX 2ZltksWXAQNZJwt7gXWyuNkgyKdFj9Qzox2pe6Ju3Yd/fciWNFe6olo8bOVh hIYN+GrqsKpY7Cqymjr6bfHxsftlU79Wy01x1xTfLur333aLBz376bnq6oIV d8XjslkUlfvf+3qzfPxUdNvXevOwaucv9/f3eznu5Lbdsnkqlk1fb5pqVaza p1mx/89d0c2rxo20qrtPXV+vi8dNXXev1bweRl427aIu1tVr54f8jHpst+6v m7bt9yLz523zstcpBoFNUVfz5+K7P50iB31fPWz7YtE2v+uL+aquNl8X1dOy 2DarZfNSL4rVsuu/UPi6aed11xUvTfuh2ensBgudy07Xem/GYtnNWzcdn07R 1VPTFn8oytlDtXDePC3nRbNdP9Sbovz4WNqqaPdjFkoLbgYxN0q3dJ9/Ftz9 pwwJf9XUT1W/fF9/XXTLv9bFHddGW0tWKcuZYpYZGcJdtcUituyEd//2k1L5 6Jz9/ZpOUQI698IXdYq4ORcM0cmu6GQhnfWZTj6qk4WEL+vkcX4KxE9xRacI 6VyU7AudhOikC+tZMq210rbkUrmokmEh3Jn/X9oiEVvkFf9l3JwrRKe6olPF 6dSITn1Fp47TieStvfBlnXH5SSD5SVzJTyIuPxGSn+hKfqK4/ERIfqIr+YlY nE6O6LySnyiYn/SZTiQ/0ZX8RCLOTyQ/EaXVW6I4W5D8RFfyE8XlJ0LyE13J TxSXnwjJT3QlP5GOqrdkgHpLV/ITxeUnQvITXclPZKPqrUTy014YrreyjKq3 Eslb8kreknF5SyJ5S17JWzJuXyWRvCWv5C0Zl7ckkrf2wpd1xuUnieQneSU/ ybj8JJH8JK/kJxmXnySSn+SV/CTj9k8S2T/JK/lJmqh6K5H8JK/kJ2kjz7ff FB/a7cqd3+uu7k/koZPv6TCnqORT8W7I5+p9vWsN1IuEQ/NtHLRXHRw7ao86 EnsSv4kjXw6DOOLO72OORB/vb+MIm+AIG3cktmeQ6AgbHQZyhI87EtuIuE1E xARHxLgjsd2N2zhCCdnsek9k1MHYlsltHJQTIiXHHYntw9zGETXBETXuSGxz 5zaO6AmO6HFHYjtGt3HETHBkvOJHt6Fu48iEii/GK350b+smjtCEik/jFT+6 YXYbRyZUfBqv+NFduNs4MqHi03jFj27t3caRCRWfxit+dL/wNo7Q7c8vNF7x o5uQt3FwQsWn8Yof3dm8jSMTKj6NV/zodultHJlQ8Wm84kf3YG9yfqEJFZ/G K350Y/c2EZlQ8Wm84kd3i2/iiCxvf36R4zuB6Bb0bRycsBOQ4zuB6L72bRyZ sBOQ4zuB6Gb5bRyZsBOQ4zuB6A78bRyhCY6MV/zotv5tHJlQ8eV4xY9+V3Ab RyZUfDle8aNfQNzGkQkVX45X/Oi3GrdxZELFl+MVP/pVyW0cmVDx5XjFd39e rqtX94dque7c53fbrt7/WZKV2hTLbrhgeTBh3m429dwpcbDZouorr/Vlr7Nw AKvsYTiPK4bbnYVyddvtk0CABQGuvoMAhgI4ChAogFCARAEKBWgUgEZaopFW aKQVGmmFRlqhkVZopBUaaYVGWqGRVmikFRppjUZao5HWaKQ1GmmNRlqjkdZo pDUaaY1GWqORNmikDRppg0baoJE2aKQNGmmDRtqgkTZopA0aaYtG2qKRtmik LRppi0baopG2aKQtGmmLRtqCkTZliQIYCuAoQKAAQgESBSgUoFGAQQFopBka aYZGmqGRZmikGRpphkaaoZFmaKQZGmmGRpqjkeZopDkaaY5GmqOR5mikORpp jkaao5HmaKQFGmmBRlqgkRZopAUaaYFGWqCRFmikBRppgUaa0EgTGmlCI01o pAmNNKGRJjTShEYa7ZEZtEdm0B6ZQXtkBu2RGbRHZtAemUF7ZAbtkRm0R2bQ HplBe2QG7ZEZtEdm0B6ZQXtkBu2RGbRHZtAemUF7ZAbtkRm0R2bQHplBe2QG 7ZEZtEdm0B6ZQXtkBu2RGbRHZtAemUF7ZAbtkRm0R2bQHplBe2QG7ZEZtEdm 0B6ZQXtkBu2RGbRHZtAemUF7ZAbtkRm0R2bQHpmx8pwChZ1/xM8/CpjGJZdC WwroYtLv88vzYej8o4BJ6vwjff6Rmc1+bZ+rpqm733/73K7rbw///G2myslU OZkqJ1PlZKqcTJWTqXIyVU6myslUOZkqJ1PlZKqcTJWTqXIyVU6myslUOZkq J1PlZKqcTJWTqXIyVU6myslUOZkqJ1PlZKqcTJWTqXIyVU6myslUOZkqJ1Pl ZKqcTJWTqXIyVU6myslUOZkqJ1PlZKqcTJWTqXIyVU6myslUOZkqJ1PlZKqc TJWTqXIyVU6myslUOZkqJ1PlZKqcTJWTqXIyVU6myslUOZkqJ1PlZKqcv2Wq HJxe5iLgZblaVatVcfdv//qOFYvF/1XJddUcOfe370+WzJJZ8v+P5FFi/m8j /fprvWn9Rx7y/bt3//Lu98XPz/UxDZgbp3hfrbbVw6ou1nVfDaVn7ox8qv3V lqLy+OLD83L+XDR1veiKvp091IUzfVV9qhf3RfGXdtv0RX86cN/uRYY/uDG+ GbzZNutBetkXD7WrcPVsU99ttk3jvfg8JW7UHx6LT+22qDa1Aw3muSHXAVXf +H83biLqmf/D3Y9F+9r7qz5OflF3/aZ9s2Ewoeod6LV3nu11zf657d3oz1V/ kPfGHCBr58K88jd8/C2e7W7ou7vidVX7GHwebbBt1j5+ORM7P4tFuxt12d3H Vesf/2fWxXc/fv/u52nrYtk5J5262X766oX7927OTiPywY3qPl3c/28T0/mh h3tdmZAuE9JlQrpMSJcJ6TIhXSaky4R0mZAuE9JlQrpMSJcJ6TIhXSakuz0h 3fBlrN63JibQ0X0e5EZkdFMY6KZ7ZK94NHaunkI5N9ny00FAurkpHHPTLWfJ lrPZFFK5BMvZyCAgodwUFrnpcy6SLRezKbRx0y0nOOdc71pM4Ymb7pFMjoWc TSGGm265SrZczaYwwU23XCdbrmdTqN+mW26SLQ/UVoDrbbrlybVVBGorQO42 2XJKrq0UqK0Am9t0y5NrKwVqK0DfNt3y5NpKgdoK8LVNtzy5tlKgtgIEbdMt p1vv5ylQWwFGtukeJddWCtRWgIJtuuXJtZUCtRXgXJtueXJtpUBtBUjWJu/n Kbm2UqC2Aqxq0+c8ubZSoLYCNGqTLZflrffzMlBzAd606R4l11wZqLkAUdp0 y5NrrgzUXIAZbbrlyTVXBmouQIU23XJKtjxQWwHus+mWJ9dWGaitANnZdMuT a6sM1FaA3Wy65cm1VQZqK0BnNt3y5NoqA7UV4C+bbnlybZWB2ooQlu2pyobL g5mtLLOVZbayzFaW2coyW1lmK8tsZZmtLLOVZbayzFaW2coyW1lmK8tsZZmt LLOVZbayzFaW2coyW1lmK8tsZZmtLLOVZbayzFZ2ja3sjB+DnX/Ezz8KmMYl l0JbCuhi0u/zy/Nh6PyjgEnq/CN9/pE5/8gG3AvE2W3HNRM2NEvOJ5Khvt1V jIUxqiwTMCwBwxMwIgFDCRiZgFEJGJ2AMQmYhHWQsEYVS1gHLGEdsEvrgMQl DKmgP5xrMjyIUWTDa2fAyIuYUDoL5LOQ36wstWKm1KFUKbTPbAmg0P7hOoil gFJ8Cu0lroMoBSRTQCoFpFNAJgWUsiJsyoqwKSvCpqwIm7IibKCMuzxx/llo 5TCtS/fwisDg/m4dsUD1D70HYFxaN5QNZQd/3FE8CHJJ3e2bKAhySciYAP9Y U39YfXqjGTvc7uo+k76RE54/124QT3222L6ulvOq3w/8BanZ4WLZ9vVIsP7Y 100/cKCdSu+I0lZt1//9jnbtq+WjJ/CrP3q6tK+LL6TfbNiTpQ1eem3jNr1R pTkjNp+K36yWD0/9C78v7x6WzW+Kqj/s64r28dH/oid3JyU/p4ulv7DWOszu RhsTptjUj26SGjdzu9k9/nr0QeXg1o4kz/9xfyHPDbgzwCk8UuRt3Ru2bF66 efVa36/bI7PKN2kpVNAsWV42S/AEs5yiI7N+qpqnZrnpt81TyCy3rkJWCSUu W0WEW+X0HBn1w39Wq+2yDxrEDW6QTjCImyOD3lXNy7L55YdmVYetkhy3KmFN OT1HVv1jtX7YLBdP9S9/rD4FzdIKNuvo7BNvlj5eUv9Rr1bth5dm+ViHjHI5 usStYrhVXtHxomq275cvYYs4vsqlSLGIHy/zf39e9vVzu+kuzBPhS11SilV0 vNb/qfrQtU3YIo0vcylTLNKn67yZby9YZBNWuEqxyB4v8b/U7rmrghYxnrC6 ExKUV3Q8R+2mWv3y52rz0G43IcOoVAmp3OCGeUVHht0/Vi/13ape3L+09/P1 Ijxp4fxJaqQmU0pKYCcJtL7bscfe15tNG5w1E3wEjSztSFVOyKDm+Ansnl0G vWzThcm6YlTKbJ1M1uNy1deby2bxMmWuErKoU3RkVrVYbNxO96FtX0Zs0ylT lvBU8l3iOtm9b+qn7araHJ63Urmd5n4P71mN97YaUQplZkdfpGh2+93Pm+Id 9puBD9mTOs89dbQb4G3z+3dP87Z5vP+4Xv3GK+5cbekHtuHPjktSSo5kIjv7 dev3Ok9FeMwvp3AY76C/aZv6/jW8k7ywPKThbGSHK83U9fH9e/d/ft5U8xe3 eOdd8IFSF0yzY1MlEvZvTtNx+mmCm0kVTjr+GMJHzEmoauok7cyfq83da+W2 uH1999r/8sd39+36MWShMMFSwohZPhJMnhBMp+rKA8WkO54ZEXikuOVa8nL8 mdrD90+VsKZUR4+WtpKdDrA7714cQZzAmQq1BMa8MaqUpG3IGyoF92xMY97s 4Ttb+EmOCLwrGZtVLTQXmgUMYca/v6Er07rH7+f11JQRvZwpYm6lhPS63a3y X2sc03vAh7Jk4NXQLV/zjHil3LHKt44CXgl3eHKby3GvDvgor8yoJf56reKh Baak1VJcs2SP31miVWxclbZuaTIe0CvdqUhpfk3vDh9a2SNqNbPWMhtaTuSm 1HeIR9Ue8FEPlH07AW9f/AnqQgnWklyW4eOnuC+q8OcRv0y6h9FGk0opSiO4 CgW9dHmZruw7DvjdLND4LLDRgBjD/PftQ0+ClOQq7pV0fcBHPQmMHSLidtSv wdIfbidZTsJyMXYySjnW7npKoZc8oab03nS6Z/f84mJirFTG35wY2RmcrabP Q56V8MNwo7WBMaE04zoQRK38C74rD/PbAKEojioWlgyJ0OpxwzF/efuK4v0A Uc8zo7dDxvrCWT88hy6ju9wydrQwSQf+o83ar8Hug1OcaBElHFrdoEcW9eHD KoV7azEmJXS3vbrjLe3m02sf7Le7neqIWWrsSJJiluXhJ1/uX8NI99mmftgu V4viuz8Vz3W1qDe7X4zp/S/bnKKH7/gHf8NHvb1K2f++Tds0/ml4v+w/BcYY HhMns9vSto/u02rVL9d18bDs/Xf/vQHddr2uDjPUHQ1RN912cH94pePnyg9x 9MbnbXaPQP2mGogJHOzo53u6vtoMxrg5+3Z4NbSfjeENUOhgNiZA7iA9indn ztnxpR/lv+vL1O4d2Fkt8G/ymS48gULjM87Y2Afp6OHdiiO3w1A8bvw38WgF LtGStZLixj9IA/YP9cIdoSPt34uPCfm+zLiR7igcbyGXVkhNKtLCg/iVMOzS 16jQcB4eXy27fcaYjFCjf2ayhNYalYZ0/FobxOMVlJZJKilysb2JxysQsetM mIj4qfi5c4ej0t8Jj1N/kI4e3pB0pxsZN/peGIy7Jo7EXRM/T9vVyv+U3LJ7 djum03pylNf9Lxlum6rvq7mX67YPQw0LA6pVd2nIdft+Z163L2Nv9xf8j/Qd 1ZmhQ3QmVTBTGrfF3A9zAgmLM08rGS9OpYTEPVFirDhJZSwibm0ZLy7dVpkD 4loJwsQlJq4wcQOJS8x2hUykK/VAmPy9H4GJEyauMXFgIl2tsgIRlyUiLgRk jDtCaUjcKkwcGd1GPnwu0b5VPr97SMAoHMOBMLBSuzQIyfNSgPKEyfMSlAft 4ag9EpQHVp6r6qVC5N0WkzFQnoNriCyZEsZYoXGMRnyRsoTm1qhSIbH2fVUg uXNjDPIseHkCx7cEymPj2xKpfZp0yUB5YNehSnf4YJi8lYi8JYbKG1AemH+3 W+WKgfIclBeYPFKTvbwpQXnQfkOQvCiR/T9xNlDFQgBkRncAQgEKBOgSAhhs hzAACAVIFKBAgOAoAHVaoE4L1GkBO61RgEEBFgQQOq2EzhKhTktwaWgGPUCC SewB8gBCARoFGBRgQYBAZ0kwFMBRADqthE4rodNK6LRKdFolOq0SnFaDLm+D Lm+D1QcPUChAowCDAsBIG/QBMugDZNAHyAg00ugTZwQaaYFGWqCRFmikBRpp g8bBoHEwaBwMGgcLOg2dJXcAhgI4ChAoAJxWi24dwO6NiG3fHANgHyQKUChA owCDAtDVytHAcTRwaAWyaAWyaAWyaAWyYAXi0sAAjgIECpAoAFveXIFl1wEw H0iBcSCFNREcwJQoAPLBCkkoANvo+kscmAbJVIkCoEhbg73McADwwOEA4CwZ 8DjgAQIFEAqQKEChAPDlhJGcK5sA0mWJgoQVlqEgzY3lKMjVJCi5+UsmBD0k HqGgjLtDKBihYYSBERZFWHiuLIMRHEYIGEEwAou54QyMoEcYGIFF0ArB0LeY rnKWArpI5EqnIijl7RAKRhjYF/+NIEyPO39DFWWHIBhhYIRFvbelMUzAKMY1 1INQ1ipZIitTi7Jk0Klrh9AoArkltkcIGEEoQsJzZWEdFppdzcpS4giLIqDa u0MA9YRLNnzPDlvxXHImInuTZyiCUaZUSqAooYRE+iBclcoQstHdI3AdYH3h RpZcIOe/PQKwTLizlufrRBFIRhJCkzDo5tihdAnPmb9baKVOQxkYZRW8FSdm beztoTMUeCeQuMtukZcETlCeUlOloEjAKOeVAeu1HO7/GAGj/DZPpaCIUJQk QcbAKGMtug9xR08pS/TenjT+NzpLjaNib5Eco4w7HROHUSRZaWGUAxFy+0z7 RWgNiBAMtMyhuJXMwCh/vQnWRW4xodFV/gttUG7330nX0Iu7HQKJzw6hDIyw KAK5k7pHCBgBzxVy03+PgOfKQJ7L6N3/57XlUP7JNDDK+i9qINYpVgqpYYRF EcgO3SOsRnt9DsXdiRGeM+VO8kIkodJ0WRhFShtolSrpNukaRaDf1nAoRdDV UI9w5UDDCIsiGIMRCkbAfjCDIjjmhyHoGz17hIYRBkZYEEHwCwJhXM4k5Ka4 85xH3rU+1mONpbj7OicoB0LzjKHSX2SzOMr/9hryrbSByl9jCAldtN0hkL6L RygHwry3nPzv+cEoxZjSLAFl0LzpUMYIJHu4paMpsvd2pMehFOfo95o8140l w2CY1m4uEmEShxlp0RO0/347MyWTOMzvLTgOGwh9cBiZyNsSpzDJS/TIPvA6 CM0lDiMt4dcAXJWlsbBvHuaSdYK24etkF2A7chhd3BXv683y8dPA67JnSipW y+ZlR4M00Mz4j7evvRv9mHN0T/Pft3218sQ137yxK/2hKO+L4ufnZVe4/1bF w/bpfvbTqvYaN/Vru+k967+3Z9lsP959fOz+oe26++5peT9v1/ez2WPlxxy4 W4u7gZBptWh+1xeef+bUhs3Gs6zZcvZfrtRQKStEAQA= --=-sUQe/EUEnFfmuTVZr/gj-- --=-ogl8kgQbnf6+xbdP2JFl Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- iQIVAwUARJwCdKVg1VMiehFYAQIoZA/+NkA7O/V9Rl2MGezCfs3hK77IgAnDVQgN a0EH6ZvSrcxg8E/PIJEf0vASiCuiJt7kV4ZQxKL4tDfXX4Uez2F7jao0WzGMHjp2 akmC6ub0Md+PjKvqt7v4IFTZNiSYjnXXMXa5E4TbJQ1pF68GLL2tqvQ6moJ+pJr6 n6kkKBIbPAJ6Z10qf9APGBmTDytBfcXKR8SQ4xifsKDgd6EDGANHoUl+uRAUt8at E3CFwE/onkZ0bBOqxhtKgfvhKJr/Yu28IHLlJTIQ/wkZNhOBdzaPLHdjLoE3lMhh Zq+Ogv/7aF1rjnzw6ARULZ02/1Cq4VZvfL3Kp6jpu/Yez5Y3bCkGKarGvDhltoAg kLh61hHP7SatOdJG/EgaxJqrC5+r5Zwa20+5JCWILxeQQiXIqnXAinXj9pu/XgLe EQiS1P/XkQtWqs0v2zvjHlznYgT8sSD0QlYQLHmXRGWXxOu+wNt1kfby6Npg3d1i q1FbsIPMVJBnTKFmzgHcufVEoZheIktCuEA0j6YN33nwLmVqZgqPMJs++E49eOAF WXTs4NoS1DVEHoaMkQHTaKB1ZaFUlZVcCSbhnRvu6tz5QfZPR2kWtfsGjYVca4eE CeOy4Bg9gQ/GzQJW03GrDREoaHHG7hTsrrGqf9G41T8i0kptoynxmuSRb8kKHDcX tfwySGBMkk8= =XHHm -----END PGP SIGNATURE----- --=-ogl8kgQbnf6+xbdP2JFl-- From owner-xfs@oss.sgi.com Fri Jun 23 13:03:57 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 23 Jun 2006 13:04:11 -0700 (PDT) Received: from mondschein.lichtvoll.de (ms2.lichtvoll.de [194.150.191.235] (may be forged)) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5NK3tDW008307 for ; Fri, 23 Jun 2006 13:03:56 -0700 Received: from localhost (dslb-084-056-110-075.pools.arcor-ip.net [84.56.110.75]) by mondschein.lichtvoll.de (Postfix) with ESMTP id 3C4D0FA511 for ; Fri, 23 Jun 2006 22:02:05 +0200 (CEST) From: Martin Steigerwald To: linux-xfs@oss.sgi.com Subject: Re: xfs crash with linux 2.6.15.7 and disabled write caches (long) Date: Fri, 23 Jun 2006 22:01:29 +0200 User-Agent: KMail/1.9.1 References: <200606230156.04907.Martin@lichtvoll.de> <200606230912.35640.Martin@lichtvoll.de> In-Reply-To: <200606230912.35640.Martin@lichtvoll.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606232201.29440.Martin@lichtvoll.de> X-archive-position: 8031 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Martin@lichtvoll.de Precedence: bulk X-list: xfs Content-Length: 19069 Lines: 420 Am Freitag 23 Juni 2006 09:12 schrieben Sie: > Hello, > > sorry for posting last mail twice. I thought I entered the wrong > mailing list address (xfs@oss.sgi.com) first as I read a mailing list > mail with linux-xfs@oss.sgi.com instead. Hello again, not that I am too keen replying to myself, but the story got a new chapter: I had another xfs corruption. I was using 2.6.17.1 and rebooting into 2.6.16.11 once to report whether the "dma_intr" message I talked about in my last mail will be shown in the log with it (see http://bugzilla.kernel.org/show_bug.cgi?id=6737). All was with writecaches disabled. This kernel bug report also contains all the relevant kernel configurations. I had no kernel crash this time, no suspend failure, no nothing, except: When I rebooted to 2.6.17.1 and as KDE was closed KMail and KWallet crashed. As I had that before when I had a filesystem crash, I booted into SUSE 10.1 and checked the debian root partition: It again had errors: deepdance:~ # xfs_check /dev/hda5 bad free block nvalid/nused 4/-1 for dir ino 1747843 block 16777216 missing free index for data block 0 in dir ino 1747843 missing free index for data block 1 in dir ino 1747843 missing free index for data block 2 in dir ino 1747843 missing free index for data block 3 in dir ino 1747843 bad free block nvalid/nused 7/-1 for dir ino 5012689 block 16777216 missing free index for data block 0 in dir ino 5012689 missing free index for data block 1 in dir ino 5012689 missing free index for data block 2 in dir ino 5012689 missing free index for data block 3 in dir ino 5012689 missing free index for data block 4 in dir ino 5012689 missing free index for data block 5 in dir ino 5012689 missing free index for data block 6 in dir ino 5012689 bad free block nvalid/nused 8/-1 for dir ino 30448144 block 16777216 missing free index for data block 0 in dir ino 30448144 missing free index for data block 1 in dir ino 30448144 missing free index for data block 2 in dir ino 30448144 missing free index for data block 3 in dir ino 30448144 missing free index for data block 4 in dir ino 30448144 missing free index for data block 5 in dir ino 30448144 missing free index for data block 6 in dir ino 30448144 missing free index for data block 7 in dir ino 30448144 bad free block nvalid/nused 21/-1 for dir ino 33641428 block 16777216 missing free index for data block 0 in dir ino 33641428 missing free index for data block 1 in dir ino 33641428 missing free index for data block 2 in dir ino 33641428 missing free index for data block 3 in dir ino 33641428 missing free index for data block 4 in dir ino 33641428 missing free index for data block 5 in dir ino 33641428 missing free index for data block 6 in dir ino 33641428 missing free index for data block 7 in dir ino 33641428 missing free index for data block 8 in dir ino 33641428 missing free index for data block 9 in dir ino 33641428 missing free index for data block 10 in dir ino 33641428 missing free index for data block 11 in dir ino 33641428 missing free index for data block 12 in dir ino 33641428 missing free index for data block 13 in dir ino 33641428 missing free index for data block 14 in dir ino 33641428 missing free index for data block 15 in dir ino 33641428 missing free index for data block 16 in dir ino 33641428 missing free index for data block 17 in dir ino 33641428 missing free index for data block 18 in dir ino 33641428 missing free index for data block 19 in dir ino 33641428 missing free index for data block 20 in dir ino 33641428 bad free block nvalid/nused 26/-1 for dir ino 42681258 block 16777216 missing free index for data block 0 in dir ino 42681258 missing free index for data block 1 in dir ino 42681258 missing free index for data block 2 in dir ino 42681258 missing free index for data block 3 in dir ino 42681258 missing free index for data block 4 in dir ino 42681258 missing free index for data block 5 in dir ino 42681258 missing free index for data block 6 in dir ino 42681258 missing free index for data block 7 in dir ino 42681258 missing free index for data block 8 in dir ino 42681258 missing free index for data block 9 in dir ino 42681258 missing free index for data block 10 in dir ino 42681258 missing free index for data block 11 in dir ino 42681258 missing free index for data block 12 in dir ino 42681258 missing free index for data block 13 in dir ino 42681258 missing free index for data block 14 in dir ino 42681258 missing free index for data block 15 in dir ino 42681258 missing free index for data block 19 in dir ino 42681258 missing free index for data block 22 in dir ino 42681258 missing free index for data block 23 in dir ino 42681258 missing free index for data block 24 in dir ino 42681258 missing free index for data block 25 in dir ino 42681258 bad free block nvalid/nused 25/-1 for dir ino 46142796 block 16777216 missing free index for data block 0 in dir ino 46142796 missing free index for data block 1 in dir ino 46142796 missing free index for data block 2 in dir ino 46142796 missing free index for data block 3 in dir ino 46142796 missing free index for data block 4 in dir ino 46142796 missing free index for data block 5 in dir ino 46142796 missing free index for data block 6 in dir ino 46142796 missing free index for data block 7 in dir ino 46142796 missing free index for data block 8 in dir ino 46142796 missing free index for data block 9 in dir ino 46142796 missing free index for data block 10 in dir ino 46142796 missing free index for data block 11 in dir ino 46142796 missing free index for data block 12 in dir ino 46142796 missing free index for data block 13 in dir ino 46142796 missing free index for data block 14 in dir ino 46142796 missing free index for data block 15 in dir ino 46142796 missing free index for data block 16 in dir ino 46142796 missing free index for data block 17 in dir ino 46142796 missing free index for data block 18 in dir ino 46142796 missing free index for data block 19 in dir ino 46142796 missing free index for data block 20 in dir ino 46142796 missing free index for data block 21 in dir ino 46142796 missing free index for data block 22 in dir ino 46142796 missing free index for data block 23 in dir ino 46142796 missing free index for data block 24 in dir ino 46142796 bad free block nvalid/nused 65/-1 for dir ino 55176185 block 16777216 missing free index for data block 0 in dir ino 55176185 missing free index for data block 1 in dir ino 55176185 missing free index for data block 2 in dir ino 55176185 missing free index for data block 3 in dir ino 55176185 missing free index for data block 4 in dir ino 55176185 missing free index for data block 5 in dir ino 55176185 missing free index for data block 6 in dir ino 55176185 missing free index for data block 7 in dir ino 55176185 missing free index for data block 8 in dir ino 55176185 missing free index for data block 9 in dir ino 55176185 missing free index for data block 10 in dir ino 55176185 missing free index for data block 11 in dir ino 55176185 missing free index for data block 12 in dir ino 55176185 missing free index for data block 13 in dir ino 55176185 missing free index for data block 14 in dir ino 55176185 missing free index for data block 15 in dir ino 55176185 missing free index for data block 16 in dir ino 55176185 missing free index for data block 17 in dir ino 55176185 missing free index for data block 18 in dir ino 55176185 missing free index for data block 19 in dir ino 55176185 missing free index for data block 20 in dir ino 55176185 missing free index for data block 21 in dir ino 55176185 missing free index for data block 22 in dir ino 55176185 missing free index for data block 23 in dir ino 55176185 missing free index for data block 24 in dir ino 55176185 missing free index for data block 25 in dir ino 55176185 missing free index for data block 26 in dir ino 55176185 missing free index for data block 27 in dir ino 55176185 missing free index for data block 28 in dir ino 55176185 missing free index for data block 29 in dir ino 55176185 missing free index for data block 30 in dir ino 55176185 missing free index for data block 31 in dir ino 55176185 missing free index for data block 32 in dir ino 55176185 missing free index for data block 33 in dir ino 55176185 missing free index for data block 34 in dir ino 55176185 missing free index for data block 35 in dir ino 55176185 missing free index for data block 36 in dir ino 55176185 missing free index for data block 37 in dir ino 55176185 missing free index for data block 38 in dir ino 55176185 missing free index for data block 39 in dir ino 55176185 missing free index for data block 40 in dir ino 55176185 missing free index for data block 41 in dir ino 55176185 missing free index for data block 42 in dir ino 55176185 missing free index for data block 43 in dir ino 55176185 missing free index for data block 44 in dir ino 55176185 missing free index for data block 45 in dir ino 55176185 missing free index for data block 46 in dir ino 55176185 missing free index for data block 47 in dir ino 55176185 missing free index for data block 48 in dir ino 55176185 missing free index for data block 49 in dir ino 55176185 missing free index for data block 50 in dir ino 55176185 missing free index for data block 51 in dir ino 55176185 missing free index for data block 52 in dir ino 55176185 missing free index for data block 53 in dir ino 55176185 missing free index for data block 54 in dir ino 55176185 missing free index for data block 56 in dir ino 55176185 missing free index for data block 58 in dir ino 55176185 missing free index for data block 60 in dir ino 55176185 missing free index for data block 63 in dir ino 55176185 missing free index for data block 64 in dir ino 55176185 bad free block nvalid/nused 5/-1 for dir ino 59806790 block 16777216 missing free index for data block 0 in dir ino 59806790 missing free index for data block 1 in dir ino 59806790 missing free index for data block 2 in dir ino 59806790 missing free index for data block 3 in dir ino 59806790 missing free index for data block 4 in dir ino 59806790 bad free block nvalid/nused 21/-1 for dir ino 62915542 block 16777216 missing free index for data block 0 in dir ino 62915542 missing free index for data block 1 in dir ino 62915542 missing free index for data block 2 in dir ino 62915542 missing free index for data block 3 in dir ino 62915542 missing free index for data block 4 in dir ino 62915542 missing free index for data block 5 in dir ino 62915542 missing free index for data block 6 in dir ino 62915542 missing free index for data block 7 in dir ino 62915542 missing free index for data block 8 in dir ino 62915542 missing free index for data block 9 in dir ino 62915542 missing free index for data block 10 in dir ino 62915542 missing free index for data block 11 in dir ino 62915542 missing free index for data block 12 in dir ino 62915542 missing free index for data block 13 in dir ino 62915542 missing free index for data block 14 in dir ino 62915542 missing free index for data block 15 in dir ino 62915542 missing free index for data block 16 in dir ino 62915542 missing free index for data block 17 in dir ino 62915542 missing free index for data block 18 in dir ino 62915542 missing free index for data block 19 in dir ino 62915542 missing free index for data block 20 in dir ino 62915542 Seemed that xfs_repair was able to repair it losslessly - lost+found was empty after repair: deepdance:/mnt # xfs_repair /dev/hda5 Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - clear lost+found (if it exists) ... - 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 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 / ... free block 16777216 for directory inode 1747843 bad nused rebuilding directory inode 1747843 free block 16777216 for directory inode 30448144 bad nused rebuilding directory inode 30448144 free block 16777216 for directory inode 59806790 bad nused rebuilding directory inode 59806790 free block 16777216 for directory inode 55176185 bad nused rebuilding directory inode 55176185 free block 16777216 for directory inode 5012689 bad nused rebuilding directory inode 5012689 free block 16777216 for directory inode 42681258 bad nused rebuilding directory inode 42681258 free block 16777216 for directory inode 46142796 bad nused rebuilding directory inode 46142796 free block 16777216 for directory inode 33641428 bad nused rebuilding directory inode 33641428 free block 16777216 for directory inode 62915542 bad nused rebuilding directory inode 62915542 - traversal finished ... - traversing all unattached subtrees ... - traversals finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... done I reconsidered my conclusion that a hardware failure is unlikely and tested the partition: ------------------------------------------------------- deepdance:~ # badblocks -s -v -n -o /home/martin/XFS-Probleme/badblocks.txt /dev/hda5 Suche nach defekten Bloecken im zerstoerungsfreien Lesen+Schreiben-Modus Von Block 0 bis 9767488 Suche nach defekten Bloecken (zerstoerungsfreier Lesen+Schreiben-Modus) Teste mit zufaelligen Mustern: erledigt Durchgang beendet, 0 defekte Bloecke gefunden. ------------------------------------------------------- Its in german, I forgot to change the locale, it reports 0 defect blocks found. The badblock file is zero bytes as well: ------------------------------------------------------- martin@deepdance:~/XFS-Probleme> ls -l badblocks.txt -rw-r--r-- 1 root root 0 2006-06-23 18:31 badblocks.txt ------------------------------------------------------- I did a long SMART selftest using "smartctl -t long /dev/hda". It completed without errors: ------------------------------------------------------- deepdance:~ # smartctl -l selftest /dev/hda smartctl version 5.33 [i686-pc-linux-gnu] Copyright (C) 2002-4 Bruce Allen Home page is http://smartmontools.sourceforge.net/ === START OF READ SMART DATA SECTION === SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Extended offline Completed without error 00% 5868 - # 2 Short offline Completed without error 00% 2950 - # 3 Extended offline Completed without error 00% 2944 - # 4 Short offline Completed without error 00% 2913 - {... all further tests without error ...] ------------------------------------------------------- There have been no tests for a long time due to a mistake in /etc/smartd.conf which I hopefully corrected today. So it seems the harddisk is okay. Only thing is 5 of these errors in the error log (all on disk power-on lifetime 393 hours): ------------------------------------------------------- deepdance:~ # smartctl -l error /dev/hda [...] Error 200 occurred at disk power-on lifetime: 393 hours (16 days + 9 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 10 59 01 73 65 6c ee Error: IDNF at LBA = 0x0e6c6573 = 241984883 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- 20 03 01 73 65 6c ee 00 00:00:50.900 READ SECTOR(S) c8 03 01 73 65 6c ee 00 00:00:50.900 READ DMA 20 03 01 73 65 6c ee 00 00:00:50.800 READ SECTOR(S) c8 03 01 73 65 6c ee 00 00:00:50.800 READ DMA 20 03 01 73 65 6c ee 00 00:00:50.700 READ SECTOR(S) ------------------------------------------------------- They are strange, cause the device does not have that much sectors: ------------------------------------------------------- deepdance:~ # LANG=C fdisk -lu /dev/hda Disk /dev/hda: 60.0 GB, 60011642880 bytes 255 heads, 63 sectors/track, 7296 cylinders, total 117210240 sectors Units = sectors of 1 * 512 = 512 bytes Device Boot Start End Blocks Id System /dev/hda1 * 63 9767519 4883728+ 7 HPFS/NTFS /dev/hda2 10233405 19535039 4650817+ c W95 FAT32 (LBA) /dev/hda3 9767520 10233404 232942+ 6 FAT16 /dev/hda4 19535040 117210239 48837600 5 Extended /dev/hda5 19535103 39070079 9767488+ 83 Linux /dev/hda6 39070143 58605119 9767488+ 83 Linux /dev/hda7 58605183 60565049 979933+ 82 Linux swap / Solaris /dev/hda8 60565113 117210239 28322563+ 83 Linux Partition table entries are not in disk order [I know, I added the extended partition before I resized the FAT32 partition to add a FAT16 one for FreeDOS;)] ------------------------------------------------------- I intend to ask on the smartmontools mailinglist about those. And I will run a memtest86 over night. Any other tips to diagnose a hardware problem? Or do above XFS errors hint at a software bug? I did not file this as bug report yet - cause I am not too sure that it is not a hardware failure. I will do, if you want me to. I really want to trace that all down. I do not really have the feeling that my data is safe at the moment (well I have a backup as of today on an external USB drive). If XFS gets corrupted again I may switch that partition to ext3. If it then crashes with ext3 I may be better off replacing that harddisk, even when I could not diagnose an error with it. But first that memtest this night... maybe this reveals something. Regards, Martin -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 From owner-xfs@oss.sgi.com Fri Jun 23 13:17:56 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 23 Jun 2006 13:18:13 -0700 (PDT) Received: from mondschein.lichtvoll.de (ms1.lichtvoll.de [194.150.191.234]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5NKHtDW010359 for ; Fri, 23 Jun 2006 13:17:55 -0700 Received: from localhost (dslb-084-056-110-075.pools.arcor-ip.net [84.56.110.75]) by mondschein.lichtvoll.de (Postfix) with ESMTP id 6BD70FA511 for ; Fri, 23 Jun 2006 22:16:08 +0200 (CEST) From: Martin Steigerwald To: linux-xfs@oss.sgi.com Subject: XFS safe with CONFIG_REGPARM? User-Agent: KMail/1.9.1 MIME-Version: 1.0 Content-Disposition: inline Date: Fri, 23 Jun 2006 22:15:33 +0200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200606232215.33555.Martin@lichtvoll.de> X-archive-position: 8032 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Martin@lichtvoll.de Precedence: bulk X-list: xfs Content-Length: 1078 Lines: 28 Hello, I had an XFS filesystem crash using 2.6.15.7 with sws2-2.2 and CONFIG_REGPARM some week ago (not the one yesterday that was without CONFIG_REGPARM). The kernel crashed down badly and the XFS formatted debian root partition was so corrupted that I decided to restore a backup. I did not report it since I was busy doing other stuff. I thought this happened due to CONFIG_REGPARM being set... I am not so sure anymore since I now had that bad crash with 2.6.15 without CONFIG_REGPARM being set (see my last mails). Now given that CONFIG_REGPARM defaults to being enabled with 2.6.17 I am interested whether its safe to use with XFS. I do not use it currently to be on the safe side. This is the patch that enabled it by default: http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b824eb605ccba995fd32c6590aed365f93d48002 I asked the same question for software suspend 2 on suspend2-users@lists.suspend2.net Regards, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 From owner-xfs@oss.sgi.com Sat Jun 24 02:46:28 2006 Received: with ECARTIS (v1.0.0; list xfs); Sat, 24 Jun 2006 02:46:44 -0700 (PDT) Received: from mondschein.lichtvoll.de (ms1.lichtvoll.de [194.150.191.234]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5O9kNDW030763 for ; Sat, 24 Jun 2006 02:46:28 -0700 Received: from localhost (dslb-084-056-085-255.pools.arcor-ip.net [84.56.85.255]) by mondschein.lichtvoll.de (Postfix) with ESMTP id 9667AFA510; Sat, 24 Jun 2006 11:44:29 +0200 (CEST) From: Martin Steigerwald To: Martin Steigerwald Subject: Re: xfs crash with linux 2.6.15.7 and disabled write caches (long) Date: Sat, 24 Jun 2006 11:43:59 +0200 User-Agent: KMail/1.9.1 References: <200606230156.04907.Martin@lichtvoll.de> <200606230912.35640.Martin@lichtvoll.de> <200606232201.29440.Martin@lichtvoll.de> In-Reply-To: <200606232201.29440.Martin@lichtvoll.de> Cc: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Message-Id: <200606241143.59536.Martin@lichtvoll.de> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id k5O9kSDW030776 X-archive-position: 8033 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Martin@lichtvoll.de Precedence: bulk X-list: xfs Content-Length: 1410 Lines: 50 Am Freitag 23 Juni 2006 22:01 schrieben Sie: > And I will run a memtest86 over night. Hello, memtest86 was fine as well. No errors. Seems that the hardware works like I except from IBM quality. Well lets see how that continues. I probably write a kernel bug report about this later 2.6.17.1 and 2.6.16.11 XFS crash... (dunno on which kernel it happened, since I had no kernel ooops)... But it might not worth it. It may be better when I now use 2.6.17.1 only in order to be able to tell the exact kernel version and configuration under which corruption occured, should corruption occur again. But for I probably should update the SUSE 10.1 kernel to my 2.6.17.1 configuration as well. BTW even blktool cannot query write cache: root@deepdance:~ -> blktool /dev/hda wcache it is not possible to query settings via command 'wcache' Unless I may get this one to work: root@deepdance:~ -> blktool /dev/hda i2o-wcache BLKI2OGWSTRAT: Invalid argument From manage: i2o-wcache Query or set an I2O block device's write cache. Maybe with one of the next kernels I build, the current one doesnt support it: root@deepdance:/boot -> grep "I2O" config-2.6.17.1-tp23-sws2-2.2.6 # CONFIG_SCSI_DPT_I2O is not set # I2O device support # CONFIG_I2O is not set Regards, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 From owner-xfs@oss.sgi.com Sun Jun 25 04:54:43 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 25 Jun 2006 04:55:06 -0700 (PDT) Received: from postfix1-c.free.fr (postfix1-c.free.fr [213.228.0.79]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5PBsgDW025525 for ; Sun, 25 Jun 2006 04:54:43 -0700 Received: from smtp1-g19.free.fr (smtp1-g19.free.fr [212.27.42.27]) by postfix1-c.free.fr (Postfix) with ESMTP id 834A11D3E53A for ; Sun, 25 Jun 2006 11:09:43 +0200 (CEST) Received: from [192.168.0.7] (mna75-2-82-67-197-146.fbx.proxad.net [82.67.197.146]) by smtp1-g19.free.fr (Postfix) with ESMTP id AAF349A65B; Sun, 25 Jun 2006 12:09:26 +0200 (CEST) From: Duncan Sands To: "Avuton Olrich" Subject: Re: XFS crashed twice, once in 2.6.16.20, next in 2.6.17, reproducable Date: Sun, 25 Jun 2006 12:09:23 +0200 User-Agent: KMail/1.9.1 Cc: "Nathan Scott" , linux-kernel@vger.kernel.org, xfs@oss.sgi.com References: <3aa654a40606190044q43dca571qdc06ee13d82d979@mail.gmail.com> <20060620165209.C1080488@wobbly.melbourne.sgi.com> <3aa654a40606200120v5baf0304ka205f1ad8f136ad9@mail.gmail.com> In-Reply-To: <3aa654a40606200120v5baf0304ka205f1ad8f136ad9@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606251209.23766.duncan.sands@math.u-psud.fr> X-archive-position: 8036 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: duncan.sands@math.u-psud.fr Precedence: bulk X-list: xfs Content-Length: 678 Lines: 15 I just got a new XFS crash running 2.6.17, again with problems at block 16777216 - I'll try to make a copy of the corrupted filesystem available. Interestingly enough, I'm also seeing ext3 corruption. The usual manifestation is that a program fails to run, with a message about it not being in executable format (if it happens again I will take a note of the exact message). I've had no problems at all with 2.6.17. It seems to be happening randomly, which makes me suspect a race condition (uniprocessor machine, but preemptable kernel), or memory corruption. I will rebuild the kernel with all kernel debugging options turned on, once I recover the filesystem. Ciao, D. From owner-xfs@oss.sgi.com Sun Jun 25 06:55:45 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 25 Jun 2006 06:56:08 -0700 (PDT) Received: from smtp2-g19.free.fr (smtp2-g19.free.fr [212.27.42.28]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5PDtdDW007353 for ; Sun, 25 Jun 2006 06:55:45 -0700 Received: from [192.168.0.7] (mna75-2-82-67-197-146.fbx.proxad.net [82.67.197.146]) by smtp2-g19.free.fr (Postfix) with ESMTP id 9096B73141; Sun, 25 Jun 2006 15:55:20 +0200 (CEST) From: Duncan Sands To: "Avuton Olrich" Subject: Re: XFS crashed twice, once in 2.6.16.20, next in 2.6.17, reproducable Date: Sun, 25 Jun 2006 15:55:17 +0200 User-Agent: KMail/1.9.1 Cc: "Nathan Scott" , linux-kernel@vger.kernel.org, xfs@oss.sgi.com References: <3aa654a40606190044q43dca571qdc06ee13d82d979@mail.gmail.com> <3aa654a40606200120v5baf0304ka205f1ad8f136ad9@mail.gmail.com> <200606251209.23766.duncan.sands@math.u-psud.fr> In-Reply-To: <200606251209.23766.duncan.sands@math.u-psud.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606251555.18356.duncan.sands@math.u-psud.fr> X-archive-position: 8037 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: duncan.sands@math.u-psud.fr Precedence: bulk X-list: xfs Content-Length: 944 Lines: 18 On Sunday 25 June 2006 12:09, Duncan Sands wrote: > I just got a new XFS crash running 2.6.17, again with problems at block > 16777216 - I'll try to make a copy of the corrupted filesystem available. > Interestingly enough, I'm also seeing ext3 corruption. The usual > manifestation is that a program fails to run, with a message about it > not being in executable format (if it happens again I will take a note of > the exact message). I've had no problems at all with 2.6.17. It seems > to be happening randomly, which makes me suspect a race condition > (uniprocessor machine, but preemptable kernel), or memory corruption. > I will rebuild the kernel with all kernel debugging options turned > on, once I recover the filesystem. Sorry, that should say: "I've had no problems at all with 2.6.15". Also, xfs_repair successfully repaired the filesystem this time. I've kept a copy of the filesystem in case anyone is interested. Duncan. From owner-xfs@oss.sgi.com Sun Jun 25 08:01:58 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 25 Jun 2006 08:02:22 -0700 (PDT) Received: from smtp.sifycorp.com (smtp.sifycorp.com [202.144.77.55]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5PF1rDW014303 for ; Sun, 25 Jun 2006 08:01:56 -0700 Received: (sifymail 13246 invoked by uid 507); 25 Jun 2006 19:31:35 +0530 Received: from 10.1.8.85 (HELO smtp.sifycorp.com) (10.1.8.85) by 10.1.8.85 with ESMTP; 25 Jun 2006 19:31:35 +0530 X-QHPSI: clean Received: (sifymail 13233 invoked by uid 507); 25 Jun 2006 19:31:34 +0530 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=corporate; d=sifycorp.com; b=pba/vGd0d9VdtPqHJTtpKlMLGJcqDUbuPP39JqgKDDM2ng9Gyjg8QWqduGDpm0o0 ; Received: from 221.135.104.102 (HELO TDLTI4) (manojkumar_mp@sifycorp.com@221.135.104.102) by 10.1.8.85 with ESMTPA; 25 Jun 2006 19:31:34 +0530 Message-ID: <006f01c6985f$ae71da90$666887dd@TDLTI4> From: "Manoj Kumar" To: Cc: , Subject: Phase 7 Fatal Error Date: Sun, 25 Jun 2006 19:30:13 +0530 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit X-archive-position: 8038 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: manojkumar_mp@sifycorp.com Precedence: bulk X-list: xfs Content-Length: 1320 Lines: 36 Hi, When I tried to xfs I am having this error . xfs_iread:dip --> di_core.di_magic(0xa68) !=XFS_DINODE_MAGIC (OX494 e) fatal error -- couldn't map inode 14413788, err=22 Regards, Saravanan V S ********** DISCLAIMER ********** Information contained and transmitted by this E-MAIL is proprietary to Sify Limited and is intended for use only by the individual or entity to which it is addressed, and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If this is a forwarded message, the content of this E-MAIL may not have been sent with the authority of the Company. If you are not the intended recipient, an agent of the intended recipient or a person responsible for delivering the information to the named recipient, you are notified that any use, distribution, transmission, printing, copying or dissemination of this information in any way or in any manner is strictly prohibited. If you have received this communication in error, please delete this mail & notify us immediately at admin@sifycorp.com Log on to www.Sifymax.com for Cricket video score card, Hot videos from Lakme Fashion Week and more only on Sify Max! Get to see what's happening in your favourite City on Bangalore Live! www.bangalorelive.in [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Sun Jun 25 13:15:12 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 25 Jun 2006 13:15:31 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.190]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5PKFBDW025299 for ; Sun, 25 Jun 2006 13:15:12 -0700 Received: by nf-out-0910.google.com with SMTP id a25so810600nfc for ; Sun, 25 Jun 2006 13:14:53 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:mime-version:content-type:content-disposition:user-agent; b=URnJenJFtbLZa8u0/SdcocDWrMwUuM7t6t69PymI5p2g0BtjjLjm4r8DM8EJ+SvAHy5WUdsgrGvhXazATD4mfehD+qMJFCllRB4L50rGsxmsSvuiRV9BnhZUH/DyoqnJMVW7r9Wb/8kyDiV0nD9dP7ihaAm90pWXc8qESUZlVug= Received: by 10.48.242.3 with SMTP id p3mr4297314nfh; Sun, 25 Jun 2006 13:14:53 -0700 (PDT) Received: from gmail.com ( [217.67.117.64]) by mx.gmail.com with ESMTP id a23sm5329820nfc.2006.06.25.13.14.52; Sun, 25 Jun 2006 13:14:53 -0700 (PDT) Received: by gmail.com (nbSMTP-1.00) for uid 1000 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168/168 bits)) adobriyan@gmail.com; Mon, 26 Jun 2006 00:15:31 +0400 (MSD) Date: Mon, 26 Jun 2006 00:15:29 +0400 From: Alexey Dobriyan To: Andrew Morton Cc: xfs@oss.sgi.com, linux-fsdevel@vger.kernel.org Subject: [PATCH] xfs: update ->flush method proto Message-ID: <20060625201529.GA7560@martell.zuzino.mipt.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11 X-archive-position: 8039 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: adobriyan@gmail.com Precedence: bulk X-list: xfs Content-Length: 464 Lines: 19 Signed-off-by: Alexey Dobriyan --- fs/xfs/linux-2.6/xfs_file.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/fs/xfs/linux-2.6/xfs_file.c +++ b/fs/xfs/linux-2.6/xfs_file.c @@ -295,7 +295,8 @@ xfs_file_open( STATIC int xfs_file_close( - struct file *filp) + struct file *filp, + fl_owner_t id) { return -bhv_vop_close(vn_from_inode(filp->f_dentry->d_inode), 0, file_count(filp) > 1 ? L_FALSE : L_TRUE, NULL); From owner-xfs@oss.sgi.com Sun Jun 25 13:43:12 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 25 Jun 2006 13:43:25 -0700 (PDT) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5PKhBDW029164 for ; Sun, 25 Jun 2006 13:43:11 -0700 Received: by ug-out-1314.google.com with SMTP id e2so1722319ugf for ; Sun, 25 Jun 2006 13:42:53 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:mime-version:content-type:content-disposition:user-agent; b=fDJtbWqYOyN8JunPstPjdw9ZmR8AFsE0nFcEQOjdHUsQjpWQd223LznLrKSsk6IsLUNQsNaN76ujlPkMa9SirJ8cCXAo3sDKyNpQGSFxwNRK9x7zaE/rju0L+5u05IcnVBo7toGhe7c/jC4pYgJWpeM5VENoi/BbhucNXfYW0lQ= Received: by 10.66.221.19 with SMTP id t19mr4298545ugg; Sun, 25 Jun 2006 13:42:53 -0700 (PDT) Received: from gmail.com ( [217.67.117.64]) by mx.gmail.com with ESMTP id k1sm3290931ugf.2006.06.25.13.42.45; Sun, 25 Jun 2006 13:42:51 -0700 (PDT) Received: by gmail.com (nbSMTP-1.00) for uid 1000 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168/168 bits)) adobriyan@gmail.com; Mon, 26 Jun 2006 00:43:29 +0400 (MSD) Date: Mon, 26 Jun 2006 00:43:22 +0400 From: Alexey Dobriyan To: Andrew Morton Cc: linux-fsdevel@vger.kernel.org, xfs@oss.sgi.com Subject: [PATCH v2] xfs: drop dir checks on link(directory) Message-ID: <20060625204322.GA9086@martell.zuzino.mipt.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11 X-archive-position: 8040 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: adobriyan@gmail.com Precedence: bulk X-list: xfs Content-Length: 771 Lines: 32 VFS bans it. Signed-off-by: Alexey Dobriyan --- fs/xfs/linux-2.6/xfs_iops.c | 2 -- fs/xfs/xfs_vnodeops.c | 2 -- 2 files changed, 4 deletions(-) --- a/fs/xfs/linux-2.6/xfs_iops.c +++ b/fs/xfs/linux-2.6/xfs_iops.c @@ -419,8 +419,6 @@ xfs_vn_link( int error; ip = old_dentry->d_inode; /* inode being linked to */ - if (S_ISDIR(ip->i_mode)) - return -EPERM; tdvp = vn_from_inode(dir); vp = vn_from_inode(ip); --- a/fs/xfs/xfs_vnodeops.c +++ b/fs/xfs/xfs_vnodeops.c @@ -2603,8 +2603,6 @@ xfs_link( vn_trace_entry(src_vp, __FUNCTION__, (inst_t *)__return_address); target_namelen = VNAMELEN(dentry); - if (VN_ISDIR(src_vp)) - return XFS_ERROR(EPERM); sip = xfs_vtoi(src_vp); tdp = XFS_BHVTOI(target_dir_bdp); From owner-xfs@oss.sgi.com Sun Jun 25 15:09:14 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 25 Jun 2006 15:09:26 -0700 (PDT) Received: from ZenIV.linux.org.uk (zeniv.linux.org.uk [195.92.253.2]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5PM9DDW008011 for ; Sun, 25 Jun 2006 15:09:13 -0700 Received: from viro by ZenIV.linux.org.uk with local (Exim 4.52 #1 (Red Hat Linux)) id 1FubHL-0008QD-NU; Sun, 25 Jun 2006 21:32:23 +0100 Date: Sun, 25 Jun 2006 21:32:23 +0100 From: Al Viro To: Alexey Dobriyan Cc: Andrew Morton , xfs@oss.sgi.com, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH] xfs: update ->flush method proto Message-ID: <20060625203223.GI27946@ftp.linux.org.uk> References: <20060625201529.GA7560@martell.zuzino.mipt.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060625201529.GA7560@martell.zuzino.mipt.ru> User-Agent: Mutt/1.4.1i X-archive-position: 8041 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: viro@ftp.linux.org.uk Precedence: bulk X-list: xfs Content-Length: 1015 Lines: 32 On Mon, Jun 26, 2006 at 12:15:29AM +0400, Alexey Dobriyan wrote: > Signed-off-by: Alexey Dobriyan ACK. Another in the same direction and that should cover it (patch is incremental, not replacement) Signed-off-by: Al Viro --- diff --git a/arch/powerpc/platforms/cell/spufs/file.c b/arch/powerpc/platforms/cell/spufs/file.c index 80c0266..ee9c160 100644 --- a/arch/powerpc/platforms/cell/spufs/file.c +++ b/arch/powerpc/platforms/cell/spufs/file.c @@ -1150,7 +1150,7 @@ static unsigned int spufs_mfc_poll(struc return mask; } -static int spufs_mfc_flush(struct file *file) +static int spufs_mfc_flush(struct file *file, fl_owner_t id) { struct spu_context *ctx = file->private_data; int ret; @@ -1176,7 +1176,7 @@ #endif static int spufs_mfc_fsync(struct file *file, struct dentry *dentry, int datasync) { - return spufs_mfc_flush(file); + return spufs_mfc_flush(file, NULL); } static int spufs_mfc_fasync(int fd, struct file *file, int on) From owner-xfs@oss.sgi.com Sun Jun 25 16:27:55 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 25 Jun 2006 16:28:17 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k5PNRgDW020996 for ; Sun, 25 Jun 2006 16:27:54 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA02894 for ; Mon, 26 Jun 2006 09:27:15 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id BC60F4A588F9; Mon, 26 Jun 2006 09:27:13 +1000 (EST) To: linux-xfs@oss.sgi.com Subject: TAKE 904196 - cleanup & warning fixes from Alexey Message-Id: <20060625232713.BC60F4A588F9@chook.melbourne.sgi.com> Date: Mon, 26 Jun 2006 09:27:13 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 8042 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 1381 Lines: 40 Remove redundant directory checks from inode link operation. Signed-off-by: Alexey Dobriyan Date: Mon Jun 26 09:23:07 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: Alexey Dobriyan The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:26343a linux-2.6/xfs_iops.c - 1.252 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_iops.c.diff?r1=text&tr1=1.252&r2=text&tr2=1.251&f=h linux-2.4/xfs_iops.c - 1.227 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_iops.c.diff?r1=text&tr1=1.227&r2=text&tr2=1.226&f=h - Remove redundant directory checks from inode link operation. Update flush method prototype. Signed-off-by: Alexey Dobriyan Date: Mon Jun 26 09:26:34 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: Alexey Dobriyan ,Al Viro The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:26344a linux-2.6/xfs_file.c - 1.142 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_file.c.diff?r1=text&tr1=1.142&r2=text&tr2=1.141&f=h - Update flush method prototype. From owner-xfs@oss.sgi.com Sun Jun 25 20:49:10 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 25 Jun 2006 20:49:40 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k5Q3mvDW023517 for ; Sun, 25 Jun 2006 20:49:08 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA07881; Mon, 26 Jun 2006 13:48:25 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 179464A588F9; Mon, 26 Jun 2006 13:48:24 +1000 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: PARTIAL TAKE 953287 - link fix Message-Id: <20060626034824.179464A588F9@chook.melbourne.sgi.com> Date: Mon, 26 Jun 2006 13:48:24 +1000 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 8045 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 739 Lines: 18 Remove a race condition where a linked inode could BUG_ON in d_instantiate, due to fast transaction committal removing the last remaining reference before we were all done. Date: Mon Jun 26 13:47:38 AEST 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: tes The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:26347a linux-2.6/xfs_iops.c - 1.253 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_iops.c.diff?r1=text&tr1=1.253&r2=text&tr2=1.252&f=h linux-2.4/xfs_iops.c - 1.228 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_iops.c.diff?r1=text&tr1=1.228&r2=text&tr2=1.227&f=h From owner-xfs@oss.sgi.com Sun Jun 25 21:08:12 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 25 Jun 2006 21:08:36 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k5Q47vDW025704 for ; Sun, 25 Jun 2006 21:08:11 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA08203; Mon, 26 Jun 2006 14:07:24 +1000 From: Timothy Shimmin Organization: SGI To: Johannes Berg Subject: Re: error xlog_recover_do_inode_trans(1) / bug when recovering Date: Mon, 26 Jun 2006 14:06:48 +1000 User-Agent: KMail/1.8.2 Cc: xfs@oss.sgi.com References: <1151074934.7608.43.camel@localhost> In-Reply-To: <1151074934.7608.43.camel@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606261406.48756.tes@sgi.com> X-archive-position: 8046 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs Content-Length: 868 Lines: 21 Hi Johannes, On Saturday 24 June 2006 1:02 am, Johannes Berg wrote: > I got a corrupted xfs device that printed out, when trying to recover: > Bad inode magic number, .... > Internal error xlog_recover_do_inode_trans(1) ... > Looks like the inode item in the transaction is bad in the ondisk log. Did you mount and replay the log with a different word-size linux by any chance? I.e. replay with 32 bit linux having crashed on a 64 bit linux or vice versa? (Seen a few of those lately) If it was that case, then this is a known bug and now handled in recovery with a new kernel. Normally, though that bug is shown slightly ealier when it tries to read from a bad inode offset IIRC. It would be interesting to see the ondisk log which can be saved using # xfs_logprint -C filename devicename However, "xfs_repair -L" will have zeroed yours out now. Cheers, --Tim From owner-xfs@oss.sgi.com Sun Jun 25 22:29:23 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 25 Jun 2006 22:29:45 -0700 (PDT) Received: from sipsolutions.net (crystal.sipsolutions.net [195.210.38.204]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5Q5TJDW002567 for ; Sun, 25 Jun 2006 22:29:22 -0700 Received: from [84.135.236.245] (helo=johannes.berg) by sipsolutions.net with esmtpsa (TLS-1.0:RSA_ARCFOUR_MD5:16) (Exim 4.62) (envelope-from ) id 1FujeU-0001f3-Tu; Mon, 26 Jun 2006 06:28:52 +0100 Subject: Re: error xlog_recover_do_inode_trans(1) / bug when recovering From: Johannes Berg To: Timothy Shimmin Cc: xfs@oss.sgi.com In-Reply-To: <200606261406.48756.tes@sgi.com> References: <1151074934.7608.43.camel@localhost> <200606261406.48756.tes@sgi.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-DiAltrdnjInfVgUnrcHg" Date: Mon, 26 Jun 2006 07:28:32 +0200 Message-Id: <1151299712.7608.67.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 X-archive-position: 8048 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: johannes@sipsolutions.net Precedence: bulk X-list: xfs Content-Length: 2099 Lines: 53 --=-DiAltrdnjInfVgUnrcHg Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi, > On Saturday 24 June 2006 1:02 am, Johannes Berg wrote: > > I got a corrupted xfs device that printed out, when trying to recover: > > Bad inode magic number, .... > > Internal error xlog_recover_do_inode_trans(1) ... > > > Looks like the inode item in the transaction is bad in the ondisk log. > Did you mount and replay the log with a different word-size linux by any= =20 > chance? I.e. replay with 32 bit linux having crashed on a 64 bit linux or > vice versa? (Seen a few of those lately) No, the filesystem is used only on my 64-bit system. I did all the recovery from my laptop (32-bit) but seeing it crash at replay on my 64 bit system made me not even try the replay from my laptop via firewire. > It would be interesting to see the ondisk log which can be saved using > # xfs_logprint -C filename devicename > However, "xfs_repair -L" will have zeroed yours out now. Well, I still have a copy, so if xfs_repair -C works on an image file I can extract the log. I'll mail it to you later today or tomorrow. johannes --=-DiAltrdnjInfVgUnrcHg Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- iQIVAwUARJ9wfqVg1VMiehFYAQKmnBAAqbfiZUZx1wYPQwJVBWVBe0QKAPbmulcp 0Kx7MQDQQkWFOgVrvOvTUM9CgLtNAJjkRYg7FbqX4pR57ZWdQb2lymnqLdC0zoUc ZnBzkkGrQf9unITtgm8S6qT+LNJN1bB/JhfpBBnzAQDG7BYix1MBWM/LlWacltHR 96I2rDowm2xeOEcHDjPNS7XhnAhk/RzBclsX6WdoffhbbdboZXSTkSzOQ+6PEQ/8 f8MiPWYEO+yFCDkXf0LI57ewInfFyjdlV4hvxTzhfuWSQbYIjPYscwWf+WiNVOy9 pBCeCWjitawd47800n0wCKgIPrNUZp8XOnlNS6NCvgiezGZhM4i3tKeV506mWzW8 wQhWDUS2VeGcms/Rsj7+OsF32JhSJ2AI9NnlpGgsy1b9RhL5pPIe/ksHX3o+/1k/ iOhXtc4KAr4ZdiPY3KK+f/QQr2VIgxflyzjf6GM+VGpnLlkfoPQFXdVJZ0ku4yo0 RK8dQs7M09OJykxspG0qP5+YaLouN5syaGpfGVH4UqDA9IJnBvrtoCkuEJv6Bd5G QMj5Ko51akchlvur5v2vqx99BlHhYmQQOt9tH/d/2Fvh9mbV1euMXW3RZAl/Ysl3 ruOi3qaZygh0uWQCqC3cAg1DXU4SB9RuY3wfZqiC/DI4tUkXfh0g3LLSRIVyPyF/ u+5oMGYeTrk= =jdG6 -----END PGP SIGNATURE----- --=-DiAltrdnjInfVgUnrcHg-- From owner-xfs@oss.sgi.com Sun Jun 25 22:25:51 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 25 Jun 2006 22:26:19 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k5Q5PbDW001683 for ; Sun, 25 Jun 2006 22:25:49 -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 PAA09533; Mon, 26 Jun 2006 15:25:04 +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 k5Q5P0gw1264800; Mon, 26 Jun 2006 15:25:01 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k5Q5OwZc1263039; Mon, 26 Jun 2006 15:24:58 +1000 (EST) Date: Mon, 26 Jun 2006 15:24:57 +1000 From: Nathan Scott To: "Randy.Dunlap" Cc: xfs@oss.sgi.com, lkml Subject: Re: XFS warning (2.6.17-git9) Message-ID: <20060626152457.A1264508@wobbly.melbourne.sgi.com> References: <20060625221459.7e72bbad.rdunlap@xenotime.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20060625221459.7e72bbad.rdunlap@xenotime.net>; from rdunlap@xenotime.net on Sun, Jun 25, 2006 at 10:14:59PM -0700 X-archive-position: 8047 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 434 Lines: 15 On Sun, Jun 25, 2006 at 10:14:59PM -0700, Randy.Dunlap wrote: > > was a new (second) parameter added? > > on xfs_file_close: > fs/xfs/linux-2.6/xfs_file.c:555: warning: initialization from incompatible pointer type > fs/xfs/linux-2.6/xfs_file.c:580: warning: initialization from incompatible pointer type > Its been fixed already in Linus git tree. A second parameter was added just after the XFS callout was added. -- Nathan From owner-xfs@oss.sgi.com Mon Jun 26 00:29:00 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 26 Jun 2006 00:29:24 -0700 (PDT) Received: from xenotime.net (xenotime.net [66.160.160.81]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k5Q7SxDW021775 for ; Mon, 26 Jun 2006 00:28:59 -0700 Received: from midway.site ([71.245.108.25]) by xenotime.net for ; Sun, 25 Jun 2006 22:12:11 -0700 Date: Sun, 25 Jun 2006 22:14:59 -0700 From: "Randy.Dunlap" To: nathans@sgi.com, xfs@oss.sgi.com Cc: lkml Subject: XFS warning (2.6.17-git9) Message-Id: <20060625221459.7e72bbad.rdunlap@xenotime.net> Organization: YPO4 X-Mailer: Sylpheed version 2.2.5 (GTK+ 2.8.3; x86_64-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 8049 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: rdunlap@xenotime.net Precedence: bulk X-list: xfs Content-Length: 246 Lines: 10 was a new (second) parameter added? on xfs_file_close: fs/xfs/linux-2.6/xfs_file.c:555: warning: initialization from incompatible pointer type fs/xfs/linux-2.6/xfs_file.c:580: warning: initialization from incompatible pointer type --- ~Randy From owner-xfs@oss.sgi.com Mon Jun 26 21:20:19 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 26 Jun 2006 21:20:46 -0700 (PDT) Received: from omx1.americas.sgi.com (omx1.americas.sgi.com [198.149.16.13]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5R4K8DW008467 for ; Mon, 26 Jun 2006 21:20:18 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with SMTP id k5R37Xnx012106 for ; Mon, 26 Jun 2006 22:07:34 -0500 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA08983; Tue, 27 Jun 2006 13:07:22 +1000 From: Timothy Shimmin Organization: SGI To: Martin Steigerwald Subject: Re: Repeating fs corruption Date: Tue, 27 Jun 2006 13:06:43 +1000 User-Agent: KMail/1.8.2 Cc: ViNiL , linux-xfs@oss.sgi.com References: <200606201758.20400.vladimir.linek@netcentrum.cz> <200606211218.21463.tes@sgi.com> <200606210854.57238.Martin@lichtvoll.de> In-Reply-To: <200606210854.57238.Martin@lichtvoll.de> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Message-Id: <200606271306.43872.tes@sgi.com> X-archive-position: 8051 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs Content-Length: 1828 Lines: 45 On Wednesday 21 June 2006 4:54 pm, Martin Steigerwald wrote: > Am Mittwoch 21 Juni 2006 04:18 schrieb Timothy Shimmin: > > On Wednesday 21 June 2006 5:44 am, Martin Steigerwald wrote: > > > Am Dienstag 20 Juni 2006 17:58 schrieb ViNiL: > > > > Can anyone explain to me, what (and why is that :-) is going on > > > > with the filesystem? > > > > > > do you use write caching? With kernel 2.6.16 XFS got corrupted three > > > times in one week here with writecache enabled. > > > > FYI > > Have you looked at: > > http://oss.sgi.com/projects/xfs/faq.html#wcache > > Hello, Hi. My procmail didn't like you and I've just seen your email. > > yes I did, but still I do not understand the complete picture: > > Firstly hdparm -i /dev/somedevice does not show the *current* state of the > write cache but only the harddisk default state. This can easily be > verified by using hdparm -W0 and then hdparm -i again. Unfortunately it > is not possible to query the write cache status via hdparm -W. > But how about using "hdparm -I" like the faq suggests? :) Uppercase -I seems to work for me. -i Display the identification info that was obtained from the drive at boot time, if available.... -I Request identification info directly from the drive, which is displayed in a new expanded format with considerably more detail than with the older -i flag. > > I am have the oppinion, that XFS should deny write access when it detects > it cannot be safe. But for that it would be necessary to query the > current harddisks writecache state and whether write barrier is > available. It write cache is on and write barrier is off, XFS should > mount read only IMHO and issuing a big fat warning. > Yeah, this subject has been discussed before with the XFS team. --Tim From owner-xfs@oss.sgi.com Mon Jun 26 22:16:31 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 26 Jun 2006 22:16:55 -0700 (PDT) Received: from mondschein.lichtvoll.de (ms2.lichtvoll.de [194.150.191.235] (may be forged)) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5R5GUDW016143 for ; Mon, 26 Jun 2006 22:16:31 -0700 Received: from localhost (dslb-084-057-099-253.pools.arcor-ip.net [84.57.99.253]) by mondschein.lichtvoll.de (Postfix) with ESMTP id F3D04FA50F; Tue, 27 Jun 2006 07:14:08 +0200 (CEST) From: Martin Steigerwald To: Timothy Shimmin Subject: Re: Repeating fs corruption Date: Tue, 27 Jun 2006 07:16:01 +0200 User-Agent: KMail/1.9.1 Cc: ViNiL , linux-xfs@oss.sgi.com References: <200606201758.20400.vladimir.linek@netcentrum.cz> <200606210854.57238.Martin@lichtvoll.de> <200606271306.43872.tes@sgi.com> In-Reply-To: <200606271306.43872.tes@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606270716.01988.Martin@lichtvoll.de> X-archive-position: 8052 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Martin@lichtvoll.de Precedence: bulk X-list: xfs Content-Length: 1470 Lines: 38 Am Dienstag 27 Juni 2006 05:06 schrieb Timothy Shimmin: > > yes I did, but still I do not understand the complete picture: > > > > Firstly hdparm -i /dev/somedevice does not show the *current* state > > of the write cache but only the harddisk default state. This can > > easily be verified by using hdparm -W0 and then hdparm -i again. > > Unfortunately it is not possible to query the write cache status via > > hdparm -W. > > But how about using "hdparm -I" like the faq suggests? :) > Uppercase -I seems to work for me. Hello Timothy, thank you. Yeah, hdparm -I works for me, too. I didn't notice that it was an uppercase I in the FAQ. > > I am have the oppinion, that XFS should deny write access when it > > detects it cannot be safe. But for that it would be necessary to > > query the current harddisks writecache state and whether write > > barrier is available. It write cache is on and write barrier is off, > > XFS should mount read only IMHO and issuing a big fat warning. > Yeah, this subject has been discussed before with the XFS team. Right now things seem to be pretty stable with 2.6.17.1 and disabled write caches. If all goes well, I will make a backup next weekend and enable the write caches to see what happens. I have the good feeling that 2.6.17 is more stable than 2.6.16 was in its beginning. Let's see. Regards, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 From owner-xfs@oss.sgi.com Tue Jun 27 10:01:17 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 27 Jun 2006 10:01:27 -0700 (PDT) Received: from mail.wietec.com (nomail.wietec.com [194.90.235.10]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5RH1FDW009087 for ; Tue, 27 Jun 2006 10:01:16 -0700 Received: from main (localhost [127.0.0.1]) by main (Postfix) with ESMTP id EB1E32580B4 for ; Tue, 27 Jun 2006 16:54:06 +0300 (IDT) Received: by mail.wietec.com (Postfix, from userid 65534) id C3DC92580D1; Tue, 27 Jun 2006 16:54:06 +0300 (IDT) Received: from Orixp (unknown [194.90.235.172]) by mail.wietec.com (Postfix) with ESMTP id C91D22580B4 for ; Tue, 27 Jun 2006 16:54:02 +0300 (IDT) From: "ORI IDAN" To: Subject: Snapshot in XFS Date: Tue, 27 Jun 2006 16:53:42 +0200 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2663 Thread-Index: AcaZ+Xu0GCnkmVJjS7KRUVQSlc8+UA== Message-Id: <20060627135402.C91D22580B4@mail.wietec.com> X-Anti-Virus: Kaspersky Anti-Virus for MailServers 5.5.10/RELEASE, bases: 27062006 #190986, status: clean Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit X-archive-position: 8053 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: ori@wietec.com Precedence: bulk X-list: xfs Content-Length: 846 Lines: 46 Dear Sir, Madam., My name is Ori Idan and I work for an Israeli reseller of storage systems. One of our systems is a NAS that is based on Linux 2.6.13 and XFS. Creating Snapshots on this machine denies access to the all shares for 15 seconds. I understand that the procedure that causes this is the locking of the file system with xfs_freeze. My questions are: 1. Is it theoretically possible to create snapshots without xfs_freeze? Is it theoretically possible to have snapshots creation that will not disable access to the shares? 2. Should we expect a development of that sort? 3. If not, is it possible to reduce the freeze time, and what is the minimum time? I appreciate your help and thank you very much, Ori Idan Network Storage Specialist Wietec 09-8859889 050-4885982 [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Tue Jun 27 10:24:08 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 27 Jun 2006 10:24:31 -0700 (PDT) Received: from sipsolutions.net (crystal.sipsolutions.net [195.210.38.204]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5RHO5DW012444 for ; Tue, 27 Jun 2006 10:24:07 -0700 Received: from [131.234.76.224] (helo=dhcp-76-224.uni-paderborn.de) by sipsolutions.net with esmtpsa (TLS-1.0:RSA_ARCFOUR_MD5:16) (Exim 4.62) (envelope-from ) id 1FvHHs-0001D9-JK; Tue, 27 Jun 2006 18:23:44 +0100 Subject: Re: error xlog_recover_do_inode_trans(1) / bug when recovering From: Johannes Berg To: Timothy Shimmin Cc: xfs@oss.sgi.com In-Reply-To: <1151299712.7608.67.camel@localhost> References: <1151074934.7608.43.camel@localhost> <200606261406.48756.tes@sgi.com> <1151299712.7608.67.camel@localhost> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-MsfHPzPiRNoi0NSouI7r" Date: Tue, 27 Jun 2006 12:58:21 +0200 Message-Id: <1151405901.26941.16.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 X-archive-position: 8054 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: johannes@sipsolutions.net Precedence: bulk X-list: xfs Content-Length: 1828 Lines: 44 --=-MsfHPzPiRNoi0NSouI7r Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2006-06-26 at 07:28 +0200, Johannes Berg wrote: > Well, I still have a copy, so if xfs_repair -C works on an image file I > can extract the log. I'll mail it to you later today or tomorrow. Still far too large to mail, bzip'ed around 1 GB. Would probably be easier to snail-mail it to someone on DVD if you really care ;) I'm much more interested in the xfs_repair part of the bug anyway though -- the filesystem is still mountable but some things bugger up, hopefully until I can properly xfs_repair it. But there I also don't see how you could repair the bug without being able to reproduce. We can have a live irc debug session should you be so inclined, I'd just need free some space on my powerbook to be able to extract the full image. johannes --=-MsfHPzPiRNoi0NSouI7r Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- iQIVAwUARKEPS6Vg1VMiehFYAQKVvQ/+NIYJSWE0e3myoAgi6feNZKkPHoaPUATJ sOkovZj70no9/SsW+9h0dm6lBJ6LNSyo7RxhgeBt35GxdkrvgTB7byxXzWXeybL2 Eq4n09kOYXq3c0NaPFR1tSc3uXqO9uip5vKq4pKpCc89/byP4mRh6RLyFdTyho1v v+dIRguUa6FLy6z56GPkJsulG0zVdQX1yZhLaaOYE3FO+6xe1IzU4ge7DQEICETE HNQf4gEOQ0YZIsSlJFqjw/BBxOso89Xsz+gIt2Pz75JhDIyhMs1ATfRI8TjXOU7L t+9WlfGnsxGkbKht+cSritPFvPp8k8AhJFst6cInWwAsp2IKRvPbkqtQfxDqn/GM eRFqzgIeeolHEU65cUnWkdz3Sn0yq1xD6L7qhhaRcxHWQ8AhJ/1ArXQpr1a1ygC0 sq7LmpYQI5piZ0n7sxfnNjlfZLU2UyG12FZrBfS2PLgO9KDxsgq3/OqxE9TeIFwv xnAfGu5T/1kj9cs9s4cLChvBg9qN4/uOeKhQo8WnEIZmRdQSVWisOhDAI7IuLOrF 44TsvX/NjZYwOMR52iay50RHYOUhDHNtAi9AUPnw+hZ2LoWMrXKWYZ4pb75dRWwx DYihbhx2hH7Y7ueYHOqs4Yy6V9MSgO5H7Pw4XhTJA9vHppq6e445I8olbKGYZAK/ Zkd1jwPOi68= =ZtYy -----END PGP SIGNATURE----- --=-MsfHPzPiRNoi0NSouI7r-- From owner-xfs@oss.sgi.com Tue Jun 27 14:39:33 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 27 Jun 2006 14:39:46 -0700 (PDT) Received: from mx2.quantum.com (mx2.quantum.com [146.174.252.112]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5RLdWDW023124 for ; Tue, 27 Jun 2006 14:39:32 -0700 Received: from ppoq3mim2.QUANTUM.COM (imcq32.quantum.com [10.50.4.172]) by mx2.quantum.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k5RKALtl023663 for ; Tue, 27 Jun 2006 14:10:21 -0600 Received: from ppoq3mim1.QUANTUM.COM ([10.50.2.135]) by ppoq3mim2.QUANTUM.COM with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Jun 2006 14:22:09 -0600 Received: from irvq3mbha.QUANTUM.COM ([192.168.3.244]) by ppoq3mim1.QUANTUM.COM with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Jun 2006 14:22:07 -0600 Received: from irvq3msg1.QUANTUM.COM ([192.168.3.26]) by irvq3mbha.QUANTUM.COM with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Jun 2006 13:22:06 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Subject: Date: Tue, 27 Jun 2006 13:22:06 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Index: AcaaJ1uLGXhNZ+97TKKKsR7mYwATkw== From: "Jurgen van der Linden" To: X-OriginalArrivalTime: 27 Jun 2006 20:22:06.0092 (UTC) FILETIME=[5BC8B4C0:01C69A27] Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit X-archive-position: 8056 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Jurgen.Vanderlinden@quantum.com Precedence: bulk X-list: xfs Content-Length: 1071 Lines: 35 Hello, I am using XFS that comes with Linux kernel 2.6.12.5. When doing heavy IO to XFS sparse files, I get the following error: XFS internal error XFS_WANT_CORRUPTED_GOTO at line 2210 of file fs/xfs/xfs_bmap_btree.c. Caller 0x801ee0bbn=1.000000 Filesystem "sda4": Corruption of in-memory data detected. Shutting down filesystem: sda4 Please umount the filesystem, and rectify the problem(s) Similar to the XFS Bugzilla report 680 http://oss.sgi.com/bugzilla/show_bug.cgi?id=680 and 414 http://oss.sgi.com/bugzilla/show_bug.cgi?id=414 Google also showed several instances of similar errors, but unfortunately I have not seen a clear resolution. Repeating the same test on the same hardware using the ext3 filesystem gives no problems. Comparing the Linux kernel sources for XFS between 2.6.12 and 2.17.1 shows a large number of changes, does any of the changes since 2.6.12 adressess this or a similar problems? Any suggestions on avoiding this bug? Any suggestions on tracking down the root cause of this bug? Jurgen. [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Tue Jun 27 23:55:46 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 27 Jun 2006 23:56:07 -0700 (PDT) Received: from smtp103.sbc.mail.mud.yahoo.com (smtp103.sbc.mail.mud.yahoo.com [68.142.198.202]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k5S6tfDW005943 for ; Tue, 27 Jun 2006 23:55:45 -0700 Received: (qmail 93973 invoked from network); 28 Jun 2006 06:55:23 -0000 Received: from unknown (HELO stupidest.org) (cwedgwood@sbcglobal.net@71.202.63.228 with login) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 28 Jun 2006 06:55:23 -0000 Received: by tuatara.stupidest.org (Postfix, from userid 10000) id 158DC180FD80; Tue, 27 Jun 2006 23:55:24 -0700 (PDT) Date: Tue, 27 Jun 2006 23:55:23 -0700 From: Chris Wedgwood To: ORI IDAN Cc: xfs@oss.sgi.com Subject: Re: Snapshot in XFS Message-ID: <20060628065523.GA1045@tuatara.stupidest.org> References: <20060627135402.C91D22580B4@mail.wietec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060627135402.C91D22580B4@mail.wietec.com> X-archive-position: 8065 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: xfs Content-Length: 195 Lines: 7 On Tue, Jun 27, 2006 at 04:53:42PM +0200, ORI IDAN wrote: > 3. If not, is it possible to reduce the freeze time, and what is the > minimum time? if you fsync before the freeze does that help? From owner-xfs@oss.sgi.com Wed Jun 28 00:38:35 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 28 Jun 2006 00:38:46 -0700 (PDT) Received: from smtp111.sbc.mail.mud.yahoo.com (smtp111.sbc.mail.mud.yahoo.com [68.142.198.210]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k5S7cRDW018474 for ; Wed, 28 Jun 2006 00:38:35 -0700 Received: (qmail 2585 invoked from network); 28 Jun 2006 07:38:11 -0000 Received: from unknown (HELO stupidest.org) (cwedgwood@sbcglobal.net@71.202.63.228 with login) by smtp111.sbc.mail.mud.yahoo.com with SMTP; 28 Jun 2006 07:38:11 -0000 Received: by tuatara.stupidest.org (Postfix, from userid 10000) id C6DCB185F2CE; Wed, 28 Jun 2006 00:38:12 -0700 (PDT) Date: Wed, 28 Jun 2006 00:38:12 -0700 From: Chris Wedgwood To: ORI IDAN Cc: xfs@oss.sgi.com Subject: Re: Snapshot in XFS Message-ID: <20060628073812.GA1627@tuatara.stupidest.org> References: <20060627135402.C91D22580B4@mail.wietec.com> <20060628065523.GA1045@tuatara.stupidest.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060628065523.GA1045@tuatara.stupidest.org> X-archive-position: 8066 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: xfs Content-Length: 171 Lines: 9 On Tue, Jun 27, 2006 at 11:55:23PM -0700, Chris Wedgwood wrote: > if you fsync before the freeze does that help? ^^^^^ actually, i mean sync, not fsync sorry From owner-xfs@oss.sgi.com Thu Jun 29 01:37:36 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 29 Jun 2006 01:37:50 -0700 (PDT) Received: from mondschein.lichtvoll.de (ms2.lichtvoll.de [194.150.191.235] (may be forged)) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5T8bZDW004068 for ; Thu, 29 Jun 2006 01:37:36 -0700 Received: from localhost (dslb-084-056-088-037.pools.arcor-ip.net [84.56.88.37]) by mondschein.lichtvoll.de (Postfix) with ESMTP id ADD51FA4F3 for ; Thu, 29 Jun 2006 10:36:57 +0200 (CEST) From: Martin Steigerwald To: linux-xfs@oss.sgi.com Subject: Re: repeating slight XFS corruption in kernel 2.6.17.1 Date: Thu, 29 Jun 2006 10:37:11 +0200 User-Agent: KMail/1.9.1 References: <200606280031.18863.Martin@lichtvoll.de> <200606280053.42485.Martin@lichtvoll.de> In-Reply-To: <200606280053.42485.Martin@lichtvoll.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606291037.12221.Martin@lichtvoll.de> X-archive-position: 8069 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Martin@lichtvoll.de Precedence: bulk X-list: xfs Content-Length: 885 Lines: 33 Am Mittwoch 28 Juni 2006 00:53 schrieben Sie: > Am Mittwoch 28 Juni 2006 00:31 schrieben Sie: > > Hallo, > > > > it is of the same minor kind that I reported in my last e-mail in > > this thread on linux-xfs mailing list: > > > > Re: xfs crash with linux 2.6.15.7 and disabled write caches (long) > > Message-Id: <200606232201.29440.Martin@lichtvoll.de> > > > > This time I wrote a kernel bug report: > > > > http://bugzilla.kernel.org/show_bug.cgi?id=6757 > > Hello Nathan, > > is that one covered by your XFS corruption fix? Hello, I am testing this fix now. All seems fine but it is to early to tell anything definite. I attached the patch to my bug report in case anybody else likes to try it as well: http://bugzilla.kernel.org/show_bug.cgi?id=6757 Regards, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 From owner-xfs@oss.sgi.com Thu Jun 29 17:04:39 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 29 Jun 2006 17:05:13 -0700 (PDT) Received: from omx1.americas.sgi.com (omx1.americas.sgi.com [198.149.16.13]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5U04QDW020034 for ; Thu, 29 Jun 2006 17:04:38 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with SMTP id k5TMEgnx020041 for ; Thu, 29 Jun 2006 17:14:44 -0500 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA05820; Fri, 30 Jun 2006 08:14:29 +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 k5TMEPgw1373438; Fri, 30 Jun 2006 08:14:26 +1000 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k5TMEKma1372477; Fri, 30 Jun 2006 08:14:20 +1000 (EST) Date: Fri, 30 Jun 2006 08:14:20 +1000 From: Nathan Scott To: Ralf Hildebrandt , tes@sgi.com Cc: xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: BUG: held lock freed! with 2.6.17-mm3 and 2.6.17-mm4 Message-ID: <20060630081420.A1371683@wobbly.melbourne.sgi.com> References: <20060629203809.GD20456@charite.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20060629203809.GD20456@charite.de>; from Ralf.Hildebrandt@charite.de on Thu, Jun 29, 2006 at 10:38:09PM +0200 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id k5U04dDW020104 X-archive-position: 8070 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: xfs Content-Length: 33451 Lines: 685 On Thu, Jun 29, 2006 at 10:38:09PM +0200, Ralf Hildebrandt wrote: > 2.6.17-mm3 and mm4 both report a "BUG: held lock freed!" while booting > up. Find the two dmesg outputs attached. Thanks Ralf, From the traces, looks like it happens during the unlinked inode list processing, just after log recovery (I assume you crashed / rebooted without unmounting before this boot?). Tim, do you see any situation in recovery where we might have freed an inode while it was locked? Not sure how the s_umount_key lock can be involved here, that may be a separate issue. cheers. > ========================= > [ BUG: held lock freed! ] > ------------------------- > init/1 is freeing memory dbab7750-dbab77e3, with a lock still held there! > 3 locks held by init/1: > #0: (&type->s_umount_key#13){--..}, at: [] sget+0x1b1/0x350 > #1: (&(&ip->i_iolock)->mr_lock){--..}, at: [] xfs_ilock+0xa1/0xb0 > #2: (&(&ip->i_lock)->mr_lock){--..}, at: [] xfs_ilock+0x7d/0xb0 > > -- > Ralf Hildebrandt (i.A. des IT-Zentrums) Ralf.Hildebrandt@charite.de > Charite - Universitätsmedizin Berlin Tel. +49 (0)30-450 570-155 > Gemeinsame Einrichtung von FU- und HU-Berlin Fax. +49 (0)30-450 570-962 > IT-Zentrum Standort CBF send no mail to spamtrap@charite.de > level) > ACPI: IRQ0 used by override. > ACPI: IRQ2 used by override. > Enabling APIC mode: Flat. Using 1 I/O APICs > Using ACPI (MADT) for SMP configuration information > Allocating PCI resources starting at 30000000 (gap: 20000000:dff80000) > Detected 1591.934 MHz processor. > Built 1 zonelists. Total pages: 114496 > Kernel command line: auto BOOT_IMAGE=Linux ro root=301 hdc=noprobe hdc=cdrom video=vesafb:ywrap,mtrr:4 pci=assign-busses lapic panic=15 > ide_setup: hdc=noprobe > ide_setup: hdc=cdrom > mapped APIC to ffffd000 (fee00000) > mapped IOAPIC to ffffc000 (fec00000) > Enabling fast FPU save and restore... done. > Enabling unmasked SIMD FPU exception support... done. > Initializing CPU#0 > CPU 0 irqstacks, hard=c03f1000 soft=c03f0000 > PID hash table entries: 2048 (order: 11, 8192 bytes) > Console: colour dummy device 80x25 > Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar > ... MAX_LOCKDEP_SUBCLASSES: 8 > ... MAX_LOCK_DEPTH: 30 > ... MAX_LOCKDEP_KEYS: 2048 > ... CLASSHASH_SIZE: 1024 > ... MAX_LOCKDEP_ENTRIES: 8192 > ... MAX_LOCKDEP_CHAINS: 8192 > ... CHAINHASH_SIZE: 4096 > memory used by lock dependency info: 696 kB > per task-struct memory footprint: 1200 bytes > Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) > Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) > Memory: 449036k/457984k available (2016k kernel code, 8508k reserved, 766k data, 200k init, 0k highmem) > Checking if this processor honours the WP bit even in supervisor mode... Ok. > Calibrating delay using timer specific routine.. 3187.75 BogoMIPS (lpj=6375500) > Mount-cache hash table entries: 512 > CPU: After generic identify, caps: 078bfbff e3d3fbff 00000000 00000000 00000001 00000000 00000001 > CPU: After vendor identify, caps: 078bfbff e3d3fbff 00000000 00000000 00000001 00000000 00000001 > CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) > CPU: L2 Cache: 1024K (64 bytes/line) > CPU: After all inits, caps: 078bfbff e3d3fbff 00000000 00000410 00000001 00000000 00000001 > Intel machine check architecture supported. > Intel machine check reporting enabled on CPU#0. > Compat vDSO mapped to ffffe000. > CPU: AMD Turion(tm) 64 Mobile Technology ML-30 stepping 02 > Checking 'hlt' instruction... OK. > SMP alternatives: switching to UP code > Freeing SMP alternatives: 0k freed > ACPI: Core revision 20060608 > ENABLING IO-APIC IRQs > ..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1 > ..MP-BIOS bug: 8254 timer not connected to IO-APIC > ...trying to set up timer (IRQ0) through the 8259A ... failed. > ...trying to set up timer as Virtual Wire IRQ... works. > NET: Registered protocol family 16 > ACPI: bus type pci registered > PCI: BIOS Bug: MCFG area at e0000000 is not E820-reserved > PCI: Not using MMCONFIG. > PCI: PCI BIOS revision 2.10 entry at 0xf0031, last bus=1 > Setting up standard PCI resources > ACPI: Interpreter enabled > ACPI: Using IOAPIC for interrupt routing > ACPI: PCI Root Bridge [PCI0] (0000:00) > PCI: Probing PCI hardware (bus 00) > PCI: Ignoring BAR0-3 of IDE controller 0000:00:14.1 > Boot video device is 0000:01:05.0 > PCI: Transparent bridge - 0000:00:14.4 > ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] > ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P1._PRT] > ACPI: Embedded Controller [EC] (gpe 6) interrupt mode. > ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.POP2._PRT] > ACPI: PCI Interrupt Link [LNKA] (IRQs 5 6 7 10 11 12 14 15) *0, disabled. > ACPI: PCI Interrupt Link [LNKB] (IRQs 5 6 7 *10 11 12 14 15) > ACPI: PCI Interrupt Link [LNKC] (IRQs *5 6 7 10 11 12 14 15) > ACPI: PCI Interrupt Link [LNKD] (IRQs 5 6 7 10 *11 12 14 15) > ACPI: PCI Interrupt Link [LNKE] (IRQs 5 *6 7 10 11 12 14 15) > ACPI: PCI Interrupt Link [LNKF] (IRQs 5 6 *7 10 11 12 14 15) > ACPI: PCI Interrupt Link [LNKG] (IRQs *5 6 7 10 11 12 14 15) > ACPI: PCI Interrupt Link [LNKH] (IRQs 5 6 7 10 11 12 14 15) *0, disabled. > Linux Plug and Play Support v0.97 (c) Adam Belay > pnp: PnP ACPI init > pnp: PnP ACPI: found 11 devices > PCI: Using ACPI for IRQ routing > PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report > PCI: Device 0000:02:03.0 not found by BIOS > PCI: Device 0000:02:04.0 not found by BIOS > PCI: Device 0000:02:04.1 not found by BIOS > PCI: Device 0000:02:04.2 not found by BIOS > PCI: Device 0000:02:09.0 not found by BIOS > PCI: Bridge: 0000:00:01.0 > IO window: d000-dfff > MEM window: fbe00000-fbefffff > PREFETCH window: f0000000-faffffff > PCI: Bus 3, cardbus bridge: 0000:02:04.0 > IO window: 0000e000-0000e0ff > IO window: 0000e400-0000e4ff > PREFETCH window: 30000000-31ffffff > MEM window: 36000000-37ffffff > PCI: Bus 7, cardbus bridge: 0000:02:04.1 > IO window: 0000ec00-0000ecff > IO window: 00001000-000010ff > PREFETCH window: 32000000-33ffffff > MEM window: 38000000-39ffffff > PCI: Bridge: 0000:00:14.4 > IO window: e000-efff > MEM window: fbf00000-fbffffff > PREFETCH window: 30000000-34ffffff > ACPI: PCI Interrupt 0000:02:04.0[A] -> GSI 19 (level, low) -> IRQ 16 > ACPI: PCI Interrupt 0000:02:04.1[B] -> GSI 20 (level, low) -> IRQ 17 > NET: Registered protocol family 2 > IP route cache hash table entries: 4096 (order: 2, 16384 bytes) > TCP established hash table entries: 16384 (order: 8, 1572864 bytes) > TCP bind hash table entries: 8192 (order: 7, 819200 bytes) > TCP: Hash tables configured (established 16384 bind 8192) > TCP reno registered > SGI XFS with no debug enabled > Initializing Cryptographic API > io scheduler noop registered > io scheduler anticipatory registered > io scheduler deadline registered > io scheduler cfq registered (default) > vesafb: framebuffer at 0xf0000000, mapped to 0xdc880000, using 3072k, total 65536k > vesafb: mode is 1024x768x16, linelength=2048, pages=41 > vesafb: protected mode interface info at c000:52f9 > vesafb: pmi: set display start = c00c5367, set palette = c00c53a1 > vesafb: pmi: ports = d810 d816 d854 d838 d83c d85c d800 d804 d8b0 d8b2 d8b4 > vesafb: scrolling: ywrap using protected mode interface, yres_virtual=1536 > vesafb: Truecolor: size=0:5:6:5, shift=0:11:5:0 > Console: switching to colour frame buffer device 128x48 > fb0: VESA VGA frame buffer device > lp: driver loaded but no devices found > RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize > Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 > ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx > ATIIXP: IDE controller at PCI slot 0000:00:14.1 > ACPI: PCI Interrupt 0000:00:14.1[A] -> GSI 16 (level, low) -> IRQ 18 > ATIIXP: chipset revision 0 > ATIIXP: not 100% native mode: will probe irqs later > ide0: BM-DMA at 0xff00-0xff07, BIOS settings: hda:DMA, hdb:pio > ide1: BM-DMA at 0xff08-0xff0f, BIOS settings: hdc:DMA, hdd:pio > Probing IDE interface ide0... > hda: WDC WD600VE-00HDT0, ATA DISK drive > ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 > Probing IDE interface ide1... > ide1 at 0x170-0x177,0x376 on irq 15 > hda: max request size: 128KiB > hda: 117210240 sectors (60011 MB) w/8192KiB Cache, CHS=65535/16/63, UDMA(100) > hda: cache flushes supported > hda: hda1 hda2 < hda5 > > PNP: PS/2 Controller [PNP0303:PS2K,PNP0f03:PS2M] at 0x60,0x64 irq 1,12 > i8042.c: Detected active multiplexing controller, rev 1.1. > serio: i8042 AUX0 port at 0x60,0x64 irq 12 > serio: i8042 AUX1 port at 0x60,0x64 irq 12 > serio: i8042 AUX2 port at 0x60,0x64 irq 12 > serio: i8042 AUX3 port at 0x60,0x64 irq 12 > serio: i8042 KBD port at 0x60,0x64 irq 1 > mice: PS/2 mouse device common for all mice > TCP bic registered > Using IPI Shortcut mode > ACPI: (supports S0 S1 S3 S4 S5) > Time: tsc clocksource has been installed. > Freeing unused kernel memory: 200k freed > XFS mounting filesystem hda1 > Starting XFS recovery on filesystem: hda1 (logdev: internal) > input: AT Translated Set 2 keyboard as /class/input/input0 > > ========================= > [ BUG: held lock freed! ] > ------------------------- > init/1 is freeing memory dbe68750-dbe687e3, with a lock still held there! > 3 locks held by init/1: > #0: (&type->s_umount_key#13){--..}, at: [] sget+0x1b1/0x350 > #1: (&(&ip->i_iolock)->mr_lock){--..}, at: [] xfs_ilock+0xa1/0xb0 > #2: (&(&ip->i_lock)->mr_lock){--..}, at: [] xfs_ilock+0x7d/0xb0 > > stack backtrace: > [] show_trace+0x12/0x20 > [] dump_stack+0x19/0x20 > [] debug_check_no_locks_freed+0x154/0x170 > [] __init_rwsem+0x21/0x60 > [] xfs_inode_lock_init+0x25/0xe0 > [] xfs_iget+0x17a/0x59a > [] xlog_recover_process_iunlinks+0x316/0x500 > [] xlog_recover_finish+0x2c8/0x380 > [] xfs_log_mount_finish+0x37/0x50 > [] xfs_mountfs+0xe52/0x1020 > [] xfs_ioinit+0x29/0x40 > [] xfs_mount+0x66d/0xa20 > [] vfs_mount+0x25/0x30 > [] xfs_fs_fill_super+0x76/0x1e0 > [] get_sb_bdev+0xf6/0x130 > [] xfs_fs_get_sb+0x21/0x30 > [] vfs_kern_mount+0x40/0xa0 > [] do_kern_mount+0x36/0x50 > [] do_mount+0x232/0x610 > [] sys_mount+0x6f/0xb0 > [] syscall_call+0x7/0xb > Ending XFS recovery on filesystem: hda1 (logdev: internal) > NET: Registered protocol family 1 > Yenta: CardBus bridge found at 0000:02:04.0 [1462:0131] > Yenta: ISA IRQ mask 0x0cb8, PCI irq 16 > Socket status: 30000006 > pcmcia: parent PCI bridge I/O window: 0xe000 - 0xefff > cs: IO port probe 0xe000-0xefff: clean. > pcmcia: parent PCI bridge Memory window: 0xfbf00000 - 0xfbffffff > pcmcia: parent PCI bridge Memory window: 0x30000000 - 0x34ffffff > Yenta: CardBus bridge found at 0000:02:04.1 [1462:0131] > Synaptics Touchpad, model: 1, fw: 5.9, id: 0x116eb1, caps: 0xa04713/0x0 > Yenta: ISA IRQ mask 0x0cb8, PCI irq 17 > Socket status: 30000006 > pcmcia: parent PCI bridge I/O window: 0xe000 - 0xefff > cs: IO port probe 0xe000-0xefff: clean. > pcmcia: parent PCI bridge Memory window: 0xfbf00000 - 0xfbffffff > pcmcia: parent PCI bridge Memory window: 0x30000000 - 0x34ffffff > ACPI: PCI Interrupt 0000:02:09.0[A] -> GSI 22 (level, low) -> IRQ 19 > rt2500 1.1.0 CVS 2005/07/10 http://rt2x00.serialmonkey.com > 8139too Fast Ethernet driver 0.9.27 > ACPI: PCI Interrupt 0000:02:03.0[A] -> GSI 18 (level, low) -> IRQ 20 > eth1: RealTek RTL8139 at 0xdcb92c00, 00:10:dc:e8:c8:4f, IRQ 20 > eth1: Identified 8139 chip type 'RTL-8101' > input: SynPS/2 Synaptics TouchPad as /class/input/input1 > psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 1 > piix4_smbus 0000:00:14.0: Found 0000:00:14.0 device > usbcore: registered new driver usbfs > usbcore: registered new driver hub > hdc: ATAPI 24X DVD-ROM DVD-R-RAM CD-R/RW drive, 2048kB Cache > Uniform CD-ROM driver Revision: 3.20 > Linux agpgart interface v0.101 (c) Dave Jones > ACPI: PCI Interrupt 0000:00:14.6[B] -> GSI 17 (level, low) -> IRQ 22 > hda: cache flushes supported > ACPI: PCI Interrupt 0000:00:13.2[A] -> GSI 19 (level, low) -> IRQ 16 > ehci_hcd 0000:00:13.2: EHCI Host Controller > ehci_hcd 0000:00:13.2: new USB bus registered, assigned bus number 1 > ehci_hcd 0000:00:13.2: irq 16, io mem 0xfbdff000 > ehci_hcd 0000:00:13.2: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004 > usb usb1: new device found, idVendor=0000, idProduct=0000 > usb usb1: new device strings: Mfr=3, Product=2, SerialNumber=1 > usb usb1: Product: EHCI Host Controller > usb usb1: Manufacturer: Linux 2.6.17-mm3 ehci_hcd > usb usb1: SerialNumber: 0000:00:13.2 > usb usb1: configuration #1 chosen from 1 choice > hub 1-0:1.0: USB hub found > hub 1-0:1.0: 8 ports detected > ohci_hcd: 2006 May 24 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI) > ts: Compaq touchscreen protocol output > ACPI: PCI Interrupt 0000:00:13.0[A] -> GSI 19 (level, low) -> IRQ 16 > ohci_hcd 0000:00:13.0: OHCI Host Controller > ohci_hcd 0000:00:13.0: new USB bus registered, assigned bus number 2 > ohci_hcd 0000:00:13.0: irq 16, io mem 0xfbdfd000 > usb usb2: new device found, idVendor=0000, idProduct=0000 > usb usb2: new device strings: Mfr=3, Product=2, SerialNumber=1 > usb usb2: Product: OHCI Host Controller > usb usb2: Manufacturer: Linux 2.6.17-mm3 ohci_hcd > usb usb2: SerialNumber: 0000:00:13.0 > usb usb2: configuration #1 chosen from 1 choice > hub 2-0:1.0: USB hub found > hub 2-0:1.0: 4 ports detected > Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled > ACPI: PCI Interrupt 0000:00:13.1[A] -> GSI 19 (level, low) -> IRQ 16 > ohci_hcd 0000:00:13.1: OHCI Host Controller > ohci_hcd 0000:00:13.1: new USB bus registered, assigned bus number 3 > ohci_hcd 0000:00:13.1: irq 16, io mem 0xfbdfe000 > usb usb3: new device found, idVendor=0000, idProduct=0000 > usb usb3: new device strings: Mfr=3, Product=2, SerialNumber=1 > usb usb3: Product: OHCI Host Controller > usb usb3: Manufacturer: Linux 2.6.17-mm3 ohci_hcd > usb usb3: SerialNumber: 0000:00:13.1 > usb usb3: configuration #1 chosen from 1 choice > hub 3-0:1.0: USB hub found > hub 3-0:1.0: 4 ports detected > ACPI: PCI Interrupt 0000:00:14.5[B] -> GSI 17 (level, low) -> IRQ 22 > usb 3-1: new low speed USB device using ohci_hcd and address 2 > cs: IO port probe 0x100-0x4ff: excluding 0x408-0x40f 0x4d0-0x4d7 > cs: IO port probe 0x800-0x8ff: clean. > cs: IO port probe 0xc00-0xcff: excluding 0xc00-0xc07 0xc10-0xc17 0xc50-0xc57 0xc68-0xc6f 0xcd0-0xcdf 0xcf8-0xcff > cs: IO port probe 0xa00-0xaff: clean. > cs: IO port probe 0x100-0x4ff: excluding 0x408-0x40f 0x4d0-0x4d7 > cs: IO port probe 0x800-0x8ff: clean. > cs: IO port probe 0xc00-0xcff: excluding 0xc00-0xc07 0xc10-0xc17 0xc50-0xc57 0xc68-0xc6f 0xcd0-0xcdf 0xcf8-0xcff > cs: IO port probe 0xa00-0xaff: clean. > usb 3-1: new device found, idVendor=046d, idProduct=c00c > usb 3-1: new device strings: Mfr=1, Product=2, SerialNumber=0 > usb 3-1: Product: USB Optical Mouse > usb 3-1: Manufacturer: Logitech > usb 3-1: configuration #1 chosen from 1 choice > input: Logitech USB Optical Mouse as /class/input/input2 > usbcore: registered new driver usbmouse > drivers/usb/input/usbmouse.c: v1.6:USB HID Boot Protocol mouse driver > usbcore: registered new driver hiddev > usbcore: registered new driver usbhid > drivers/usb/input/hid-core.c: v2.6:USB HID core driver > hda: cache flushes supported > Adding 1349420k swap on /dev/hda5. Priority:-1 extents:1 across:1349420k > Linux video capture interface: v2.00 > saa7130/34: v4l2 driver version 0.2.14 loaded > pcmcia: Detected deprecated PCMCIA ioctl usage from process: discover. > pcmcia: This interface will soon be removed from the kernel; please expect breakage unless you upgrade to new tools. > pcmcia: see http://www.kernel.org/pub/linux/utils/kernel/pcmcia/pcmcia.html for details. > NET: Registered protocol family 17 > ACPI: Battery Slot [BAT1] (battery present) > ACPI: AC Adapter [ADP1] (on-line) > ACPI: CPU0 (power states: C1[C1] C2[C2] C3[C3]) > ACPI: Power Button (FF) [PWRF] > ACPI: Lid Switch [LID0] > ACPI: Sleep Button (CM) [SLPB] > ACPI: Power Button (CM) [PWRB] > Time: acpi_pm clocksource has been installed. > ACPI: Thermal Zone [THRM] (64 C) > powernow-k8: Found 1 AMD Turion(tm) 64 Mobile Technology ML-30 processors (version 2.00.00) > powernow-k8: 0 : fid 0x0 (800 MHz), vid 0x12 > powernow-k8: 1 : fid 0x8 (1600 MHz), vid 0x4 > powernow-k8: ph2 null fid transition 0x8 > [drm] Initialized drm 1.0.1 20051102 > APIC error on CPU0: 00(40) > APIC error on CPU0: 40(40) > APIC error on CPU0: 40(40) > APIC error on CPU0: 40(40) > APIC error on CPU0: 40(40) > APIC error on CPU0: 40(40) > APIC error on CPU0: 40(40) > APIC error on CPU0: 40(40) > APIC error on CPU0: 40(40) > APIC error on CPU0: 40(40) > APIC error on CPU0: 40(40) > APIC error on CPU0: 40(40) > APIC error on CPU0: 40(40) > APIC error on CPU0: 40(40) > APIC error on CPU0: 40(40) > APIC error on CPU0: 40(40) > APIC error on CPU0: 40(40) > APIC error on CPU0: 40(40) > psmouse.c: TouchPad at isa0060/serio2/input0 - driver resynched. > APIC error on CPU0: 40(40) > 0x08242005 MSFT 0x00000097) @ 0x1bf40200 > ACPI: MADT (v001 MSI OEMAPIC 0x08242005 MSFT 0x00000097) @ 0x1bf40300 > ACPI: WDRT (v001 MSI MSI_OEM 0x08242005 MSFT 0x00000097) @ 0x1bf40360 > ACPI: MCFG (v001 MSI OEMMCFG 0x08242005 MSFT 0x00000097) @ 0x1bf403b0 > ACPI: SSDT (v001 OEM_ID OEMTBLID 0x00000001 INTL 0x02002026) @ 0x1bf43620 > ACPI: OEMB (v001 MSI MSI_OEM 0x08242005 MSFT 0x00000097) @ 0x1bf50040 > ACPI: DSDT (v001 MSI 1013 0x08242005 INTL 0x02002026) @ 0x00000000 > ATI board detected. Disabling timer routing over 8254. > ACPI: PM-Timer IO Port: 0x4008 > ACPI: Local APIC address 0xfee00000 > ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) > Processor #0 15:4 APIC version 16 > ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0]) > IOAPIC[0]: apic_id 1, version 33, address 0xfec00000, GSI 0-23 > ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) > ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 21 low level) > ACPI: IRQ0 used by override. > ACPI: IRQ2 used by override. > Enabling APIC mode: Flat. Using 1 I/O APICs > Using ACPI (MADT) for SMP configuration information > Allocating PCI resources starting at 30000000 (gap: 20000000:dff80000) > Detected 1592.032 MHz processor. > Built 1 zonelists. Total pages: 114496 > Kernel command line: BOOT_IMAGE=Linux ro root=301 hdc=noprobe hdc=cdrom video=vesafb:ywrap,mtrr:4 pci=assign-busses lapic panic=15 > ide_setup: hdc=noprobe > ide_setup: hdc=cdrom > mapped APIC to ffffd000 (fee00000) > mapped IOAPIC to ffffc000 (fec00000) > Enabling fast FPU save and restore... done. > Enabling unmasked SIMD FPU exception support... done. > Initializing CPU#0 > CPU 0 irqstacks, hard=c03f6000 soft=c03f5000 > PID hash table entries: 2048 (order: 11, 8192 bytes) > Console: colour dummy device 80x25 > Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar > ... MAX_LOCKDEP_SUBCLASSES: 8 > ... MAX_LOCK_DEPTH: 30 > ... MAX_LOCKDEP_KEYS: 2048 > ... CLASSHASH_SIZE: 1024 > ... MAX_LOCKDEP_ENTRIES: 8192 > ... MAX_LOCKDEP_CHAINS: 8192 > ... CHAINHASH_SIZE: 4096 > memory used by lock dependency info: 696 kB > per task-struct memory footprint: 1200 bytes > Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) > Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) > Memory: 449016k/457984k available (2034k kernel code, 8528k reserved, 769k data, 200k init, 0k highmem) > Checking if this processor honours the WP bit even in supervisor mode... Ok. > Calibrating delay using timer specific routine.. 3187.58 BogoMIPS (lpj=6375170) > Mount-cache hash table entries: 512 > CPU: After generic identify, caps: 078bfbff e3d3fbff 00000000 00000000 00000001 00000000 00000001 > CPU: After vendor identify, caps: 078bfbff e3d3fbff 00000000 00000000 00000001 00000000 00000001 > CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) > CPU: L2 Cache: 1024K (64 bytes/line) > CPU: After all inits, caps: 078bfbff e3d3fbff 00000000 00000410 00000001 00000000 00000001 > Intel machine check architecture supported. > Intel machine check reporting enabled on CPU#0. > Compat vDSO mapped to ffffe000. > CPU: AMD Turion(tm) 64 Mobile Technology ML-30 stepping 02 > Checking 'hlt' instruction... OK. > ACPI: Core revision 20060623 > ENABLING IO-APIC IRQs > ..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1 > ..MP-BIOS bug: 8254 timer not connected to IO-APIC > ...trying to set up timer (IRQ0) through the 8259A ... failed. > ...trying to set up timer as Virtual Wire IRQ... works. > NET: Registered protocol family 16 > ACPI: bus type pci registered > PCI: BIOS Bug: MCFG area at e0000000 is not E820-reserved > PCI: Not using MMCONFIG. > PCI: PCI BIOS revision 2.10 entry at 0xf0031, last bus=1 > Setting up standard PCI resources > ACPI: Interpreter enabled > ACPI: Using IOAPIC for interrupt routing > ACPI: PCI Root Bridge [PCI0] (0000:00) > PCI: Probing PCI hardware (bus 00) > PCI: Ignoring BAR0-3 of IDE controller 0000:00:14.1 > Boot video device is 0000:01:05.0 > PCI: Transparent bridge - 0000:00:14.4 > ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] > ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P1._PRT] > ACPI: Embedded Controller [EC] (gpe 6) interrupt mode. > ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.POP2._PRT] > ACPI: PCI Interrupt Link [LNKA] (IRQs 5 6 7 10 11 12 14 15) *0, disabled. > ACPI: PCI Interrupt Link [LNKB] (IRQs 5 6 7 *10 11 12 14 15) > ACPI: PCI Interrupt Link [LNKC] (IRQs *5 6 7 10 11 12 14 15) > ACPI: PCI Interrupt Link [LNKD] (IRQs 5 6 7 10 *11 12 14 15) > ACPI: PCI Interrupt Link [LNKE] (IRQs 5 *6 7 10 11 12 14 15) > ACPI: PCI Interrupt Link [LNKF] (IRQs 5 6 *7 10 11 12 14 15) > ACPI: PCI Interrupt Link [LNKG] (IRQs *5 6 7 10 11 12 14 15) > ACPI: PCI Interrupt Link [LNKH] (IRQs 5 6 7 10 11 12 14 15) *0, disabled. > Linux Plug and Play Support v0.97 (c) Adam Belay > pnp: PnP ACPI init > pnp: PnP ACPI: found 11 devices > PCI: Using ACPI for IRQ routing > PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report > PCI: Device 0000:02:03.0 not found by BIOS > PCI: Device 0000:02:04.0 not found by BIOS > PCI: Device 0000:02:04.1 not found by BIOS > PCI: Device 0000:02:04.2 not found by BIOS > PCI: Device 0000:02:09.0 not found by BIOS > PCI: Bridge: 0000:00:01.0 > IO window: d000-dfff > MEM window: fbe00000-fbefffff > PREFETCH window: f0000000-faffffff > PCI: Bus 3, cardbus bridge: 0000:02:04.0 > IO window: 0000e000-0000e0ff > IO window: 0000e400-0000e4ff > PREFETCH window: 30000000-31ffffff > MEM window: 36000000-37ffffff > PCI: Bus 7, cardbus bridge: 0000:02:04.1 > IO window: 0000ec00-0000ecff > IO window: 00001000-000010ff > PREFETCH window: 32000000-33ffffff > MEM window: 38000000-39ffffff > PCI: Bridge: 0000:00:14.4 > IO window: e000-efff > MEM window: fbf00000-fbffffff > PREFETCH window: 30000000-34ffffff > Device `[CBC0]' is not power manageable<6>ACPI: PCI Interrupt 0000:02:04.0[A] -> GSI 19 (level, low) -> IRQ 16 > Device `[CBC1]' is not power manageable<6>ACPI: PCI Interrupt 0000:02:04.1[B] -> GSI 20 (level, low) -> IRQ 17 > NET: Registered protocol family 2 > IP route cache hash table entries: 4096 (order: 2, 16384 bytes) > TCP established hash table entries: 16384 (order: 8, 1572864 bytes) > TCP bind hash table entries: 8192 (order: 7, 819200 bytes) > TCP: Hash tables configured (established 16384 bind 8192) > TCP reno registered > SGI XFS with no debug enabled > Initializing Cryptographic API > io scheduler noop registered > io scheduler anticipatory registered > io scheduler deadline registered > io scheduler cfq registered (default) > vesafb: framebuffer at 0xf0000000, mapped to 0xdc880000, using 3072k, total 65536k > vesafb: mode is 1024x768x16, linelength=2048, pages=41 > vesafb: protected mode interface info at c000:52f9 > vesafb: pmi: set display start = c00c5367, set palette = c00c53a1 > vesafb: pmi: ports = d810 d816 d854 d838 d83c d85c d800 d804 d8b0 d8b2 d8b4 > vesafb: scrolling: ywrap using protected mode interface, yres_virtual=1536 > vesafb: Truecolor: size=0:5:6:5, shift=0:11:5:0 > Console: switching to colour frame buffer device 128x48 > fb0: VESA VGA frame buffer device > lp: driver loaded but no devices found > RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize > Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 > ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx > ATIIXP: IDE controller at PCI slot 0000:00:14.1 > ACPI: PCI Interrupt 0000:00:14.1[A] -> GSI 16 (level, low) -> IRQ 18 > ATIIXP: chipset revision 0 > ATIIXP: not 100% native mode: will probe irqs later > ide0: BM-DMA at 0xff00-0xff07, BIOS settings: hda:DMA, hdb:pio > ide1: BM-DMA at 0xff08-0xff0f, BIOS settings: hdc:DMA, hdd:pio > Probing IDE interface ide0... > hda: WDC WD600VE-00HDT0, ATA DISK drive > ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 > Probing IDE interface ide1... > ide1 at 0x170-0x177,0x376 on irq 15 > hda: max request size: 128KiB > hda: 117210240 sectors (60011 MB) w/8192KiB Cache, CHS=65535/16/63, UDMA(100) > hda: cache flushes supported > hda: hda1 hda2 < hda5 > > PNP: PS/2 Controller [PNP0303:PS2K,PNP0f03:PS2M] at 0x60,0x64 irq 1,12 > i8042.c: Detected active multiplexing controller, rev 1.1. > serio: i8042 AUX0 port at 0x60,0x64 irq 12 > serio: i8042 AUX1 port at 0x60,0x64 irq 12 > serio: i8042 AUX2 port at 0x60,0x64 irq 12 > serio: i8042 AUX3 port at 0x60,0x64 irq 12 > serio: i8042 KBD port at 0x60,0x64 irq 1 > mice: PS/2 mouse device common for all mice > TCP bic registered > Using IPI Shortcut mode > ACPI: (supports S0 S1 S3 S4 S5) > Time: tsc clocksource has been installed. > Freeing unused kernel memory: 200k freed > XFS mounting filesystem hda1 > Starting XFS recovery on filesystem: hda1 (logdev: internal) > input: AT Translated Set 2 keyboard as /class/input/input0 > > ========================= > [ BUG: held lock freed! ] > ------------------------- > init/1 is freeing memory dbab7750-dbab77e3, with a lock still held there! > 3 locks held by init/1: > #0: (&type->s_umount_key#13){--..}, at: [] sget+0x1b1/0x350 > #1: (&(&ip->i_iolock)->mr_lock){--..}, at: [] xfs_ilock+0xa1/0xb0 > #2: (&(&ip->i_lock)->mr_lock){--..}, at: [] xfs_ilock+0x7d/0xb0 > > stack backtrace: > [] show_trace+0x12/0x20 > [] dump_stack+0x19/0x20 > [] debug_check_no_locks_freed+0x154/0x170 > [] __init_rwsem+0x21/0x60 > [] xfs_inode_lock_init+0x25/0xe0 > [] xfs_iget+0x17a/0x59a > [] xlog_recover_process_iunlinks+0x316/0x500 > [] xlog_recover_finish+0x2c8/0x380 > [] xfs_log_mount_finish+0x37/0x50 > [] xfs_mountfs+0xe52/0x1020 > [] xfs_ioinit+0x29/0x40 > [] xfs_mount+0x66d/0xa20 > [] vfs_mount+0x25/0x30 > [] xfs_fs_fill_super+0x76/0x1e0 > [] get_sb_bdev+0xf6/0x130 > [] xfs_fs_get_sb+0x21/0x30 > [] vfs_kern_mount+0x40/0xa0 > [] do_kern_mount+0x36/0x50 > [] do_mount+0x27e/0x6d0 > [] sys_mount+0x6f/0xb0 > [] syscall_call+0x7/0xb > Ending XFS recovery on filesystem: hda1 (logdev: internal) > NET: Registered protocol family 1 > Yenta: CardBus bridge found at 0000:02:04.0 [1462:0131] > Yenta: ISA IRQ mask 0x0cb8, PCI irq 16 > Socket status: 30000006 > pcmcia: parent PCI bridge I/O window: 0xe000 - 0xefff > cs: IO port probe 0xe000-0xefff: clean. > pcmcia: parent PCI bridge Memory window: 0xfbf00000 - 0xfbffffff > pcmcia: parent PCI bridge Memory window: 0x30000000 - 0x34ffffff > Yenta: CardBus bridge found at 0000:02:04.1 [1462:0131] > Yenta: ISA IRQ mask 0x0cb8, PCI irq 17 > Socket status: 30000006 > pcmcia: parent PCI bridge I/O window: 0xe000 - 0xefff > cs: IO port probe 0xe000-0xefff: clean. > pcmcia: parent PCI bridge Memory window: 0xfbf00000 - 0xfbffffff > pcmcia: parent PCI bridge Memory window: 0x30000000 - 0x34ffffff > 8139too Fast Ethernet driver 0.9.27 > Device `[RTL]' is not power manageable<6>ACPI: PCI Interrupt 0000:02:03.0[A] -> GSI 18 (level, low) -> IRQ 19 > eth0: RealTek RTL8139 at 0xdc87ec00, 00:10:dc:e8:c8:4f, IRQ 19 > eth0: Identified 8139 chip type 'RTL-8101' > ACPI: PCI Interrupt 0000:02:09.0[A] -> GSI 22 (level, low) -> IRQ 20 > rt2500 1.1.0 CVS 2005/07/10 http://rt2x00.serialmonkey.com > hdc: ATAPI 24X DVD-ROM DVD-R-RAM CD-R/RW drive, 2048kB Cache > Uniform CD-ROM driver Revision: 3.20 > Synaptics Touchpad, model: 1, fw: 5.9, id: 0x116eb1, caps: 0xa04713/0x0 > input: SynPS/2 Synaptics TouchPad as /class/input/input1 > psmouse.c: TouchPad at isa0060/serio2/input0 lost sync at byte 1 > usbcore: registered new driver usbfs > usbcore: registered new driver hub > piix4_smbus 0000:00:14.0: Found 0000:00:14.0 device > ohci_hcd: 2006 May 24 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI) > ACPI: PCI Interrupt 0000:00:13.0[A] -> GSI 19 (level, low) -> IRQ 16 > ohci_hcd 0000:00:13.0: OHCI Host Controller > ohci_hcd 0000:00:13.0: new USB bus registered, assigned bus number 1 > ohci_hcd 0000:00:13.0: irq 16, io mem 0xfbdfd000 > ts: Compaq touchscreen protocol output > usb usb1: new device found, idVendor=0000, idProduct=0000 > usb usb1: new device strings: Mfr=3, Product=2, SerialNumber=1 > usb usb1: Product: OHCI Host Controller > usb usb1: Manufacturer: Linux 2.6.17-mm4 ohci_hcd > usb usb1: SerialNumber: 0000:00:13.0 > usb usb1: configuration #1 chosen from 1 choice > hub 1-0:1.0: USB hub found > hub 1-0:1.0: 4 ports detected > hda: cache flushes supported > ACPI: PCI Interrupt 0000:00:13.1[A] -> GSI 19 (level, low) -> IRQ 16 > ohci_hcd 0000:00:13.1: OHCI Host Controller > ohci_hcd 0000:00:13.1: new USB bus registered, assigned bus number 2 > ohci_hcd 0000:00:13.1: irq 16, io mem 0xfbdfe000 > Linux agpgart interface v0.101 (c) Dave Jones > usb usb2: new device found, idVendor=0000, idProduct=0000 > usb usb2: new device strings: Mfr=3, Product=2, SerialNumber=1 > usb usb2: Product: OHCI Host Controller > usb usb2: Manufacturer: Linux 2.6.17-mm4 ohci_hcd > usb usb2: SerialNumber: 0000:00:13.1 > usb usb2: configuration #1 chosen from 1 choice > hub 2-0:1.0: USB hub found > hub 2-0:1.0: 4 ports detected > Device `[EUSB]' is not power manageable<6>ACPI: PCI Interrupt 0000:00:13.2[A] -> GSI 19 (level, low) -> IRQ 16 > ehci_hcd 0000:00:13.2: EHCI Host Controller > ehci_hcd 0000:00:13.2: new USB bus registered, assigned bus number 3 > ehci_hcd 0000:00:13.2: irq 16, io mem 0xfbdff000 > ehci_hcd 0000:00:13.2: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004 > usb usb3: new device found, idVendor=0000, idProduct=0000 > usb usb3: new device strings: Mfr=3, Product=2, SerialNumber=1 > usb usb3: Product: EHCI Host Controller > usb usb3: Manufacturer: Linux 2.6.17-mm4 ehci_hcd > usb usb3: SerialNumber: 0000:00:13.2 > usb usb3: configuration #1 chosen from 1 choice > hub 3-0:1.0: USB hub found > hub 3-0:1.0: 8 ports detected > ACPI: PCI Interrupt 0000:00:14.6[B] -> GSI 17 (level, low) -> IRQ 22 > ACPI: PCI Interrupt 0000:00:14.5[B] -> GSI 17 (level, low) -> IRQ 22 > Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled > cs: IO port probe 0x100-0x4ff: excluding 0x408-0x40f 0x4d0-0x4d7 > cs: IO port probe 0x800-0x8ff: clean. > cs: IO port probe 0xc00-0xcff: excluding 0xc00-0xc07 0xc10-0xc17 0xc50-0xc57 0xc68-0xc6f 0xcd0-0xcdf 0xcf8-0xcff > cs: IO port probe 0xa00-0xaff: clean. > cs: IO port probe 0x100-0x4ff: excluding 0x408-0x40f 0x4d0-0x4d7 > cs: IO port probe 0x800-0x8ff: clean. > cs: IO port probe 0xc00-0xcff: excluding 0xc00-0xc07 0xc10-0xc17 0xc50-0xc57 0xc68-0xc6f 0xcd0-0xcdf 0xcf8-0xcff > cs: IO port probe 0xa00-0xaff: clean. > hda: cache flushes supported > Adding 1349420k swap on /dev/hda5. Priority:-1 extents:1 across:1349420k > Linux video capture interface: v2.00 > saa7130/34: v4l2 driver version 0.2.14 loaded > pcmcia: Detected deprecated PCMCIA ioctl usage from process: discover. > pcmcia: This interface will soon be removed from the kernel; please expect breakage unless you upgrade to new tools. > pcmcia: see http://www.kernel.org/pub/linux/utils/kernel/pcmcia/pcmcia.html for details. > NET: Registered protocol family 17 > ACPI: Battery Slot [BAT1] (battery present) > ACPI: AC Adapter [ADP1] (on-line) > ACPI: duty_cycle spans bit 4 > ACPI: CPU0 (power states: C1[C1] C2[C2] C3[C3]) > ACPI: Power Button (FF) [PWRF] > ACPI: Lid Switch [LID0] > ACPI: Sleep Button (CM) [SLPB] > ACPI: Power Button (CM) [PWRB] > ACPI: Thermal Zone [THRM] (64 C) > Time: acpi_pm clocksource has been installed. > powernow-k8: Found 1 AMD Turion(tm) 64 Mobile Technology ML-30 processors (version 2.00.00) > ACPI: Invalid package argument > ACPI Exception (acpi_processor-0272): AE_BAD_PARAMETER, Invalid _PSS data [20060623] > powernow-k8: 0 : fid 0x0 (800 MHz), vid 0x12 > powernow-k8: 1 : fid 0x8 (1600 MHz), vid 0x4 > powernow-k8: ph2 null fid transition 0x8 > [drm] Initialized drm 1.0.1 20051102 > psmouse.c: TouchPad at isa0060/serio2/input0 - driver resynched. -- Nathan From owner-xfs@oss.sgi.com Thu Jun 29 22:37:21 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 29 Jun 2006 22:37:44 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k5U5b8DW013591 for ; Thu, 29 Jun 2006 22:37:19 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA14540; Fri, 30 Jun 2006 15:36:25 +1000 From: Timothy Shimmin Organization: SGI To: Nathan Scott Subject: Re: BUG: held lock freed! with 2.6.17-mm3 and 2.6.17-mm4 Date: Fri, 30 Jun 2006 15:35:40 +1000 User-Agent: KMail/1.8.2 Cc: Ralf Hildebrandt , xfs@oss.sgi.com, linux-kernel@vger.kernel.org References: <20060629203809.GD20456@charite.de> <20060630081420.A1371683@wobbly.melbourne.sgi.com> In-Reply-To: <20060630081420.A1371683@wobbly.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606301535.40890.tes@sgi.com> X-archive-position: 8071 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs Content-Length: 707 Lines: 19 On Friday 30 June 2006 8:14 am, Nathan Scott wrote: > On Thu, Jun 29, 2006 at 10:38:09PM +0200, Ralf Hildebrandt wrote: > > 2.6.17-mm3 and mm4 both report a "BUG: held lock freed!" while booting > > up. Find the two dmesg outputs attached. > > Thanks Ralf, > > >From the traces, looks like it happens during the unlinked inode list > > processing, just after log recovery (I assume you crashed / rebooted > without unmounting before this boot?). Tim, do you see any situation > in recovery where we might have freed an inode while it was locked? Had a look but I can't see anything apparent at this stage, let's run our unlink recovery test on the -mm tree next week, which should expose the bug. --Tim From owner-xfs@oss.sgi.com Fri Jun 30 00:48:30 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 30 Jun 2006 00:48:53 -0700 (PDT) Received: from mail.charite.de (mail.charite.de [160.45.207.131]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5U7mTDW007687 for ; Fri, 30 Jun 2006 00:48:30 -0700 Received: from localhost (localhost [127.0.0.1]) by mail.charite.de (Postfix) with ESMTP id AA840220F21; Fri, 30 Jun 2006 09:48:10 +0200 (CEST) Received: from mail.charite.de ([127.0.0.1]) by localhost (mail.charite.de [127.0.0.1]) (amavisd-new, port 10025) with LMTP id lJN7q0JZLWu4; Fri, 30 Jun 2006 09:48:06 +0200 (CEST) Received: from postamt.charite.de (postamt.charite.de [160.45.207.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.charite.de (Postfix) with ESMTP id A51C8220F23; Fri, 30 Jun 2006 09:48:05 +0200 (CEST) Received: by postamt.charite.de (Postfix, from userid 7945) id 3229B220A2E; Fri, 30 Jun 2006 09:48:05 +0200 (CEST) Date: Fri, 30 Jun 2006 09:48:05 +0200 From: Ralf Hildebrandt To: Nathan Scott Cc: Ralf Hildebrandt , tes@sgi.com, xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: BUG: held lock freed! with 2.6.17-mm3 and 2.6.17-mm4 Message-ID: <20060630074805.GE6003@charite.de> Mail-Followup-To: Nathan Scott , tes@sgi.com, xfs@oss.sgi.com, linux-kernel@vger.kernel.org References: <20060629203809.GD20456@charite.de> <20060630081420.A1371683@wobbly.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20060630081420.A1371683@wobbly.melbourne.sgi.com> User-Agent: Mutt/1.5.11+cvs20060403 X-archive-position: 8072 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Ralf.Hildebrandt@charite.de Precedence: bulk X-list: xfs Content-Length: 1026 Lines: 30 * Nathan Scott : > On Thu, Jun 29, 2006 at 10:38:09PM +0200, Ralf Hildebrandt wrote: > > 2.6.17-mm3 and mm4 both report a "BUG: held lock freed!" while booting > > up. Find the two dmesg outputs attached. > > Thanks Ralf, > > From the traces, looks like it happens during the unlinked inode list > processing, just after log recovery (I assume you crashed / rebooted > without unmounting before this boot?). Absolutely. The root-fs could not be umounted correctly, since the -mm3 and -mm4 Kernels sometime produce unkillable processes. One of these processes had files open on /, thus the reboot left me with an unclean XFS fs! -- _________________________________________________ Charité - Universitätsmedizin Berlin _________________________________________________ Ralf Hildebrandt i.A. Geschäftsbereich Informationsmanagement Campus Benjamin Franklin Hindenburgdamm 30 | Berlin Tel. +49 30 450 570155 | Fax +49 30 450 570962 Ralf.Hildebrandt@charite.de http://www.charite.de From owner-xfs@oss.sgi.com Fri Jun 30 13:27:02 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 30 Jun 2006 13:27:13 -0700 (PDT) Received: from mondschein.lichtvoll.de (ms2.lichtvoll.de [194.150.191.235] (may be forged)) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k5UKR0DW014084 for ; Fri, 30 Jun 2006 13:27:02 -0700 Received: from localhost (dslb-084-056-073-029.pools.arcor-ip.net [84.56.73.29]) by mondschein.lichtvoll.de (Postfix) with ESMTP id 99045FA4F3 for ; Fri, 30 Jun 2006 22:26:09 +0200 (CEST) From: Martin Steigerwald To: linux-xfs@oss.sgi.com Subject: Re: repeating slight XFS corruption in kernel 2.6.17.1 Date: Fri, 30 Jun 2006 22:26:33 +0200 User-Agent: KMail/1.9.1 References: <200606280031.18863.Martin@lichtvoll.de> <200606280053.42485.Martin@lichtvoll.de> <200606291037.12221.Martin@lichtvoll.de> In-Reply-To: <200606291037.12221.Martin@lichtvoll.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606302226.34009.Martin@lichtvoll.de> X-archive-position: 8075 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Martin@lichtvoll.de Precedence: bulk X-list: xfs Content-Length: 483 Lines: 21 Am Donnerstag 29 Juni 2006 10:37 schrieben Sie: > Hello, > > I am testing this fix now. All seems fine but it is to early to tell > anything definite. > > I attached the patch to my bug report in case anybody else likes to try > it as well: > > http://bugzilla.kernel.org/show_bug.cgi?id=6757 Hello, patch seems to be fine. Thanks a lot Mandy and Nathan! Regards, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7