From owner-linux-xfs@oss.sgi.com Tue Nov 1 01:24:25 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 01 Nov 2005 01:24:28 -0800 (PST) Received: from smtp.pzkagis.cz (gis6.netbox.cz [83.240.30.214]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jA19OHO0017518 for ; Tue, 1 Nov 2005 01:24:24 -0800 Received: (from luf@localhost) by smtp.pzkagis.cz (8.11.6/8.11.6) id jA19Kj026714; Tue, 1 Nov 2005 10:20:45 +0100 Date: Tue, 1 Nov 2005 10:20:45 +0100 From: Ludek Finstrle To: Eric Sandeen Cc: Renaat Dumon , linux-xfs@oss.sgi.com Subject: Re: XFS corruption on 2.4.28 Message-ID: <20051101092045.GB26576@soptik.pzkagis.cz> References: <200510302326.j9UNPw4u005031@outmx013.isp.belgacom.be> <20051031090429.GA17240@soptik.pzkagis.cz> <436650D4.9000307@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <436650D4.9000307@sgi.com> User-Agent: Mutt/1.4i X-archive-position: 6480 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: luf@pzkagis.cz Precedence: bulk X-list: linux-xfs > >I notice this behaviour few weeks ago (max. 4 weeks). There is a patch for > >it in CVS. Try search through mail-archiv for "df vs du -sk" (or similar). > > I -think- that that fix is for a different problem... in that previous > case, xfs_repair could correctly repair the filesystem, without moving > files to lost+found. I'm not so sure. xfs_repair moved / and some other files to lost+found in first run after a long time (and xfs_fsr). I try xfs_fsr and xfs_repair after few hours next time. So it seems conformable to my problems. I didn't try remount. Finally file with same size has same odd size (I don't remember the right numbers: e.g. 4321 -> 774329921, ...) I think Renaat could try the fix. He doesn't go to bigger problems when he try it. I know I had to run xfs_fsr but my filesystem isn't under heavy load. Luf From owner-linux-xfs@oss.sgi.com Tue Nov 1 02:22:26 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 01 Nov 2005 02:22:29 -0800 (PST) Received: from postit.belbone.be (postit.belbone.be [195.13.1.2]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jA1AMOO0022989 for ; Tue, 1 Nov 2005 02:22:25 -0800 Received: from overdrive (overdrive.ops.belbone.be [192.168.20.80]) by postit.belbone.be (Postfix) with ESMTP id 488ED1774FE; Tue, 1 Nov 2005 11:19:10 +0100 (CET) From: "Renaat Dumon" To: "'Ludek Finstrle'" , "'Eric Sandeen'" Cc: Subject: RE: XFS corruption on 2.4.28 Date: Tue, 1 Nov 2005 11:19:08 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXexZY2SlmJkhvXQmGqTAQrhx9UwgAB/avw In-Reply-To: <20051101092045.GB26576@soptik.pzkagis.cz> Message-Id: <20051101101910.488ED1774FE@postit.belbone.be> X-archive-position: 6481 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: renaat.dumon@belbone.be Precedence: bulk X-list: linux-xfs Thanks, but putting another kernel on that box might not be that easy, I get this box in an "appliance" form. I don't have the kernel .config etc R. -----Original Message----- From: Ludek Finstrle [mailto:luf@pzkagis.cz] Sent: 01 November 2005 10:21 To: Eric Sandeen Cc: Renaat Dumon; linux-xfs@oss.sgi.com Subject: Re: XFS corruption on 2.4.28 > >I notice this behaviour few weeks ago (max. 4 weeks). There is a > >patch for it in CVS. Try search through mail-archiv for "df vs du -sk" (or similar). > > I -think- that that fix is for a different problem... in that previous > case, xfs_repair could correctly repair the filesystem, without moving > files to lost+found. I'm not so sure. xfs_repair moved / and some other files to lost+found in first run after a long time (and xfs_fsr). I try xfs_fsr and xfs_repair after few hours next time. So it seems conformable to my problems. I didn't try remount. Finally file with same size has same odd size (I don't remember the right numbers: e.g. 4321 -> 774329921, ...) I think Renaat could try the fix. He doesn't go to bigger problems when he try it. I know I had to run xfs_fsr but my filesystem isn't under heavy load. Luf From owner-linux-xfs@oss.sgi.com Tue Nov 1 03:17:36 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 01 Nov 2005 03:17:40 -0800 (PST) Received: from smtp.pzkagis.cz (gis6.netbox.cz [83.240.30.214]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jA1BHZO0026673 for ; Tue, 1 Nov 2005 03:17:35 -0800 Received: (from luf@localhost) by smtp.pzkagis.cz (8.11.6/8.11.6) id jA1BE0a27504; Tue, 1 Nov 2005 12:14:00 +0100 Date: Tue, 1 Nov 2005 12:14:00 +0100 From: "'Ludek Finstrle'" To: Renaat Dumon Cc: "'Eric Sandeen'" , linux-xfs@oss.sgi.com Subject: Re: XFS corruption on 2.4.28 Message-ID: <20051101111400.GA27417@soptik.pzkagis.cz> References: <20051101092045.GB26576@soptik.pzkagis.cz> <20051101101910.488ED1774FE@postit.belbone.be> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051101101910.488ED1774FE@postit.belbone.be> User-Agent: Mutt/1.4i X-archive-position: 6482 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: luf@pzkagis.cz Precedence: bulk X-list: linux-xfs > Thanks, but putting another kernel on that box might not be that easy, I get > this box in an "appliance" form. I don't have the kernel .config etc I'm sorry, I misunderstood word "appliance" before. Why don't you claim it? Or why don't you consult it with your suplier at least? Luf From owner-linux-xfs@oss.sgi.com Tue Nov 1 15:39:57 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 01 Nov 2005 15:40:01 -0800 (PST) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jA1NdvO0008173 for ; Tue, 1 Nov 2005 15:39:57 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id jA1NahxT019902 for ; Tue, 1 Nov 2005 17:36:44 -0600 Received: from [128.162.232.50] (stout.americas.sgi.com [128.162.232.50]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id jA1NahDN19010863; Tue, 1 Nov 2005 17:36:43 -0600 (CST) Message-ID: <4367FC0A.7060401@sgi.com> Date: Tue, 01 Nov 2005 17:36:42 -0600 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0.6-1.1.fc4 (X11/20050720) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux@horizon.com CC: linux-xfs@oss.sgi.com Subject: Re: 2.6.13.2 amd64: XFS: xlog_recover_process_data: bad clientid References: <20051101233237.18777.qmail@science.horizon.com> In-Reply-To: <20051101233237.18777.qmail@science.horizon.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6485 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 567 Lines: 15 linux@horizon.com wrote: >>Is the problematic filesystem on the aforementioned flakey driver? > > > Yes. Sorry I wasn't clear. The SATA driver hung (the machine was still > "up", but with all the root FS inaccessible, I couldn't do much), and > when I rebooted it, the root FS wouldn't come back. Well, xfs does assume that if the underlying IO layers tell it that something is written, that it is in fact written. Depending on the level of flakiness in your SATA driver, it looks quite possible that you have encountered a SATA bug, not an xfs bug. -Eric From owner-linux-xfs@oss.sgi.com Tue Nov 1 15:35:51 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 01 Nov 2005 15:35:55 -0800 (PST) Received: from science.horizon.com (science.horizon.com [192.35.100.1]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id jA1NZoO0007806 for ; Tue, 1 Nov 2005 15:35:51 -0800 Received: (qmail 18786 invoked by uid 1000); 1 Nov 2005 18:32:37 -0500 Date: 1 Nov 2005 18:32:37 -0500 Message-ID: <20051101233237.18777.qmail@science.horizon.com> From: linux@horizon.com To: linux@horizon.com, sandeen@sgi.com Subject: Re: 2.6.13.2 amd64: XFS: xlog_recover_process_data: bad clientid Cc: linux-xfs@oss.sgi.com In-Reply-To: X-archive-position: 6484 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: linux@horizon.com Precedence: bulk X-list: linux-xfs Content-Length: 719 Lines: 21 > Is the problematic filesystem on the aforementioned flakey driver? Yes. Sorry I wasn't clear. The SATA driver hung (the machine was still "up", but with all the root FS inaccessible, I couldn't do much), and when I rebooted it, the root FS wouldn't come back. > Any kernel messages prior to the fs problems? (related to underlying > IO problems?) I couldn't get dmesg off the machine, but FWIW, the scrollback buffer was reported in http://marc.theaimsgroup.com/?l=linux-ide&m=113035431221239 My understanding was that this was a "freeze" type failure, so there shouldn't be any garbage on the disk, but it's possible I'm wrong; after all, we don't understand the failures very well. Thanks for the reply! From owner-linux-xfs@oss.sgi.com Tue Nov 1 17:21:11 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 01 Nov 2005 17:21:13 -0800 (PST) Received: from science.horizon.com (science.horizon.com [192.35.100.1]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id jA21LAO0018680 for ; Tue, 1 Nov 2005 17:21:11 -0800 Received: (qmail 28540 invoked by uid 1000); 1 Nov 2005 20:17:53 -0500 Date: 1 Nov 2005 20:17:53 -0500 Message-ID: <20051102011753.28539.qmail@science.horizon.com> From: linux@horizon.com To: linux@horizon.com, sandeen@sgi.com Subject: Re: 2.6.13.2 amd64: XFS: xlog_recover_process_data: bad clientid Cc: linux-xfs@oss.sgi.com In-Reply-To: <4367FC0A.7060401@sgi.com> X-archive-position: 6486 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: linux@horizon.com Precedence: bulk X-list: linux-xfs Content-Length: 887 Lines: 20 > Well, xfs does assume that if the underlying IO layers tell it that > something is written, that it is in fact written. Depending on the level > of flakiness in your SATA driver, it looks quite possible that you have > encountered a SATA bug, not an xfs bug. I assure you, I don't expect perfection in the face of such flakiness, but it did seem a little bit less than robust. Mostly, I'm wondering: - Can we extract any information about what misbehaved to help the SATA debugging process? - Is running xfs_repair the best thing to do? Are all of those error messages reasonably harmless? I don't know what's "normal" in xfs_repair output the way that I know that complaints about dtime, too many blocks allocated, and bitmap inconsistencies are basically harmless in e2fsck output, and I only need to worry about other messages. Thank you very much for your help! From owner-linux-xfs@oss.sgi.com Tue Nov 1 19:49:55 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 01 Nov 2005 19:49:59 -0800 (PST) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jA23nsO0026535 for ; Tue, 1 Nov 2005 19:49:54 -0800 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 jA24t3nB012320 for ; Tue, 1 Nov 2005 20:55:03 -0800 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 jA23jdOS2568115; Tue, 1 Nov 2005 19:45:40 -0800 (PST) Message-ID: <43683663.9030807@sgi.com> Date: Tue, 01 Nov 2005 21:45:39 -0600 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux@horizon.com CC: linux-xfs@oss.sgi.com Subject: Re: 2.6.13.2 amd64: XFS: xlog_recover_process_data: bad clientid References: <20051102011753.28539.qmail@science.horizon.com> In-Reply-To: <20051102011753.28539.qmail@science.horizon.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6487 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1275 Lines: 33 linux@horizon.com wrote: >>Well, xfs does assume that if the underlying IO layers tell it that >>something is written, that it is in fact written. Depending on the level >>of flakiness in your SATA driver, it looks quite possible that you have >>encountered a SATA bug, not an xfs bug. > > > I assure you, I don't expect perfection in the face of such > flakiness, but it did seem a little bit less than robust. If the underlying layers tell XFS that data is safe, it is not XFS's fault when it's not there later, and in fact there is nothing that XFS or any other journaling filesystem can do about it... things are journaled only until they are safe on disk, as reported by the IO subsystems. > Mostly, I'm wondering: > - Can we extract any information about what misbehaved to help the SATA > debugging process I doubt it. > - Is running xfs_repair the best thing to do? Are all of those error > messages reasonably harmless? I don't know what's "normal" in > xfs_repair output the way that I know that complaints about dtime, > too many blocks allocated, and bitmap inconsistencies are basically > harmless in e2fsck output, and I only need to worry about other > messages. xfs_repair is your only option. Run it and hope for the best. -Eric From owner-linux-xfs@oss.sgi.com Tue Nov 1 22:47:36 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 01 Nov 2005 22:47:44 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id jA26lYO0007870 for ; Tue, 1 Nov 2005 22:47:35 -0800 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA22484 for ; Wed, 2 Nov 2005 17:44:19 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 8BD9549BFB65; Wed, 2 Nov 2005 17:44:17 +1100 (EST) To: linux-xfs@oss.sgi.com Subject: TAKE 904196 - use gfp_t where needed Message-Id: <20051102064417.8BD9549BFB65@chook.melbourne.sgi.com> Date: Wed, 2 Nov 2005 17:44:17 +1100 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 6488 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 797 Lines: 19 Use the gfp_t type in the places we need to, for sparse - thanks to Chris Wedgwood. Date: Wed Nov 2 17:42:53 AEDT 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: cw@f00f.org The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:24276a linux-2.6/xfs_aops.c - 1.100 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_aops.c.diff?r1=text&tr1=1.100&r2=text&tr2=1.99&f=h linux-2.6/xfs_buf.c - 1.211 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_buf.c.diff?r1=text&tr1=1.211&r2=text&tr2=1.210&f=h linux-2.6/kmem.h - 1.32 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/kmem.h.diff?r1=text&tr1=1.32&r2=text&tr2=1.31&f=h From owner-linux-xfs@oss.sgi.com Wed Nov 2 01:11:08 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 02 Nov 2005 01:11:16 -0800 (PST) Received: from s14.s14avahost.net (s14.s14avahost.net [66.98.146.55]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jA29B3O0023140 for ; Wed, 2 Nov 2005 01:11:07 -0800 Received: from 81-178-240-98.dsl.pipex.com ([81.178.240.98] helo=[192.168.1.2]) by s14.s14avahost.net with esmtpa (Exim 4.52) id 1EXEZ1-00085G-GU; Wed, 02 Nov 2005 03:05:48 -0600 Message-ID: <436881E3.3040208@katalix.com> Date: Wed, 02 Nov 2005 09:07:47 +0000 From: Chris Elston User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: celston@katalix.com CC: linux-xfs@oss.sgi.com, nathans@sgi.com, sandeen@sgi.com, jchapman@katalix.com Subject: Re: [PATCH] Re: Files >4GB in XFS realtime partition Content-Type: multipart/mixed; boundary="------------060802050105000708020709" X-PopBeforeSMTPSenders: celston@katalix.com X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - s14.s14avahost.net X-AntiAbuse: Original Domain - oss.sgi.com X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - katalix.com X-Source: X-Source-Args: X-Source-Dir: X-archive-position: 6489 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: celston@katalix.com Precedence: bulk X-list: linux-xfs Content-Length: 1289 Lines: 39 This is a multi-part message in MIME format. --------------060802050105000708020709 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit > Thanks! Could you resend that patch as just a regular text file (inline text at the end of your mail would be fine)? Should be straight text now, was UUENCODED before. Cheers, -- Chris Elston Katalix Systems Ltd http://www.katalix.com Catalysts for your Embedded Linux software development --------------060802050105000708020709 Content-Type: text/plain; name="XFS_RT_4GB.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="XFS_RT_4GB.patch" --- TDC775-2.4.29/fs/xfs/xfs_iomap.h 2005-10-31 15:37:54.000000000 +0000 +++ PATCHED/fs/xfs/xfs_iomap.h 2005-10-31 15:18:29.000000000 +0000 @@ -86,7 +86,7 @@ xfs_buftarg_t *iomap_target; loff_t iomap_offset; /* offset of mapping, bytes */ loff_t iomap_bsize; /* size of mapping, bytes */ - size_t iomap_delta; /* offset into mapping, bytes */ + loff_t iomap_delta; /* offset into mapping, bytes */ iomap_flags_t iomap_flags; } xfs_iomap_t; --------------060802050105000708020709-- From owner-linux-xfs@oss.sgi.com Wed Nov 2 04:43:11 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 02 Nov 2005 04:43:16 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.190]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jA2Ch8O0020799 for ; Wed, 2 Nov 2005 04:43:11 -0800 Received: from [212.227.126.200] (helo=mrvnet.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1EXHuE-0002HH-00 for linux-xfs@oss.sgi.com; Wed, 02 Nov 2005 13:39:54 +0100 Received: from [172.23.4.152] (helo=pustefix152.kundenserver.de) by mrvnet.kundenserver.de with esmtp (Exim 3.35 #1) id 1EXHuE-0002Mo-00 for linux-xfs@oss.sgi.com; Wed, 02 Nov 2005 13:39:54 +0100 Message-Id: <14058202.53011130935194511.JavaMail.servlet@kundenserver> From: o.otahal@omnikum.de To: Subject: xfsdump request MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Priority: 3 X-Binford: 6100 (more power) X-Mailer: Webmail X-Originating-From: 27360706 X-Routing: DE X-Message-Id: <27360706$1130935194511172.23.4.152680097@pustefix152.kundenserver.de-303834160> X-Received: from pustefix152.kundenserver.de by 84.150.195.128 with HTTP id 27360706 for [linux-xfs@oss.sgi.com]; Wed, 2 Nov 2005 13:39:54 CET Date: Wed, 02 Nov 2005 13:39:54 +0100 X-Provags-ID: kundenserver.de abuse@kundenserver.de ident:@172.23.4.152 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id jA2ChBO0020802 X-archive-position: 6490 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: o.otahal@omnikum.de Precedence: bulk X-list: linux-xfs Content-Length: 331 Lines: 7 Hi Is it possible to expand the xfsdump command for a more verbose mode like “stat –t” for every dumped file in the next version of xfsdump? Additionally with a checksum like md5 for every file would be very fine? The intention is, to create a table of contents with all information about a backuped file. Thanks, Othmar Otahal From owner-linux-xfs@oss.sgi.com Wed Nov 2 05:53:28 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 02 Nov 2005 05:53:32 -0800 (PST) Received: from postit.belbone.be (postit.belbone.be [195.13.1.2]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jA2DrQO0027524 for ; Wed, 2 Nov 2005 05:53:27 -0800 Received: from overdrive (overdrive.ops.belbone.be [192.168.20.80]) by postit.belbone.be (Postfix) with ESMTP id 99B69177505; Wed, 2 Nov 2005 14:50:10 +0100 (CET) From: "Renaat Dumon" To: "'Eric Sandeen'" Cc: Subject: RE: XFS corruption on 2.4.28 Date: Wed, 2 Nov 2005 14:50:13 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXemxon+DTwCBFeQgq6VmfLEgptkABGIQFA In-Reply-To: Message-Id: <20051102135010.99B69177505@postit.belbone.be> X-archive-position: 6492 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: renaat.dumon@belbone.be Precedence: bulk X-list: linux-xfs Content-Length: 3162 Lines: 87 Hi Eric, I did the tests, (added one "for" loop because of [0-9a-f]/[0-9a-f]/[0-9a-f]/somereallylongfilename.somenumber.db ) I did not observe the behaviour then :( I have - in the mean time - gotten a chance to remount the filesystem too on this particular box (which is the worst box I have for the phenomenon, due to the amount of data that is sitting on it I guess). This night new backups will occur, so I'll know pretty soon now whether or not the geometry options have anything to do with it One question though, suppose I create an XFS filesystem using a 2.6 bootdisk, untar a 2.4 system backup on the disk, and then boot from disk (so a 2.4 kernel). Could that interfere? That's what I did originally, but I have the mean time recreated the filesystem under the running 2.4 kernel, so I guess that shouldn't be an issue .. Kind regards, Renaat -----Original Message----- From: Eric Sandeen [mailto:sandeen@sgi.com] Sent: 01 November 2005 05:17 To: Renaat Dumon Subject: RE: XFS corruption on 2.4.28 Renaat Dumon wrote: > Hi Eric, > > Thanks for taking the time to look at this. > > bacardi root # xfs_info /Storage > meta-data=/Storage isize=256 agcount=56, agsize=1048576 > blks > = sectsz=512 > data = bsize=4096 blocks=58663328, imaxpct=25 > = sunit=0 swidth=0 blks, unwritten=0 > naming =version 2 bsize=4096 > log =internal bsize=4096 blocks=7161, version=1 > = sectsz=512 sunit=0 blks > realtime =none extsz=65536 blocks=0, rtextents=0 FWIW I tried this test with stock 2.4.28: [root@penguin5 src2]# mkfs.xfs -f -bsize=4096 -dfile,name=testfs,agsize=1048576b,size=58663328b,unwritten=0 meta-data=testfs isize=256 agcount=56, agsize=1048576 blks = sectsz=512 data = bsize=4096 blocks=58663328, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=28644, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 [root@penguin5 src2]# mount -o loop,noatime,sunit=128,swidth=256 testfs /mnt/test/ [root@penguin5 src2]# cd /mnt/test/ [root@penguin5 test]# ls [root@penguin5 test]# echo abcdefghijklmnopqrstuvwxyza > file [root@penguin5 test]# ls -l file -rw-r--r-- 1 root root 28 Oct 31 22:03 file [root@penguin5 test]# for a in `seq 1 3`; do for b in `seq 1 3`; do for c in `seq 1 10000`; do mkdir -p $a/$b; cp file $a/$b/00005d697a5a05795f53cb7b081f242d.$c.db; done; done; done [root@penguin5 test]# find . | xargs du -sk | grep -v ^4 366124 . 122040 ./1 122040 ./2 122040 ./3 so that did not trip it. perhaps you could try a similar test with your kernel.... either on loopback like this, or on your real filesystem? Does the above tree structure / file naming more or less match your real application? -Eric From owner-linux-xfs@oss.sgi.com Wed Nov 2 09:04:05 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 02 Nov 2005 09:04:08 -0800 (PST) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jA2H45O0013657 for ; Wed, 2 Nov 2005 09:04:05 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id jA2I9Ioe026317 for ; Wed, 2 Nov 2005 10:09:19 -0800 Received: from tulip-e236.americas.sgi.com (tulip-e236.americas.sgi.com [128.162.236.208]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id jA2GxoDN19064288; Wed, 2 Nov 2005 10:59:50 -0600 (CST) Received: from [128.162.232.14] (lnx-yingping.americas.sgi.com [128.162.232.14]) by tulip-e236.americas.sgi.com (8.12.9/ASC-news-1.4) with ESMTP id jA2GxoRA10385294; Wed, 2 Nov 2005 10:59:50 -0600 (CST) Message-ID: <4368F086.2060503@sgi.com> Date: Wed, 02 Nov 2005 10:59:50 -0600 From: Yingping Lu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20041020 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Subject: TAKE 940655 - XFS corruption caused by serial fsstresses Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6493 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: yingping@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 606 Lines: 19 Fixed the inconsistency between attribute b-tree intermidiate node and leaf blocks. The problem came from xfsqa test 117. Date: Wed Nov 2 08:40:48 PST 2005 Workarea: penguin.americas.sgi.com:/src/yingping/xfs-kern Inspected by: tes nathans Author: yingping The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:201527a xfs_da_btree.c - 1.159 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_da_btree.c.diff?r1=text&tr1=1.159&r2=text&tr2=1.158&f=h - Enabled useextra flag for attribute fork in v2 directory format. From owner-linux-xfs@oss.sgi.com Wed Nov 2 11:10:59 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 02 Nov 2005 11:11:04 -0800 (PST) Received: from science.horizon.com (science.horizon.com [192.35.100.1]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id jA2JAwO0022765 for ; Wed, 2 Nov 2005 11:10:59 -0800 Received: (qmail 29536 invoked by uid 1000); 2 Nov 2005 14:07:44 -0500 Date: 2 Nov 2005 14:07:44 -0500 Message-ID: <20051102190744.29534.qmail@science.horizon.com> From: linux@horizon.com To: sandeen@sgi.com Subject: Re: 2.6.13.2 amd64: XFS: xlog_recover_process_data: bad clientid Cc: linux@horizon.com, linux-xfs@oss.sgi.com In-Reply-To: <43683663.9030807@sgi.com> X-archive-position: 6494 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: linux@horizon.com Precedence: bulk X-list: linux-xfs Content-Length: 1118 Lines: 30 > xfs_repair is your only option. Run it and hope for the best. Ah, it complains about an unflushed log and won't run. It might be a worthwhile addition to the sfs_repair man page to mention that "-n" implies "-L". If it is indeed the case that the *only* code which can replay a log is in the kernel, that might be worth saying explicitly, too. I'm poking at xfs_logprint wondering if there's a way to get it to do something useful. >> - Can we extract any information about what misbehaved to help the SATA >> debugging process > I doubt it. Well, we can at least conclude that it didn't "fail fast" and freeze at a particular point in time, right? Because that would have left consistent metadata. (OF course, it could been the RAID-10 setup. If I have mirror pairs A/B and C/D, and the B&C driver got wedged, so the last write went only to A and D, and on recovery the RAID system synchronized A to B and C to D, that would leave a half-written log entry. But I'm using a 256K stripe size, and log entries are 32K, so they shouldn't be split across stripes....) Anyway, thanks a lot for your help! From owner-linux-xfs@oss.sgi.com Wed Nov 2 13:43:01 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 02 Nov 2005 13:43:07 -0800 (PST) Received: from postit.belbone.be (postit.belbone.be [195.13.1.2]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jA2LgxO0009992 for ; Wed, 2 Nov 2005 13:43:00 -0800 Received: from overdrive (overdrive.ops.belbone.be [192.168.20.80]) by postit.belbone.be (Postfix) with ESMTP id 1EEA31775D1; Wed, 2 Nov 2005 22:39:46 +0100 (CET) From: "Renaat Dumon" To: "'Eric Sandeen'" Cc: Subject: RE: XFS corruption on 2.4.28 Date: Wed, 2 Nov 2005 22:39:50 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcXemxon+DTwCBFeQgq6VmfLEgptkABWY0jw In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-Id: <20051102213946.1EEA31775D1@postit.belbone.be> X-archive-position: 6495 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: renaat.dumon@belbone.be Precedence: bulk X-list: linux-xfs Content-Length: 3534 Lines: 93 Mounting the filesystem without the geometry doesn't change things, the size is still wrongly reported for .db files. I have however found files that should be 44 bytes (from ls -al) and bacardi 0 # ls -al 000b21176cda012e1c0a7828f75347c3.289492.db -rw------- 1 root root 44 Nov 2 20:18 000b21176cda012e1c0a7828f75347c3.289492.db bacardi 0 # du -sk 000b21176cda012e1c0a7828f75347c3.289492.db 2147483532 000b21176cda012e1c0a7828f75347c3.289492.db The value that du reports is the same as the one for 28-byte files, so it's a constant, regardless of the real size of the file. FWIW, this is a filesystem with a huge amount of files: bacardi 0 # df -hi Filesystem Inodes IUsed IFree IUse% Mounted on /dev/root 8.0M 44K 8.0M 1% / /dev/md0 12K 33 12K 1% /boot /dev/md3 224M 11M 214M 5% /Storage none 63K 1 63K 1% /dev/shm I have requested my vendor to actually build a kernel with the most recent patches + include the most recent userland progs. Could it be that a newer version of xfs_repair might catch some inconsistencies the current version would not ? Kind regards, Renaat -----Original Message----- From: Eric Sandeen [mailto:sandeen@sgi.com] Sent: 01 November 2005 05:17 To: Renaat Dumon Subject: RE: XFS corruption on 2.4.28 Renaat Dumon wrote: > Hi Eric, > > Thanks for taking the time to look at this. > > bacardi root # xfs_info /Storage > meta-data=/Storage isize=256 agcount=56, agsize=1048576 > blks > = sectsz=512 > data = bsize=4096 blocks=58663328, imaxpct=25 > = sunit=0 swidth=0 blks, unwritten=0 > naming =version 2 bsize=4096 > log =internal bsize=4096 blocks=7161, version=1 > = sectsz=512 sunit=0 blks > realtime =none extsz=65536 blocks=0, rtextents=0 FWIW I tried this test with stock 2.4.28: [root@penguin5 src2]# mkfs.xfs -f -bsize=4096 -dfile,name=testfs,agsize=1048576b,size=58663328b,unwritten=0 meta-data=testfs isize=256 agcount=56, agsize=1048576 blks = sectsz=512 data = bsize=4096 blocks=58663328, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=28644, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 [root@penguin5 src2]# mount -o loop,noatime,sunit=128,swidth=256 testfs /mnt/test/ [root@penguin5 src2]# cd /mnt/test/ [root@penguin5 test]# ls [root@penguin5 test]# echo abcdefghijklmnopqrstuvwxyza > file [root@penguin5 test]# ls -l file -rw-r--r-- 1 root root 28 Oct 31 22:03 file [root@penguin5 test]# for a in `seq 1 3`; do for b in `seq 1 3`; do for c in `seq 1 10000`; do mkdir -p $a/$b; cp file $a/$b/00005d697a5a05795f53cb7b081f242d.$c.db; done; done; done [root@penguin5 test]# find . | xargs du -sk | grep -v ^4 366124 . 122040 ./1 122040 ./2 122040 ./3 so that did not trip it. perhaps you could try a similar test with your kernel.... either on loopback like this, or on your real filesystem? Does the above tree structure / file naming more or less match your real application? -Eric From owner-linux-xfs@oss.sgi.com Wed Nov 2 14:00:05 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 02 Nov 2005 14:00:07 -0800 (PST) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jA2M04O0011592 for ; Wed, 2 Nov 2005 14:00:04 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id jA2N5KaX032360 for ; Wed, 2 Nov 2005 15:05:20 -0800 Received: from [128.162.232.50] (stout.americas.sgi.com [128.162.232.50]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id jA2LunDN19076523; Wed, 2 Nov 2005 15:56:50 -0600 (CST) Message-ID: <43693621.6040902@sgi.com> Date: Wed, 02 Nov 2005 15:56:49 -0600 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0.6-1.1.fc4 (X11/20050720) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Renaat Dumon CC: linux-xfs@oss.sgi.com Subject: Re: XFS corruption on 2.4.28 References: <20051102213946.1EEA31775D1@postit.belbone.be> In-Reply-To: <20051102213946.1EEA31775D1@postit.belbone.be> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6496 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1465 Lines: 39 Renaat Dumon wrote: > Mounting the filesystem without the geometry doesn't change things, the size > is still wrongly reported for .db files. Ok, good to know. You should put it back now :) > I have however found files that should be 44 bytes (from ls -al) and > > bacardi 0 # ls -al 000b21176cda012e1c0a7828f75347c3.289492.db > -rw------- 1 root root 44 Nov 2 20:18 > 000b21176cda012e1c0a7828f75347c3.289492.db > bacardi 0 # du -sk 000b21176cda012e1c0a7828f75347c3.289492.db > 2147483532 000b21176cda012e1c0a7828f75347c3.289492.db > > > The value that du reports is the same as the one for 28-byte files, so it's > a constant, regardless of the real size of the file. Interesting. > FWIW, this is a filesystem with a huge amount of files: > > bacardi 0 # df -hi > Filesystem Inodes IUsed IFree IUse% Mounted on > /dev/root 8.0M 44K 8.0M 1% / > /dev/md0 12K 33 12K 1% /boot > /dev/md3 224M 11M 214M 5% /Storage > none 63K 1 63K 1% /dev/shm > > I have requested my vendor to actually build a kernel with the most recent > patches + include the most recent userland progs. Could it be that a newer > version of xfs_repair might catch some inconsistencies the current version > would not ? It would probably be good to see some of the repair output when you run it on a problematic filesystem... -Eric From owner-linux-xfs@oss.sgi.com Wed Nov 2 14:21:15 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 02 Nov 2005 14:21:17 -0800 (PST) Received: from science.horizon.com (science.horizon.com [192.35.100.1]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id jA2MLEO0013478 for ; Wed, 2 Nov 2005 14:21:14 -0800 Received: (qmail 16065 invoked by uid 1000); 2 Nov 2005 17:18:00 -0500 Date: 2 Nov 2005 17:18:00 -0500 Message-ID: <20051102221800.16064.qmail@science.horizon.com> From: linux@horizon.com To: sandeen@sgi.com Subject: Re: 2.6.13.2 amd64: XFS: xlog_recover_process_data: bad clientid Cc: linux-xfs@oss.sgi.com, linux@horizon.com In-Reply-To: <20051102190744.29534.qmail@science.horizon.com> X-archive-position: 6497 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: linux@horizon.com Precedence: bulk X-list: linux-xfs Content-Length: 2557 Lines: 54 Just some more info... I ran xfs_repair -L, but then ran xfs_check, and it found a lot of problems remaining, in particular a lot of: link count mismatch for inode 514608143 (name ?), nlink 4, counted 3 link count mismatch for inode 514608156 (name ?), nlink 4, counted 3 link count mismatch for inode 514608168 (name ?), nlink 4, counted 3 link count mismatch for inode 514608172 (name ?), nlink 4, counted 3 link count mismatch for inode 514608180 (name ?), nlink 4, counted 3 link count mismatch for inode 514964512 (name ?), nlink 18, counted 17 link count mismatch for inode 514964526 (name ?), nlink 18, counted 17 link count mismatch for inode 514964528 (name ?), nlink 18, counted 17 link count mismatch for inode 514964531 (name ?), nlink 18, counted 17 link count mismatch for inode 514964532 (name ?), nlink 18, counted 17 link count mismatch for inode 514964533 (name ?), nlink 18, counted 17 link count mismatch for inode 514964535 (name ?), nlink 18, counted 17 link count mismatch for inode 514939937 (name ?), nlink 26, counted 25 link count mismatch for inode 515270699 (name ?), nlink 4, counted 3 link count mismatch for inode 515270700 (name ?), nlink 4, counted 3 link count mismatch for inode 515270701 (name ?), nlink 4, counted 3 link count mismatch for inode 515270703 (name ?), nlink 4, counted 3 link count mismatch for inode 515270704 (name ?), nlink 4, counted 3 link count mismatch for inode 514965508 (name ?), nlink 16, counted 15 link count mismatch for inode 514610208 (name ?), nlink 3, counted 4 link count mismatch for inode 514610209 (name ?), nlink 3, counted 4 link count mismatch for inode 523361301 (name ?), nlink 17, counted 16 link count mismatch for inode 523361312 (name ?), nlink 0, counted 2 So I'm running xfs_repair again, and it's not coming up clean. Is this supposed to happen? I didn't see a message about "re-run xfs_repair" anywhere... # xfs_repair /dev/md4 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 imap claims a free inode 129571903 is in use, correcting imap and clearing inode cleared inode 129571903 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 (in progress as I write this) From owner-linux-xfs@oss.sgi.com Wed Nov 2 15:14:19 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 02 Nov 2005 15:14:22 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id jA2NEHO0016624 for ; Wed, 2 Nov 2005 15:14:18 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA14990; Thu, 3 Nov 2005 10:10:57 +1100 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id jA2NB9kt6179512; Thu, 3 Nov 2005 10:11:10 +1100 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id jA2NB75Z6220653; Thu, 3 Nov 2005 10:11:07 +1100 (EST) Date: Thu, 3 Nov 2005 10:11:07 +1100 From: Nathan Scott To: Jan Kasprzak Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: XFS information leak during crash Message-ID: <20051103101107.O6239737@wobbly.melbourne.sgi.com> References: <20051102212722.GC6759@fi.muni.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20051102212722.GC6759@fi.muni.cz>; from kas@fi.muni.cz on Wed, Nov 02, 2005 at 10:27:22PM +0100 X-archive-position: 6498 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2103 Lines: 48 Hello Jan, On Wed, Nov 02, 2005 at 10:27:22PM +0100, Jan Kasprzak wrote: > Hello, world!\n > > I have found that after the system crash (e.h. a hard reset or a power > failure) XFS corrupts files which have been written to just before the crash: > The result is that those files contain data from random blocks on the > disk (e.g. from previously deleted files). This can have security/privacy > implications - users can see the contents of other users' old files. If you think you have found a security issue, it would be courteous to at least discuss this with the maintainers first. And since you are a frequent linux-xfs list poster too, it seems a bit odd that you're reporting this on linux-kernel instead... *shrug*, whatever. This issue affects every filesystem, right? Or are you claiming its only XFS affected here? Have you run your parallel-buffered-writers test case on any other filesystems? I'd be interested in the results, in particular, with all of the data=xxx modes of other filesystems. > either). Does XFS support a something like ext3's "data=ordered" mount > option? No, it doesn't. > Otherwise it is pretty unusable on multi-user systems. That's a ridiculous assertion. While this small metadata vs. buffered- data-write window exists on _any_ filesystem not using a data=ordered/ data=journaled mode (which I believe is quite a common mode of operation even on filesystems that offer those modes), it is impossible to exploit this in any sane way. You'd think people on a multi-user system might actually notice the machine being frequently rebooted while you try to tickle this window to get at "interesting" uninitialised freespace, no? Having said that, a data=ordered mode for XFS would be a nice feature. It just hasn't reached the top of our priority list, and its not been offered up as a patch by anyone yet. If anyone's interested in writing this, they should coordinate with hch and myself - there's a fair bit of I/O path work being done at the moment, which in the end will make a data=ordered mode alot easier to implement. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Nov 2 15:39:48 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 02 Nov 2005 15:39:53 -0800 (PST) Received: from tirith.ics.muni.cz (tirith.ics.muni.cz [147.251.4.36]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jA2NdlO0018155 for ; Wed, 2 Nov 2005 15:39:47 -0800 Received: from anxur.fi.muni.cz (anxur.fi.muni.cz [147.251.48.3]) by tirith.ics.muni.cz (8.13.2/8.13.2) with ESMTP id jA2NaTNi031908; Thu, 3 Nov 2005 00:36:30 +0100 Received: by anxur.fi.muni.cz (Postfix, from userid 11561) id 5708322AF74; Thu, 3 Nov 2005 00:36:29 +0100 (CET) Date: Thu, 3 Nov 2005 00:36:29 +0100 From: Jan Kasprzak To: Nathan Scott Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: XFS information leak during crash Message-ID: <20051102233629.GD6759@fi.muni.cz> References: <20051102212722.GC6759@fi.muni.cz> <20051103101107.O6239737@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051103101107.O6239737@wobbly.melbourne.sgi.com> User-Agent: Mutt/1.4.1i X-Muni-Spam-TestIP: 147.251.48.3 X-Muni-Envelope-From: kas@fi.muni.cz X-Muni-Virus-Test: Clean X-archive-position: 6499 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kas@fi.muni.cz Precedence: bulk X-list: linux-xfs Content-Length: 3726 Lines: 83 Nathan Scott wrote: : > The result is that those files contain data from random blocks on the : > disk (e.g. from previously deleted files). This can have security/privacy : > implications - users can see the contents of other users' old files. : : If you think you have found a security issue, it would be courteous : to at least discuss this with the maintainers first. Well, I think while it is a security issue, it is not serious enough to make it secret (it is not exploitable by anyone except those who are able to crash the machine). : And since you : are a frequent linux-xfs list poster too, it seems a bit odd that : you're reporting this on linux-kernel instead... *shrug*, whatever. I am sorry for this one - I am not subscribed to linux-xfs. Next time I will post to linux-xfs first. : : This issue affects every filesystem, right? Or are you claiming its : only XFS affected here? Have you run your parallel-buffered-writers : test case on any other filesystems? I'd be interested in the results, : in particular, with all of the data=xxx modes of other filesystems. : I will do this tomorrow or the day after and post the results. : > either). Does XFS support a something like ext3's "data=ordered" mount : > option? : : No, it doesn't. : OK. : > Otherwise it is pretty unusable on multi-user systems. : : That's a ridiculous assertion. While this small metadata vs. buffered- : data-write window exists on _any_ filesystem not using a data=ordered/ : data=journaled mode (which I believe is quite a common mode of operation : even on filesystems that offer those modes), As for ext3, I believe the vast majority of ext3 filesystems run in data=ordered mode. But yes, the same problem affects all filesystem except those running in data=ordered/journal mode. : it is impossible to exploit : this in any sane way. You'd think people on a multi-user system might : actually notice the machine being frequently rebooted while you try to : tickle this window to get at "interesting" uninitialised freespace, no? Yes, of course. However, the issue is probably much worse on XFS, because on XFS it probably affects not only the files being created/extended, but also the files being rewritten. Most other filesystems rewrite the files in-place, so when you rewrite the file, even with data=writeback you get only the mix of the old and new contents. Not somebody else's random data. This particular problem was that one of my users apparently opened his TeX document just to fix few typos, and ended up with the file which contained some part of a shell script and some binary data :-( I agree this is hard to exploit on purpose, however it can still leak a sensitive data. For example, this particular server runs also a mail server for ~2200 users, so a private mail can end up in somebody else's files. : Having said that, a data=ordered mode for XFS would be a nice feature. : It just hasn't reached the top of our priority list, and its not been : offered up as a patch by anyone yet. If anyone's interested in writing : this, they should coordinate with hch and myself - there's a fair bit : of I/O path work being done at the moment, which in the end will make : a data=ordered mode alot easier to implement. OK, thanks! I wish I would have time to do more kernel hacking ... -Yenya -- | Jan "Yenya" Kasprzak | | GPG: ID 1024/D3498839 Fingerprint 0D99A7FB206605D7 8B35FCDE05B18A5E | | http://www.fi.muni.cz/~kas/ Journal: http://www.fi.muni.cz/~kas/blog/ | > Specs are a basis for _talking_about_ things. But they are _not_ a basis < > for implementing software. --Linus Torvalds < From owner-linux-xfs@oss.sgi.com Wed Nov 2 15:53:10 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 02 Nov 2005 15:53:12 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id jA2Nr8O0019036 for ; Wed, 2 Nov 2005 15:53:09 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA16148; Thu, 3 Nov 2005 10:49:46 +1100 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id jA2Nnwkt6282574; Thu, 3 Nov 2005 10:49:59 +1100 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id jA2NnumE6186888; Thu, 3 Nov 2005 10:49:56 +1100 (EST) Date: Thu, 3 Nov 2005 10:49:56 +1100 From: Nathan Scott To: Jan Kasprzak Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: XFS information leak during crash Message-ID: <20051103104956.B6081538@wobbly.melbourne.sgi.com> References: <20051102212722.GC6759@fi.muni.cz> <20051103101107.O6239737@wobbly.melbourne.sgi.com> <20051102233629.GD6759@fi.muni.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20051102233629.GD6759@fi.muni.cz>; from kas@fi.muni.cz on Thu, Nov 03, 2005 at 12:36:29AM +0100 X-archive-position: 6500 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 919 Lines: 24 On Thu, Nov 03, 2005 at 12:36:29AM +0100, Jan Kasprzak wrote: > ... > Yes, of course. However, the issue is probably much worse > on XFS, because on XFS it probably affects not only the files being > created/extended, but also the files being rewritten. Most other No, thats not correct - XFS behaves as most filesystems do and will write over the top of existing data. > filesystems rewrite the files in-place, so when you rewrite the file, > even with data=writeback you get only the mix of the old and new > contents. Not somebody else's random data. XFS also rewrites files in-place. You will never get someone else's current data (that would be metadata corruption...), it would only ever be uninitialised, previously-free space. But as I said, other filesystems have the same window in which this can happen (in the absence of stronger data ordering/journalling semantics, of course). cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Nov 2 16:06:33 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 02 Nov 2005 16:06:37 -0800 (PST) Received: from tirith.ics.muni.cz (tirith.ics.muni.cz [147.251.4.36]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jA306WO0020268 for ; Wed, 2 Nov 2005 16:06:33 -0800 Received: from anxur.fi.muni.cz (anxur.fi.muni.cz [147.251.48.3]) by tirith.ics.muni.cz (8.13.2/8.13.2) with ESMTP id jA303Hj9026783; Thu, 3 Nov 2005 01:03:18 +0100 Received: by anxur.fi.muni.cz (Postfix, from userid 11561) id 76C1D22AF74; Thu, 3 Nov 2005 01:03:17 +0100 (CET) Date: Thu, 3 Nov 2005 01:03:17 +0100 From: Jan Kasprzak To: Nathan Scott Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: XFS information leak during crash Message-ID: <20051103000317.GE6759@fi.muni.cz> References: <20051102212722.GC6759@fi.muni.cz> <20051103101107.O6239737@wobbly.melbourne.sgi.com> <20051102233629.GD6759@fi.muni.cz> <20051103104956.B6081538@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051103104956.B6081538@wobbly.melbourne.sgi.com> User-Agent: Mutt/1.4.1i X-Muni-Spam-TestIP: 147.251.48.3 X-Muni-Envelope-From: kas@fi.muni.cz X-Muni-Virus-Test: Clean X-archive-position: 6501 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kas@fi.muni.cz Precedence: bulk X-list: linux-xfs Content-Length: 882 Lines: 27 Nathan Scott wrote: : XFS behaves as most filesystems do and : will write over the top of existing data. OK, thanks for the clarification. : XFS also rewrites files in-place. You will never get someone else's : current data (that would be metadata corruption...), Of course. : it would only : ever be uninitialised, previously-free space. Yes, but an old data from previously deleted files (sendmail's temporary files, vim save files, etc) may contain a sensitive information. -Y. -- | Jan "Yenya" Kasprzak | | GPG: ID 1024/D3498839 Fingerprint 0D99A7FB206605D7 8B35FCDE05B18A5E | | http://www.fi.muni.cz/~kas/ Journal: http://www.fi.muni.cz/~kas/blog/ | > Specs are a basis for _talking_about_ things. But they are _not_ a basis < > for implementing software. --Linus Torvalds < From owner-linux-xfs@oss.sgi.com Wed Nov 2 16:14:27 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 02 Nov 2005 16:14:29 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id jA30EPO0020976 for ; Wed, 2 Nov 2005 16:14:26 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA16671; Thu, 3 Nov 2005 11:11:06 +1100 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id jA30BHkt6264294; Thu, 3 Nov 2005 11:11:18 +1100 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id jA30BFJq6285589; Thu, 3 Nov 2005 11:11:15 +1100 (EST) Date: Thu, 3 Nov 2005 11:11:15 +1100 From: Nathan Scott To: Jan Kasprzak Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: XFS information leak during crash Message-ID: <20051103111115.C6081538@wobbly.melbourne.sgi.com> References: <20051102212722.GC6759@fi.muni.cz> <20051103101107.O6239737@wobbly.melbourne.sgi.com> <20051102233629.GD6759@fi.muni.cz> <20051103104956.B6081538@wobbly.melbourne.sgi.com> <20051103000317.GE6759@fi.muni.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20051103000317.GE6759@fi.muni.cz>; from kas@fi.muni.cz on Thu, Nov 03, 2005 at 01:03:17AM +0100 X-archive-position: 6502 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 417 Lines: 15 On Thu, Nov 03, 2005 at 01:03:17AM +0100, Jan Kasprzak wrote: > : it would only ever be uninitialised, previously-free space. > > Yes, but an old data from previously deleted files > (sendmail's temporary files, vim save files, etc) may contain > a sensitive information. Indeed. But this is a generic issue affecting most filesystems; its not specific to XFS as your original mail claimed. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Nov 2 16:22:25 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 02 Nov 2005 16:22:29 -0800 (PST) Received: from artax.karlin.mff.cuni.cz (artax.karlin.mff.cuni.cz [195.113.31.125]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jA30MOO0025778 for ; Wed, 2 Nov 2005 16:22:25 -0800 Received: by artax.karlin.mff.cuni.cz (Postfix, from userid 17421) id A96893FFE; Thu, 3 Nov 2005 01:19:10 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by artax.karlin.mff.cuni.cz (Postfix) with ESMTP id A8CA73FF3; Thu, 3 Nov 2005 01:19:10 +0100 (CET) Date: Thu, 3 Nov 2005 01:19:10 +0100 (CET) From: Mikulas Patocka To: Nathan Scott Cc: Jan Kasprzak , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: XFS information leak during crash In-Reply-To: <20051103101107.O6239737@wobbly.melbourne.sgi.com> Message-ID: References: <20051102212722.GC6759@fi.muni.cz> <20051103101107.O6239737@wobbly.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 6503 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mikulas@artax.karlin.mff.cuni.cz Precedence: bulk X-list: linux-xfs Content-Length: 292 Lines: 11 >> either). Does XFS support a something like ext3's "data=ordered" mount >> option? > > No, it doesn't. BTW. Why does it sometimes overwrite files with zeros after crash and journal replay then? I thought that this was because it tries to avoid users seeing uninitialized data. Mikulas From owner-linux-xfs@oss.sgi.com Wed Nov 2 16:41:10 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 02 Nov 2005 16:41:13 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id jA30f8O0026989 for ; Wed, 2 Nov 2005 16:41:09 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA17405; Thu, 3 Nov 2005 11:37:52 +1100 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id jA30c4kt6289716; Thu, 3 Nov 2005 11:38:04 +1100 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id jA30c1S76281310; Thu, 3 Nov 2005 11:38:01 +1100 (EST) Date: Thu, 3 Nov 2005 11:38:01 +1100 From: Nathan Scott To: Mikulas Patocka Cc: Jan Kasprzak , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: XFS information leak during crash Message-ID: <20051103113801.E6081538@wobbly.melbourne.sgi.com> References: <20051102212722.GC6759@fi.muni.cz> <20051103101107.O6239737@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 mikulas@artax.karlin.mff.cuni.cz on Thu, Nov 03, 2005 at 01:19:10AM +0100 X-archive-position: 6504 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 804 Lines: 24 On Thu, Nov 03, 2005 at 01:19:10AM +0100, Mikulas Patocka wrote: > >> either). Does XFS support a something like ext3's "data=ordered" mount > >> option? > > > > No, it doesn't. > > BTW. Why does it sometimes overwrite files with zeros after crash and > journal replay then? I thought that this was because it tries to avoid > users seeing uninitialized data. No, thats kinda related but not the same issue, its more to do with a truncate (or open(O_TRUNC)) followed by buffered writes to an existing file, which some applications do, and how that interacts poorly with delayed allocation (nothing is "overwritten with zeroes", its actually just a "hole"). But I do intend to get _some_ work done today, so you can google for a more detailed answer there if you're interested. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Nov 2 16:45:31 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 02 Nov 2005 16:45:36 -0800 (PST) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jA30jUO0027519 for ; Wed, 2 Nov 2005 16:45:31 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id jA31olMO032345 for ; Wed, 2 Nov 2005 17:50:47 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id jA30gGDN19082675; Wed, 2 Nov 2005 18:42:16 -0600 (CST) Received: (from overby@localhost) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) id jA30fu3a18715941; Wed, 2 Nov 2005 18:41:56 -0600 (CST) Date: Wed, 2 Nov 2005 18:41:56 -0600 (CST) Message-Id: <200511030041.jA30fu3a18715941@daisy-e236.americas.sgi.com> From: Glen Overby To: mikulas@artax.karlin.mff.cuni.cz Cc: nathans@sgi.com, linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: XFS information leak during crash In-Reply-To: message from Mikulas Patocka sent 3 November 2005 References: <20051102212722.GC6759@fi.muni.cz> <20051103101107.O6239737@wobbly.melbourne.sgi.com> X-archive-position: 6505 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: overby@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 921 Lines: 23 On November 3, Mikulas Patocka wrote: > BTW. Why does it sometimes overwrite files with zeros after crash and > journal replay then? I thought that this was because it tries to avoid > users seeing uninitialized data. It doesn't overwrite the file with zeros. You're getting an inode that has a non-zero size, but no data in the file. That is, a file that is a single hole. This happens because XFS logs metadata quickly, but the data in the file gets written more slowly. You'll see the same zeroing if you create a sparse file: write a megabyte of data, lseek forward a megabyte, and write another megabyte of data. When reading the area you lseeked over, it will read as zeros. The same is done for files that were preallocated, but haven't been written to (that is, the file has unwritten extents). You can look at the files in question with xfs_bmap -v and see that there's no extents there. Glen Overby From owner-linux-xfs@oss.sgi.com Thu Nov 3 04:20:12 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Nov 2005 04:20:35 -0800 (PST) Received: from lxorguk.ukuu.org.uk (clock-tower.bc.nu [81.2.110.250] (may be forged)) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jA3CKAO0022809 for ; Thu, 3 Nov 2005 04:20:11 -0800 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by lxorguk.ukuu.org.uk (8.13.4/8.13.4) with ESMTP id jA3CjooI020022; Thu, 3 Nov 2005 12:45:50 GMT Received: (from alan@localhost) by localhost.localdomain (8.13.4/8.13.4/Submit) id jA3CjoC4020021; Thu, 3 Nov 2005 12:45:50 GMT X-Authentication-Warning: localhost.localdomain: alan set sender to alan@lxorguk.ukuu.org.uk using -f Subject: Re: XFS information leak during crash From: Alan Cox To: Nathan Scott Cc: Jan Kasprzak , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com In-Reply-To: <20051103111115.C6081538@wobbly.melbourne.sgi.com> References: <20051102212722.GC6759@fi.muni.cz> <20051103101107.O6239737@wobbly.melbourne.sgi.com> <20051102233629.GD6759@fi.muni.cz> <20051103104956.B6081538@wobbly.melbourne.sgi.com> <20051103000317.GE6759@fi.muni.cz> <20051103111115.C6081538@wobbly.melbourne.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 03 Nov 2005 12:45:49 +0000 Message-Id: <1131021949.18848.21.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) X-archive-position: 6507 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: alan@lxorguk.ukuu.org.uk Precedence: bulk X-list: linux-xfs Content-Length: 586 Lines: 14 On Iau, 2005-11-03 at 11:11 +1100, Nathan Scott wrote: > On Thu, Nov 03, 2005 at 01:03:17AM +0100, Jan Kasprzak wrote: > > : it would only ever be uninitialised, previously-free space. > > > > Yes, but an old data from previously deleted files > > (sendmail's temporary files, vim save files, etc) may contain > > a sensitive information. > > Indeed. But this is a generic issue affecting most filesystems; > its not specific to XFS as your original mail claimed. Very true. You can use ext3 in data journalling mode if this is a concern but that guarantee has a performance cost From owner-linux-xfs@oss.sgi.com Thu Nov 3 08:37:32 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Nov 2005 08:37:37 -0800 (PST) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jA3GbVO0025684 for ; Thu, 3 Nov 2005 08:37:32 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [198.149.16.14]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id jA3HgrRB023621 for ; Thu, 3 Nov 2005 09:42:53 -0800 Received: from [128.162.232.50] (stout.americas.sgi.com [128.162.232.50]) by ledzep.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id jA3GYGsL24723656; Thu, 3 Nov 2005 10:34:16 -0600 (CST) Message-ID: <436A3C07.20402@sgi.com> Date: Thu, 03 Nov 2005 10:34:15 -0600 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0.6-1.1.fc4 (X11/20050720) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Renaat Dumon CC: linux-xfs@oss.sgi.com Subject: Re: XFS corruption on 2.4.28 References: <20051103112237.5C045177612@postit.belbone.be> In-Reply-To: <20051103112237.5C045177612@postit.belbone.be> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6508 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 842 Lines: 25 Renaat Dumon wrote: > Hi Eric, > > I've put the parameters back, and had a contact with one the "platform" guys > of my vendor. > > When I asked if he could think of something to explain the fact that > apparently only the small .db files were affected, he wasn't sure. But he > did mention these files where designed to be this small, so they could be > stored on disk in meta-data only. While I don't know what this really means, > I thought I'd run this by you to see if maybe it could isolate the issue a > little bit further. It means that for very small files, the file data can be stored in the disk inode itself, rather than in an extent outside the inode. Not a bad idea. If you're in touch w/ the vendor, perhaps you can work with him to try a stock 2.4.28 kernel, see if the problem persists. -Eric > Thanks, > > Renaat From owner-linux-xfs@oss.sgi.com Thu Nov 3 09:08:59 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Nov 2005 09:09:10 -0800 (PST) Received: from thunker.thunk.org (thunk.org [69.25.196.29]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jA3H8xO0027952 for ; Thu, 3 Nov 2005 09:08:59 -0800 Received: from root (helo=think.thunk.org) by thunker.thunk.org with local-esmtp (Exim 3.35 #1 (Debian)) id 1EXiWn-00050J-00; Thu, 03 Nov 2005 12:05:29 -0500 Received: from tytso by think.thunk.org with local (Exim 4.54) id 1EXiWl-0001s0-74; Thu, 03 Nov 2005 12:05:27 -0500 Date: Thu, 3 Nov 2005 12:05:27 -0500 From: "Theodore Ts'o" To: Alan Cox Cc: Nathan Scott , Jan Kasprzak , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: XFS information leak during crash Message-ID: <20051103170527.GA7113@thunk.org> Mail-Followup-To: Theodore Ts'o , Alan Cox , Nathan Scott , Jan Kasprzak , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com References: <20051102212722.GC6759@fi.muni.cz> <20051103101107.O6239737@wobbly.melbourne.sgi.com> <20051102233629.GD6759@fi.muni.cz> <20051103104956.B6081538@wobbly.melbourne.sgi.com> <20051103000317.GE6759@fi.muni.cz> <20051103111115.C6081538@wobbly.melbourne.sgi.com> <1131021949.18848.21.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1131021949.18848.21.camel@localhost.localdomain> User-Agent: Mutt/1.5.11 X-archive-position: 6509 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tytso@mit.edu Precedence: bulk X-list: linux-xfs Content-Length: 763 Lines: 20 On Thu, Nov 03, 2005 at 12:45:49PM +0000, Alan Cox wrote: > On Iau, 2005-11-03 at 11:11 +1100, Nathan Scott wrote: > > On Thu, Nov 03, 2005 at 01:03:17AM +0100, Jan Kasprzak wrote: > > > : it would only ever be uninitialised, previously-free space. > > > > > > Yes, but an old data from previously deleted files > > > (sendmail's temporary files, vim save files, etc) may contain > > > a sensitive information. > > > > Indeed. But this is a generic issue affecting most filesystems; > > its not specific to XFS as your original mail claimed. > > Very true. You can use ext3 in data journalling mode if this is a > concern but that guarantee has a performance cost The default ordered journalling mode solves this problem at a much lower cost. - Ted From owner-linux-xfs@oss.sgi.com Thu Nov 3 12:36:29 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Nov 2005 12:36:31 -0800 (PST) Received: from science.horizon.com (science.horizon.com [192.35.100.1]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id jA3KaRO0013331 for ; Thu, 3 Nov 2005 12:36:28 -0800 Received: (qmail 27627 invoked by uid 1000); 3 Nov 2005 15:33:13 -0500 Date: 3 Nov 2005 15:33:13 -0500 Message-ID: <20051103203313.27622.qmail@science.horizon.com> From: linux@horizon.com To: sandeen@sgi.com Subject: Re: 2.6.13.2 amd64: XFS: xlog_recover_process_data: bad clientid Cc: linux@horizon.com, linux-xfs@oss.sgi.com In-Reply-To: <20051102221800.16064.qmail@science.horizon.com> X-archive-position: 6510 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: linux@horizon.com Precedence: bulk X-list: linux-xfs Content-Length: 6481 Lines: 164 Ah! The *second* xfs_repair run ended in a segfault.... (xfs_repair version 2.6.36, debian package xfsprogs 2.6.36-1) I'm trying a third... # xfs_repair /dev/md4 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 imap claims a free inode 129571903 is in use, correcting imap and clearing inode cleared inode 129571903 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 no .. entry for directory 313303087 - agno = 10 - agno = 11 no .. entry for directory 386031650 mismatch between format (2) and size (0) in directory ino 386031671 cleared inode 386031671 - agno = 12 entry "/." at block 0 offset 32 in directory inode 424609817 references invalid inode 18374686479671623679 clearing inode number in entry at offset 32... entry at block 0 offset 32 in directory inode 424609817 has illegal name "/.": no .. entry for directory 424609817 entry "/." at block 0 offset 32 in directory inode 424609838 references invalid inode 18374686479671623679 clearing inode number in entry at offset 32... entry at block 0 offset 32 in directory inode 424609838 has illegal name "/.": entry "/alpha" at block 0 offset 72 in directory inode 424609838 references invalid inode 18374686479671623679 clearing inode number in entry at offset 72... entry at block 0 offset 72 in directory inode 424609838 has illegal name "/alpha": entry "/arm" at block 0 offset 112 in directory inode 424609838 references invalid inode 18374686479671623679 clearing inode number in entry at offset 112... entry at block 0 offset 112 in directory inode 424609838 has illegal name "/arm": entry "/c4x" at block 0 offset 144 in directory inode 424609838 references invalid inode 18374686479671623679 clearing inode number in entry at offset 144... entry at block 0 offset 144 in directory inode 424609838 has illegal name "/c4x": entry "/frv" at block 0 offset 648 in directory inode 424609838 references invalid inode 18374686479671623679 clearing inode number in entry at offset 648... entry at block 0 offset 648 in directory inode 424609838 has illegal name "/frv": entry "/i386" at block 0 offset 752 in directory inode 424609838 references invalid inode 18374686479671623679 clearing inode number in entry at offset 752... entry at block 0 offset 752 in directory inode 424609838 has illegal name "/i386": no .. entry for directory 424609838 - agno = 13 - agno = 14 - agno = 15 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - clear lost+found (if it exists) ... - clearing existing "lost+found" inode - marking entry "lost+found" to be deleted - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 no .. entry for directory 313303087 - agno = 10 - agno = 11 - agno = 12 no .. entry for directory 424609817 entry "fcris" at block 0 offset 184 in directory inode 424609838 references free inode 129571903 clearing inode number in entry at offset 184... entry "fh8300" at block 0 offset 712 in directory inode 424609838 references free inode 386031671 clearing inode number in entry at offset 712... no .. entry for directory 424609838 - 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 1024 - traversal finished ... - traversing all unattached subtrees ... rebuilding directory inode 424609817 rebuilding directory inode 424609838 corrupt block 0 in directory inode 424609839: junking block Segmentation fault Run number 3 actually finished... # xfs_repair /dev/md4 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 no .. entry for directory 313303087 - agno = 10 - agno = 11 no .. entry for directory 386031650 - agno = 12 no .. entry for directory 424609817 no .. entry for directory 424609838 mismatch between format (2) and size (0) in directory ino 424609839 cleared inode 424609839 - agno = 13 - agno = 14 - agno = 15 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - clear lost+found (if it exists) ... - clearing existing "lost+found" inode - marking entry "lost+found" to be deleted - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 no .. entry for directory 313303087 - agno = 10 [missed some here] resetting inode 278955071 nlinks from 9 to 8 resetting inode 278958082 nlinks from 9 to 8 resetting inode 278958083 nlinks from 7 to 6 resetting inode 278958084 nlinks from 7 to 6 resetting inode 278958085 nlinks from 7 to 6 resetting inode 278958086 nlinks from 7 to 6 resetting inode 278958087 nlinks from 7 to 6 [...] resetting inode 515270696 nlinks from 5 to 6 resetting inode 515270697 nlinks from 3 to 4 resetting inode 515270710 nlinks from 3 to 4 resetting inode 523361301 nlinks from 17 to 16 done From owner-linux-xfs@oss.sgi.com Thu Nov 3 13:34:37 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 03 Nov 2005 13:34:45 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id jA3LYZO0016787 for ; Thu, 3 Nov 2005 13:34:36 -0800 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA13407; Fri, 4 Nov 2005 08:31:16 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 6ABB849E5EF0; Fri, 4 Nov 2005 08:31:15 +1100 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: PARTIAL TAKE 945242 - fix inode32 mode Message-Id: <20051103213115.6ABB849E5EF0@chook.melbourne.sgi.com> Date: Fri, 4 Nov 2005 08:31:15 +1100 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 6511 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 573 Lines: 15 Fix an inode32 regression - if no options are presented, must still set default flags. Thanks to Chris Pascoe for finding and fixing. Date: Fri Nov 4 08:30:01 AEDT 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: Christopher Pascoe The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:24292a xfs_vfsops.c - 1.485 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vfsops.c.diff?r1=text&tr1=1.485&r2=text&tr2=1.484&f=h From owner-linux-xfs@oss.sgi.com Fri Nov 4 07:23:35 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 04 Nov 2005 07:23:40 -0800 (PST) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jA4FNYO0016452 for ; Fri, 4 Nov 2005 07:23:34 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [198.149.16.14]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id jA4FKIxT020004 for ; Fri, 4 Nov 2005 09:20:19 -0600 Received: from [128.162.232.50] (stout.americas.sgi.com [128.162.232.50]) by ledzep.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id jA4FKFsL24785165; Fri, 4 Nov 2005 09:20:15 -0600 (CST) Message-ID: <436B7C2E.1000304@sgi.com> Date: Fri, 04 Nov 2005 09:20:14 -0600 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0.6-1.1.fc4 (X11/20050720) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Elston CC: linux-xfs@oss.sgi.com, nathans@sgi.com, jchapman@katalix.com Subject: Re: [PATCH] Re: Files >4GB in XFS realtime partition References: <200510311812.j9VICiO0030280@oss.sgi.com> In-Reply-To: <200510311812.j9VICiO0030280@oss.sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6513 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 423 Lines: 16 Chris Elston wrote: > See > http://marc.theaimsgroup.com/?t=111642565400004&r=1&w=2 > for original report. Did you guys ever try the xfs_io sequence as suggested by Nathan in that original report? It passed for Nathan on x86; maybe you guys can try it on your mips rig too, just to satisfy our curiosity. I'll go stare at code a bit today, too, try to convince myself that your patch is correct. :) Thanks, -Eric From owner-linux-xfs@oss.sgi.com Fri Nov 4 11:22:02 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 04 Nov 2005 11:22:07 -0800 (PST) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jA4JM2O0001346 for ; Fri, 4 Nov 2005 11:22:02 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id jA4KRXLF006174 for ; Fri, 4 Nov 2005 12:27:33 -0800 Received: from [128.162.232.50] (stout.americas.sgi.com [128.162.232.50]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id jA4JHhDN19208798; Fri, 4 Nov 2005 13:17:43 -0600 (CST) Message-ID: <436BB3D7.10601@sgi.com> Date: Fri, 04 Nov 2005 13:17:43 -0600 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0.6-1.1.fc4 (X11/20050720) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Elston CC: linux-xfs@oss.sgi.com, nathans@sgi.com, jchapman@katalix.com Subject: Re: [PATCH] Re: Files >4GB in XFS realtime partition References: <200510311812.j9VICiO0030280@oss.sgi.com> In-Reply-To: <200510311812.j9VICiO0030280@oss.sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6514 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 809 Lines: 18 Chris Elston wrote: --- TDC775-2.4.29/fs/xfs/xfs_iomap.h 2005-10-31 15:37:54.000000000 +0000 > +++ PATCHED/fs/xfs/xfs_iomap.h 2005-10-31 15:18:29.000000000 +0000 > @@ -86,7 +86,7 @@ > xfs_buftarg_t *iomap_target; > loff_t iomap_offset; /* offset of mapping, bytes */ > loff_t iomap_bsize; /* size of mapping, bytes */ > - size_t iomap_delta; /* offset into mapping, bytes */ > + loff_t iomap_delta; /* offset into mapping, bytes */ > iomap_flags_t iomap_flags; > } xfs_iomap_t; Yep, I agree that this is correct. The way I was trying to expose it wasn't quite the right approach, but as I traced it through it's pretty obviously correct. Thanks! -Eric From owner-linux-xfs@oss.sgi.com Fri Nov 4 14:36:34 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 04 Nov 2005 14:36:39 -0800 (PST) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jA4MaXO0015593 for ; Fri, 4 Nov 2005 14:36:34 -0800 Received: from internal-mail-relay.corp.sgi.com (internal-mail-relay.corp.sgi.com [198.149.32.51]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id jA4MXIxT029891 for ; Fri, 4 Nov 2005 16:33:18 -0600 Received: from naboo.americas.sgi.com (naboo.americas.sgi.com [128.162.233.73]) by internal-mail-relay.corp.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id jA4MXH2Z282498900; Fri, 4 Nov 2005 14:33:18 -0800 (PST) Received: from naboo.americas.sgi.com (localhost [127.0.0.1]) by naboo.americas.sgi.com (8.13.3/8.13.3) with ESMTP id jA4MXHAB031069; Fri, 4 Nov 2005 16:33:17 -0600 Received: (from hch@localhost) by naboo.americas.sgi.com (8.13.3/8.13.3/Submit) id jA4MXHGQ031068; Fri, 4 Nov 2005 16:33:17 -0600 Date: Fri, 4 Nov 2005 16:33:17 -0600 From: Christoph Hellwig Message-Id: <200511042233.jA4MXHGQ031068@naboo.americas.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Subject: TAKE 941804 - remove over-eager assert X-archive-position: 6515 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@relay.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 520 Lines: 16 Date: Fri Nov 4 14:33:06 PST 2005 Workarea: naboo.americas.sgi.com:/go/space/hch/xfs-2.6.x Inspected by: yingping The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: xfs-linux:xfs-kern:201702a fs/xfs/xfs_vnodeops.c - 1.656 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vnodeops.c.diff?r1=text&tr1=1.656&r2=text&tr2=1.655&f=h - i_mapping.nrpages may be non-zero for device inodes. the vfs already checks i_data.nrpages which is what we care about. From owner-linux-xfs@oss.sgi.com Fri Nov 4 15:50:05 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 04 Nov 2005 15:50:08 -0800 (PST) Received: from science.horizon.com (science.horizon.com [192.35.100.1]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id jA4No3O0019248 for ; Fri, 4 Nov 2005 15:50:04 -0800 Received: (qmail 10452 invoked by uid 1000); 4 Nov 2005 18:46:48 -0500 Date: 4 Nov 2005 18:46:48 -0500 Message-ID: <20051104234648.10451.qmail@science.horizon.com> From: linux@horizon.com To: linux-xfs@oss.sgi.com Subject: Should xfs_repair make xfs_check stop complaining? Cc: linux@horizon.com In-Reply-To: <20051103203313.27622.qmail@science.horizon.com> X-archive-position: 6516 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: linux@horizon.com Precedence: bulk X-list: linux-xfs Content-Length: 17703 Lines: 378 Um, just wondering... I have a file system, on which I have run xfs_repair six times, and xfs_check still has complaints about it. I understand the xfs_repair rebuilds lost+found every time, so it keeps finding unreferenced files, but xfs_repair keeps fixing things like > resetting inode 335565855 nlinks from 14 to 15 but leaves the subsequent inodes for xfs_check to complain about: > link count mismatch for inode 335565856 (name ?), nlink 14, counted 15 > link count mismatch for inode 335565857 (name ?), nlink 14, counted 15 Note that they're NOT the same inode number, so it's as if xfs_repair is missing some problems. Looking at the multiple runs, I see different inode numbers each time. xfs_repair and xfs_db are both version 2.6.36. Is this normal behaviour? I'm used to e2fsck which complains loudly if it leaves uncorrected errors. xfs_repair (#6) said: 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) ... - clearing existing "lost+found" inode - marking entry "lost+found" to be deleted - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - 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 1024 - traversal finished ... - traversing all unattached subtrees ... - traversals finished ... - moving disconnected inodes to lost+found ... disconnected dir inode 15509532, moving to lost+found disconnected dir inode 15509538, moving to lost+found disconnected inode 33556494, moving to lost+found disconnected dir inode 51346432, moving to lost+found disconnected dir inode 51346437, moving to lost+found disconnected inode 67238927, moving to lost+found disconnected inode 67263492, moving to lost+found disconnected inode 67263493, moving to lost+found disconnected dir inode 84868125, moving to lost+found disconnected dir inode 129571895, moving to lost+found disconnected inode 167868474, moving to lost+found disconnected inode 167868477, moving to lost+found disconnected inode 167868479, moving to lost+found disconnected inode 167869440, moving to lost+found disconnected inode 167869442, moving to lost+found disconnected inode 167869444, moving to lost+found disconnected inode 167869445, moving to lost+found disconnected inode 167869449, moving to lost+found disconnected inode 167869454, moving to lost+found disconnected inode 193486865, moving to lost+found disconnected dir inode 287203344, moving to lost+found disconnected dir inode 313303087, moving to lost+found disconnected dir inode 349614088, moving to lost+found disconnected dir inode 386031650, moving to lost+found disconnected dir inode 386031670, moving to lost+found disconnected inode 402863163, moving to lost+found disconnected dir inode 424609813, moving to lost+found disconnected dir inode 424609817, moving to lost+found disconnected dir inode 424609838, moving to lost+found disconnected dir inode 486566967, moving to lost+found Phase 7 - verify and correct link counts... resetting inode 47615030 nlinks from 9 to 10 resetting inode 72902656 nlinks from 3 to 4 resetting inode 72902657 nlinks from 3 to 4 resetting inode 72902658 nlinks from 3 to 4 resetting inode 72902659 nlinks from 3 to 4 resetting inode 72902660 nlinks from 3 to 4 resetting inode 72902661 nlinks from 3 to 4 resetting inode 72902662 nlinks from 3 to 4 resetting inode 72902663 nlinks from 3 to 4 resetting inode 72902664 nlinks from 3 to 4 resetting inode 72902665 nlinks from 3 to 4 resetting inode 72902666 nlinks from 3 to 4 resetting inode 72902667 nlinks from 3 to 4 resetting inode 72902668 nlinks from 3 to 4 resetting inode 72902669 nlinks from 3 to 4 resetting inode 72902670 nlinks from 3 to 4 resetting inode 72902671 nlinks from 3 to 4 resetting inode 72902672 nlinks from 3 to 4 resetting inode 72902673 nlinks from 3 to 4 resetting inode 72902674 nlinks from 3 to 4 resetting inode 72902675 nlinks from 3 to 4 resetting inode 72902676 nlinks from 3 to 4 resetting inode 72902677 nlinks from 3 to 4 resetting inode 72902678 nlinks from 3 to 4 resetting inode 72902679 nlinks from 3 to 4 resetting inode 72902680 nlinks from 3 to 4 resetting inode 72902681 nlinks from 3 to 4 resetting inode 72902682 nlinks from 3 to 4 resetting inode 72902683 nlinks from 3 to 4 resetting inode 72902684 nlinks from 3 to 4 resetting inode 72902685 nlinks from 3 to 4 resetting inode 72902686 nlinks from 3 to 4 resetting inode 72902687 nlinks from 3 to 4 resetting inode 302496781 nlinks from 14 to 15 resetting inode 302496782 nlinks from 20 to 21 resetting inode 302496783 nlinks from 20 to 21 resetting inode 302496784 nlinks from 14 to 15 resetting inode 302496785 nlinks from 20 to 21 resetting inode 302496786 nlinks from 20 to 21 resetting inode 302496787 nlinks from 14 to 15 resetting inode 302496788 nlinks from 20 to 21 resetting inode 302496789 nlinks from 14 to 15 resetting inode 335565855 nlinks from 14 to 15 done and xfs_check then said: block 2/262 expected type unknown got free2 block 2/263 expected type unknown got free2 block 2/264 expected type unknown got free2 block 2/265 expected type unknown got free2 block 2/266 expected type unknown got free2 block 2/158606 expected type unknown got free2 link count mismatch for inode 9521204 (name ?), nlink 18, counted 17 link count mismatch for inode 9521206 (name ?), nlink 18, counted 17 link count mismatch for inode 9521207 (name ?), nlink 18, counted 17 link count mismatch for inode 8159262 (name ?), nlink 2277, counted 2278 link count mismatch for inode 4295701 (name ?), nlink 13, counted 12 link count mismatch for inode 4295702 (name ?), nlink 13, counted 12 link count mismatch for inode 4295703 (name ?), nlink 11, counted 10 link count mismatch for inode 4295705 (name ?), nlink 13, counted 12 link count mismatch for inode 37956638 (name ?), nlink 3, counted 4 link count mismatch for inode 37956639 (name ?), nlink 3, counted 4 link count mismatch for inode 47756317 (name ?), nlink 57, counted 62 link count mismatch for inode 47756319 (name ?), nlink 14, counted 15 link count mismatch for inode 39545890 (name ?), nlink 149, counted 150 link count mismatch for inode 47281154 (name ?), nlink 16, counted 17 link count mismatch for inode 36780063 (name ?), nlink 2, counted 3 link count mismatch for inode 67423241 (name ?), nlink 445, counted 448 link count mismatch for inode 72395795 (name ?), nlink 6, counted 7 link count mismatch for inode 72395796 (name ?), nlink 10, counted 11 link count mismatch for inode 72395799 (name ?), nlink 6, counted 7 link count mismatch for inode 72395800 (name ?), nlink 6, counted 7 link count mismatch for inode 72395801 (name ?), nlink 6, counted 7 link count mismatch for inode 72395802 (name ?), nlink 6, counted 7 link count mismatch for inode 72395803 (name ?), nlink 8, counted 9 link count mismatch for inode 107157534 (name ?), nlink 8, counted 9 link count mismatch for inode 107157541 (name ?), nlink 3, counted 4 link count mismatch for inode 107157542 (name ?), nlink 3, counted 4 link count mismatch for inode 107157543 (name ?), nlink 3, counted 4 link count mismatch for inode 107157544 (name ?), nlink 3, counted 4 link count mismatch for inode 107157545 (name ?), nlink 3, counted 4 link count mismatch for inode 107157546 (name ?), nlink 3, counted 4 link count mismatch for inode 107157547 (name ?), nlink 3, counted 4 link count mismatch for inode 107157548 (name ?), nlink 3, counted 4 link count mismatch for inode 107157550 (name ?), nlink 3, counted 4 link count mismatch for inode 109702154 (name ?), nlink 3, counted 4 link count mismatch for inode 109702156 (name ?), nlink 5, counted 6 link count mismatch for inode 109702157 (name ?), nlink 5, counted 6 link count mismatch for inode 109702158 (name ?), nlink 5, counted 6 link count mismatch for inode 109702159 (name ?), nlink 3, counted 4 link count mismatch for inode 144276493 (name ?), nlink 24, counted 25 link count mismatch for inode 144276494 (name ?), nlink 24, counted 25 link count mismatch for inode 144276495 (name ?), nlink 24, counted 25 link count mismatch for inode 144920600 (name ?), nlink 6, counted 7 link count mismatch for inode 144920601 (name ?), nlink 8, counted 9 link count mismatch for inode 144920607 (name ?), nlink 6, counted 7 link count mismatch for inode 144920608 (name ?), nlink 6, counted 7 link count mismatch for inode 144920609 (name ?), nlink 8, counted 9 link count mismatch for inode 144058403 (name ?), nlink 9, counted 10 link count mismatch for inode 241771561 (name ?), nlink 3, counted 4 link count mismatch for inode 240273428 (name ?), nlink 7, counted 6 link count mismatch for inode 240273430 (name ?), nlink 9, counted 8 link count mismatch for inode 240273431 (name ?), nlink 7, counted 6 link count mismatch for inode 240273432 (name ?), nlink 9, counted 8 link count mismatch for inode 240273433 (name ?), nlink 9, counted 8 link count mismatch for inode 240273434 (name ?), nlink 9, counted 8 link count mismatch for inode 240273435 (name ?), nlink 7, counted 6 link count mismatch for inode 240273436 (name ?), nlink 9, counted 8 link count mismatch for inode 240273437 (name ?), nlink 7, counted 6 link count mismatch for inode 240273438 (name ?), nlink 9, counted 8 link count mismatch for inode 240273439 (name ?), nlink 9, counted 8 link count mismatch for inode 346406949 (name ?), nlink 3, counted 4 link count mismatch for inode 340941885 (name ?), nlink 10, counted 11 link count mismatch for inode 340941886 (name ?), nlink 10, counted 11 link count mismatch for inode 343417900 (name ?), nlink 18, counted 17 link count mismatch for inode 343417902 (name ?), nlink 16, counted 15 link count mismatch for inode 340957216 (name ?), nlink 10, counted 11 link count mismatch for inode 340957217 (name ?), nlink 10, counted 11 link count mismatch for inode 335565856 (name ?), nlink 14, counted 15 link count mismatch for inode 335565857 (name ?), nlink 14, counted 15 link count mismatch for inode 383432717 (name ?), nlink 18, counted 17 link count mismatch for inode 383432719 (name ?), nlink 18, counted 17 link count mismatch for inode 424606730 (name ?), nlink 16, counted 18 link count mismatch for inode 414889995 (name ?), nlink 17, counted 18 link count mismatch for inode 414889996 (name ?), nlink 17, counted 18 link count mismatch for inode 414889998 (name ?), nlink 17, counted 18 link count mismatch for inode 414889999 (name ?), nlink 17, counted 18 link count mismatch for inode 404029469 (name ?), nlink 15, counted 16 link count mismatch for inode 410588170 (name ?), nlink 4, counted 3 link count mismatch for inode 442877964 (name ?), nlink 94, counted 95 link count mismatch for inode 441138178 (name ?), nlink 4, counted 3 link count mismatch for inode 441138180 (name ?), nlink 4, counted 3 link count mismatch for inode 437784616 (name ?), nlink 17, counted 18 link count mismatch for inode 473682976 (name ?), nlink 13, counted 12 link count mismatch for inode 473682978 (name ?), nlink 13, counted 12 link count mismatch for inode 473682979 (name ?), nlink 13, counted 12 link count mismatch for inode 473682980 (name ?), nlink 13, counted 12 link count mismatch for inode 473682981 (name ?), nlink 13, counted 12 link count mismatch for inode 473682982 (name ?), nlink 13, counted 12 link count mismatch for inode 477552672 (name ?), nlink 4, counted 3 link count mismatch for inode 477552673 (name ?), nlink 4, counted 3 link count mismatch for inode 477552674 (name ?), nlink 4, counted 3 link count mismatch for inode 477552675 (name ?), nlink 4, counted 3 link count mismatch for inode 477552676 (name ?), nlink 4, counted 3 link count mismatch for inode 477552677 (name ?), nlink 4, counted 3 link count mismatch for inode 477552678 (name ?), nlink 4, counted 3 link count mismatch for inode 477552679 (name ?), nlink 4, counted 3 link count mismatch for inode 477552680 (name ?), nlink 4, counted 3 link count mismatch for inode 477552681 (name ?), nlink 4, counted 3 link count mismatch for inode 477552682 (name ?), nlink 4, counted 3 link count mismatch for inode 477552683 (name ?), nlink 4, counted 3 link count mismatch for inode 477580336 (name ?), nlink 4, counted 3 link count mismatch for inode 473673741 (name ?), nlink 7, counted 8 link count mismatch for inode 514965508 (name ?), nlink 16, counted 15 link count mismatch for inode 514610208 (name ?), nlink 3, counted 4 link count mismatch for inode 514610209 (name ?), nlink 3, counted 4 If it helps, the output of xfs_repair #5 was: 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) ... - clearing existing "lost+found" inode - marking entry "lost+found" to be deleted - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - 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 1024 - traversal finished ... - traversing all unattached subtrees ... - traversals finished ... - moving disconnected inodes to lost+found ... disconnected dir inode 15509532, moving to lost+found disconnected dir inode 15509538, moving to lost+found disconnected inode 33556494, moving to lost+found disconnected dir inode 51346432, moving to lost+found disconnected dir inode 51346437, moving to lost+found disconnected inode 67238927, moving to lost+found disconnected inode 67263492, moving to lost+found disconnected inode 67263493, moving to lost+found disconnected dir inode 84868125, moving to lost+found disconnected dir inode 129571895, moving to lost+found disconnected inode 167868474, moving to lost+found disconnected inode 167868477, moving to lost+found disconnected inode 167868479, moving to lost+found disconnected inode 167869440, moving to lost+found disconnected inode 167869442, moving to lost+found disconnected inode 167869444, moving to lost+found disconnected inode 167869445, moving to lost+found disconnected inode 167869449, moving to lost+found disconnected inode 167869454, moving to lost+found disconnected inode 193486865, moving to lost+found disconnected dir inode 287203344, moving to lost+found disconnected dir inode 313303087, moving to lost+found disconnected dir inode 349614088, moving to lost+found disconnected dir inode 386031650, moving to lost+found disconnected dir inode 386031670, moving to lost+found disconnected inode 402863163, moving to lost+found disconnected dir inode 424609813, moving to lost+found disconnected dir inode 424609817, moving to lost+found disconnected dir inode 424609838, moving to lost+found disconnected dir inode 486566967, moving to lost+found Phase 7 - verify and correct link counts... resetting inode 47756320 nlinks from 14 to 15 resetting inode 47756332 nlinks from 14 to 15 resetting inode 47756342 nlinks from 14 to 15 resetting inode 47756345 nlinks from 40 to 43 resetting inode 47756350 nlinks from 27 to 29 resetting inode 201775157 nlinks from 14 to 15 resetting inode 201775158 nlinks from 14 to 15 resetting inode 269022216 nlinks from 9 to 10 resetting inode 269022217 nlinks from 9 to 10 resetting inode 269099015 nlinks from 9 to 10 resetting inode 269099016 nlinks from 9 to 10 resetting inode 269415486 nlinks from 9 to 10 done From owner-linux-xfs@oss.sgi.com Fri Nov 4 17:07:31 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 04 Nov 2005 17:07:33 -0800 (PST) Received: from smtp.well.com (smtp.well.com [206.80.4.7]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jA517UO0027606 for ; Fri, 4 Nov 2005 17:07:30 -0800 X-WELL-Auth: Yes Received: from well.com (well.com [206.80.4.5]) by smtp.well.com (8.13.5/8.13.5) with ESMTP id jA514Fco026014 for ; Fri, 4 Nov 2005 17:04:15 -0800 (PST) Date: Fri, 4 Nov 2005 17:04:15 -0800 (PST) From: Neil Harkins To: linux-xfs@oss.sgi.com Subject: xfsdump, the journal, and incremental dumps of subtrees... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 6517 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nharkins@well.com Precedence: bulk X-list: linux-xfs Content-Length: 743 Lines: 21 Hi. New to list, and didn't find an answer in the FAQ, or a quick search of the archive, sorry if this resurrects a horse: Does xfsdump -l use the journal to determine what's changed for an incremental dump? Background: I'm currently using rsync to perform incremental updates of a subtree with a significant number of files, when only about 5% changes, and the filesystem walk to check each file's timestamp is totally unnecessary if the journal can be consulted. If xfsdump uses the journal to avoid the walk, then using xfsdump | xfsrestore would be ideal, except according to the man page, it doesn't allow incrementals of subtrees. :( Could someone explain why that is the case? Thanks in advance for any insight, -neil From owner-linux-xfs@oss.sgi.com Fri Nov 4 17:56:54 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 04 Nov 2005 17:56:58 -0800 (PST) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jA51usO0029755 for ; Fri, 4 Nov 2005 17:56:54 -0800 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 jA532R9L006679 for ; Fri, 4 Nov 2005 19:02:27 -0800 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 jA51rcOS3188789; Fri, 4 Nov 2005 17:53:38 -0800 (PST) Message-ID: <436C10A1.6000802@sgi.com> Date: Fri, 04 Nov 2005 19:53:37 -0600 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux@horizon.com CC: linux-xfs@oss.sgi.com Subject: Re: Should xfs_repair make xfs_check stop complaining? References: <20051104234648.10451.qmail@science.horizon.com> In-Reply-To: <20051104234648.10451.qmail@science.horizon.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6518 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1112 Lines: 32 linux@horizon.com wrote: > Um, just wondering... I have a file system, on which I have run xfs_repair > six times, and xfs_check still has complaints about it. > > I understand the xfs_repair rebuilds lost+found every time, so it > keeps finding unreferenced files, but xfs_repair keeps fixing things like > >>resetting inode 335565855 nlinks from 14 to 15 > > > but leaves the subsequent inodes for xfs_check to complain about: > >>link count mismatch for inode 335565856 (name ?), nlink 14, counted 15 >>link count mismatch for inode 335565857 (name ?), nlink 14, counted 15 > > > Note that they're NOT the same inode number, so it's as if xfs_repair is missing > some problems. Looking at the multiple runs, I see different inode numbers each > time. > > xfs_repair and xfs_db are both version 2.6.36. > > Is this normal behaviour? I'm used to e2fsck which complains loudly if > it leaves uncorrected errors. Try moving lost+found to somewhere else, /lost+found2 or something, and re-run xfs_repair. Do problems still persist? Also that xfs_repair is not the -very- latest version.... -Eric From owner-linux-xfs@oss.sgi.com Fri Nov 4 18:40:32 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 04 Nov 2005 18:40:38 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id jA52eUO0032351 for ; Fri, 4 Nov 2005 18:40:31 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA18015; Sat, 5 Nov 2005 13:37:10 +1100 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id jA52bNkt6313791; Sat, 5 Nov 2005 13:37:24 +1100 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id jA52bMTb6350362; Sat, 5 Nov 2005 13:37:22 +1100 (EST) Date: Sat, 5 Nov 2005 13:37:22 +1100 From: Nathan Scott To: Neil Harkins Cc: linux-xfs@oss.sgi.com Subject: Re: xfsdump, the journal, and incremental dumps of subtrees... Message-ID: <20051105133722.A6350193@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 nharkins@well.com on Fri, Nov 04, 2005 at 05:04:15PM -0800 X-archive-position: 6519 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1024 Lines: 31 On Fri, Nov 04, 2005 at 05:04:15PM -0800, Neil Harkins wrote: > > Hi. New to list, and didn't find an answer in the FAQ, or > a quick search of the archive, sorry if this resurrects a horse: > > Does xfsdump -l use the journal to determine what's changed > for an incremental dump? No, the journal doesnt hold the sort of information needed to make decisions related to incremental dumps (its a circular log, not what you're thinking). > Background: I'm currently using rsync to perform incremental updates > of a subtree with a significant number of files, when only about 5% > changes, and the filesystem walk to check each file's timestamp > is totally unnecessary if the journal can be consulted. It cannot. > If xfsdump uses the journal to avoid the walk, then using > xfsdump | xfsrestore would be ideal, except according to > the man page, it doesn't allow incrementals of subtrees. :( > Could someone explain why that is the case? Not sure about that one off the top of my head. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Fri Nov 4 19:31:03 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 04 Nov 2005 19:31:06 -0800 (PST) Received: from science.horizon.com (science.horizon.com [192.35.100.1]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id jA53V2O0002995 for ; Fri, 4 Nov 2005 19:31:02 -0800 Received: (qmail 5543 invoked by uid 1000); 4 Nov 2005 22:27:47 -0500 Date: 4 Nov 2005 22:27:47 -0500 Message-ID: <20051105032747.5542.qmail@science.horizon.com> From: linux@horizon.com To: linux@horizon.com, sandeen@sgi.com Subject: Re: Should xfs_repair make xfs_check stop complaining? Cc: linux-xfs@oss.sgi.com In-Reply-To: <436C10A1.6000802@sgi.com> X-archive-position: 6520 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: linux@horizon.com Precedence: bulk X-list: linux-xfs Content-Length: 630 Lines: 19 > Try moving lost+found to somewhere else, /lost+found2 or something, and > re-run xfs_repair. Do problems still persist? Er... does this imply that I should try to mount the file system? I haven't been doing that until it checks out clean. Or is there some other way to rename the lost+found directory? > Also that xfs_repair is not the -very- latest version.... Should I try 2.7.3 or something else? Confusingly, the "latest" and "Release-1.3.1" directories hold 2.5.6, "testing" holds 2.6.4 and 2.6.13 and it's the plain ftp://oss.sgi.com/projects/xfs/cmd_tars directory which holds 2.7.3. Thanks a lot for your help! From owner-linux-xfs@oss.sgi.com Fri Nov 4 22:25:06 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 04 Nov 2005 22:25:09 -0800 (PST) Received: from science.horizon.com (science.horizon.com [192.35.100.1]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id jA56P5O0014200 for ; Fri, 4 Nov 2005 22:25:06 -0800 Received: (qmail 28466 invoked by uid 1000); 5 Nov 2005 01:21:49 -0500 Date: 5 Nov 2005 01:21:49 -0500 Message-ID: <20051105062149.28459.qmail@science.horizon.com> From: linux@horizon.com To: linux@horizon.com, sandeen@sgi.com Subject: Re: Should xfs_repair make xfs_check stop complaining? Cc: linux-xfs@oss.sgi.com In-Reply-To: <436C10A1.6000802@sgi.com> X-archive-position: 6521 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: linux@horizon.com Precedence: bulk X-list: linux-xfs Content-Length: 8245 Lines: 132 > Also that xfs_repair is not the -very- latest version.... Well, xfsprogs 2.7.3 produces a much cleaner xfs_repair output, with no link count messages in phase 7, but xfs_check still thinks there's something wrong: # xfs_check /dev/md4 block 2/262 expected type unknown got free2 block 2/263 expected type unknown got free2 block 2/264 expected type unknown got free2 block 2/265 expected type unknown got free2 block 2/266 expected type unknown got free2 block 2/158606 expected type unknown got free2 link count mismatch for inode 9521204 (name ?), nlink 18, counted 17 link count mismatch for inode 9521206 (name ?), nlink 18, counted 17 link count mismatch for inode 9521207 (name ?), nlink 18, counted 17 link count mismatch for inode 8159262 (name ?), nlink 2277, counted 2278 link count mismatch for inode 4295701 (name ?), nlink 13, counted 12 link count mismatch for inode 4295702 (name ?), nlink 13, counted 12 link count mismatch for inode 4295703 (name ?), nlink 11, counted 10 link count mismatch for inode 4295705 (name ?), nlink 13, counted 12 link count mismatch for inode 37956638 (name ?), nlink 3, counted 4 link count mismatch for inode 37956639 (name ?), nlink 3, counted 4 link count mismatch for inode 47756317 (name ?), nlink 57, counted 62 link count mismatch for inode 47756319 (name ?), nlink 14, counted 15 link count mismatch for inode 39545890 (name ?), nlink 149, counted 150 link count mismatch for inode 47281154 (name ?), nlink 16, counted 17 link count mismatch for inode 36780063 (name ?), nlink 2, counted 3 link count mismatch for inode 67423241 (name ?), nlink 445, counted 448 link count mismatch for inode 72395795 (name ?), nlink 6, counted 7 link count mismatch for inode 72395796 (name ?), nlink 10, counted 11 link count mismatch for inode 72395799 (name ?), nlink 6, counted 7 link count mismatch for inode 72395800 (name ?), nlink 6, counted 7 link count mismatch for inode 72395801 (name ?), nlink 6, counted 7 link count mismatch for inode 72395802 (name ?), nlink 6, counted 7 link count mismatch for inode 72395803 (name ?), nlink 8, counted 9 link count mismatch for inode 107157534 (name ?), nlink 8, counted 9 link count mismatch for inode 107157541 (name ?), nlink 3, counted 4 link count mismatch for inode 107157542 (name ?), nlink 3, counted 4 link count mismatch for inode 107157543 (name ?), nlink 3, counted 4 link count mismatch for inode 107157544 (name ?), nlink 3, counted 4 link count mismatch for inode 107157545 (name ?), nlink 3, counted 4 link count mismatch for inode 107157546 (name ?), nlink 3, counted 4 link count mismatch for inode 107157547 (name ?), nlink 3, counted 4 link count mismatch for inode 107157548 (name ?), nlink 3, counted 4 link count mismatch for inode 107157550 (name ?), nlink 3, counted 4 link count mismatch for inode 109702154 (name ?), nlink 3, counted 4 link count mismatch for inode 109702156 (name ?), nlink 5, counted 6 link count mismatch for inode 109702157 (name ?), nlink 5, counted 6 link count mismatch for inode 109702158 (name ?), nlink 5, counted 6 link count mismatch for inode 109702159 (name ?), nlink 3, counted 4 link count mismatch for inode 144276493 (name ?), nlink 24, counted 25 link count mismatch for inode 144276494 (name ?), nlink 24, counted 25 link count mismatch for inode 144276495 (name ?), nlink 24, counted 25 link count mismatch for inode 144920600 (name ?), nlink 6, counted 7 link count mismatch for inode 144920601 (name ?), nlink 8, counted 9 link count mismatch for inode 144920607 (name ?), nlink 6, counted 7 link count mismatch for inode 144920608 (name ?), nlink 6, counted 7 link count mismatch for inode 144920609 (name ?), nlink 8, counted 9 link count mismatch for inode 144058403 (name ?), nlink 9, counted 10 link count mismatch for inode 241771561 (name ?), nlink 3, counted 4 link count mismatch for inode 240273428 (name ?), nlink 7, counted 6 link count mismatch for inode 240273430 (name ?), nlink 9, counted 8 link count mismatch for inode 240273431 (name ?), nlink 7, counted 6 link count mismatch for inode 240273432 (name ?), nlink 9, counted 8 link count mismatch for inode 240273433 (name ?), nlink 9, counted 8 link count mismatch for inode 240273434 (name ?), nlink 9, counted 8 link count mismatch for inode 240273435 (name ?), nlink 7, counted 6 link count mismatch for inode 240273436 (name ?), nlink 9, counted 8 link count mismatch for inode 240273437 (name ?), nlink 7, counted 6 link count mismatch for inode 240273438 (name ?), nlink 9, counted 8 link count mismatch for inode 240273439 (name ?), nlink 9, counted 8 link count mismatch for inode 346406949 (name ?), nlink 3, counted 4 link count mismatch for inode 340941885 (name ?), nlink 10, counted 11 link count mismatch for inode 340941886 (name ?), nlink 10, counted 11 link count mismatch for inode 343417900 (name ?), nlink 18, counted 17 link count mismatch for inode 343417902 (name ?), nlink 16, counted 15 link count mismatch for inode 340957216 (name ?), nlink 10, counted 11 link count mismatch for inode 340957217 (name ?), nlink 10, counted 11 link count mismatch for inode 335565856 (name ?), nlink 14, counted 15 link count mismatch for inode 335565857 (name ?), nlink 14, counted 15 link count mismatch for inode 383432717 (name ?), nlink 18, counted 17 link count mismatch for inode 383432719 (name ?), nlink 18, counted 17 link count mismatch for inode 424606730 (name ?), nlink 16, counted 18 link count mismatch for inode 414889995 (name ?), nlink 17, counted 18 link count mismatch for inode 414889996 (name ?), nlink 17, counted 18 link count mismatch for inode 414889998 (name ?), nlink 17, counted 18 link count mismatch for inode 414889999 (name ?), nlink 17, counted 18 link count mismatch for inode 404029469 (name ?), nlink 15, counted 16 link count mismatch for inode 410588170 (name ?), nlink 4, counted 3 link count mismatch for inode 442877964 (name ?), nlink 94, counted 95 link count mismatch for inode 441138178 (name ?), nlink 4, counted 3 link count mismatch for inode 441138180 (name ?), nlink 4, counted 3 link count mismatch for inode 437784616 (name ?), nlink 17, counted 18 link count mismatch for inode 473682976 (name ?), nlink 13, counted 12 link count mismatch for inode 473682978 (name ?), nlink 13, counted 12 link count mismatch for inode 473682979 (name ?), nlink 13, counted 12 link count mismatch for inode 473682980 (name ?), nlink 13, counted 12 link count mismatch for inode 473682981 (name ?), nlink 13, counted 12 link count mismatch for inode 473682982 (name ?), nlink 13, counted 12 link count mismatch for inode 477552672 (name ?), nlink 4, counted 3 link count mismatch for inode 477552673 (name ?), nlink 4, counted 3 link count mismatch for inode 477552674 (name ?), nlink 4, counted 3 link count mismatch for inode 477552675 (name ?), nlink 4, counted 3 link count mismatch for inode 477552676 (name ?), nlink 4, counted 3 link count mismatch for inode 477552677 (name ?), nlink 4, counted 3 link count mismatch for inode 477552678 (name ?), nlink 4, counted 3 link count mismatch for inode 477552679 (name ?), nlink 4, counted 3 link count mismatch for inode 477552680 (name ?), nlink 4, counted 3 link count mismatch for inode 477552681 (name ?), nlink 4, counted 3 link count mismatch for inode 477552682 (name ?), nlink 4, counted 3 link count mismatch for inode 477552683 (name ?), nlink 4, counted 3 link count mismatch for inode 477580336 (name ?), nlink 4, counted 3 link count mismatch for inode 473673741 (name ?), nlink 7, counted 8 link count mismatch for inode 514965508 (name ?), nlink 16, counted 15 link count mismatch for inode 514610208 (name ?), nlink 3, counted 4 link count mismatch for inode 514610209 (name ?), nlink 3, counted 4 Yet another xfs_repair run produces just one nlinks message: disconnected inode 402863163, moving to lost+found disconnected dir inode 424609813, moving to lost+found disconnected dir inode 424609817, moving to lost+found disconnected dir inode 424609838, moving to lost+found disconnected dir inode 486566967, moving to lost+found Phase 7 - verify and correct link counts... resetting inode 217079825 nlinks from 10 to 9 done (Which, oddly, isn't on the xfs_check list. This is getting weird.) From owner-linux-xfs@oss.sgi.com Fri Nov 4 23:22:32 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 04 Nov 2005 23:22:35 -0800 (PST) Received: from science.horizon.com (science.horizon.com [192.35.100.1]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id jA57MVO0017157 for ; Fri, 4 Nov 2005 23:22:31 -0800 Received: (qmail 4955 invoked by uid 1000); 5 Nov 2005 02:19:15 -0500 Date: 5 Nov 2005 02:19:15 -0500 Message-ID: <20051105071915.4954.qmail@science.horizon.com> From: linux@horizon.com To: sandeen@sgi.com Subject: Re: Should xfs_repair make xfs_check stop complaining? Cc: linux@horizon.com, linux-xfs@oss.sgi.com In-Reply-To: <436C10A1.6000802@sgi.com> X-archive-position: 6522 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: linux@horizon.com Precedence: bulk X-list: linux-xfs Content-Length: 9679 Lines: 184 > Try moving lost+found to somewhere else, /lost+found2 or something, and > re-run xfs_repair. Do problems still persist? > > Also that xfs_repair is not the -very- latest version.... Okay, with xfsprogs 2.7.3, I found one minor bug: /# xfs_check -V Usage: xfs_check [-fsvV] [-l logdev] [-i ino]... [-b bno]... special and moving /lost+found to /lost+found2 produces a clean xfs_repair: # xfs_repair /dev/md4 2>&1 | tee /tmp/repair10 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 / ... - traversal finished ... - traversing all unattached subtrees ... - traversals finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... done ...but xfs_check is still complaining: /# xfs_check /dev/md4 block 2/262 expected type unknown got free2 block 2/263 expected type unknown got free2 block 2/264 expected type unknown got free2 block 2/265 expected type unknown got free2 block 2/266 expected type unknown got free2 block 2/158606 expected type unknown got free2 link count mismatch for inode 9521204 (name ?), nlink 18, counted 17 link count mismatch for inode 9521206 (name ?), nlink 18, counted 17 link count mismatch for inode 9521207 (name ?), nlink 18, counted 17 link count mismatch for inode 8159262 (name ?), nlink 2277, counted 2278 link count mismatch for inode 4295701 (name ?), nlink 13, counted 12 link count mismatch for inode 4295702 (name ?), nlink 13, counted 12 link count mismatch for inode 4295703 (name ?), nlink 11, counted 10 link count mismatch for inode 4295705 (name ?), nlink 13, counted 12 link count mismatch for inode 37956638 (name ?), nlink 3, counted 4 link count mismatch for inode 37956639 (name ?), nlink 3, counted 4 link count mismatch for inode 47756317 (name ?), nlink 57, counted 62 link count mismatch for inode 47756319 (name ?), nlink 14, counted 15 link count mismatch for inode 39545890 (name ?), nlink 149, counted 150 link count mismatch for inode 47281154 (name ?), nlink 16, counted 17 link count mismatch for inode 36780063 (name ?), nlink 2, counted 3 link count mismatch for inode 67423241 (name ?), nlink 445, counted 448 link count mismatch for inode 72395795 (name ?), nlink 6, counted 7 link count mismatch for inode 72395796 (name ?), nlink 10, counted 11 link count mismatch for inode 72395799 (name ?), nlink 6, counted 7 link count mismatch for inode 72395800 (name ?), nlink 6, counted 7 link count mismatch for inode 72395801 (name ?), nlink 6, counted 7 link count mismatch for inode 72395802 (name ?), nlink 6, counted 7 link count mismatch for inode 72395803 (name ?), nlink 8, counted 9 link count mismatch for inode 107157534 (name ?), nlink 8, counted 9 link count mismatch for inode 107157541 (name ?), nlink 3, counted 4 link count mismatch for inode 107157542 (name ?), nlink 3, counted 4 link count mismatch for inode 107157543 (name ?), nlink 3, counted 4 link count mismatch for inode 107157544 (name ?), nlink 3, counted 4 link count mismatch for inode 107157545 (name ?), nlink 3, counted 4 link count mismatch for inode 107157546 (name ?), nlink 3, counted 4 link count mismatch for inode 107157547 (name ?), nlink 3, counted 4 link count mismatch for inode 107157548 (name ?), nlink 3, counted 4 link count mismatch for inode 107157550 (name ?), nlink 3, counted 4 link count mismatch for inode 109702154 (name ?), nlink 3, counted 4 link count mismatch for inode 109702156 (name ?), nlink 5, counted 6 link count mismatch for inode 109702157 (name ?), nlink 5, counted 6 link count mismatch for inode 109702158 (name ?), nlink 5, counted 6 link count mismatch for inode 109702159 (name ?), nlink 3, counted 4 link count mismatch for inode 144276493 (name ?), nlink 24, counted 25 link count mismatch for inode 144276494 (name ?), nlink 24, counted 25 link count mismatch for inode 144276495 (name ?), nlink 24, counted 25 link count mismatch for inode 144920600 (name ?), nlink 6, counted 7 link count mismatch for inode 144920601 (name ?), nlink 8, counted 9 link count mismatch for inode 144920607 (name ?), nlink 6, counted 7 link count mismatch for inode 144920608 (name ?), nlink 6, counted 7 link count mismatch for inode 144920609 (name ?), nlink 8, counted 9 link count mismatch for inode 144058403 (name ?), nlink 9, counted 10 link count mismatch for inode 241771561 (name ?), nlink 3, counted 4 link count mismatch for inode 240273428 (name ?), nlink 7, counted 6 link count mismatch for inode 240273430 (name ?), nlink 9, counted 8 link count mismatch for inode 240273431 (name ?), nlink 7, counted 6 link count mismatch for inode 240273432 (name ?), nlink 9, counted 8 link count mismatch for inode 240273433 (name ?), nlink 9, counted 8 link count mismatch for inode 240273434 (name ?), nlink 9, counted 8 link count mismatch for inode 240273435 (name ?), nlink 7, counted 6 link count mismatch for inode 240273436 (name ?), nlink 9, counted 8 link count mismatch for inode 240273437 (name ?), nlink 7, counted 6 link count mismatch for inode 240273438 (name ?), nlink 9, counted 8 link count mismatch for inode 240273439 (name ?), nlink 9, counted 8 link count mismatch for inode 346406949 (name ?), nlink 3, counted 4 link count mismatch for inode 340941885 (name ?), nlink 10, counted 11 link count mismatch for inode 340941886 (name ?), nlink 10, counted 11 link count mismatch for inode 343417900 (name ?), nlink 18, counted 17 link count mismatch for inode 343417902 (name ?), nlink 16, counted 15 link count mismatch for inode 340957216 (name ?), nlink 10, counted 11 link count mismatch for inode 340957217 (name ?), nlink 10, counted 11 link count mismatch for inode 335565856 (name ?), nlink 14, counted 15 link count mismatch for inode 335565857 (name ?), nlink 14, counted 15 link count mismatch for inode 383432717 (name ?), nlink 18, counted 17 link count mismatch for inode 383432719 (name ?), nlink 18, counted 17 link count mismatch for inode 424606730 (name ?), nlink 16, counted 18 link count mismatch for inode 414889995 (name ?), nlink 17, counted 18 link count mismatch for inode 414889996 (name ?), nlink 17, counted 18 link count mismatch for inode 414889998 (name ?), nlink 17, counted 18 link count mismatch for inode 414889999 (name ?), nlink 17, counted 18 link count mismatch for inode 404029469 (name ?), nlink 15, counted 16 link count mismatch for inode 410588170 (name ?), nlink 4, counted 3 link count mismatch for inode 442877964 (name ?), nlink 94, counted 95 link count mismatch for inode 441138178 (name ?), nlink 4, counted 3 link count mismatch for inode 441138180 (name ?), nlink 4, counted 3 link count mismatch for inode 437784616 (name ?), nlink 17, counted 18 link count mismatch for inode 473682976 (name ?), nlink 13, counted 12 link count mismatch for inode 473682978 (name ?), nlink 13, counted 12 link count mismatch for inode 473682979 (name ?), nlink 13, counted 12 link count mismatch for inode 473682980 (name ?), nlink 13, counted 12 link count mismatch for inode 473682981 (name ?), nlink 13, counted 12 link count mismatch for inode 473682982 (name ?), nlink 13, counted 12 link count mismatch for inode 477552672 (name ?), nlink 4, counted 3 link count mismatch for inode 477552673 (name ?), nlink 4, counted 3 link count mismatch for inode 477552674 (name ?), nlink 4, counted 3 link count mismatch for inode 477552675 (name ?), nlink 4, counted 3 link count mismatch for inode 477552676 (name ?), nlink 4, counted 3 link count mismatch for inode 477552677 (name ?), nlink 4, counted 3 link count mismatch for inode 477552678 (name ?), nlink 4, counted 3 link count mismatch for inode 477552679 (name ?), nlink 4, counted 3 link count mismatch for inode 477552680 (name ?), nlink 4, counted 3 link count mismatch for inode 477552681 (name ?), nlink 4, counted 3 link count mismatch for inode 477552682 (name ?), nlink 4, counted 3 link count mismatch for inode 477552683 (name ?), nlink 4, counted 3 link count mismatch for inode 477580336 (name ?), nlink 4, counted 3 link count mismatch for inode 473673741 (name ?), nlink 7, counted 8 link count mismatch for inode 514965508 (name ?), nlink 16, counted 15 link count mismatch for inode 514610208 (name ?), nlink 3, counted 4 link count mismatch for inode 514610209 (name ?), nlink 3, counted 4 From owner-linux-xfs@oss.sgi.com Sat Nov 5 23:15:15 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 05 Nov 2005 23:15:17 -0800 (PST) Received: from science.horizon.com (science.horizon.com [192.35.100.1]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id jA67FEO0017471 for ; Sat, 5 Nov 2005 23:15:14 -0800 Received: (qmail 30866 invoked by uid 1000); 6 Nov 2005 02:11:57 -0500 Date: 6 Nov 2005 02:11:57 -0500 Message-ID: <20051106071157.30865.qmail@science.horizon.com> From: linux@horizon.com To: sandeen@sgi.com Subject: Re: Should xfs_repair make xfs_check stop complaining? Cc: linux@horizon.com, linux-xfs@oss.sgi.com In-Reply-To: <436C10A1.6000802@sgi.com> X-archive-position: 6525 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: linux@horizon.com Precedence: bulk X-list: linux-xfs Content-Length: 4309 Lines: 139 Two more cfs_repair runs, the second of which ended in a segfault. Note that these are like the 11th and 12th time I've run xfs_repair on the same 150 GB file system. Maybe I should just go back to ext3... # xfs_repair /dev/md4 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) ... - clearing existing "lost+found" inode - marking entry "lost+found" to be deleted - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - 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 1024 - traversal finished ... - traversing all unattached subtrees ... - traversals finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... resetting inode 343417900 nlinks from 18 to 17 resetting inode 343417902 nlinks from 16 to 15 resetting inode 404029469 nlinks from 15 to 16 resetting inode 414889995 nlinks from 17 to 18 resetting inode 414889996 nlinks from 17 to 18 resetting inode 414889998 nlinks from 17 to 18 resetting inode 414889999 nlinks from 17 to 18 resetting inode 414890000 nlinks from 17 to 18 resetting inode 414890002 nlinks from 15 to 16 resetting inode 414890003 nlinks from 17 to 18 resetting inode 414890004 nlinks from 17 to 18 resetting inode 414890009 nlinks from 15 to 16 resetting inode 414890010 nlinks from 17 to 18 resetting inode 414890012 nlinks from 17 to 18 done # xfs_repair /dev/md4 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) ... - clearing existing "lost+found" inode - marking entry "lost+found" to be deleted - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - 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 1024 Segmentation fault # From owner-linux-xfs@oss.sgi.com Sun Nov 6 04:24:02 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 06 Nov 2005 04:24:09 -0800 (PST) Received: from astra.simleu.ro ([80.97.22.153]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jA6CO1O0008593 for ; Sun, 6 Nov 2005 04:24:02 -0800 Received: from saytrin.hq.k1024.org (unknown [62.217.245.194]) by astra.simleu.ro (Postfix) with ESMTP id 9C00050; Sun, 6 Nov 2005 14:20:43 +0200 (EET) Received: by saytrin.hq.k1024.org (Postfix, from userid 4004) id 1CF5F1494A8; Sun, 6 Nov 2005 14:19:26 +0200 (EET) Date: Sun, 6 Nov 2005 14:19:25 +0200 From: Iustin Pop To: linux@horizon.com Cc: linux-xfs@oss.sgi.com Subject: Re: Should xfs_repair make xfs_check stop complaining? Message-ID: <20051106121925.GA4135@saytrin.hq.k1024.org> Mail-Followup-To: linux@horizon.com, linux-xfs@oss.sgi.com References: <436C10A1.6000802@sgi.com> <20051106071157.30865.qmail@science.horizon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051106071157.30865.qmail@science.horizon.com> X-Linux: This message was written on Linux X-Header: /usr/include gives great headers User-Agent: Mutt/1.5.11 X-archive-position: 6526 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: iusty@k1024.org Precedence: bulk X-list: linux-xfs Content-Length: 485 Lines: 14 On Sun, Nov 06, 2005 at 02:11:57AM -0500, linux@horizon.com wrote: > Two more cfs_repair runs, the second of which ended in a segfault. > Note that these are like the 11th and 12th time I've run xfs_repair on the > same 150 GB file system. > > Maybe I should just go back to ext3... This means you haven't seen e2fsck turning a mountable (with inaccesible files) filesystem into a complete mess, no longer mountable. The same e2fsck finishing also with segfault... Regards, Iustin From owner-linux-xfs@oss.sgi.com Sun Nov 6 04:56:45 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 06 Nov 2005 04:56:49 -0800 (PST) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jA6CujO0010229 for ; Sun, 6 Nov 2005 04:56:45 -0800 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 jA6CrTxT003363 for ; Sun, 6 Nov 2005 06:53:29 -0600 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 jA6CrROS3469514; Sun, 6 Nov 2005 04:53:28 -0800 (PST) Message-ID: <436DFCC7.1060307@sgi.com> Date: Sun, 06 Nov 2005 06:53:27 -0600 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux@horizon.com CC: linux-xfs@oss.sgi.com Subject: Re: Should xfs_repair make xfs_check stop complaining? References: <20051106071157.30865.qmail@science.horizon.com> In-Reply-To: <20051106071157.30865.qmail@science.horizon.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6527 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 393 Lines: 14 linux@horizon.com wrote: > Two more cfs_repair runs, the second of which ended in a segfault. > Note that these are like the 11th and 12th time I've run xfs_repair on the > same 150 GB file system. > > Maybe I should just go back to ext3... or maybe you should fix your IO subsystem before worrying about the filesystem on top of it... Is your SATA subsystem now working properly? -Eric From owner-linux-xfs@oss.sgi.com Mon Nov 7 21:07:06 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 07 Nov 2005 21:07:10 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id jA8574O0023578 for ; Mon, 7 Nov 2005 21:07:05 -0800 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA05624 for ; Tue, 8 Nov 2005 16:03:46 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 8726C49E5F58; Tue, 8 Nov 2005 16:03:45 +1100 (EST) To: linux-xfs@oss.sgi.com Subject: TAKE 907752 - minor userspace updates Message-Id: <20051108050345.8726C49E5F58@chook.melbourne.sgi.com> Date: Tue, 8 Nov 2005 16:03:45 +1100 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 6529 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 15902 Lines: 231 Update git merge tool to handle couple more special case files, etc. Date: Mon Nov 7 12:00:41 AEDT 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-cmds Inspected by: nathans The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:24299a xfsmisc/p_mod2git - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsmisc/p_mod2git.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h Keep packaging scripts in sync across all of the packages we maintain. Date: Mon Nov 7 12:02:30 AEDT 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-cmds Inspected by: nathans The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:24301a acl/debian/rules - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/debian/rules.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h attr/debian/rules - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/debian/rules.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h xfsprogs/debian/rules - 1.22 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/debian/rules.diff?r1=text&tr1=1.22&r2=text&tr2=1.21&f=h xfsdump/debian/rules - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/debian/rules.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h dmapi/debian/rules - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/dmapi/debian/rules.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h attr/m4/package_globals.m4 - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/m4/package_globals.m4.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h acl/m4/package_globals.m4 - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/m4/package_globals.m4.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h dmapi/m4/package_xfslibs.m4 - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/dmapi/m4/package_xfslibs.m4.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h dmapi/m4/package_globals.m4 - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/dmapi/m4/package_globals.m4.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h xfsprogs/m4/package_globals.m4 - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/m4/package_globals.m4.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h xfsdump/m4/package_xfslibs.m4 - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/m4/package_xfslibs.m4.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h xfsdump/m4/package_globals.m4 - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsdump/m4/package_globals.m4.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h xfstests/m4/package_globals.m4 - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/m4/package_globals.m4.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h xfstests/m4/package_utilies.m4 - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/m4/package_utilies.m4.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h xfstests/m4/package_libcdev.m4 - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/m4/package_libcdev.m4.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h Merge back recent changes from xfs kernel headers. Date: Tue Nov 8 15:59:55 AEDT 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-cmds Inspected by: nathans The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:24317a xfsprogs/include/xfs_trans_space.h - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_trans_space.h.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h xfsprogs/include/xfs_log.h - 1.20 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_log.h.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h xfsprogs/include/xfs_inum.h - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_inum.h.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h xfsprogs/include/xfs_ialloc.h - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_ialloc.h.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h xfsprogs/include/xfs_ag.h - 1.18 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_ag.h.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h xfsprogs/include/xfs_extfree_item.h - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_extfree_item.h.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h xfsprogs/include/xfs_buf_item.h - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_buf_item.h.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h xfsprogs/include/buildrules - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/buildrules.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h xfsprogs/include/xfs_attr_sf.h - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_attr_sf.h.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h xfsprogs/include/xfs_log_priv.h - 1.20 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_log_priv.h.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h xfsprogs/include/xfs_da_btree.h - 1.19 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_da_btree.h.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h xfsprogs/include/handle.h - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/handle.h.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h xfsprogs/include/xfs_bit.h - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_bit.h.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h xfsprogs/include/volume.h - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/volume.h.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h xfsprogs/include/xfs_sb.h - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_sb.h.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h xfsprogs/include/xfs_dir2_block.h - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_dir2_block.h.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h xfsprogs/include/xfs_fs.h - 1.36 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_fs.h.diff?r1=text&tr1=1.36&r2=text&tr2=1.35&f=h xfsprogs/include/xfs_dir.h - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_dir.h.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h xfsprogs/include/xfs_arch.h - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_arch.h.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h xfsprogs/include/libxfs.h - 1.43 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/libxfs.h.diff?r1=text&tr1=1.43&r2=text&tr2=1.42&f=h xfsprogs/include/xfs_rtalloc.h - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_rtalloc.h.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h xfsprogs/include/fstyp.h - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/fstyp.h.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h xfsprogs/include/xfs_ialloc_btree.h - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_ialloc_btree.h.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h xfsprogs/include/xfs_inode_item.h - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_inode_item.h.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h xfsprogs/include/Makefile - 1.25 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/Makefile.diff?r1=text&tr1=1.25&r2=text&tr2=1.24&f=h xfsprogs/include/dvh.h - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/dvh.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h xfsprogs/include/xfs_log_recover.h - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_log_recover.h.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h xfsprogs/include/xfs_dfrag.h - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_dfrag.h.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h xfsprogs/include/libxlog.h - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/libxlog.h.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h xfsprogs/include/xfs_bmap_btree.h - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_bmap_btree.h.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h xfsprogs/include/builddefs.in - 1.45 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/builddefs.in.diff?r1=text&tr1=1.45&r2=text&tr2=1.44&f=h xfsprogs/include/xfs_dir2_sf.h - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_dir2_sf.h.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h xfsprogs/include/xfs_dir_leaf.h - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_dir_leaf.h.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h xfsprogs/include/platform_defs.h.in - 1.32 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/platform_defs.h.in.diff?r1=text&tr1=1.32&r2=text&tr2=1.31&f=h xfsprogs/include/xfs_mount.h - 1.46 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_mount.h.diff?r1=text&tr1=1.46&r2=text&tr2=1.45&f=h xfsprogs/include/xfs_btree.h - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_btree.h.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h xfsprogs/include/xfs_dir2_data.h - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_dir2_data.h.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h xfsprogs/include/xfs_inode.h - 1.40 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_inode.h.diff?r1=text&tr1=1.40&r2=text&tr2=1.39&f=h xfsprogs/include/xfs_dir2_leaf.h - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_dir2_leaf.h.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h xfsprogs/include/xfs_attr_leaf.h - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_attr_leaf.h.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h xfsprogs/include/xfs_types.h - 1.27 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_types.h.diff?r1=text&tr1=1.27&r2=text&tr2=1.26&f=h xfsprogs/include/xfs_trans.h - 1.19 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_trans.h.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h xfsprogs/include/xfs_dir_sf.h - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_dir_sf.h.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h xfsprogs/include/xfs_alloc.h - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_alloc.h.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h xfsprogs/include/jdm.h - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/jdm.h.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h xfsprogs/include/xqm.h - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xqm.h.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h xfsprogs/include/xfs_imap.h - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_imap.h.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h xfsprogs/include/xfs_bmap.h - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_bmap.h.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h xfsprogs/include/xfs_alloc_btree.h - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_alloc_btree.h.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h xfsprogs/include/xfs_quota.h - 1.19 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_quota.h.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h xfsprogs/include/xfs_dir2_node.h - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_dir2_node.h.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h xfsprogs/include/xfs_dir2.h - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_dir2.h.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h xfsprogs/include/xfs_dinode.h - 1.18 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_dinode.h.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h xfsprogs/repair/phase6.c - 1.20 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/repair/phase6.c.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h xfsprogs/libxfs/xfs_ialloc.c - 1.23 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/xfs_ialloc.c.diff?r1=text&tr1=1.23&r2=text&tr2=1.22&f=h xfsprogs/libxfs/xfs.h - 1.47 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/xfs.h.diff?r1=text&tr1=1.47&r2=text&tr2=1.46&f=h xfsprogs/libxfs/xfs_dir2_leaf.c - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/xfs_dir2_leaf.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h xfsprogs/libxfs/xfs_attr_leaf.c - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/xfs_attr_leaf.c.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h xfsprogs/libxfs/xfs_alloc.c - 1.24 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/xfs_alloc.c.diff?r1=text&tr1=1.24&r2=text&tr2=1.23&f=h xfsprogs/libxfs/xfs_alloc_btree.c - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/xfs_alloc_btree.c.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h xfsprogs/include/buildmacros - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/buildmacros.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h xfsprogs/include/irix.h - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/irix.h.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h xfsprogs/include/freebsd.h - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/freebsd.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h xfsprogs/include/darwin.h - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/darwin.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h xfsprogs/include/linux.h - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/linux.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h xfsprogs/include/project.h - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/project.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h xfsprogs/include/path.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/path.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h xfsprogs/include/input.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/input.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h xfsprogs/include/command.h - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/command.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h Merge back kernel fixes/code updates in xfs. Date: Tue Nov 8 16:02:56 AEDT 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-cmds Inspected by: nathans The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:24318a xfsprogs/libxfs/xfs_da_btree.c - 1.29 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/xfs_da_btree.c.diff?r1=text&tr1=1.29&r2=text&tr2=1.28&f=h xfsprogs/libxfs/xfs.h - 1.48 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/xfs.h.diff?r1=text&tr1=1.48&r2=text&tr2=1.47&f=h xfsprogs/libxfs/xfs_dir2_sf.c - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/xfs_dir2_sf.c.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h xfsprogs/libxfs/xfs_dir_leaf.c - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/xfs_dir_leaf.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h xfsprogs/libxfs/xfs_mount.c - 1.22 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/xfs_mount.c.diff?r1=text&tr1=1.22&r2=text&tr2=1.21&f=h From owner-linux-xfs@oss.sgi.com Tue Nov 8 05:27:14 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 08 Nov 2005 05:27:20 -0800 (PST) Received: from mail.linbit.com (aug.linbit.com [212.69.162.22]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jA8DRDO0008856 for ; Tue, 8 Nov 2005 05:27:13 -0800 Received: from mescal.linbit (213-229-1-138.sdsl-line.inode.at [213.229.1.138]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.linbit.com (LINBIT Mail Daemon) with ESMTP id A9690151AA for ; Tue, 8 Nov 2005 14:23:54 +0100 (CET) From: Philipp Reisner Organization: LINBIT To: linux-xfs@oss.sgi.com Subject: XFS unstable with little memory; OOPS in prune_dcache() Date: Tue, 8 Nov 2005 14:25:06 +0100 User-Agent: KMail/1.8 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Message-Id: <200511081425.06695.philipp.reisner@linbit.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id jA8DREO0008860 X-archive-position: 6530 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: philipp.reisner@linbit.com Precedence: bulk X-list: linux-xfs Content-Length: 6767 Lines: 199 Hi XFS gurus, I experienced a series of kernel crashes, that are triggered by: o XFS ( Kernel vanilla 2.6.13.4 ) o uniprocessor (compiled for K7) / no HIGHMEM o little memory ( 256 MB Ram ) o 200GB XFS filesystem, 138GB used o 4378907 inodes ( 4 m) o 30349548 dentries (30 m) The system is used as a backup server. Each of the production systems is backed up by hardlinking the previous day's backup, and then breaking the hardlinks and replacing the changed files by running rsync. [ See rsbak3 at http://oss.linbit.com/ ] The outcome is that we have mostly small files, but most of these inodes have about 30 - 40 directory entries. The OOPS happended during the backup run, after we changed the FS from ext3 to XFS. The same machine run with ext3 perfectly stable, then we tested all hardware components in multiple ways. In the end it turned out that with one GB of memory it is also stable with XFS. A reliable way to reproduce the crash is to run tiobend and an ls -lR concurrently. It took about 30 minutes to one hour to trigger the OOPS. BTW, XFS is much faster than ext3 with this highly hardlinked structure. Here is the OOPS, and what I found out about it... general protection fault: 0000 [#1] Modules linked in: ipv6 bonding evdev parport_pc parport pcspkr via_rhine ehci_hcd uhci_hcd generic 8139too 8139cp via_agp agpgart xfs dm_mirror dm_snapshot dm_mod raid5 raid1 raid0 xor ide_disk via82cxxx ide_core md_mod CPU: 0 EIP: 0060:[] Not tainted VLI EFLAGS: 00010216 (2.6.13sv-k7-up-lowmem) EIP is at prune_dcache+0x37/0x160 eax: c039fa64 ebx: c0fc7d9c ecx: c0bc7d30 edx: ffffffff esi: 00000000 edi: 00000024 ebp: cdfeea60 esp: cd481eb8 ds: 007b es: 007b ss: 0068 Process kswapd0 (pid: 124, threadinfo=cd480000 task=cd42c590) Stack: c074a794 cd481ef0 c013b068 cd481ef0 0000e8d0 00000000 000000e6 c0169bcf 00000080 c013f8f9 00000080 000000d0 00008116 003a3400 00000000 00000073 00000000 00000000 c039e74c 00000001 c039e620 00008115 c0140bee 00000020 Call Trace: [] get_dirty_limits+0x18/0xd0 [] shrink_dcache_memory+0x1f/0x50 [] shrink_slab+0x179/0x1c0 [] balance_pgdat+0x2ce/0x3a0 [] kswapd+0xde/0x100 [] autoremove_wake_function+0x0/0x60 [] autoremove_wake_function+0x0/0x60 [] kswapd+0x0/0x100 [] kernel_thread_helper+0x5/0x14 Code: 75 07 83 c4 10 5b 5e 5f c3 c7 04 24 94 a7 74 c0 e8 9f c2 fa ff 8b 0d 68 fa 39 c0 81 f9 64 fa 39 c0 74 df 8b 01 8b 51 04 89 50 04 <89> 02 89 49 04 89 09 a1 68 fa 39 c0 8d 44 20 00 ff 0d 70 fa 39 The OOPS happens in list_del_init(), it is maked in the C-snipplet. /** * prune_dcache - shrink the dcache * @count: number of entries to try and free * * Shrink the dcache. This is done when we need * more memory, or simply when we need to unmount * something (at which point we need to unuse * all dentries). * * This function may fail to free any resources if * all the dentries are in use. */ static void prune_dcache(int count) { spin_lock(&dcache_lock); for (; count ; count--) { struct dentry *dentry; struct list_head *tmp; cond_resched_lock(&dcache_lock); tmp = dentry_unused.prev; if (tmp == &dentry_unused) break; list_del_init(tmp); <=<<==<<<===<<<<==== prefetch(dentry_unused.prev); dentry_stat.nr_unused--; dentry = list_entry(tmp, struct dentry, d_lru); spin_lock(&dentry->d_lock); /* * We found an inuse dentry which was not removed from * dentry_unused because of laziness during lookup. Do not free * it - just keep it off the dentry_unused list. */ if (atomic_read(&dentry->d_count)) { spin_unlock(&dentry->d_lock); continue; } /* If the dentry was recently referenced, don't free it. */ if (dentry->d_flags & DCACHE_REFERENCED) { dentry->d_flags &= ~DCACHE_REFERENCED; list_add(&dentry->d_lru, &dentry_unused); dentry_stat.nr_unused++; spin_unlock(&dentry->d_lock); continue; } prune_one_dentry(dentry); } spin_unlock(&dcache_lock); } Here is the same in GCC's assember output: prune_dcache: .stabn 68,0,395,.LM177-prune_dcache .LM177: pushl %edi pushl %esi pushl %ebx subl $16, %esp movl 32(%esp), %edi .stabn 68,0,397,.LM178-prune_dcache .LM178: .LBB73: testl %edi, %edi jne .L263 .L209: .stabn 68,0,432,.LM179-prune_dcache .LM179: addl $16, %esp popl %ebx popl %esi popl %edi ret .p2align 6,,7 .L263: .stabn 68,0,401,.LM180-prune_dcache .LM180: .LBB74: movl $dcache_lock, (%esp) call cond_resched_lock .stabn 68,0,403,.LM181-prune_dcache .LM181: movl dentry_unused+4, %ecx .stabn 68,0,404,.LM182-prune_dcache .LM182: cmpl $dentry_unused, %ecx je .L209 .stabs "include/linux/list.h",132,0,0,.Ltext63 .Ltext63: .stabn 68,0,150,.LM183-prune_dcache .LM183: .LBB75: .LBB76: movl (%ecx), %eax movl 4(%ecx), %edx .stabn 68,0,151,.LM184-prune_dcache .LM184: movl %edx, 4(%eax) .stabn 68,0,152,.LM185-prune_dcache .LM185: movl %eax, (%edx) <=<<==<<<===<<<<==== .stabn 68,0,220,.LM186-prune_dcache .LM186: .LBE76: movl %ecx, 4(%ecx) movl %ecx, (%ecx) .stabs "include/asm/processor.h",132,0,0,.Ltext64 .Ltext64: The output of xfs_info [root@anat:/tmp]# xfs_info /var/backup meta-data=/var/backup isize=256 agcount=16, agsize=3276800 blks = sectsz=512 data = bsize=4096 blocks=52428800, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=25600, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 -- : Dipl-Ing Philipp Reisner Tel +43-1-8178292-50 : : LINBIT Information Technologies GmbH Fax +43-1-8178292-82 : : Schönbrunnerstr 244, 1120 Vienna, Austria http://www.linbit.com : From owner-linux-xfs@oss.sgi.com Tue Nov 8 07:48:00 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 08 Nov 2005 07:48:06 -0800 (PST) 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 jA8Fm0O0023957 for ; Tue, 8 Nov 2005 07:48:00 -0800 Received: from soloth.lewis.org (localhost.localdomain [127.0.0.1]) by soloth.lewis.org (8.12.11/8.12.11) with ESMTP id jA8Figd6026041 for ; Tue, 8 Nov 2005 10:44:42 -0500 Received: from localhost (jlewis@localhost) by soloth.lewis.org (8.12.11/8.12.11/Submit) with ESMTP id jA8FigxH026037 for ; Tue, 8 Nov 2005 10:44:42 -0500 X-Authentication-Warning: soloth.lewis.org: jlewis owned process doing -bs Date: Tue, 8 Nov 2005 10:44:42 -0500 (EST) From: Jon Lewis To: linux-xfs Subject: SGI linux xfs cvs Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 6531 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jlewis@lewis.org Precedence: bulk X-list: linux-xfs Content-Length: 746 Lines: 14 Has anyone tried compiling the Linux 2.4 XFS CVS snapshot recently and used it to export an XFS fs via NFS? I brought this up a few months ago, and was just looking at it again. For some reason, using that kernel, clients that mount an exported XFS can traverse/read directories, but not read files (attempts result in i/o errors). NFS exported EXT3 on the same kernel works fine. I'm probably going to try the latest 2.4 from kernel.org and see what happens with it. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From owner-linux-xfs@oss.sgi.com Tue Nov 8 08:08:17 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 08 Nov 2005 08:08:27 -0800 (PST) Received: from ty.sabi.co.UK ([82.69.39.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jA8G8GO0025803 for ; Tue, 8 Nov 2005 08:08:17 -0800 Received: from from [127.0.0.1] (helo=base.ty.sabi.co.UK) by ty.sabi.co.UK with esmtp(Exim 4.54 #1) id 1EZVxf-0007Vy-4r for ; Tue, 08 Nov 2005 16:04:39 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Message-ID: <17264.52374.316530.749268@base.ty.sabi.co.UK> Date: Tue, 8 Nov 2005 16:04:38 +0000 X-Face: SMJE]JPYVBO-9UR%/8d'mG.F!@.,l@c[f'[%S8'BZIcbQc3/">GrXDwb#;fTRGNmHr^JFb SAptvwWc,0+z+~p~"Gdr4H$(|N(yF(wwCM2bW0~U?HPEE^fkPGx^u[*[yV.gyB!hDOli}EF[\cW*S H&spRGFL}{`bj1TaD^l/"[ msn( /TH#THs{Hpj>)]f> References: <200511081425.06695.philipp.reisner@linbit.com> X-Mailer: VM 7.17 under 21.4 (patch 17) XEmacs Lucid From: pg_xfs@xfs.for.sabi.co.UK (Peter Grandi) X-Disclaimer: This message contains only personal opinions Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id jA8G8HO0025807 X-archive-position: 6532 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: pg_xfs@xfs.for.sabi.co.UK Precedence: bulk X-list: linux-xfs Content-Length: 2178 Lines: 59 >>> On Tue, 8 Nov 2005 14:25:06 +0100, Philipp Reisner >>> said: philipp.reisner> Hi XFS gurus, I experienced a series of kernel philipp.reisner> crashes, that are triggered by: philipp.reisner> o XFS ( Kernel vanilla 2.6.13.4 ) philipp.reisner> o uniprocessor (compiled for K7) / no HIGHMEM philipp.reisner> o little memory ( 256 MB Ram ) philipp.reisner> o 200GB XFS filesystem, 138GB used philipp.reisner> o 4378907 inodes ( 4 m) philipp.reisner> o 30349548 dentries (30 m) The crashes are not a big deal, as they don't happen with more RAM as you say. What would worry me about having 2656MB is the ability and time taken to check that filesystem with so many inodes and directory entries might, or at last could take a _long_ while, even if perhaps not the 75 days reported for a large 'ext3' filesystem here: http://UKAI.org/b/log/debian/snapshot/1_month_fsck-2005-07-22-00-00.html http://UKAI.org/b/log/debian/snapshot/fsck_completed_but-2005-09-04-15-00.html Couple of threads on RAM (and address space) usage: http://OSS.SGI.com/archives/linux-xfs/2005-09/msg00101.html http://OSS.SGI.com/archives/linux-xfs/2005-08/msg00031.html for example, as to checking: http://OSS.SGI.com/archives/linux-xfs/2005-08/msg00045.html «From some quick tests I just ran, for 32bit binaries xfs_check needs around 1GiB RAM per TiB of filesystem plus about 100MiB RAM per 1million inodes in the filesystem (more if you have lots of fragmented files).» More generally, the rule for most sw, and freee sw too, is ''it works for me'', where ''me'' is the developer or the employer of the developer. So if your system is very different from those used by the developers, bad luck. Right now most Linux kernel/fs developer are employed by large corporates and it is easy to imagine that they have >2GB of memory installed. Also, XFS is designed/targeted to handle very large filesystems on very large computers. On the scale of systems for which XFS was designed, a 256MB PC is an embedded system. [ ... ] philipp.reisner> [ See rsbak3 at http://oss.linbit.com/ ] or http://WWW.rsnapshot.org/ which seems similar... From owner-linux-xfs@oss.sgi.com Tue Nov 8 08:39:18 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 08 Nov 2005 08:39:22 -0800 (PST) Received: from mail.linbit.com (aug.linbit.com [212.69.162.22]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jA8GdGO0032031 for ; Tue, 8 Nov 2005 08:39:17 -0800 Received: from mescal.linbit (213-229-1-138.sdsl-line.inode.at [213.229.1.138]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.linbit.com (LINBIT Mail Daemon) with ESMTP id 3FA58151AA for ; Tue, 8 Nov 2005 17:35:59 +0100 (CET) From: Philipp Reisner Organization: LINBIT To: linux-xfs@oss.sgi.com Subject: Re: XFS unstable with little memory; OOPS in prune_dcache() Date: Tue, 8 Nov 2005 17:38:31 +0100 User-Agent: KMail/1.8 References: <200511081425.06695.philipp.reisner@linbit.com> <17264.52374.316530.749268@base.ty.sabi.co.UK> In-Reply-To: <17264.52374.316530.749268@base.ty.sabi.co.UK> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Message-Id: <200511081738.31746.philipp.reisner@linbit.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id jA8GdIO0032035 X-archive-position: 6533 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: philipp.reisner@linbit.com Precedence: bulk X-list: linux-xfs Content-Length: 2056 Lines: 51 Am Dienstag, 8. November 2005 17:04 schrieb Peter Grandi: > philipp.reisner> Hi XFS gurus, I experienced a series of kernel > philipp.reisner> crashes, that are triggered by: > > philipp.reisner> o XFS ( Kernel vanilla 2.6.13.4 ) > philipp.reisner> o uniprocessor (compiled for K7) / no HIGHMEM > philipp.reisner> o little memory ( 256 MB Ram ) > philipp.reisner> o 200GB XFS filesystem, 138GB used > philipp.reisner> o 4378907 inodes ( 4 m) > philipp.reisner> o 30349548 dentries (30 m) > > The crashes are not a big deal, as they don't happen with more > RAM as you say. > > More generally, the rule for most sw, and freee sw too, is ''it > works for me'', where ''me'' is the developer or the employer of > the developer. > Well, yes and no. Although adding RAM solves the problem for me, and if my attitude was, I need it to work for my, forget the rest. I would not have posted this message. What I see here, that I triggered a problem that the XFS developers might not be aware of. Maybe they are happy that someone showed them an unusual corner case and can fix the issue. Maybe they will simply ignore me. If someone would post a bug report like this to my own project (DRBD) I am would be happy about it and do my best to fix it as soon as possible. > > So if your system is very different from those used by the > developers, bad luck. Right now most Linux kernel/fs developer > are employed by large corporates and it is easy to imagine that > they have >2GB of memory installed. > > Also, XFS is designed/targeted to handle very large filesystems > on very large computers. On the scale of systems for which XFS > was designed, a 256MB PC is an embedded system. > I see it as: The kernel's components might not be efficient with limited resources, but they must be correct. Especially with memory pressure. -Phil -- : Dipl-Ing Philipp Reisner Tel +43-1-8178292-50 : : LINBIT Information Technologies GmbH Fax +43-1-8178292-82 : : Schönbrunnerstr 244, 1120 Vienna, Austria http://www.linbit.com : From owner-linux-xfs@oss.sgi.com Tue Nov 8 09:32:09 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 08 Nov 2005 09:32:14 -0800 (PST) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.194]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jA8HW8O0005453 for ; Tue, 8 Nov 2005 09:32:09 -0800 Received: by xproxy.gmail.com with SMTP id t13so695730wxc for ; Tue, 08 Nov 2005 09:28:51 -0800 (PST) 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=PIRMvWypVhlIr6KVmhgwsJjCeT1DXkGAgrvhCszur3jPucpP9B4ExCejfsqlCzy3nilfrVEFPrcJWhpdAsicuz/A9ciSGy+Bh3ZfT7JUdP9rcbz+7NKe9cZ8gx6NqYvp9L8hAWRQj8RV5/1W22OQhwSXXucvn3ZiNuMm6LOskWQ= Received: by 10.70.78.8 with SMTP id a8mr3071480wxb; Tue, 08 Nov 2005 09:28:51 -0800 (PST) Received: by 10.70.70.9 with HTTP; Tue, 8 Nov 2005 09:28:51 -0800 (PST) Message-ID: Date: Tue, 8 Nov 2005 10:28:51 -0700 From: Nick I To: linux-xfs@oss.sgi.com Subject: backbone of a large-file streaming system MIME-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit X-archive-position: 6534 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: clusterbuilder@gmail.com Precedence: bulk X-list: linux-xfs Content-Length: 870 Lines: 24 Hi, I help maintain a Web site at www.clusterbuilder.org. You might have seen before that I have a section called Ask the Cluster Expert, where I am building a knowledgebase of cluster and grid information. When someone asks a question I am researching the answer to build this knowledgebase out. I received the following question: *"I am looking for a variety of solutions to be a backbone of a large-file streaming system providing thousands of concurrent download streams. Preferably commodity hardware and Linux, though I'm open to commercial solutions."* I am wondering if anyone here has suggestions of what applications will work best for this type of setup. You can respond to the question at www.clusterbuilder.org/FAQ or respond in email. Thanks, Nick [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Tue Nov 8 09:52:57 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 08 Nov 2005 09:53:00 -0800 (PST) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jA8HqvO0007227 for ; Tue, 8 Nov 2005 09:52:57 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id jA8Ix0Vv028901 for ; Tue, 8 Nov 2005 10:59:00 -0800 Received: from [128.162.232.50] (stout.americas.sgi.com [128.162.232.50]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id jA8HmcDN19476593; Tue, 8 Nov 2005 11:48:39 -0600 (CST) Message-ID: <4370E4F6.7060200@sgi.com> Date: Tue, 08 Nov 2005 11:48:38 -0600 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0.6-1.1.fc4 (X11/20050720) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Philipp Reisner CC: linux-xfs@oss.sgi.com Subject: Re: XFS unstable with little memory; OOPS in prune_dcache() References: <200511081425.06695.philipp.reisner@linbit.com> <17264.52374.316530.749268@base.ty.sabi.co.UK> <200511081738.31746.philipp.reisner@linbit.com> In-Reply-To: <200511081738.31746.philipp.reisner@linbit.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6535 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 589 Lines: 15 Philipp Reisner wrote: > Well, yes and no. Although adding RAM solves the problem for me, and > if my attitude was, I need it to work for my, forget the rest. > I would not have posted this message. > > What I see here, that I triggered a problem that the XFS developers > might not be aware of. Maybe they are happy that someone showed them > an unusual corner case and can fix the issue. Maybe they will simply > ignore me. It's always good to have these datapoints & bug reports. On the other hand, nothing in the backtrace immediately suggests that this is an xfs bug... -Eric From owner-linux-xfs@oss.sgi.com Tue Nov 8 21:57:30 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 08 Nov 2005 21:57:33 -0800 (PST) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jA95vUO0000430 for ; Tue, 8 Nov 2005 21:57:30 -0800 Received: from hastur.corp.sgi.com (hastur.corp.sgi.com [198.149.32.33]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id jA973cwq021546 for ; Tue, 8 Nov 2005 23:03:38 -0800 Received: from naboo.americas.sgi.com (naboo.americas.sgi.com [128.162.233.73]) by hastur.corp.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id jA95r0eS211849135; Tue, 8 Nov 2005 21:53:00 -0800 (PST) Received: from naboo.americas.sgi.com (localhost [127.0.0.1]) by naboo.americas.sgi.com (8.13.3/8.13.3) with ESMTP id jA95r7ks023154; Tue, 8 Nov 2005 23:53:07 -0600 Received: (from hch@localhost) by naboo.americas.sgi.com (8.13.3/8.13.3/Submit) id jA95r7nt023153; Tue, 8 Nov 2005 23:53:07 -0600 Date: Tue, 8 Nov 2005 23:53:07 -0600 From: Christoph Hellwig Message-Id: <200511090553.jA95r7nt023153@naboo.americas.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Subject: TAKE 907752 - add cpu_to_be* / be*_to_cpu helpers for userspace X-archive-position: 6539 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@relay.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 455 Lines: 15 Date: Tue Nov 8 21:52:56 PST 2005 Workarea: naboo.americas.sgi.com:/go/space/hch/xfs-cmds Inspected by: nathans The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-cmds/master Modid: master:xfs-cmds:201880a xfsprogs/include/xfs_arch.h - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_arch.h.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h - add cpu_to_be* / be*_to_cpu helpers for userspace From owner-linux-xfs@oss.sgi.com Tue Nov 8 22:40:45 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 08 Nov 2005 22:40:49 -0800 (PST) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jA96ejO0003665 for ; Tue, 8 Nov 2005 22:40:45 -0800 Received: from internal-mail-relay.corp.sgi.com (internal-mail-relay.corp.sgi.com [198.149.32.51]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id jA97krFa028642 for ; Tue, 8 Nov 2005 23:46:53 -0800 Received: from naboo.americas.sgi.com (naboo.americas.sgi.com [128.162.233.73]) by internal-mail-relay.corp.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id jA96bR2Z224853249; Tue, 8 Nov 2005 22:37:27 -0800 (PST) Received: from naboo.americas.sgi.com (localhost [127.0.0.1]) by naboo.americas.sgi.com (8.13.3/8.13.3) with ESMTP id jA96bQNv014392; Wed, 9 Nov 2005 00:37:27 -0600 Received: (from hch@localhost) by naboo.americas.sgi.com (8.13.3/8.13.3/Submit) id jA96bQkl014391; Wed, 9 Nov 2005 00:37:26 -0600 Date: Wed, 9 Nov 2005 00:37:26 -0600 From: Christoph Hellwig Message-Id: <200511090637.jA96bQkl014391@naboo.americas.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Subject: TAKE 907752 - merge xfs_arch.h userspace changes back X-archive-position: 6540 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@relay.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 433 Lines: 15 Date: Tue Nov 8 22:37:16 PST 2005 Workarea: naboo.americas.sgi.com:/go/space/hch/xfs-2.6.x 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:201882a fs/xfs/xfs_arch.h - 1.50 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_arch.h.diff?r1=text&tr1=1.50&r2=text&tr2=1.49&f=h - add cpu_to_be* / be*_to_cpu helpers for userspace From owner-linux-xfs@oss.sgi.com Tue Nov 8 22:55:52 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 08 Nov 2005 22:55:55 -0800 (PST) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jA96tpO0004540 for ; Tue, 8 Nov 2005 22:55:51 -0800 Received: from internal-mail-relay.corp.sgi.com (internal-mail-relay.corp.sgi.com [198.149.32.51]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id jA96qXxT031295 for ; Wed, 9 Nov 2005 00:52:33 -0600 Received: from naboo.americas.sgi.com (naboo.americas.sgi.com [128.162.233.73]) by internal-mail-relay.corp.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id jA96qW2Z285062304; Tue, 8 Nov 2005 22:52:32 -0800 (PST) Received: from naboo.americas.sgi.com (localhost [127.0.0.1]) by naboo.americas.sgi.com (8.13.3/8.13.3) with ESMTP id jA96qWZu017656; Wed, 9 Nov 2005 00:52:32 -0600 Received: (from hch@localhost) by naboo.americas.sgi.com (8.13.3/8.13.3/Submit) id jA96qVZ3017655; Wed, 9 Nov 2005 00:52:31 -0600 Date: Wed, 9 Nov 2005 00:52:31 -0600 From: Christoph Hellwig Message-Id: <200511090652.jA96qVZ3017655@naboo.americas.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Subject: TAKE 945482 - remove unused IGET_NOALLOC flag X-archive-position: 6541 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@relay.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 821 Lines: 23 Date: Tue Nov 8 22:52:20 PST 2005 Workarea: naboo.americas.sgi.com:/go/space/hch/xfs-2.6.x Inspected by: felixb The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: xfs-linux:xfs-kern:201883a fs/xfs/linux-2.6/xfs_vfs.h - 1.56 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_vfs.h.diff?r1=text&tr1=1.56&r2=text&tr2=1.55&f=h - remove unused IGET_NOALLOC flag fs/xfs/linux-2.6/xfs_super.c - 1.349 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_super.c.diff?r1=text&tr1=1.349&r2=text&tr2=1.348&f=h - remove unused IGET_NOALLOC flag fs/xfs/linux-2.4/xfs_vfs.h - 1.57 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_vfs.h.diff?r1=text&tr1=1.57&r2=text&tr2=1.56&f=h - remove unused IGET_NOALLOC flag From owner-linux-xfs@oss.sgi.com Tue Nov 8 23:16:04 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 08 Nov 2005 23:16:07 -0800 (PST) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jA97G4O0006059 for ; Tue, 8 Nov 2005 23:16:04 -0800 Received: from internal-mail-relay.corp.sgi.com (internal-mail-relay.corp.sgi.com [198.149.32.51]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id jA98MCWA001818 for ; Wed, 9 Nov 2005 00:22:12 -0800 Received: from naboo.americas.sgi.com (naboo.americas.sgi.com [128.162.233.73]) by internal-mail-relay.corp.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id jA97Bk2Z285177801; Tue, 8 Nov 2005 23:11:46 -0800 (PST) Received: from naboo.americas.sgi.com (localhost [127.0.0.1]) by naboo.americas.sgi.com (8.13.3/8.13.3) with ESMTP id jA97Bkna019812; Wed, 9 Nov 2005 01:11:46 -0600 Received: (from hch@localhost) by naboo.americas.sgi.com (8.13.3/8.13.3/Submit) id jA97BjOA019811; Wed, 9 Nov 2005 01:11:45 -0600 Date: Wed, 9 Nov 2005 01:11:45 -0600 From: Christoph Hellwig Message-Id: <200511090711.jA97BjOA019811@naboo.americas.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Subject: PARTIAL TAKE 945483 - handle error returns from freeze_bdev X-archive-position: 6542 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@relay.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 628 Lines: 19 Date: Tue Nov 8 23:11:31 PST 2005 Workarea: naboo.americas.sgi.com:/go/space/hch/xfs-2.6.x 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:201884a fs/xfs/xfs_fsops.c - 1.110 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_fsops.c.diff?r1=text&tr1=1.110&r2=text&tr2=1.109&f=h - handle error returns from freeze_bdev fs/xfs/linux-2.6/xfs_iops.c - 1.230 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_iops.c.diff?r1=text&tr1=1.230&r2=text&tr2=1.229&f=h - handle error returns from freeze_bdev From owner-linux-xfs@oss.sgi.com Wed Nov 9 08:59:01 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 09 Nov 2005 08:59:07 -0800 (PST) Received: from tirith.ics.muni.cz (tirith.ics.muni.cz [147.251.4.36]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jA9GwxO0031127 for ; Wed, 9 Nov 2005 08:59:00 -0800 Received: from anxur.fi.muni.cz (anxur.fi.muni.cz [147.251.48.3]) by tirith.ics.muni.cz (8.13.2/8.13.2) with ESMTP id jA9GtdD0024370; Wed, 9 Nov 2005 17:55:40 +0100 Received: by anxur.fi.muni.cz (Postfix, from userid 11561) id 404F422B380; Wed, 9 Nov 2005 17:55:39 +0100 (CET) Date: Wed, 9 Nov 2005 17:55:39 +0100 From: Jan Kasprzak To: Nathan Scott Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: XFS information leak during crash Message-ID: <20051109165539.GC2572@fi.muni.cz> References: <20051102212722.GC6759@fi.muni.cz> <20051103101107.O6239737@wobbly.melbourne.sgi.com> <20051102233629.GD6759@fi.muni.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051102233629.GD6759@fi.muni.cz> User-Agent: Mutt/1.4.1i X-Muni-Spam-TestIP: 147.251.48.3 X-Muni-Envelope-From: kas@fi.muni.cz X-Muni-Virus-Test: Clean X-archive-position: 6543 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kas@fi.muni.cz Precedence: bulk X-list: linux-xfs Content-Length: 1856 Lines: 45 Jan Kasprzak wrote: : Nathan Scott wrote: : : : : This issue affects every filesystem, right? Or are you claiming its : : only XFS affected here? Have you run your parallel-buffered-writers : : test case on any other filesystems? I'd be interested in the results, : : in particular, with all of the data=xxx modes of other filesystems. : : : I will do this tomorrow or the day after and post the results. : Sorry for the delay - I did the test on other filesystems as well: "random" (i.e. not rewritten) data after the hard reset were inside the files in the following filesystems: XFS ext3 data=writeback JFS and my test program did not manage to put those "random" blocks into the files when running on ext3 with data=ordered mode (as expected). I have tried ReiserFS as well, with mixed results: - when I hit "reset" soon enough (but well after the HDD LED starts blinking), I end up with an empty directory after the reboot. It seems ReiserFS caches the filesystem operations much longer than other filesystems. - I have not seen truly random data in the files on ReiserFS after the hard reset, but I have seen blocks of zeros instead of either old or new data. This may be a pure coincidence, so ReiserFS may belong to the same group as ext3 with data=writeback mode, but I was not able to make the files contain truly random blocks by hitting the reset button. So, does ReiserFS do some kind of data journaling/ordering as well? -Yenya -- | Jan "Yenya" Kasprzak | | GPG: ID 1024/D3498839 Fingerprint 0D99A7FB206605D7 8B35FCDE05B18A5E | | http://www.fi.muni.cz/~kas/ Journal: http://www.fi.muni.cz/~kas/blog/ | > Specs are a basis for _talking_about_ things. But they are _not_ a basis < > for implementing software. --Linus Torvalds < From owner-linux-xfs@oss.sgi.com Thu Nov 10 01:56:11 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 10 Nov 2005 01:56:15 -0800 (PST) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jAA9uAO0014840 for ; Thu, 10 Nov 2005 01:56:11 -0800 Received: from hastur.corp.sgi.com (hastur.corp.sgi.com [198.149.32.33]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id jAAB2QHU016111 for ; Thu, 10 Nov 2005 03:02:26 -0800 Received: from naboo.americas.sgi.com (naboo.americas.sgi.com [128.162.233.73]) by hastur.corp.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id jAA9paeS212407272; Thu, 10 Nov 2005 01:51:37 -0800 (PST) Received: from naboo.americas.sgi.com (localhost [127.0.0.1]) by naboo.americas.sgi.com (8.13.3/8.13.3) with ESMTP id jAA9piL8016449; Thu, 10 Nov 2005 03:51:44 -0600 Received: (from hch@localhost) by naboo.americas.sgi.com (8.13.3/8.13.3/Submit) id jAA9piqm016448; Thu, 10 Nov 2005 03:51:44 -0600 Date: Thu, 10 Nov 2005 03:51:44 -0600 From: Christoph Hellwig Message-Id: <200511100951.jAA9piqm016448@naboo.americas.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Subject: TAKE 912426 - enable write barriers by default X-archive-position: 6544 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@relay.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 666 Lines: 19 Date: Thu Nov 10 01:51:31 PST 2005 Workarea: naboo.americas.sgi.com:/go/space/hch/xfs-2.6.x 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:201981a fs/xfs/xfs_vfsops.c - 1.486 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vfsops.c.diff?r1=text&tr1=1.486&r2=text&tr2=1.485&f=h - enable write barriers by default, add nobarrier mount option fs/xfs/linux-2.6/xfs_super.c - 1.350 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_super.c.diff?r1=text&tr1=1.350&r2=text&tr2=1.349&f=h - check for barrier-disabling conditions just once From owner-linux-xfs@oss.sgi.com Thu Nov 10 11:14:51 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 10 Nov 2005 11:14:54 -0800 (PST) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.200]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jAAJEpO0003505 for ; Thu, 10 Nov 2005 11:14:51 -0800 Received: by xproxy.gmail.com with SMTP id s12so689511wxc for ; Thu, 10 Nov 2005 11:11:32 -0800 (PST) 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=SAWkKLGT4G4zZUsQedXMq+Xh9uTiBxBJRn/GAmq+iR5gOfVBFBltXNXAaj3um5RCYM+3DHMywCAxHXmRMKqLGmwrSYnfzsMD28W/+NmUFoX23T6PZ+NicYJzue59kCyYY/EgIFj50wf/x8SgP0C0Y+FFMS1rCuRSxU8JtJMCwt4= Received: by 10.65.155.17 with SMTP id h17mr1316577qbo; Thu, 10 Nov 2005 11:11:32 -0800 (PST) Received: by 10.64.53.13 with HTTP; Thu, 10 Nov 2005 11:11:32 -0800 (PST) Message-ID: Date: Thu, 10 Nov 2005 19:11:32 +0000 From: Roger Willcocks To: linux-xfs@oss.sgi.com Subject: clearing 'flag unwritten extents' MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id jAAJEpO0003509 X-archive-position: 6545 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: willcor@gmail.com Precedence: bulk X-list: linux-xfs Content-Length: 164 Lines: 8 xfs_db has an option (version extflg) for setting the 'flag unwritten extents' bit in the superblock(s), but no way of clearing it. Is this deliberate? -- Roger From owner-linux-xfs@oss.sgi.com Thu Nov 10 12:37:49 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 10 Nov 2005 12:37:56 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id jAAKblO0013106 for ; Thu, 10 Nov 2005 12:37:48 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id HAA26983; Fri, 11 Nov 2005 07:34:23 +1100 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id jAAKYbkt6518858; Fri, 11 Nov 2005 07:34:37 +1100 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id jAAKYZs26463513; Fri, 11 Nov 2005 07:34:35 +1100 (EST) Date: Fri, 11 Nov 2005 07:34:35 +1100 From: Nathan Scott To: Roger Willcocks Cc: linux-xfs@oss.sgi.com Subject: Re: clearing 'flag unwritten extents' Message-ID: <20051111073434.B6484324@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 willcor@gmail.com on Thu, Nov 10, 2005 at 07:11:32PM +0000 X-archive-position: 6546 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 342 Lines: 14 On Thu, Nov 10, 2005 at 07:11:32PM +0000, Roger Willcocks wrote: > xfs_db has an option (version extflg) for setting the 'flag unwritten > extents' bit in the superblock(s), but no way of clearing it. > > Is this deliberate? Yes, once set unwritten extents may have been used, and there's no going back at that point. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Nov 10 14:00:29 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 10 Nov 2005 14:00:33 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id jAAM0RO0018192 for ; Thu, 10 Nov 2005 14:00:28 -0800 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA28993; Fri, 11 Nov 2005 08:57:04 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id B3D2049E5F3E; Fri, 11 Nov 2005 08:57:03 +1100 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 944820 - fix wrap on large direct writes Message-Id: <20051110215703.B3D2049E5F3E@chook.melbourne.sgi.com> Date: Fri, 11 Nov 2005 08:57:03 +1100 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 6547 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 498 Lines: 15 Fix a 32 bit value wraparound when providing a mapping for a large direct write. Date: Fri Nov 11 08:55:41 AEDT 2005 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:24351a linux-2.6/xfs_aops.c - 1.101 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_aops.c.diff?r1=text&tr1=1.101&r2=text&tr2=1.100&f=h From owner-linux-xfs@oss.sgi.com Thu Nov 10 21:13:18 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 10 Nov 2005 21:13:24 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id jAB5DGO0020954 for ; Thu, 10 Nov 2005 21:13:17 -0800 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA09361; Fri, 11 Nov 2005 16:09:53 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id EE39049E5F42; Fri, 11 Nov 2005 16:09:51 +1100 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: PARTIAL TAKE 945264 - quota inode allocation tweak Message-Id: <20051111050951.EE39049E5F42@chook.melbourne.sgi.com> Date: Fri, 11 Nov 2005 16:09:51 +1100 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 6548 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 466 Lines: 14 Do not inherit properties for the quota inodes from the root inode. Date: Fri Nov 11 16:09:10 AEDT 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: hch The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:24366a quota/xfs_qm.c - 1.30 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_qm.c.diff?r1=text&tr1=1.30&r2=text&tr2=1.29&f=h From owner-linux-xfs@oss.sgi.com Thu Nov 10 21:17:36 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 10 Nov 2005 21:17:39 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id jAB5HUO0021455 for ; Thu, 10 Nov 2005 21:17:35 -0800 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA09411; Fri, 11 Nov 2005 16:14:02 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 6E04349E5F42; Fri, 11 Nov 2005 16:14:02 +1100 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: PARTIAL TAKE 945264 - di_extsize Message-Id: <20051111051402.6E04349E5F42@chook.melbourne.sgi.com> Date: Fri, 11 Nov 2005 16:14:02 +1100 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 6549 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1501 Lines: 30 Implement the di_extsize allocator hint for non-realtime files as well. Also provides a mechanism for inheriting this property from the parent directory for new files. Date: Fri Nov 11 16:13:30 AEDT 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: overby@sgi.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:24367a xfsidbg.c - 1.288 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfsidbg.c.diff?r1=text&tr1=1.288&r2=text&tr2=1.287&f=h xfs_vnodeops.c - 1.657 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vnodeops.c.diff?r1=text&tr1=1.657&r2=text&tr2=1.656&f=h xfs_fs.h - 1.28 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_fs.h.diff?r1=text&tr1=1.28&r2=text&tr2=1.27&f=h xfs_inode.c - 1.422 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode.c.diff?r1=text&tr1=1.422&r2=text&tr2=1.421&f=h xfs_bmap.h - 1.92 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bmap.h.diff?r1=text&tr1=1.92&r2=text&tr2=1.91&f=h xfs_bmap.c - 1.336 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bmap.c.diff?r1=text&tr1=1.336&r2=text&tr2=1.335&f=h xfs_dinode.h - 1.77 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dinode.h.diff?r1=text&tr1=1.77&r2=text&tr2=1.76&f=h xfs_iomap.c - 1.41 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_iomap.c.diff?r1=text&tr1=1.41&r2=text&tr2=1.40&f=h From owner-linux-xfs@oss.sgi.com Thu Nov 10 21:33:55 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 10 Nov 2005 21:33:58 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id jAB5XsO0022568 for ; Thu, 10 Nov 2005 21:33:54 -0800 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA09897; Fri, 11 Nov 2005 16:30:30 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 430A749E5F42; Fri, 11 Nov 2005 16:30:29 +1100 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: PARTIAL TAKE 945264 - di_extsize userspace support Message-Id: <20051111053029.430A749E5F42@chook.melbourne.sgi.com> Date: Fri, 11 Nov 2005 16:30:29 +1100 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 6550 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1504 Lines: 28 Implement the di_extsize allocator hint for non-realtime files as well. Also provides a mechanism for inheriting this property from the parent directory for new files. Date: Fri Nov 11 16:29:47 AEDT 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-cmds Inspected by: tes@sgi.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:24368a xfsprogs/db/inode.c - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/db/inode.c.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h xfsprogs/include/xfs_fs.h - 1.37 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_fs.h.diff?r1=text&tr1=1.37&r2=text&tr2=1.36&f=h xfsprogs/include/xfs_dinode.h - 1.19 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_dinode.h.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h xfsprogs/repair/dinode.c - 1.21 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/repair/dinode.c.diff?r1=text&tr1=1.21&r2=text&tr2=1.20&f=h xfsprogs/io/open.c - 1.21 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/io/open.c.diff?r1=text&tr1=1.21&r2=text&tr2=1.20&f=h xfsprogs/man/man3/xfsctl.3 - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/man/man3/xfsctl.3.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h xfsprogs/io/attr.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/io/attr.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h From owner-linux-xfs@oss.sgi.com Thu Nov 10 21:42:12 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 10 Nov 2005 21:42:16 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id jAB5gAO0023257 for ; Thu, 10 Nov 2005 21:42:11 -0800 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA10003; Fri, 11 Nov 2005 16:38:47 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 3A07749E5F44; Fri, 11 Nov 2005 16:38:47 +1100 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: PARTIAL TAKE 945264 - mkfs and inheritable bits Message-Id: <20051111053847.3A07749E5F44@chook.melbourne.sgi.com> Date: Fri, 11 Nov 2005 16:38:47 +1100 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 6551 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1447 Lines: 27 Provide mkfs options to easily exercise all inheritable attributes, esp. the extsize allocator hint. Date: Fri Nov 11 16:38:12 AEDT 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-cmds Inspected by: tes@sgi.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:24370a xfsprogs/mkfs/proto.c - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/mkfs/proto.c.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h xfsprogs/mkfs/xfs_mkfs.c - 1.67 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/mkfs/xfs_mkfs.c.diff?r1=text&tr1=1.67&r2=text&tr2=1.66&f=h xfsprogs/mkfs/xfs_mkfs.h - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/mkfs/xfs_mkfs.h.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h xfsprogs/include/libxfs.h - 1.44 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/libxfs.h.diff?r1=text&tr1=1.44&r2=text&tr2=1.43&f=h xfsprogs/repair/phase6.c - 1.21 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/repair/phase6.c.diff?r1=text&tr1=1.21&r2=text&tr2=1.20&f=h xfsprogs/libxfs/xfs.h - 1.50 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/xfs.h.diff?r1=text&tr1=1.50&r2=text&tr2=1.49&f=h xfsprogs/libxfs/util.c - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/libxfs/util.c.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h From owner-linux-xfs@oss.sgi.com Thu Nov 10 21:44:42 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 10 Nov 2005 21:44:46 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id jAB5ieO0023720 for ; Thu, 10 Nov 2005 21:44:41 -0800 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA10039; Fri, 11 Nov 2005 16:41:18 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 009A849E5F44; Fri, 11 Nov 2005 16:41:16 +1100 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 941645 - mkfs and attr2 Message-Id: <20051111054116.009A849E5F44@chook.melbourne.sgi.com> Date: Fri, 11 Nov 2005 16:41:16 +1100 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 6552 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 981 Lines: 20 Report inline attr version, and allow mkfs to explicitly set it too. Date: Fri Nov 11 16:40:55 AEDT 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-cmds Inspected by: gwehrman@sgi.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:24371a xfsprogs/man/man8/mkfs.xfs.8 - 1.25 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/man/man8/mkfs.xfs.8.diff?r1=text&tr1=1.25&r2=text&tr2=1.24&f=h xfsprogs/mkfs/xfs_mkfs.c - 1.68 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/mkfs/xfs_mkfs.c.diff?r1=text&tr1=1.68&r2=text&tr2=1.67&f=h xfsprogs/growfs/xfs_growfs.c - 1.22 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/growfs/xfs_growfs.c.diff?r1=text&tr1=1.22&r2=text&tr2=1.21&f=h xfsprogs/include/xfs_sb.h - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_sb.h.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h From owner-linux-xfs@oss.sgi.com Thu Nov 10 21:59:05 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 10 Nov 2005 21:59:10 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id jAB5x3O0024852 for ; Thu, 10 Nov 2005 21:59:04 -0800 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA10430 for ; Fri, 11 Nov 2005 16:55:43 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 4BFE049E5F44; Fri, 11 Nov 2005 16:55:42 +1100 (EST) To: linux-xfs@oss.sgi.com Subject: TAKE 907752 - bump xfsprogs version Message-Id: <20051111055542.4BFE049E5F44@chook.melbourne.sgi.com> Date: Fri, 11 Nov 2005 16:55:42 +1100 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 6553 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 764 Lines: 18 Bump xfsprogs version for recent set of changes. Date: Fri Nov 11 16:55:26 AEDT 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-cmds Inspected by: nathans The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:24377a xfsprogs/VERSION - 1.138 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/VERSION.diff?r1=text&tr1=1.138&r2=text&tr2=1.137&f=h xfsprogs/doc/CHANGES - 1.182 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/doc/CHANGES.diff?r1=text&tr1=1.182&r2=text&tr2=1.181&f=h xfsprogs/debian/changelog - 1.124 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/debian/changelog.diff?r1=text&tr1=1.124&r2=text&tr2=1.123&f=h From owner-linux-xfs@oss.sgi.com Thu Nov 10 23:43:47 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 10 Nov 2005 23:43:51 -0800 (PST) Received: from av10-2-sn2.hy.skanova.net (av10-2-sn2.hy.skanova.net [81.228.8.182]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jAB7hjO0030768 for ; Thu, 10 Nov 2005 23:43:47 -0800 Received: by av10-2-sn2.hy.skanova.net (Postfix, from userid 502) id 3A64C382D4; Fri, 11 Nov 2005 08:40:26 +0100 (CET) Received: from smtp4-1-sn2.hy.skanova.net (smtp4-1-sn2.hy.skanova.net [81.228.8.92]) by av10-2-sn2.hy.skanova.net (Postfix) with ESMTP id 2C8CF38273 for ; Fri, 11 Nov 2005 08:40:26 +0100 (CET) Received: from sparhawk.rikjoh.com (h18n1fls31o827.telia.com [213.65.4.18]) by smtp4-1-sn2.hy.skanova.net (Postfix) with ESMTP id 02CB737E46 for ; Fri, 11 Nov 2005 08:40:25 +0100 (CET) From: Rikard Johnels To: linux-xfs@oss.sgi.com Subject: Older XFS incompatible with Linux? Date: Fri, 11 Nov 2005 08:40:23 +0100 User-Agent: KMail/1.8.2 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Message-Id: <200511110840.24017.rikard.j@rikjoh.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id jAB7hlO0030770 X-archive-position: 6554 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: rikard.j@rikjoh.com Precedence: bulk X-list: linux-xfs Content-Length: 4232 Lines: 119 Hello! I hope this is the right place to ask this question. If it isn't; please point me to where i can find a hint (or the answer) I am trying to mount a older SGI harddrive on a SuSE 9.3 system. I think it is a 5.x or maybe a 6.3 version of IRIX. Not too sure about that as i haven't been able to confirm it at all. After loading the linux kernel SCSI driver for my controller card, it detects the drive ok, But i cant mount anything. I need to recover some files from it and have no access to a SGI box. fdisk shows: Disk /dev/sda (SGI disk label): 64 heads, 32 sectors, 522 cylinders Units = cylinders of 2048 * 512 bytes ----- partitions ----- Pt# Device Info Start End Sectors Id System 1: /dev/sda1 boot 2 470 960925 a SGI xfs 2: /dev/sda2 swap 471 510 81920 3 SGI raw 9: /dev/sda3 0 1 2584 0 SGI volhdr 11: /dev/sda4 0 522 1070422 6 SGI volume ----- Bootinfo ----- Bootfile: /unix ----- Directory Entries ----- 0: sgilabel sector 2 size 512 1: ide sector 3 size 283648 2: sash sector 557 size 283648 Disk /dev/sda9 (SGI disk label): 64 heads, 32 sectors, 1 cylinders Units = cylinders of 2048 * 512 bytes ----- partitions ----- Pt# Device Info Start End Sectors Id System 1: /dev/sda9p1 boot 2 470 960925 a SGI xfs 2: /dev/sda9p2 swap 471 510 81920 3 SGI raw 9: /dev/sda9p3 0 1 2584 0 SGI volhdr 11: /dev/sda9p4 0 522 1070422 6 SGI volume ----- Bootinfo ----- Bootfile: /unix ----- Directory Entries ----- 0: sgilabel sector 2 size 512 1: ide sector 3 size 283648 2: sash sector 557 size 283648 Disk /dev/sda11 (SGI disk label): 64 heads, 32 sectors, 522 cylinders Units = cylinders of 2048 * 512 bytes ----- partitions ----- Pt# Device Info Start End Sectors Id System 1: /dev/sda11p1 boot 2 470 960925 a SGI xfs 2: /dev/sda11p2 swap 471 510 81920 3 SGI raw 9: /dev/sda11p3 0 1 2584 0 SGI volhdr 11: /dev/sda11p4 0 522 1070422 6 SGI volume ----- Bootinfo ----- Bootfile: /unix ----- Directory Entries ----- 0: sgilabel sector 2 size 512 1: ide sector 3 size 283648 2: sash sector 557 size 283648 mount /dev/sda1 /media/cdrom/ mount: /dev/sda1: can't read superblock desktop:~ # mount /dev/sda4 /media/cdrom/ mount: /dev/sda4 is not a valid block device desktop:~ # mount /dev/sda11 /media/cdrom/ mount: wrong fs type, bad option, bad superblock on /dev/sda11, missing codepage or other error In some cases useful info is found in syslog - try dmesg | tail or so desktop:~ # dmesg |tail XFS mounting filesystem sda1 XFS: nil uuid in log - IRIX style log Starting XFS recovery on filesystem: sda1 (dev: sda1) XFS: dirty log written in incompatible format - can't recover XFS: log mount/recovery failed: error 5 XFS: log mount failed EFS: partition table contained no EFS partitions desktop:~ # mount -t udf /dev/sda11 /media/cdrom/ mount: wrong fs type, bad option, bad superblock on /dev/sda11, missing codepage or other error In some cases useful info is found in syslog - try dmesg | tail or so desktop:~ # dmesg |tail XFS mounting filesystem sda1 XFS: nil uuid in log - IRIX style log Starting XFS recovery on filesystem: sda1 (dev: sda1) XFS: dirty log written in incompatible format - can't recover XFS: log mount/recovery failed: error 5 XFS: log mount failed EFS: partition table contained no EFS partitions UDF-fs: No VRS found Does this mean the filesystem is incompatible with my XFS driver for Linux? How can i mount this system and recover the files? TIA --  --          /Rikard ----------------------------------------------------------------------------- email   : rikard.j@rikjoh.com web     : http://www.rikjoh.com mob     : +46 (0)736 19 76 25 ------------------------ Public PGP fingerprint ---------------------------- < 15 28 DF 78 67 98 B2 16 1F D3 FD C5 59 D4 B6 78  46 1C EE 56 > From owner-linux-xfs@oss.sgi.com Fri Nov 11 04:52:08 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 11 Nov 2005 04:52:11 -0800 (PST) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.196]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jABCq7O0028081 for ; Fri, 11 Nov 2005 04:52:07 -0800 Received: by xproxy.gmail.com with SMTP id s11so497777wxc for ; Fri, 11 Nov 2005 04:48:48 -0800 (PST) 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=ZbPjtyYWDjKpGmqWJv+KFVCy9dFs+FNyi+S8YR2tvmQvffsvDIq1DlL+5Yy8cJjfnCWKBC0qU+vmL6RFh/pOOpOlml3zHkC5xvsqQrM3rG4P0qY6TVJV/Px6GJM3yEZReBo9KhjfbU3P5WnmVOLotqCf7DTJ1Ih9nOFoJx9SYrE= Received: by 10.65.158.1 with SMTP id k1mr2325499qbo; Fri, 11 Nov 2005 04:48:48 -0800 (PST) Received: by 10.64.53.13 with HTTP; Fri, 11 Nov 2005 04:48:48 -0800 (PST) Message-ID: Date: Fri, 11 Nov 2005 12:48:48 +0000 From: Roger Willcocks To: Nathan Scott Subject: Re: clearing 'flag unwritten extents' Cc: linux-xfs@oss.sgi.com In-Reply-To: <20051111073434.B6484324@wobbly.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <20051111073434.B6484324@wobbly.melbourne.sgi.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id jABCq8O0028083 X-archive-position: 6555 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: willcor@gmail.com Precedence: bulk X-list: linux-xfs Content-Length: 960 Lines: 32 > once [the flag unwritten extents option is] set unwritten extents may > have been used, and there's no going back at that point. I'd like to understand this a bit more - is this a security issue or an architectural one? AIUI, the 'flag unwritten extents' option allows non-root users to preallocate unwritten extents (root can always create them). Clearing the option would just prevent the creation of new unwritten extents. The system would still do the right thing with previously flagged extents. Or am I missing something? -- Roger On 11/10/05, Nathan Scott wrote: > On Thu, Nov 10, 2005 at 07:11:32PM +0000, Roger Willcocks wrote: > > xfs_db has an option (version extflg) for setting the 'flag unwritten > > extents' bit in the superblock(s), but no way of clearing it. > > > > Is this deliberate? > > Yes, once set unwritten extents may have been used, and there's > no going back at that point. > > cheers. > > -- > Nathan > From owner-linux-xfs@oss.sgi.com Fri Nov 11 05:36:42 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 11 Nov 2005 05:36:44 -0800 (PST) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jABDafO0031409 for ; Fri, 11 Nov 2005 05:36:41 -0800 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 jABDXMxT029045 for ; Fri, 11 Nov 2005 07:33:22 -0600 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 jABDXKOS4468414; Fri, 11 Nov 2005 05:33:21 -0800 (PST) Message-ID: <43749DA0.9080909@sgi.com> Date: Fri, 11 Nov 2005 07:33:20 -0600 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rikard Johnels CC: linux-xfs@oss.sgi.com Subject: Re: Older XFS incompatible with Linux? References: <200511110840.24017.rikard.j@rikjoh.com> In-Reply-To: <200511110840.24017.rikard.j@rikjoh.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6556 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1738 Lines: 51 Hi Rikard - This is somewhat of a FAQ: http://oss.sgi.com/projects/xfs/faq.html#useirixxfs Rikard Johnels wrote: > desktop:~ # dmesg |tail > > XFS mounting filesystem sda1 > XFS: nil uuid in log - IRIX style log > Starting XFS recovery on filesystem: sda1 (dev: sda1) > XFS: dirty log written in incompatible format - can't recover the log is dirty, and Linux cannot replay it because it is an irix style log. Therefore you either need to cleanly mount/unmount the fs on Irix (not possible for you, I guess), or you could try mount -o norecovery,ro to skip the log replay, or as a last resort, use xfs_repair to zero out the log (possibly throwing away important information - I'd strongly suggest making a disk image before you do this, and do the operation on the image, not the original disk - just so you can go back if you need to) -Eric > XFS: log mount/recovery failed: error 5 > XFS: log mount failed > EFS: partition table contained no EFS partitions > > desktop:~ # mount -t udf /dev/sda11 /media/cdrom/ > mount: wrong fs type, bad option, bad superblock on /dev/sda11, > missing codepage or other error > In some cases useful info is found in syslog - try > dmesg | tail or so > > desktop:~ # dmesg |tail > > XFS mounting filesystem sda1 > XFS: nil uuid in log - IRIX style log > Starting XFS recovery on filesystem: sda1 (dev: sda1) > XFS: dirty log written in incompatible format - can't recover > XFS: log mount/recovery failed: error 5 > XFS: log mount failed > EFS: partition table contained no EFS partitions > UDF-fs: No VRS found > > Does this mean the filesystem is incompatible with my XFS driver for Linux? > How can i mount this system and recover the files? > > > TIA > From owner-linux-xfs@oss.sgi.com Sun Nov 13 10:51:27 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 13 Nov 2005 10:51:32 -0800 (PST) Received: from sbapexch02.ad.corp.expertcity.com (216-219-126-102.expertcity.com [216.219.126.102] (may be forged)) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jADIpOO0005588 for ; Sun, 13 Nov 2005 10:51:27 -0800 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: FYI: mount: Unknown error 990 Date: Sun, 13 Nov 2005 10:48:03 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FYI: mount: Unknown error 990 Thread-Index: AcXogseoFh+BTYhRQCKrATP7HY2JaA== From: "Michael Ramsey" To: Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit X-archive-position: 6559 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Michael.Ramsey@citrix.com Precedence: bulk X-list: linux-xfs Content-Length: 2357 Lines: 83 Mount /dev/raidvol2/vol1 /u02 mount: Unknown error 990 Dmesg shows: XFS mounting filesystem dm-0 Starting XFS recovery on filesystem: dm-0 (dev: dm-0) Filesystem "dm-0": XFS internal error xlog_valid_rec_header(1) at line 3500 of f ile fs/xfs/xfs_log_recover.c. Caller 0xffffffff8820a005 Call Trace:{:xfs:xlog_valid_rec_header+228} {:xfs:xlog_do_recovery_pass+494} {:xfs:cmn_err+280} {:xfs:xlog_recover +180} {:xfs:xfs_log_mount+1438} {:xfs:xfs_m ountfs+1863} {:xfs:.text.lock.xfs_buf+15} {_atomic _dec_and_lock+41} {:xfs:xfs_setsize_buftarg_flags+50} {:xfs:xfs_mount+1837} {:xfs:linvfs_fi ll_super+0} {:xfs:linvfs_fill_super+0} {:xfs:linv fs_fill_super+147} {:xfs:linvfs_fill_super+0} {snprintf+ 131} {__down_write+52} {strlcpy+56} {get_filesystem+18} {sget+1085} {set_bdev_super+0} {get_sb_bdev+275} {do_kern_mount+161} {do_mount+1701} {__up_read+19} {do_page_fault+1171} {handle_mm_fault+399} {error_exit+0} {copy_mount_options+218} {sys_mount+1 39} {system_call+126} XFS: log mount/recovery failed: error 990 XFS: log mount failed I had to xfs_recover -L /dev/raidvol2/vol1 File system came back up.... Michael Ramsey Citrix Online Division Citrix Systems, Inc. 5385 Hollister Avenue Santa Barbara, CA 93111 USA www.citrix.com Phone: 805.690.2909 Cell: 805.452.4483 CONFIDENTIALITY NOTICE > This e-mail message and all documents which accompany it are intended only for the use of the individual or entity to which addressed, and may contain privileged or confidential information. Any unauthorized disclosure or distribution of this e-mail message is prohibited. If you have received this e-mail message in error, please notify me immediately. Thank you. [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Sun Nov 13 14:16:56 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 13 Nov 2005 14:17:02 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id jADMGsO0026524 for ; Sun, 13 Nov 2005 14:16:55 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA12428; Mon, 14 Nov 2005 09:13:28 +1100 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id jADMDdkt6569577; Mon, 14 Nov 2005 09:13:39 +1100 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id jADMDbYu6502848; Mon, 14 Nov 2005 09:13:37 +1100 (EST) Date: Mon, 14 Nov 2005 09:13:37 +1100 From: Nathan Scott To: Roger Willcocks Cc: linux-xfs@oss.sgi.com Subject: Re: clearing 'flag unwritten extents' Message-ID: <20051114091337.P6499030@wobbly.melbourne.sgi.com> References: <20051111073434.B6484324@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 willcor@gmail.com on Fri, Nov 11, 2005 at 12:48:48PM +0000 X-archive-position: 6560 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 450 Lines: 14 On Fri, Nov 11, 2005 at 12:48:48PM +0000, Roger Willcocks wrote: > AIUI, the 'flag unwritten extents' option allows non-root users to > preallocate unwritten extents (root can always create them). Clearing > the option would just prevent the creation of new unwritten extents. It does more than just that - in xfs_bmapi it changes the way extents are handled - look for XFS_SB_VERSION_HASEXTFLGBIT in xfs_bmap.c in particular. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Nov 13 14:25:12 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 13 Nov 2005 14:25:14 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id jADMPAO0027435 for ; Sun, 13 Nov 2005 14:25:11 -0800 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA12639; Mon, 14 Nov 2005 09:21:46 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 7044849E5F44; Mon, 14 Nov 2005 09:21:45 +1100 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 912426 - barrier argument handling typo Message-Id: <20051113222145.7044849E5F44@chook.melbourne.sgi.com> Date: Mon, 14 Nov 2005 09:21:45 +1100 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 6561 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 477 Lines: 15 Fix typo from when enabling write barriers by default, flags botch in showargs. Date: Mon Nov 14 09:21:04 AEDT 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: hch The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:24383a xfs_vfsops.c - 1.487 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vfsops.c.diff?r1=text&tr1=1.487&r2=text&tr2=1.486&f=h From owner-linux-xfs@oss.sgi.com Mon Nov 14 07:01:21 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 14 Nov 2005 07:01:26 -0800 (PST) Received: from seanic11.net (w11-6.dnslinks.net [207.44.157.90]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id jAEF1KO0026308 for ; Mon, 14 Nov 2005 07:01:20 -0800 Received: (qmail 1195 invoked from network); 14 Nov 2005 14:58:11 -0000 Received: from unknown (HELO jupiter.solar.net) (162.40.171.85) by localhost with SMTP; 14 Nov 2005 14:58:11 -0000 From: Joe Bacom Reply-To: joe@docsimple.com To: linux-xfs@oss.sgi.com Subject: xfsdump question Date: Mon, 14 Nov 2005 08:57:58 -0600 User-Agent: KMail/1.7.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200511140857.58674.joe@docsimple.com> X-archive-position: 6563 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: joe@docsimple.com Precedence: bulk X-list: linux-xfs Content-Length: 1051 Lines: 27 First, I have a normal backup routine that is incremental Monday thru Saturday and full dump on Sunday. Second, I recently installed a new primary disk drive and used xfsdump / xfsrestore (i.e. xfsdump -J - / | xfsrestore -J - /newroot) to duplicate my old drive. This was done on Sunday after the full backup ran. When my incremental (level 1) ran this morning, I got the following error message for all of my partitions. /sbin/xfsdump: using file dump (drive_simple) strategy /sbin/xfsdump: version 2.2.21 (dump format 3.0) - Running single-threaded /sbin/xfsdump: ERROR: cannot calculate incremental dump: online inventory not available /sbin/xfsdump: Dump Status: ERROR Am I missing something? I would have assumed that xfsdump would have captured the dump inventory and brought it across to the new partition. Thanks; Joe -- Microsoft (MS), like the disease it shares the acronym with, is a gradual loss of primary functions augmented with spastic jerks. Penguin: Linux version 2.6.8-24 on a dual i686 (combined 7951.42 BogoMips) From owner-linux-xfs@oss.sgi.com Mon Nov 14 07:46:01 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 14 Nov 2005 07:46:04 -0800 (PST) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jAEFk0O0029738 for ; Mon, 14 Nov 2005 07:46:00 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id jAEFgdxT015012 for ; Mon, 14 Nov 2005 09:42:39 -0600 Received: from [128.162.233.24] (fsgi275.americas.sgi.com [128.162.233.24]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id jAEFgdDN19879622; Mon, 14 Nov 2005 09:42:39 -0600 (CST) Message-ID: <4378B06E.6060802@sgi.com> Date: Mon, 14 Nov 2005 09:42:38 -0600 From: Bill Kendall User-Agent: Debian Thunderbird 1.0.6 (X11/20050802) X-Accept-Language: en-us, en MIME-Version: 1.0 To: joe@docsimple.com CC: linux-xfs@oss.sgi.com Subject: Re: xfsdump question References: <200511140857.58674.joe@docsimple.com> In-Reply-To: <200511140857.58674.joe@docsimple.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6564 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: wkendall@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1063 Lines: 29 On 11/14/05 08:57, Joe Bacom wrote: > First, I have a normal backup routine that is incremental Monday thru Saturday > and full dump on Sunday. > Second, I recently installed a new primary disk drive and used xfsdump / > xfsrestore (i.e. xfsdump -J - / | xfsrestore -J - /newroot) to duplicate my > old drive. This was done on Sunday after the full backup ran. > > When my incremental (level 1) ran this morning, I got the following error > message for all of my partitions. > > /sbin/xfsdump: using file dump (drive_simple) strategy > /sbin/xfsdump: version 2.2.21 (dump format 3.0) - Running single-threaded > /sbin/xfsdump: ERROR: cannot calculate incremental dump: online inventory not > available > /sbin/xfsdump: Dump Status: ERROR > > Am I missing something? I would have assumed that xfsdump would have captured > the dump inventory and brought it across to the new partition. > > Thanks; > > Joe > xfsdump does not dump the inventory files, even if they are on the filesystem being backed up. See the xfsdump man page for more info. Bill From owner-linux-xfs@oss.sgi.com Tue Nov 15 04:37:23 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 15 Nov 2005 04:37:30 -0800 (PST) Received: from tyo201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.214]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jAFCbMO0021448 for ; Tue, 15 Nov 2005 04:37:23 -0800 Received: from mailgate3.nec.co.jp (mailgate53.nec.co.jp [10.7.69.160] (may be forged)) by tyo201.gate.nec.co.jp (8.11.7/3.7W01080315) with ESMTP id jAFCXmE04494 for ; Tue, 15 Nov 2005 21:33:48 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id jAFCXmK06531 for linux-xfs@oss.sgi.com; Tue, 15 Nov 2005 21:33:48 +0900 (JST) Received: from secsv2.tnes.nec.co.jp (tnesvc1.tnes.nec.co.jp [10.1.101.14]) by mailsv3.nec.co.jp (8.11.7/3.7W-MAILSV4-NEC) with ESMTP id jAFCXmX20826 for ; Tue, 15 Nov 2005 21:33:48 +0900 (JST) Received: from TNESVC1.tnes.nec.co.jp ([10.1.101.14]) by secsv2.tnes.nec.co.jp (ExpressMail 5.10) with SMTP id 20051115.213607.28001964 for ; Tue, 15 Nov 2005 21:36:07 +0900 Received: FROM mailsv.tnes.nec.co.jp BY TNESVC1.tnes.nec.co.jp ; Tue Nov 15 21:36:06 2005 +0900 Received: from rifu.bsd.tnes.nec.co.jp (rifu.bsd.tnes.nec.co.jp [10.1.104.1]) by mailsv.tnes.nec.co.jp (8.11.6/3.7W01031510) with ESMTP id jAFCXla53021; Tue, 15 Nov 2005 21:33:47 +0900 (JST) Received: from noshiro.bsd.tnes.nec.co.jp (noshiro.bsd.tnes.nec.co.jp [10.1.104.24]) by rifu.bsd.tnes.nec.co.jp (8.12.11/3.7W/BSD-TNES-MX01) with ESMTP id jAFCXliH002505; Tue, 15 Nov 2005 21:33:47 +0900 Received: from localhost (localhost.localdomain [127.0.0.1]) by noshiro.bsd.tnes.nec.co.jp (Postfix) with ESMTP id 83FC774A65; Tue, 15 Nov 2005 21:33:47 +0900 (JST) Date: Tue, 15 Nov 2005 21:33:47 +0900 (JST) Message-Id: <20051115.213347.607955969.masano@tnes.nec.co.jp> To: linux-xfs@oss.sgi.com Cc: masano@tnes.nec.co.jp Subject: [PATCH] fix deadlock on ENOSPC From: ASANO Masahiro In-Reply-To: <20050803.175622.607955722.masano@tnes.nec.co.jp> References: <20050715.150717.28782011.masano@tnes.nec.co.jp> <42D7AA45.2040608@xfs.org> <20050803.175622.607955722.masano@tnes.nec.co.jp> X-Mailer: Mew version 3.3 on XEmacs 21.4.11 (Native Windows TTY Support) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 6565 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: masano@tnes.nec.co.jp Precedence: bulk X-list: linux-xfs Content-Length: 6365 Lines: 191 Hi SGI guys, As I previously reported, XFS has a deadlock problem on a ENOSPC device. http://oss.sgi.com/archives/linux-xfs/2005-07/msg00107.html I've noticed that XFS in 2.6.14 kernel has the same problem. The problem is that XFS may lock allocation groups (AGs) out of order if there isn't enough free space. XFS needs ascending order to lock multiple AGs in a transaction. In my inspection of the XFS allocation code, the following flaws were found. (1) xfs_alloc_fix_freelist() and xfs_alloc_ag_vextent() may touch an AGF and make it busy, though there is no available block on the AG. (2) In xfs_alloc_vextent(), the first loop of XFS_ALLOCTYPE_FIRST_AG starts at fsbno, but the second starts at AG#0. (3) xfs_bmap_alloc() calls xfs_alloc_vextent() repeatedly without attention whether some AGs have been locked. I've tried to fix the (1) behavior, but I couldn't. So I made a patch to fix (2) and (3). fs/xfs/xfs_alloc.c: recalculate agno at the beginning of the second loop of XFS_ALLOCTYPE_FIRST_AG. fs/xfs/xfs_alloc.h, fs/xfs/xfs_alloc.c, fs/xfs/xfs_trans.h, fs/xfs/xfs_trans_buf.c: release the AGF buffer if it is non-dirty. fs/xfs/xfs_bmap.c: quit if the AGF is locked, to start new transaction. fs/xfs/xfs_iomap.c: yield the CPU. It has survived from 24 hours of stress test. Any comments are welcome. Signed-off-by: ASANO Masahiro --- --- linux-2.6.14/fs/xfs/xfs_alloc.h.orig 2005-11-07 17:43:39.000000000 +0900 +++ linux-2.6.14/fs/xfs/xfs_alloc.h 2005-11-14 18:01:25.000000000 +0900 @@ -65,6 +65,7 @@ typedef struct xfs_alloc_arg { struct xfs_trans *tp; /* transaction pointer */ struct xfs_mount *mp; /* file system mount point */ struct xfs_buf *agbp; /* buffer for a.g. freelist header */ + struct xfs_buf *agflbp; /* buffer for agfl block pointer */ struct xfs_perag *pag; /* per-ag struct for this agno */ xfs_fsblock_t fsbno; /* file system block number */ xfs_agnumber_t agno; /* allocation group number */ --- linux-2.6.14/fs/xfs/xfs_alloc.c.orig 2005-11-07 12:07:29.000000000 +0900 +++ linux-2.6.14/fs/xfs/xfs_alloc.c 2005-11-14 18:15:58.000000000 +0900 @@ -1863,6 +1863,8 @@ xfs_alloc_fix_freelist( } else agbp = NULL; + args->agflbp = NULL; + /* If this is a metadata prefered pag and we are user data * then try somewhere else if we are not being asked to * try harder at this point @@ -1981,6 +1983,7 @@ xfs_alloc_fix_freelist( } } args->agbp = agbp; + args->agflbp = agflbp; return 0; } @@ -2393,6 +2396,10 @@ xfs_alloc_vextent( } if (flags == 0) { no_min = 1; + if (type == XFS_ALLOCTYPE_FIRST_AG) { + args->agno = XFS_FSB_TO_AGNO(mp, + args->fsbno); + } } else { flags = 0; if (type == XFS_ALLOCTYPE_START_BNO) { @@ -2417,9 +2424,17 @@ xfs_alloc_vextent( ASSERT(0); /* NOTREACHED */ } - if (args->agbno == NULLAGBLOCK) + if (args->agbno == NULLAGBLOCK) { + if (args->agbp && !xfs_trans_buf_is_dirty(args->tp, args->agbp)) { + xfs_trans_brelse(args->tp, args->agbp); + if (args->agflbp) { + xfs_trans_brelse(args->tp, args->agflbp); + } + args->agbp = NULL; + args->agflbp = NULL; + } args->fsbno = NULLFSBLOCK; - else { + } else { args->fsbno = XFS_AGB_TO_FSB(mp, args->agno, args->agbno); #ifdef DEBUG ASSERT(args->len >= args->minlen); --- linux-2.6.14/fs/xfs/xfs_trans.h.orig 2005-11-14 19:12:32.000000000 +0900 +++ linux-2.6.14/fs/xfs/xfs_trans.h 2005-11-14 18:27:24.000000000 +0900 @@ -996,6 +996,7 @@ int xfs_trans_read_buf(struct xfs_mount struct xfs_buf **); struct xfs_buf *xfs_trans_getsb(xfs_trans_t *, struct xfs_mount *, int); +int xfs_trans_buf_is_dirty(xfs_trans_t *, struct xfs_buf *); void xfs_trans_brelse(xfs_trans_t *, struct xfs_buf *); void xfs_trans_bjoin(xfs_trans_t *, struct xfs_buf *); void xfs_trans_bhold(xfs_trans_t *, struct xfs_buf *); --- linux-2.6.14/fs/xfs/xfs_trans_buf.c.orig 2005-11-14 18:00:26.000000000 +0900 +++ linux-2.6.14/fs/xfs/xfs_trans_buf.c 2005-11-14 18:31:05.000000000 +0900 @@ -497,6 +497,20 @@ shutdown_abort: return XFS_ERROR(EIO); } +/* + * Check if the buffer is dirty within this transaction. + */ +int +xfs_trans_buf_is_dirty(xfs_trans_t *tp, + xfs_buf_t *bp) +{ + xfs_buf_log_item_t *bip; + xfs_log_item_desc_t *lidp; + + bip = XFS_BUF_FSPRIVATE(bp, xfs_buf_log_item_t *); + lidp = xfs_trans_find_item(tp, (xfs_log_item_t*)bip); + return (lidp->lid_flags & XFS_LID_DIRTY) != 0; +} /* * Release the buffer bp which was previously acquired with one of the --- linux-2.6.14/fs/xfs/xfs_bmap.c.orig 2005-11-11 22:42:43.000000000 +0900 +++ linux-2.6.14/fs/xfs/xfs_bmap.c 2005-11-11 23:05:42.000000000 +0900 @@ -2674,9 +2674,10 @@ xfs_bmap_alloc( args.wasdel = ap->wasdel; args.isfl = 0; args.userdata = ap->userdata; + args.agbp = NULL; if ((error = xfs_alloc_vextent(&args))) return error; - if (tryagain && args.fsbno == NULLFSBLOCK) { + if (tryagain && args.fsbno == NULLFSBLOCK && args.agbp == NULL) { /* * Exact allocation failed. Now try with alignment * turned on. @@ -2690,7 +2691,7 @@ xfs_bmap_alloc( if ((error = xfs_alloc_vextent(&args))) return error; } - if (isaligned && args.fsbno == NULLFSBLOCK) { + if (isaligned && args.fsbno == NULLFSBLOCK && args.agbp == NULL) { /* * allocation failed, so turn off alignment and * try again. @@ -2702,14 +2703,14 @@ xfs_bmap_alloc( return error; } if (args.fsbno == NULLFSBLOCK && nullfb && - args.minlen > ap->minlen) { + args.minlen > ap->minlen && args.agbp == NULL) { args.minlen = ap->minlen; args.type = XFS_ALLOCTYPE_START_BNO; args.fsbno = ap->rval; if ((error = xfs_alloc_vextent(&args))) return error; } - if (args.fsbno == NULLFSBLOCK && nullfb) { + if (args.fsbno == NULLFSBLOCK && nullfb && args.agbp == NULL) { args.fsbno = 0; args.type = XFS_ALLOCTYPE_FIRST_AG; args.total = ap->minlen; --- linux-2.6.14/fs/xfs/xfs_iomap.c.orig 2005-11-07 13:01:22.000000000 +0900 +++ linux-2.6.14/fs/xfs/xfs_iomap.c 2005-11-11 23:07:35.000000000 +0900 @@ -840,6 +840,9 @@ xfs_iomap_write_allocate( goto error0; xfs_iunlock(ip, XFS_ILOCK_EXCL); + if (nimaps == 0) { + yield(); /* to prevent long CPU loop */ + } } /* From owner-linux-xfs@oss.sgi.com Tue Nov 15 07:16:42 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 15 Nov 2005 07:16:45 -0800 (PST) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.202]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jAFFGfO0000343 for ; Tue, 15 Nov 2005 07:16:42 -0800 Received: by xproxy.gmail.com with SMTP id t11so1443430wxc for ; Tue, 15 Nov 2005 07:13:20 -0800 (PST) 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=KpugipZ/QBZJfpl5nrtiWDApx24IclQmHa41XdrBv9qbEEvY0NsvP4t+z9W7S1Jtk+utzc9cjbKHGCXD+ksOyeJvjlxcsXbBm9a32E/+u4N0Y2PbckqOdF+jIz8puaWreyAGVbtGpJvP2dS2oq3fMbJ4PnY+COEpmcNou3B0iRQ= Received: by 10.65.244.12 with SMTP id w12mr880318qbr; Tue, 15 Nov 2005 07:13:19 -0800 (PST) Received: by 10.65.196.18 with HTTP; Tue, 15 Nov 2005 07:13:19 -0800 (PST) Message-ID: Date: Tue, 15 Nov 2005 15:13:19 +0000 From: Roger Willcocks To: Nathan Scott Subject: Re: clearing 'flag unwritten extents' Cc: linux-xfs@oss.sgi.com In-Reply-To: <20051114091337.P6499030@wobbly.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline References: <20051111073434.B6484324@wobbly.melbourne.sgi.com> <20051114091337.P6499030@wobbly.melbourne.sgi.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id jAFFGgO0000346 X-archive-position: 6566 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: willcor@gmail.com Precedence: bulk X-list: linux-xfs Content-Length: 571 Lines: 15 On 11/13/05, Nathan Scott wrote: > On Fri, Nov 11, 2005 at 12:48:48PM +0000, Roger Willcocks wrote: > > AIUI, the 'flag unwritten extents' option allows non-root users to > > preallocate unwritten extents (root can always create them). Clearing > > the option would just prevent the creation of new unwritten extents. > > It does more than just that - in xfs_bmapi it changes the way > extents are handled - look for XFS_SB_VERSION_HASEXTFLGBIT in > xfs_bmap.c in particular. But only for realtime extents - and I don't have any of those... -- Roger From owner-linux-xfs@oss.sgi.com Tue Nov 15 07:28:51 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 15 Nov 2005 07:28:56 -0800 (PST) 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 jAFFSpO0001526 for ; Tue, 15 Nov 2005 07:28:51 -0800 Received: from [172.16.82.67] ([172.16.82.67]) by MAIL01HQ.adic.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 15 Nov 2005 07:25:19 -0800 Message-ID: <4379FDDE.2040807@xfs.org> Date: Tue, 15 Nov 2005 09:25:18 -0600 From: Steve Lord User-Agent: Thunderbird 1.4.1 (X11/20051006) MIME-Version: 1.0 To: Roger Willcocks CC: Nathan Scott , linux-xfs@oss.sgi.com Subject: Re: clearing 'flag unwritten extents' References: <20051111073434.B6484324@wobbly.melbourne.sgi.com> <20051114091337.P6499030@wobbly.melbourne.sgi.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Nov 2005 15:25:19.0838 (UTC) FILETIME=[C9E5F7E0:01C5E9F8] X-archive-position: 6567 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 757 Lines: 21 Roger Willcocks wrote: > On 11/13/05, Nathan Scott wrote: >> On Fri, Nov 11, 2005 at 12:48:48PM +0000, Roger Willcocks wrote: >>> AIUI, the 'flag unwritten extents' option allows non-root users to >>> preallocate unwritten extents (root can always create them). Clearing >>> the option would just prevent the creation of new unwritten extents. >> It does more than just that - in xfs_bmapi it changes the way >> extents are handled - look for XFS_SB_VERSION_HASEXTFLGBIT in >> xfs_bmap.c in particular. > > But only for realtime extents - and I don't have any of those... > > -- > Roger > Nope, unwritten extents exist in the main part of the filesystem too. They are not always used, but they are not just for realtime files. Steve From owner-linux-xfs@oss.sgi.com Tue Nov 15 12:42:57 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 15 Nov 2005 12:43:02 -0800 (PST) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jAFKgvO0030325 for ; Tue, 15 Nov 2005 12:42:57 -0800 Received: from hastur.corp.sgi.com (hastur.corp.sgi.com [198.149.32.33] (may be forged)) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id jAFKdZxT027168 for ; Tue, 15 Nov 2005 14:39:35 -0600 Received: from naboo.americas.sgi.com (naboo.americas.sgi.com [128.162.233.73]) by hastur.corp.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id jAFKdHeS214718503; Tue, 15 Nov 2005 12:39:17 -0800 (PST) Received: from naboo.americas.sgi.com (localhost [127.0.0.1]) by naboo.americas.sgi.com (8.13.3/8.13.3) with ESMTP id jAFKdYKq002485; Tue, 15 Nov 2005 14:39:34 -0600 Received: (from hch@localhost) by naboo.americas.sgi.com (8.13.3/8.13.3/Submit) id jAFKdYmo002484; Tue, 15 Nov 2005 14:39:34 -0600 Date: Tue, 15 Nov 2005 14:39:34 -0600 From: Christoph Hellwig Message-Id: <200511152039.jAFKdYmo002484@naboo.americas.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Subject: TAKE 912426 - do barrier checks earlier X-archive-position: 6568 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@relay.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 436 Lines: 15 quota initialization may write to the filesystem Date: Tue Nov 15 12:39:18 PST 2005 Workarea: naboo.americas.sgi.com:/go/space/hch/xfs-2.6.x 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:202355a fs/xfs/xfs_vfsops.c - 1.488 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vfsops.c.diff?r1=text&tr1=1.488&r2=text&tr2=1.487&f=h From owner-linux-xfs@oss.sgi.com Tue Nov 15 13:09:30 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 15 Nov 2005 13:09:33 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id jAFL9SO0000522 for ; Tue, 15 Nov 2005 13:09:29 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA15720; Wed, 16 Nov 2005 08:05:59 +1100 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id jAFL69kt6654817; Wed, 16 Nov 2005 08:06:09 +1100 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id jAFL67U46672401; Wed, 16 Nov 2005 08:06:07 +1100 (EST) Date: Wed, 16 Nov 2005 08:06:06 +1100 From: Nathan Scott To: Roger Willcocks , Steve Lord Cc: linux-xfs@oss.sgi.com Subject: Re: clearing 'flag unwritten extents' Message-ID: <20051116080606.B6643249@wobbly.melbourne.sgi.com> References: <20051111073434.B6484324@wobbly.melbourne.sgi.com> <20051114091337.P6499030@wobbly.melbourne.sgi.com> <4379FDDE.2040807@xfs.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4379FDDE.2040807@xfs.org>; from lord@xfs.org on Tue, Nov 15, 2005 at 09:25:18AM -0600 X-archive-position: 6569 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1061 Lines: 27 On Tue, Nov 15, 2005 at 09:25:18AM -0600, Steve Lord wrote: > Roger Willcocks wrote: > > On 11/13/05, Nathan Scott wrote: > >> On Fri, Nov 11, 2005 at 12:48:48PM +0000, Roger Willcocks wrote: > >>> AIUI, the 'flag unwritten extents' option allows non-root users to > >>> preallocate unwritten extents (root can always create them). Clearing > >>> the option would just prevent the creation of new unwritten extents. > >> It does more than just that - in xfs_bmapi it changes the way > >> extents are handled - look for XFS_SB_VERSION_HASEXTFLGBIT in > >> xfs_bmap.c in particular. > > > > But only for realtime extents - and I don't have any of those... Not only realtime - look more closely in xfs_bmapi(). > Nope, unwritten extents exist in the main part of the filesystem too. > They are not always used, but they are not just for realtime files. *nod*. They are a Good Thing (tm), although the current code implementing them on Linux is pretty horrible - that will get alot better in the not-too-distant future. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Nov 16 14:11:47 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 16 Nov 2005 14:11:51 -0800 (PST) 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 jAGMBkO0023202 for ; Wed, 16 Nov 2005 14:11:47 -0800 Received: from g1ce4.g.pppool.de ([80.185.28.228] helo=mail.housecafe.de) by mail.g-house.de with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1EcVY7-0002z4-9G; Wed, 16 Nov 2005 23:14:39 +0100 Received: from prinz64.housecafe.de ([192.168.10.11] helo=[127.0.0.1]) by mail.housecafe.de with esmtp (Exim 4.54) id 1EcVRD-0005Ib-Qz; Wed, 16 Nov 2005 23:07:32 +0100 Message-ID: <437BAD87.9030102@gmx.net> Date: Wed, 16 Nov 2005 23:07:03 +0100 From: "evilninja@gmx.net" User-Agent: Mail/News 1.6a1 (Windows/20051004) MIME-Version: 1.0 To: Michael Ramsey CC: linux-xfs@oss.sgi.com Subject: Re: FYI: mount: Unknown error 990 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 0546-3, 16.11.2005), Outbound message X-Antivirus-Status: Clean X-archive-position: 6570 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: evilninja@gmx.net Precedence: bulk X-list: linux-xfs Content-Length: 465 Lines: 19 Michael Ramsey schrieb: > Mount /dev/raidvol2/vol1 /u02 > mount: Unknown error 990 > > Dmesg shows: > XFS mounting filesystem dm-0 > Starting XFS recovery on filesystem: dm-0 (dev: dm-0) > Filesystem "dm-0": XFS internal error hm, do you know / suspect the cause of the error? device failure, cabling problems, memory errors, etc? is this reproducible? with which kernel? -- BOFH excuse #245: The Borg tried to assimilate your system. Resistance is futile. From owner-linux-xfs@oss.sgi.com Thu Nov 17 09:49:54 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 17 Nov 2005 09:49:58 -0800 (PST) Received: from sbapexch02.ad.corp.expertcity.com (216-219-126-102.expertcity.com [216.219.126.102] (may be forged)) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jAHHnsO0028366 for ; Thu, 17 Nov 2005 09:49:54 -0800 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: FYI: mount: Unknown error 990 Date: Thu, 17 Nov 2005 09:46:31 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FYI: mount: Unknown error 990 Thread-Index: AcXq+kA484bU+Y4MRfOfr0FE4RRJgwAOA4MA From: "Michael Ramsey" To: Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id jAHHnsO0028370 X-archive-position: 6571 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Michael.Ramsey@citrix.com Precedence: bulk X-list: linux-xfs Content-Length: 786 Lines: 32 I suspect device issue. But if I have a dev failure why do I have to delete the journal to get xfs back up? -----Original Message----- From: evilninja@gmx.net [mailto:evilninja@gmx.net] Sent: Wednesday, November 16, 2005 2:07 PM To: Michael Ramsey Cc: linux-xfs@oss.sgi.com Subject: Re: FYI: mount: Unknown error 990 Michael Ramsey schrieb: > Mount /dev/raidvol2/vol1 /u02 > mount: Unknown error 990 > > Dmesg shows: > XFS mounting filesystem dm-0 > Starting XFS recovery on filesystem: dm-0 (dev: dm-0) Filesystem > "dm-0": XFS internal error hm, do you know / suspect the cause of the error? device failure, cabling problems, memory errors, etc? is this reproducible? with which kernel? -- BOFH excuse #245: The Borg tried to assimilate your system. Resistance is futile. From owner-linux-xfs@oss.sgi.com Thu Nov 17 12:33:10 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 17 Nov 2005 12:33:13 -0800 (PST) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jAHKX8O0010905 for ; Thu, 17 Nov 2005 12:33:10 -0800 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 jAHKTjxT005494 for ; Thu, 17 Nov 2005 14:29:45 -0600 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 jAHKThOS5760447; Thu, 17 Nov 2005 12:29:43 -0800 (PST) Message-ID: <437CE836.5050206@sgi.com> Date: Thu, 17 Nov 2005 14:29:42 -0600 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Ramsey CC: evilninja@gmx.net, linux-xfs@oss.sgi.com Subject: Re: FYI: mount: Unknown error 990 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6572 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 503 Lines: 13 Michael Ramsey wrote: > I suspect device issue. But if I have a dev failure why > do I have to delete the journal to get xfs back up? because journaling depends on writes actually completing when the device says they're complete. It's hard to cope with being lied to ;-) XFS makes the reasonable assumption that if it's been told that data is safe on disk, it can carry on with life. If that's not true, the things may well be out of whack, and xfs can't really be expected to cope well. -Eric From owner-linux-xfs@oss.sgi.com Thu Nov 17 18:15:30 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 17 Nov 2005 18:15:32 -0800 (PST) Received: from slingshot.landmarkdigital.com (66.238.243.52.ptr.us.xo.net [66.238.243.52]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id jAI2FPO0009728 for ; Thu, 17 Nov 2005 18:15:30 -0800 Received: by slingshot.landmarkdigital.com (Postfix, from userid 48) id 5FC0D2DF862A; Thu, 17 Nov 2005 20:11:54 -0600 (CST) Received: from 68.52.44.223 (SquirrelMail authenticated user rthompson); by 66.238.243.52 with HTTP; Thu, 17 Nov 2005 20:11:54 -0600 (CST) Message-ID: <32927.68.52.44.223.1132279914.squirrel@66.238.243.52> Date: Thu, 17 Nov 2005 20:11:54 -0600 (CST) Subject: RHEL ES 4 From: rthompson@landmarkdigital.com To: linux-xfs@oss.sgi.com User-Agent: SquirrelMail/1.4.3a-12.EL4 X-Mailer: SquirrelMail/1.4.3a-12.EL4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id jAI2FUO0009731 X-archive-position: 6573 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: rthompson@landmarkdigital.com Precedence: bulk X-list: linux-xfs Content-Length: 583 Lines: 12 Hi everyone, I am attempting to use XFS on a number of RHEL ES 4 servers. I need help. I have downloaded the patch, installed the xfsprogs and was able to use mkfs.xfs to format a partition. When trying to mount the filesystem, it tells me the kernel does not support XFS. I know that I need to recompile the kernel to get this thing working, but I have no idea on how to do this. I am wanting to use XFS to create a 120 TB filesystem (growable up to 300 TB). XFS is my only option if I want a filesystem this large, is this correct? Thanks in advance for your help. Rob Thompson From owner-linux-xfs@oss.sgi.com Thu Nov 17 19:39:25 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 17 Nov 2005 19:39:33 -0800 (PST) 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 jAI3dKO0018758 for ; Thu, 17 Nov 2005 19:39:25 -0800 Received: from g1bfc.g.pppool.de ([80.185.27.252] helo=mail.housecafe.de) by mail.g-house.de with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1Ecx8J-0001Vx-Q2; Fri, 18 Nov 2005 04:41:51 +0100 Received: from prinz64.housecafe.de ([192.168.10.11] helo=[127.0.0.1]) by mail.housecafe.de with esmtp (Exim 4.54) id 1Ecx1F-0004ea-Ou; Fri, 18 Nov 2005 04:34:33 +0100 Message-ID: <437D4BA9.902@gmx.net> Date: Fri, 18 Nov 2005 04:34:01 +0100 From: "evilninja@gmx.net" User-Agent: Mail/News 1.6a1 (Windows/20051004) MIME-Version: 1.0 To: rthompson@landmarkdigital.com CC: linux-xfs@oss.sgi.com Subject: Re: RHEL ES 4 References: <32927.68.52.44.223.1132279914.squirrel@66.238.243.52> In-Reply-To: <32927.68.52.44.223.1132279914.squirrel@66.238.243.52> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 0546-3, 16.11.2005), Outbound message X-Antivirus-Status: Clean X-archive-position: 6574 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: evilninja@gmx.net Precedence: bulk X-list: linux-xfs Content-Length: 796 Lines: 24 rthompson@landmarkdigital.com schrieb: > Hi everyone, > I am attempting to use XFS on a number of RHEL ES 4 servers. I need help. > I have downloaded the patch, installed the xfsprogs and was able to use > mkfs.xfs to format a partition. When trying to mount the filesystem, it > tells me the kernel does not support XFS. mkfs.xfs needs no kernel support, AFAIK. mounting however does. > I know that I need to recompile > the kernel to get this thing working, but I have no idea on how to do for general how-to-rebuild-a-kernel: http://www.digitalhermit.com/linux/Kernel-Build-HOWTO.html (and enable CONFIG_XFS_FS ;) if you want to patch your RHEL kernel with XFS, you'll probably have to get the RHEL-kernel-sources instead of the kernel.org tarball. -- BOFH excuse #100: IRQ dropout From owner-linux-xfs@oss.sgi.com Thu Nov 17 20:20:40 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 17 Nov 2005 20:20:50 -0800 (PST) Received: from levanto.mail.adnap.net.au (levanto.mail.adnap.net.au [203.6.132.83]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jAI4KeO0025576 for ; Thu, 17 Nov 2005 20:20:40 -0800 Received: from gondor (219-90-180-168.ip.adam.com.au [219.90.180.168]) by levanto.mail.adnap.net.au (Postfix) with ESMTP id EABD15F3A; Fri, 18 Nov 2005 14:47:13 +1030 (CST) Date: Fri, 18 Nov 2005 14:47:15 +1030 From: David Lloyd To: rthompson@landmarkdigital.com Cc: linux-xfs@oss.sgi.com Subject: Re: RHEL ES 4 Message-ID: <20051118144715.75945b3a@gondor> In-Reply-To: <32927.68.52.44.223.1132279914.squirrel@66.238.243.52> References: <32927.68.52.44.223.1132279914.squirrel@66.238.243.52> X-Mailer: Sylpheed-Claws 1.0.5 (GTK+ 1.2.10; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 6575 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lloy0076@adam.com.au Precedence: bulk X-list: linux-xfs Content-Length: 116 Lines: 6 Does anyone know if the selinux stuff on RHEL 4 supports XFS presuming one has the correctly patched kernel? DSL From owner-linux-xfs@oss.sgi.com Thu Nov 17 21:27:37 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 17 Nov 2005 21:27:41 -0800 (PST) Received: from ty.sabi.co.UK ([82.69.39.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jAI5RUO0029846 for ; Thu, 17 Nov 2005 21:27:36 -0800 Received: from from [127.0.0.1] (helo=base.ty.sabi.co.UK) by ty.sabi.co.UK with esmtp(Exim 4.54 #1) id 1EcyiQ-0005TT-3A for ; Fri, 18 Nov 2005 05:23:14 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Message-ID: <17277.25921.438447.340153@base.ty.sabi.co.UK> Date: Fri, 18 Nov 2005 05:23:13 +0000 X-Face: SMJE]JPYVBO-9UR%/8d'mG.F!@.,l@c[f'[%S8'BZIcbQc3/">GrXDwb#;fTRGNmHr^JFb SAptvwWc,0+z+~p~"Gdr4H$(|N(yF(wwCM2bW0~U?HPEE^fkPGx^u[*[yV.gyB!hDOli}EF[\cW*S H&spRGFL}{`bj1TaD^l/"[ msn( /TH#THs{Hpj>)]f> References: <32927.68.52.44.223.1132279914.squirrel@66.238.243.52> X-Mailer: VM 7.17 under 21.4 (patch 17) XEmacs Lucid From: pg_xfs@xfs.for.sabi.co.UK (Peter Grandi) X-Disclaimer: This message contains only personal opinions Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id jAI5RbO0029863 X-archive-position: 6576 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: pg_xfs@xfs.for.sabi.co.UK Precedence: bulk X-list: linux-xfs Content-Length: 1770 Lines: 41 >>> On Thu, 17 Nov 2005 20:11:54 -0600 (CST), >>> rthompson@landmarkdigital.com said: rthompson> Hi everyone, I am attempting to use XFS on a number of rthompson> RHEL ES 4 servers. [ ... no support ... ] rthompson> I am wanting to use XFS to create a 120 TB filesystem rthompson> (growable up to 300 TB). If that's really «TB», the total is between 2^47B and 2^49B. Creating a storage system capable of handling that is going to cost (optimistically) a few million dollars: a cheap bare drive of roughly 2^38B capacity costs around US$2^8, or roughly US$1 per 2^30B, and that means spending 1/2 million dollars just for the drives; buying cheap NAS boxes, 2^30B will cost around US$6, and that means on the order of 3 million dollars just for that. Quantity discounts are available when buying that much stuff, but I would not expect too much. Working with that kind of budget you can easily afford to hire a team of large-storage-system consultants (probably SGI can be easily persuaded to hire out the XFS team when that kind of money is involved) who can advise on the many serious issues involved at that scale, among which recompiling the RH EL kernel is probably a small detail. rthompson> XFS is my only option if I want a filesystem this rthompson> large, is this correct? [ ... ] Well, JFS can do that, and so probably can Reiser4. I have not seen benchmarks for the 2^48B range of filesystem size, but for some not too recent and rather smaller 2^3xB sizes it seems that XFS scales better than JFS. BTW I really hope that you mean "GB", not «TB», because then things are suddendly very much easier: 128GiB to 300GiB means a single disc, and RH EL's default filesystem can handle that well, even if probably XFS can handle that better in most cases. From owner-linux-xfs@oss.sgi.com Thu Nov 17 21:44:30 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 17 Nov 2005 21:44:34 -0800 (PST) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jAI5iUO0030992 for ; Thu, 17 Nov 2005 21:44:30 -0800 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 jAI6pqpp004185 for ; Thu, 17 Nov 2005 22:51:52 -0800 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 jAI5e6OS5832352; Thu, 17 Nov 2005 21:40:06 -0800 (PST) Message-ID: <437D6935.2090905@sgi.com> Date: Thu, 17 Nov 2005 23:40:05 -0600 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: rthompson@landmarkdigital.com CC: linux-xfs@oss.sgi.com Subject: Re: RHEL ES 4 References: <32927.68.52.44.223.1132279914.squirrel@66.238.243.52> In-Reply-To: <32927.68.52.44.223.1132279914.squirrel@66.238.243.52> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6577 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1045 Lines: 24 rthompson@landmarkdigital.com wrote: > Hi everyone, > I am attempting to use XFS on a number of RHEL ES 4 servers. I need help. > I have downloaded the patch, installed the xfsprogs and was able to use > mkfs.xfs to format a partition. When trying to mount the filesystem, it > tells me the kernel does not support XFS. I know that I need to recompile > the kernel to get this thing working, but I have no idea on how to do > this. I am wanting to use XFS to create a 120 TB filesystem (growable up > to 300 TB). XFS is my only option if I want a filesystem this large, is > this correct? Thanks in advance for your help. > > Rob Thompson > You could get xfs going on RHEL4 w/o rebuilding the kernel, by just building xfs as an external module. I can provide an xfs codebase that -should- work if you really want to do this. Standard disclaimers about breaking & keeping both pieces apply here. But I'd suggest that you use something like SLES9, if at all possible, because SuSE will actually support your endeavors with xfs. -Eric From owner-linux-xfs@oss.sgi.com Fri Nov 18 02:27:55 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 18 Nov 2005 02:27:58 -0800 (PST) Received: from tyo202.gate.nec.co.jp (TYO202.gate.nec.co.jp [210.143.35.52]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jAIARsO0021215 for ; Fri, 18 Nov 2005 02:27:55 -0800 Received: from mailgate3.nec.co.jp (mailgate53.nec.co.jp [10.7.69.192]) by tyo202.gate.nec.co.jp (8.11.7/3.7W01080315) with ESMTP id jAIAOIb15826 for ; Fri, 18 Nov 2005 19:24:18 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id jAIAOIU14074 for linux-xfs@oss.sgi.com; Fri, 18 Nov 2005 19:24:18 +0900 (JST) Received: from secsv2.tnes.nec.co.jp (tnesvc1.tnes.nec.co.jp [10.1.101.14]) by mailsv5.nec.co.jp (8.11.7/3.7W-MAILSV4-NEC) with ESMTP id jAIAOIn21917 for ; Fri, 18 Nov 2005 19:24:18 +0900 (JST) Received: from TNESVC1.tnes.nec.co.jp ([10.1.101.14]) by secsv2.tnes.nec.co.jp (ExpressMail 5.10) with SMTP id 20051118.192428.58602804 for ; Fri, 18 Nov 2005 19:24:28 +0900 Received: FROM mailsv.tnes.nec.co.jp BY TNESVC1.tnes.nec.co.jp ; Fri Nov 18 19:24:27 2005 +0900 Received: from rifu.bsd.tnes.nec.co.jp (rifu.bsd.tnes.nec.co.jp [10.1.104.1]) by mailsv.tnes.nec.co.jp (8.11.6/3.7W01031510) with ESMTP id jAIAOHa50502 for ; Fri, 18 Nov 2005 19:24:17 +0900 (JST) Received: from noshiro.bsd.tnes.nec.co.jp (noshiro.bsd.tnes.nec.co.jp [10.1.104.24]) by rifu.bsd.tnes.nec.co.jp (8.12.11/3.7W/BSD-TNES-MX01) with ESMTP id jAIAOHO1001555 for ; Fri, 18 Nov 2005 19:24:17 +0900 Received: from localhost (localhost.localdomain [127.0.0.1]) by noshiro.bsd.tnes.nec.co.jp (Postfix) with ESMTP id 7D4CA74A83 for ; Fri, 18 Nov 2005 19:24:17 +0900 (JST) Date: Fri, 18 Nov 2005 19:24:17 +0900 (JST) Message-Id: <20051118.192417.291442852.masano@tnes.nec.co.jp> To: linux-xfs@oss.sgi.com Subject: Re: [PATCH] fix deadlock on ENOSPC From: ASANO Masahiro In-Reply-To: <20051115.213347.607955969.masano@tnes.nec.co.jp> References: <42D7AA45.2040608@xfs.org> <20050803.175622.607955722.masano@tnes.nec.co.jp> <20051115.213347.607955969.masano@tnes.nec.co.jp> X-Mailer: Mew version 3.3 on XEmacs 21.4.11 (Native Windows TTY Support) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 6578 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: masano@tnes.nec.co.jp Precedence: bulk X-list: linux-xfs Content-Length: 228 Lines: 13 > Hi SGI guys, > > As I previously reported, XFS has a deadlock problem on a ENOSPC > device. No one comments the patch I sent 3 days ago. I'd like to know whether someone is looking now, or it's simply rejected. -- masano From owner-linux-xfs@oss.sgi.com Fri Nov 18 07:12:25 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 18 Nov 2005 07:12:29 -0800 (PST) Received: from archer.landmarkdigital.com (66.238.242.138.ptr.us.xo.net [66.238.242.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id jAIFCOO0011644 for ; Fri, 18 Nov 2005 07:12:25 -0800 Received: from rthompson.landmarkdigital.com (rthompson.landmarkdigital.com [172.20.50.111]) by archer.landmarkdigital.com (Postfix) with ESMTP id EE37E398C0D0; Fri, 18 Nov 2005 09:09:01 -0600 (CST) Subject: Re: RHEL ES 4 From: Rob Thompson Reply-To: rthompson@landmarkdigital.com To: Eric Sandeen Cc: linux-xfs@oss.sgi.com In-Reply-To: <437D6935.2090905@sgi.com> References: <32927.68.52.44.223.1132279914.squirrel@66.238.243.52> <437D6935.2090905@sgi.com> Content-Type: text/plain Date: Fri, 18 Nov 2005 09:07:11 -0600 Message-Id: <1132326431.12165.9.camel@rwthompson.landmarkdigital.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-22) Content-Transfer-Encoding: 7bit X-archive-position: 6579 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: rthompson@landmarkdigital.com Precedence: bulk X-list: linux-xfs Content-Length: 1496 Lines: 38 This is in fact a 120 TB (not GB) filesystem that I am trying to build. What I am attempting to do is to take 80 1.6 TB arrays ((8 x 250 GB Raid 5 arrays) 10 arrays from 8 seperate SAN's). Use LVM to make one large volume, then use xfs to format and mount this as a single filesystem. Any advice - or gotcha's would be appreciated. Thanks, Rob On Thu, 2005-11-17 at 23:40 -0600, Eric Sandeen wrote: > rthompson@landmarkdigital.com wrote: > > Hi everyone, > > I am attempting to use XFS on a number of RHEL ES 4 servers. I need help. > > I have downloaded the patch, installed the xfsprogs and was able to use > > mkfs.xfs to format a partition. When trying to mount the filesystem, it > > tells me the kernel does not support XFS. I know that I need to recompile > > the kernel to get this thing working, but I have no idea on how to do > > this. I am wanting to use XFS to create a 120 TB filesystem (growable up > > to 300 TB). XFS is my only option if I want a filesystem this large, is > > this correct? Thanks in advance for your help. > > > > Rob Thompson > > > > You could get xfs going on RHEL4 w/o rebuilding the kernel, by just > building xfs as an external module. I can provide an xfs codebase that > -should- work if you really want to do this. Standard disclaimers about > breaking & keeping both pieces apply here. > > But I'd suggest that you use something like SLES9, if at all possible, > because SuSE will actually support your endeavors with xfs. > > -Eric From owner-linux-xfs@oss.sgi.com Fri Nov 18 07:18:02 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 18 Nov 2005 07:18:06 -0800 (PST) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jAIFI1O0012340 for ; Fri, 18 Nov 2005 07:18:01 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id jAIFEcxT008514 for ; Fri, 18 Nov 2005 09:14:38 -0600 Received: from [128.162.232.50] (stout.americas.sgi.com [128.162.232.50]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id jAIFEcDN20110008; Fri, 18 Nov 2005 09:14:38 -0600 (CST) Message-ID: <437DEFDD.7070706@sgi.com> Date: Fri, 18 Nov 2005 09:14:37 -0600 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0.6-1.1.fc4 (X11/20050720) X-Accept-Language: en-us, en MIME-Version: 1.0 To: rthompson@landmarkdigital.com CC: linux-xfs@oss.sgi.com Subject: Re: RHEL ES 4 References: <32927.68.52.44.223.1132279914.squirrel@66.238.243.52> <437D6935.2090905@sgi.com> <1132326431.12165.9.camel@rwthompson.landmarkdigital.com> In-Reply-To: <1132326431.12165.9.camel@rwthompson.landmarkdigital.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6580 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 863 Lines: 23 Rob Thompson wrote: > This is in fact a 120 TB (not GB) filesystem that I am trying to build. > > What I am attempting to do is to take 80 1.6 TB arrays ((8 x 250 GB Raid > 5 arrays) 10 arrays from 8 seperate SAN's). Use LVM to make one large > volume, then use xfs to format and mount this as a single filesystem. > > Any advice - or gotcha's would be appreciated. one piece of advice would be to use an opteron or em64_t or ia64 box - the ia32 kernels from RHEL4 have 4k stacks enabled which may not play well with xfs on top of lvm on top of whatever your other drivers are, under any possible nfs sharing, etc. If 4k stacks don'w cut it for you (testing would be in order...) and you must use ia32 kernels, then you would have to rebuild the kernel with 8k stacks - patches have floated around this list previously for that. -Eric > Thanks, > Rob From owner-linux-xfs@oss.sgi.com Fri Nov 18 07:28:29 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 18 Nov 2005 07:28:32 -0800 (PST) Received: from archer.landmarkdigital.com (66.238.242.138.ptr.us.xo.net [66.238.242.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id jAIFSRO0013467 for ; Fri, 18 Nov 2005 07:28:29 -0800 Received: from rthompson.landmarkdigital.com (rthompson.landmarkdigital.com [172.20.50.111]) by archer.landmarkdigital.com (Postfix) with ESMTP id 674FA398C0D0; Fri, 18 Nov 2005 09:25:04 -0600 (CST) Subject: Re: RHEL ES 4 From: Rob Thompson Reply-To: rthompson@landmarkdigital.com To: Eric Sandeen Cc: linux-xfs@oss.sgi.com In-Reply-To: <437DEFDD.7070706@sgi.com> References: <32927.68.52.44.223.1132279914.squirrel@66.238.243.52> <437D6935.2090905@sgi.com> <1132326431.12165.9.camel@rwthompson.landmarkdigital.com> <437DEFDD.7070706@sgi.com> Content-Type: text/plain Date: Fri, 18 Nov 2005 09:23:13 -0600 Message-Id: <1132327393.12165.12.camel@rwthompson.landmarkdigital.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-22) Content-Transfer-Encoding: 7bit X-archive-position: 6581 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: rthompson@landmarkdigital.com Precedence: bulk X-list: linux-xfs Content-Length: 1103 Lines: 36 Eric, Thanks for the advice. I am running the 64-bit kernel: uname -a 2.6.9-22.ELsmp #1 SMP x86_64 x86_64 x86_64 GNU/Linux Thanks, Rob On Fri, 2005-11-18 at 09:14 -0600, Eric Sandeen wrote: > Rob Thompson wrote: > > This is in fact a 120 TB (not GB) filesystem that I am trying to build. > > > > What I am attempting to do is to take 80 1.6 TB arrays ((8 x 250 GB Raid > > 5 arrays) 10 arrays from 8 seperate SAN's). Use LVM to make one large > > volume, then use xfs to format and mount this as a single filesystem. > > > > Any advice - or gotcha's would be appreciated. > > one piece of advice would be to use an opteron or em64_t or ia64 box - the ia32 > kernels from RHEL4 have 4k stacks enabled which may not play well with xfs on > top of lvm on top of whatever your other drivers are, under any possible nfs > sharing, etc. > > If 4k stacks don'w cut it for you (testing would be in order...) and you must > use ia32 kernels, then you would have to rebuild the kernel with 8k stacks - > patches have floated around this list previously for that. > > -Eric > > > Thanks, > > Rob From owner-linux-xfs@oss.sgi.com Fri Nov 18 07:51:31 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 18 Nov 2005 07:51:35 -0800 (PST) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jAIFpUO0015486 for ; Fri, 18 Nov 2005 07:51:30 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [198.149.16.14]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id jAIFm7xT013464 for ; Fri, 18 Nov 2005 09:48:07 -0600 Received: from [128.162.232.50] (stout.americas.sgi.com [128.162.232.50]) by ledzep.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id jAIFm7sL25618578; Fri, 18 Nov 2005 09:48:07 -0600 (CST) Message-ID: <437DF7B6.5080807@sgi.com> Date: Fri, 18 Nov 2005 09:48:06 -0600 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0.6-1.1.fc4 (X11/20050720) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com CC: rthompson@landmarkdigital.com Subject: RHEL4 2.6.9-22EL xfs module src.rpm for testing Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6583 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1813 Lines: 37 Hey, let's give it a whirl. No promises, but please do let me know how it works out. ftp://oss.sgi.com/projects/xfs/testing/RHEL4/ ################################################################# # # # NOTICE # # This xfs module rpm has been provided for testing purposes # # only. It is believed to be functional, but it has not been # # heavily tested. In particular, you may have issues with the # # 4KSTACKS option on RHEL4 ia32 kernels, depending on your IO # # hardware, layering, nfs usage, etc. # # # # Please do NOT report any problems with this module, or with # # the kernel when this module is loaded, to Red Hat. # # You may report issues to the linux-xfs@oss.sgi.com list. # # (Please also report successes!) # # # ################################################################# To rebuild, do something like this: rpmbuild --rebuild --target i686 --define "kernel_topdir /lib/modules/2.6.9-22.EL/build" kernel-module-xfs-2.6.9-22.EL-0.1-1.src.rpm where the --target should match your architecture (actually not needed for x86_64 or ia64, it just affects the rpm name), and the kernel_topdir is /lib/modules/`uname -r`/build for the RHEL4 kernel you wish to build against. I have tested this xfs codebase a little bit with the xfs qa tests from xfs-cmds cvs with the 2.6.9-22.ELsmp kernel on ia32. It should work on other architectures and flavors (bigmem, non-smp, etc), and it may work with other RHEL4 kernel versions, but no guarantees on that. -Eric From owner-linux-xfs@oss.sgi.com Fri Nov 18 07:56:21 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 18 Nov 2005 07:56:24 -0800 (PST) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jAIFuLO0016110 for ; Fri, 18 Nov 2005 07:56:21 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [198.149.16.14]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id jAIFqwxT014095 for ; Fri, 18 Nov 2005 09:52:58 -0600 Received: from [128.162.232.50] (stout.americas.sgi.com [128.162.232.50]) by ledzep.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id jAIFqvsL25621449; Fri, 18 Nov 2005 09:52:57 -0600 (CST) Message-ID: <437DF8D8.9060704@sgi.com> Date: Fri, 18 Nov 2005 09:52:56 -0600 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0.6-1.1.fc4 (X11/20050720) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ASANO Masahiro CC: linux-xfs@oss.sgi.com Subject: Re: [PATCH] fix deadlock on ENOSPC References: <42D7AA45.2040608@xfs.org> <20050803.175622.607955722.masano@tnes.nec.co.jp> <20051115.213347.607955969.masano@tnes.nec.co.jp> <20051118.192417.291442852.masano@tnes.nec.co.jp> In-Reply-To: <20051118.192417.291442852.masano@tnes.nec.co.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6584 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 463 Lines: 19 ASANO Masahiro wrote: >>Hi SGI guys, >> >>As I previously reported, XFS has a deadlock problem on a ENOSPC >>device. > > > No one comments the patch I sent 3 days ago. > I'd like to know whether someone is looking now, or it's simply > rejected. It's not been rejected, but we need to find some time to look into it. We know of the bug, but we need a bit of time to review your patch. We do appreciate your efforts to resolve the problem! Thanks, -Eric From owner-linux-xfs@oss.sgi.com Fri Nov 18 08:09:42 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 18 Nov 2005 08:09:46 -0800 (PST) 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 jAIG9fO0017289 for ; Fri, 18 Nov 2005 08:09:42 -0800 Received: from g3272.g.pppool.de ([80.185.50.114] helo=mail.housecafe.de) by mail.g-house.de with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1Ed8rA-0002Qf-C0; Fri, 18 Nov 2005 17:12:56 +0100 Received: from prinz64.housecafe.de ([192.168.10.11] helo=[127.0.0.1]) by mail.housecafe.de with esmtp (Exim 4.54) id 1Ed8ki-0007zF-55; Fri, 18 Nov 2005 17:06:16 +0100 Message-ID: <437DFBD8.3070106@gmx.net> Date: Fri, 18 Nov 2005 17:05:44 +0100 From: "evilninja@gmx.net" User-Agent: Mail/News 1.6a1 (Windows/20051004) MIME-Version: 1.0 To: rthompson@landmarkdigital.com CC: linux-xfs@oss.sgi.com Subject: Re: RHEL ES 4 References: <32927.68.52.44.223.1132279914.squirrel@66.238.243.52> <437D6935.2090905@sgi.com> <1132326431.12165.9.camel@rwthompson.landmarkdigital.com> In-Reply-To: <1132326431.12165.9.camel@rwthompson.landmarkdigital.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 0546-3, 16.11.2005), Outbound message X-Antivirus-Status: Clean X-archive-position: 6585 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: evilninja@gmx.net Precedence: bulk X-list: linux-xfs Content-Length: 468 Lines: 15 Rob Thompson schrieb: > This is in fact a 120 TB (not GB) filesystem that I am trying to build. i recall an issue, where one was in need to xfs_check/xfs_repair a big xfs volume and did not have enough memory. with sizes like yours i'd run xfs_check & friends before going into production, just in case... but then again i don't remember the thread this issue was discussed, so it's totally bogus perhaps... -- BOFH excuse #266: All of the packets are empty. From owner-linux-xfs@oss.sgi.com Fri Nov 18 08:25:13 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 18 Nov 2005 08:25:18 -0800 (PST) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jAIGPDO0022659 for ; Fri, 18 Nov 2005 08:25:13 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id jAIHWdLl029346 for ; Fri, 18 Nov 2005 09:32:39 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id jAIGLnDN20113278; Fri, 18 Nov 2005 10:21:49 -0600 (CST) 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 jAIGLnfR384888; Fri, 18 Nov 2005 10:21:49 -0600 (CST) Received: by attica.americas.sgi.com (Postfix, from userid 9762) id 2163C460082; Fri, 18 Nov 2005 10:21:49 -0600 (CST) To: linux-xfs@sgi.com, sgi.bugs.xfs@sgi.com Subject: TAKE 945412 - Fixed an assertion failure in xfs_reclaim by delayed block Message-Id: <20051118162149.2163C460082@attica.americas.sgi.com> Date: Fri, 18 Nov 2005 10:21:49 -0600 (CST) From: yingping@sgi.com (Yingping Lu) X-archive-position: 6586 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: yingping@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 851 Lines: 16 Fixed an assertion failure in xfs_reclaim caused by delayed block. The assertion failure came from XFS QA41. The fix is done by enabling truncate for delayed block in xfs_inactive. Date: Fri Nov 18 08:17:35 PST 2005 Workarea: attica.americas.sgi.com:/data/lwork/attica3/yingping/xfs-kern Inspected by: gwehrman The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:202521a xfs_vnodeops.c - 1.659 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vnodeops.c.diff?r1=text&tr1=1.659&r2=text&tr2=1.658&f=h - Enable truncate for delayed block even though the size and nextent of the inode are 0. This happens when the file system run out of space, thus a write of 1 page may end up with one or a few delayed block but failure of the whole page, which results to size of 0. From owner-linux-xfs@oss.sgi.com Fri Nov 18 08:37:56 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 18 Nov 2005 08:38:00 -0800 (PST) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jAIGbuO0023714 for ; Fri, 18 Nov 2005 08:37:56 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [198.149.16.14]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id jAIGYXxT020120 for ; Fri, 18 Nov 2005 10:34:33 -0600 Received: from [128.162.232.50] (stout.americas.sgi.com [128.162.232.50]) by ledzep.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id jAIGYWsL25619248; Fri, 18 Nov 2005 10:34:32 -0600 (CST) Message-ID: <437E0297.40807@sgi.com> Date: Fri, 18 Nov 2005 10:34:31 -0600 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0.6-1.1.fc4 (X11/20050720) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "evilninja@gmx.net" CC: rthompson@landmarkdigital.com, linux-xfs@oss.sgi.com Subject: Re: RHEL ES 4 References: <32927.68.52.44.223.1132279914.squirrel@66.238.243.52> <437D6935.2090905@sgi.com> <1132326431.12165.9.camel@rwthompson.landmarkdigital.com> <437DFBD8.3070106@gmx.net> In-Reply-To: <437DFBD8.3070106@gmx.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6587 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 557 Lines: 18 evilninja@gmx.net wrote: > Rob Thompson schrieb: > >> This is in fact a 120 TB (not GB) filesystem that I am trying to build. > > > i recall an issue, where one was in need to xfs_check/xfs_repair a big > xfs volume and did not have enough memory. with sizes like yours i'd run > xfs_check & friends before going into production, just in case... > > but then again i don't remember the thread this issue was discussed, so > it's totally bogus perhaps... > Oh, repair on a 300T filesystem -wil-l be painful anywhere, I think, unfortunately. -Eric From owner-linux-xfs@oss.sgi.com Fri Nov 18 08:49:47 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 18 Nov 2005 08:49:52 -0800 (PST) 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 jAIGnkO0024514 for ; Fri, 18 Nov 2005 08:49:47 -0800 Received: from g3272.g.pppool.de ([80.185.50.114] helo=mail.housecafe.de) by mail.g-house.de with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1Ed9Ty-0002r0-Cv for linux-xfs@oss.sgi.com; Fri, 18 Nov 2005 17:53:02 +0100 Received: from prinz64.housecafe.de ([192.168.10.11] helo=[127.0.0.1]) by mail.housecafe.de with esmtp (Exim 4.54) id 1Ed9NV-00088S-Mi for linux-xfs@oss.sgi.com; Fri, 18 Nov 2005 17:46:21 +0100 Message-ID: <437E053E.8090704@gmx.net> Date: Fri, 18 Nov 2005 17:45:50 +0100 From: "evilninja@gmx.net" User-Agent: Mail/News 1.6a1 (Windows/20051004) MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: RHEL ES 4 References: <32927.68.52.44.223.1132279914.squirrel@66.238.243.52> <437D6935.2090905@sgi.com> <1132326431.12165.9.camel@rwthompson.landmarkdigital.com> <437DFBD8.3070106@gmx.net> <437E0297.40807@sgi.com> In-Reply-To: <437E0297.40807@sgi.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 0546-3, 16.11.2005), Outbound message X-Antivirus-Status: Clean X-archive-position: 6588 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: evilninja@gmx.net Precedence: bulk X-list: linux-xfs Content-Length: 433 Lines: 14 Eric Sandeen schrieb: > Oh, repair on a 300T filesystem -wil-l be painful anywhere, I think, > unfortunately. hm, painful yes, but hopefully not impossible? otherwise if sth. goes wrong on a 300TB fs the only way to fix it would be restoring from backup, no matter how tiny the corruption might be (and xfs_repair could fix it easliy if only the volume was not so big).... -- BOFH excuse #5: static from plastic slide rules From owner-linux-xfs@oss.sgi.com Fri Nov 18 08:50:23 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 18 Nov 2005 08:50:28 -0800 (PST) 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 jAIGoLO0024630 for ; Fri, 18 Nov 2005 08:50:22 -0800 Received: from from [127.0.0.1] (helo=base.ty.sabi.co.UK) by ty.sabi.co.UK with esmtp(Exim 4.54 #1) id 1Ed9NR-0000It-L3 for ; Fri, 18 Nov 2005 16:46:17 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17278.1367.64252.355681@base.ty.sabi.co.UK> Date: Fri, 18 Nov 2005 16:46:15 +0000 X-Face: SMJE]JPYVBO-9UR%/8d'mG.F!@.,l@c[f'[%S8'BZIcbQc3/">GrXDwb#;fTRGNmHr^JFb SAptvwWc,0+z+~p~"Gdr4H$(|N(yF(wwCM2bW0~U?HPEE^fkPGx^u[*[yV.gyB!hDOli}EF[\cW*S H&spRGFL}{`bj1TaD^l/"[ msn( /TH#THs{Hpj>)]f> References: <32927.68.52.44.223.1132279914.squirrel@66.238.243.52> <437D6935.2090905@sgi.com> <1132326431.12165.9.camel@rwthompson.landmarkdigital.com> X-Mailer: VM 7.17 under 21.4 (patch 17) XEmacs Lucid From: pg_xfs@xfs.for.sabi.co.UK (Peter Grandi) X-Disclaimer: This message contains only personal opinions X-archive-position: 6589 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: pg_xfs@xfs.for.sabi.co.UK Precedence: bulk X-list: linux-xfs Content-Length: 986 Lines: 24 >>> On Fri, 18 Nov 2005 09:07:11 -0600, Rob Thompson >>> said: [ ... ] rthompson> This is in fact a 120 TB (not GB) filesystem that I rthompson> am trying to build. What I am attempting to do is to rthompson> take 80 1.6 TB arrays ((8 x 250 GB Raid 5 arrays) 10 rthompson> arrays from 8 seperate SAN's). Use LVM to make one rthompson> large volume, then use xfs to format and mount this rthompson> as a single filesystem. It sounds easy :-), but both the idea and this configuration of a single fs of that size as you describe above to me feel rather extraordinarily ''optimistic'', to use a euphemism. rthompson> Any advice - or gotcha's would be appreciated. Again, the best advice I can think of is to hire RH or SGI Professional Services to give you a non-public assessement of your project, which probably will cost you only a small fraction of the multimillion dollar budget; a mailing list is not an appropriate place for such a discussion. From owner-linux-xfs@oss.sgi.com Fri Nov 18 09:23:44 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 18 Nov 2005 09:23:50 -0800 (PST) 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 jAIHNgO0030850 for ; Fri, 18 Nov 2005 09:23:44 -0800 Received: from from [127.0.0.1] (helo=base.ty.sabi.co.UK) by ty.sabi.co.UK with esmtp(Exim 4.54 #1) id 1Ed9o4-0000Rh-Hm for ; Fri, 18 Nov 2005 17:13:48 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17278.3018.984724.417876@base.ty.sabi.co.UK> Date: Fri, 18 Nov 2005 17:13:46 +0000 X-Face: SMJE]JPYVBO-9UR%/8d'mG.F!@.,l@c[f'[%S8'BZIcbQc3/">GrXDwb#;fTRGNmHr^JFb SAptvwWc,0+z+~p~"Gdr4H$(|N(yF(wwCM2bW0~U?HPEE^fkPGx^u[*[yV.gyB!hDOli}EF[\cW*S H&spRGFL}{`bj1TaD^l/"[ msn( /TH#THs{Hpj>)]f> References: <32927.68.52.44.223.1132279914.squirrel@66.238.243.52> <437D6935.2090905@sgi.com> <1132326431.12165.9.camel@rwthompson.landmarkdigital.com> <437DFBD8.3070106@gmx.net> <437E0297.40807@sgi.com> <437E053E.8090704@gmx.net> X-Mailer: VM 7.17 under 21.4 (patch 17) XEmacs Lucid From: pg_xfs@xfs.for.sabi.co.UK (Peter Grandi) X-Disclaimer: This message contains only personal opinions X-archive-position: 6590 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: pg_xfs@xfs.for.sabi.co.UK Precedence: bulk X-list: linux-xfs Content-Length: 882 Lines: 26 >>> On Fri, 18 Nov 2005 17:45:50 +0100, "evilninja@gmx.net" >>> said: evilninja> Eric Sandeen schrieb: Eric> Oh, repair on a 300T filesystem -wil-l be painful Eric> anywhere, I think, unfortunately. evilninja> hm, painful yes, but hopefully not impossible? evilninja> otherwise if sth. goes wrong on a 300TB fs I suspect that Eric above is trying to be an master of the understatement.... evilninja> the only way to fix it would be restoring from evilninja> backup, no matter how tiny the corruption might be evilninja> (and xfs_repair could fix it easliy if only the evilninja> volume was not so big).... As an amusing mental exercise, consider this: how to make such a backup of a 300TB filesystem? Overall I would guess that designing a 2^48B filesystem is a bit of a research problem, and requires serious study and thinking, if one cannot avoid it. From owner-linux-xfs@oss.sgi.com Fri Nov 18 09:44:52 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 18 Nov 2005 09:44:58 -0800 (PST) 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 jAIHipO0032379 for ; Fri, 18 Nov 2005 09:44:51 -0800 Received: from g3272.g.pppool.de ([80.185.50.114] helo=mail.housecafe.de) by mail.g-house.de with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1EdALG-0003QX-U6 for linux-xfs@oss.sgi.com; Fri, 18 Nov 2005 18:48:07 +0100 Received: from prinz64.housecafe.de ([192.168.10.11] helo=[127.0.0.1]) by mail.housecafe.de with esmtp (Exim 4.54) id 1EdAEj-0000BE-1a for linux-xfs@oss.sgi.com; Fri, 18 Nov 2005 18:41:21 +0100 Message-ID: <437E1221.6000108@gmx.net> Date: Fri, 18 Nov 2005 18:40:49 +0100 From: "evilninja@gmx.net" User-Agent: Mail/News 1.6a1 (Windows/20051004) MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: RHEL ES 4 References: <32927.68.52.44.223.1132279914.squirrel@66.238.243.52> <437D6935.2090905@sgi.com> <1132326431.12165.9.camel@rwthompson.landmarkdigital.com> <437DFBD8.3070106@gmx.net> <437E0297.40807@sgi.com> <437E053E.8090704@gmx.net> <17278.3018.984724.417876@base.ty.sabi.co.UK> In-Reply-To: <17278.3018.984724.417876@base.ty.sabi.co.UK> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 0546-3, 16.11.2005), Outbound message X-Antivirus-Status: Clean X-archive-position: 6591 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: evilninja@gmx.net Precedence: bulk X-list: linux-xfs Content-Length: 508 Lines: 19 Peter Grandi schrieb: > As an amusing mental exercise, consider this: how to make such > a backup of a 300TB filesystem? hehe, tricky indeed. > Overall I would guess that designing a 2^48B filesystem is a bit > of a research problem, and requires serious study and thinking, > if one cannot avoid it. hm, Sun has its magic "ZFS" in stock now: http://www.opensolaris.org/os/community/zfs/ pretty impressive features, although i've never used it... -- BOFH excuse #421: Domain controller not responding From owner-linux-xfs@oss.sgi.com Fri Nov 18 09:53:29 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 18 Nov 2005 09:53:34 -0800 (PST) Received: from mail.linux-sxs.org (mail.linux-sxs.org [64.116.183.6]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jAIHrSO0000745 for ; Fri, 18 Nov 2005 09:53:29 -0800 Received: from mail.linux-sxs.org (localhost [127.0.0.1]) by mail.linux-sxs.org (8.13.5/8.13.5/Debian-3) with ESMTP id jAIGoXAQ015252 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 18 Nov 2005 11:50:34 -0500 Received: from localhost (netllama@localhost) by mail.linux-sxs.org (8.13.5/8.13.5/Submit) with ESMTP id jAIGoW5o015249; Fri, 18 Nov 2005 11:50:33 -0500 X-Authentication-Warning: mail.linux-sxs.org: netllama owned process doing -bs Date: Fri, 18 Nov 2005 11:50:32 -0500 (EST) From: Net Llama! To: "evilninja@gmx.net" cc: linux-xfs@oss.sgi.com Subject: Re: RHEL ES 4 In-Reply-To: <437E1221.6000108@gmx.net> Message-ID: References: <32927.68.52.44.223.1132279914.squirrel@66.238.243.52> <437D6935.2090905@sgi.com> <1132326431.12165.9.camel@rwthompson.landmarkdigital.com> <437DFBD8.3070106@gmx.net> <437E0297.40807@sgi.com> <437E053E.8090704@gmx.net> <17278.3018.984724.417876@base.ty.sabi.co.UK> <437E1221.6000108@gmx.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: milter-sender/0.62.837 (localhost [127.0.0.1]); Fri, 18 Nov 2005 11:50:35 -0500 Received-SPF: pass (mail.linux-sxs.org: domain of netllama@linux-sxs.org designates 127.0.0.1 as permitted sender) receiver=mail.linux-sxs.org; client-ip=127.0.0.1; helo=mail.linux-sxs.org; envelope-from=netllama@linux-sxs.org; x-software=spfmilter 0.95 http://www.acme.com/software/spfmilter/ with libspf2; X-archive-position: 6592 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: netllama@linux-sxs.org Precedence: bulk X-list: linux-xfs Content-Length: 425 Lines: 12 On Fri, 18 Nov 2005, evilninja@gmx.net wrote: > hm, Sun has its magic "ZFS" in stock now: > http://www.opensolaris.org/os/community/zfs/ > pretty impressive features, although i've never used it... Yea, but then you have to use Solaris. :P -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lonni J Friedman netllama@linux-sxs.org LlamaLand http://netllama.linux-sxs.org From owner-linux-xfs@oss.sgi.com Fri Nov 18 10:14:46 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 18 Nov 2005 10:14:49 -0800 (PST) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jAIIEkO0002736 for ; Fri, 18 Nov 2005 10:14:46 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [198.149.16.14]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id jAIJMCTP013101 for ; Fri, 18 Nov 2005 11:22:12 -0800 Received: from [128.162.232.50] (stout.americas.sgi.com [128.162.232.50]) by ledzep.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id jAIIAJsL25627614; Fri, 18 Nov 2005 12:10:20 -0600 (CST) Message-ID: <437E190B.7070901@sgi.com> Date: Fri, 18 Nov 2005 12:10:19 -0600 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0.6-1.1.fc4 (X11/20050720) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "evilninja@gmx.net" CC: linux-xfs@oss.sgi.com Subject: Re: RHEL ES 4 References: <32927.68.52.44.223.1132279914.squirrel@66.238.243.52> <437D6935.2090905@sgi.com> <1132326431.12165.9.camel@rwthompson.landmarkdigital.com> <437DFBD8.3070106@gmx.net> <437E0297.40807@sgi.com> <437E053E.8090704@gmx.net> In-Reply-To: <437E053E.8090704@gmx.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6593 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 660 Lines: 19 evilninja@gmx.net wrote: > Eric Sandeen schrieb: > >> Oh, repair on a 300T filesystem -wil-l be painful anywhere, I think, >> unfortunately. > > > hm, painful yes, but hopefully not impossible? otherwise if sth. goes > wrong on a 300TB fs the only way to fix it would be restoring from > backup, no matter how tiny the corruption might be (and xfs_repair could > fix it easliy if only the volume was not so big).... > The time & memory requirements for repair on a filesystem of this size are currently extremely large... there have been some rules of thumb for time/memory requirements on this list before, but I don't have them offhand... -Eric From owner-linux-xfs@oss.sgi.com Fri Nov 18 10:38:54 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 18 Nov 2005 10:38:58 -0800 (PST) Received: from web34101.mail.mud.yahoo.com (web34101.mail.mud.yahoo.com [66.163.178.99]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id jAIIcsO0004505 for ; Fri, 18 Nov 2005 10:38:54 -0800 Received: (qmail 24208 invoked by uid 60001); 18 Nov 2005 18:35:30 -0000 Message-ID: <20051118183530.24206.qmail@web34101.mail.mud.yahoo.com> Received: from [66.192.136.59] by web34101.mail.mud.yahoo.com via HTTP; Fri, 18 Nov 2005 10:35:30 PST X-RocketYMMF: thebs413 Date: Fri, 18 Nov 2005 10:35:30 -0800 (PST) From: "Bryan J. Smith" Reply-To: b.j.smith@ieee.org Subject: Re: RHEL ES 4 To: Net Llama! , "evilninja@gmx.net" Cc: linux-xfs@oss.sgi.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-archive-position: 6594 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: b.j.smith@ieee.org Precedence: bulk X-list: linux-xfs Content-Length: 331 Lines: 13 Net Llama! wrote: > Yea, but then you have to use Solaris. :P Not necessarily. The license may be compatible with some of the BSD kernels. -- Bryan J. Smith | Sent from Yahoo Mail mailto:b.j.smith@ieee.org | (please excuse any http://thebs413.blogspot.com/ | missing headers) From owner-linux-xfs@oss.sgi.com Fri Nov 18 12:20:15 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 18 Nov 2005 12:20:24 -0800 (PST) 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 jAIKKEO0015593 for ; Fri, 18 Nov 2005 12:20:15 -0800 Received: from soloth.lewis.org (localhost.localdomain [127.0.0.1]) by soloth.lewis.org (8.12.11/8.12.11) with ESMTP id jAIKGp3p011576 for ; Fri, 18 Nov 2005 15:16:51 -0500 Received: from localhost (jlewis@localhost) by soloth.lewis.org (8.12.11/8.12.11/Submit) with ESMTP id jAIKGp6a011572 for ; Fri, 18 Nov 2005 15:16:51 -0500 X-Authentication-Warning: soloth.lewis.org: jlewis owned process doing -bs Date: Fri, 18 Nov 2005 15:16:51 -0500 (EST) From: Jon Lewis To: linux-xfs@oss.sgi.com Subject: Re: RHEL ES 4 In-Reply-To: <437E0297.40807@sgi.com> Message-ID: References: <32927.68.52.44.223.1132279914.squirrel@66.238.243.52> <437D6935.2090905@sgi.com> <1132326431.12165.9.camel@rwthompson.landmarkdigital.com> <437DFBD8.3070106@gmx.net> <437E0297.40807@sgi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 6595 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jlewis@lewis.org Precedence: bulk X-list: linux-xfs Content-Length: 987 Lines: 25 On Fri, 18 Nov 2005, Eric Sandeen wrote: >> i recall an issue, where one was in need to xfs_check/xfs_repair a big xfs >> volume and did not have enough memory. with sizes like yours i'd run >> xfs_check & friends before going into production, just in case... >> >> but then again i don't remember the thread this issue was discussed, so >> it's totally bogus perhaps... > > Oh, repair on a 300T filesystem -wil-l be painful anywhere, I think, > unfortunately. There's a big difference between painful (waiting days, weeks? for an fsck), and impossible (needing more physical memory than can be installed) to do the fsck. One fs this large seems like a recipe for trouble. What are you planning on storing? ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From owner-linux-xfs@oss.sgi.com Fri Nov 18 12:24:05 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 18 Nov 2005 12:24:16 -0800 (PST) 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 jAIKO4O0016137 for ; Fri, 18 Nov 2005 12:24:05 -0800 Received: from from [127.0.0.1] (helo=base.ty.sabi.co.UK) by ty.sabi.co.UK with esmtp(Exim 4.54 #1) id 1EdChN-0001jm-Ju for ; Fri, 18 Nov 2005 20:19:05 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17278.14135.445455.274801@base.ty.sabi.co.UK> Date: Fri, 18 Nov 2005 20:19:03 +0000 X-Face: SMJE]JPYVBO-9UR%/8d'mG.F!@.,l@c[f'[%S8'BZIcbQc3/">GrXDwb#;fTRGNmHr^JFb SAptvwWc,0+z+~p~"Gdr4H$(|N(yF(wwCM2bW0~U?HPEE^fkPGx^u[*[yV.gyB!hDOli}EF[\cW*S H&spRGFL}{`bj1TaD^l/"[ msn( /TH#THs{Hpj>)]f> References: <32927.68.52.44.223.1132279914.squirrel@66.238.243.52> <437D6935.2090905@sgi.com> <1132326431.12165.9.camel@rwthompson.landmarkdigital.com> <437DFBD8.3070106@gmx.net> <437E0297.40807@sgi.com> <437E053E.8090704@gmx.net> <437E190B.7070901@sgi.com> X-Mailer: VM 7.17 under 21.4 (patch 17) XEmacs Lucid From: pg_xfs@xfs.for.sabi.co.UK (Peter Grandi) X-Disclaimer: This message contains only personal opinions X-archive-position: 6596 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: pg_xfs@xfs.for.sabi.co.UK Precedence: bulk X-list: linux-xfs Content-Length: 1756 Lines: 51 >>> On Fri, 18 Nov 2005 12:10:19 -0600, Eric Sandeen >>> said: [ ... ] >>> Oh, repair on a 300T filesystem -wil-l be painful anywhere, >>> I think, unfortunately. >> hm, painful yes, but hopefully not impossible? otherwise if >> sth. goes wrong on a 300TB fs the only way to fix it would be >> restoring from backup, no matter how tiny the corruption >> might be (and xfs_repair could fix it easliy if only the >> volume was not so big).... > The time & memory requirements for repair on a filesystem of > this size are currently extremely large... there have been > some rules of thumb for time/memory requirements on this list > before, but I don't have them offhand... As a handy pointer I summarized the issue a bit, with links to past discussions, in a recent posting, Nov. 10th.: http://OSS.SGI.com/archives/linux-xfs/2005-11/msg00051.html BTW, I was scanning recently the XFS mailing list archives (and got depressed by the sheer percentage of fools trying rather ambitious things), and 'xfs_check'/'xfs_repair' time/space taken is a common ''surprise''. My impression is that the most common questions are: * What about XFS and RH EL 3/4? * What about files filled with zeroes? * What about XFS, lots of other stuff, and 4K kernel stacks? * How much RAM do 'xfs_check'/'xfs_repair' take? * I got RAM and plenty of swap space, 'xfs_check'/'xfs_repair' still fail on 32 bit system on filesystems larger than 2TiB? * What about XFS, small lowmem and lots and lots of cached pages with kernel 2.4? * What about XFS and SCSI HAs that don't support READ/WRITE16? I suppose that someone could put these in a little web page and then put the URL in the footer of every email sent out by the mailing list processor. From owner-linux-xfs@oss.sgi.com Fri Nov 18 14:30:15 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 18 Nov 2005 14:30:19 -0800 (PST) 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 jAIMUFO0023490 for ; Fri, 18 Nov 2005 14:30:15 -0800 Received: from from [127.0.0.1] (helo=base.ty.sabi.co.UK) by ty.sabi.co.UK with esmtp(Exim 4.54 #1) id 1EdEgv-0002BU-Bt for ; Fri, 18 Nov 2005 22:26:45 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17278.21797.158098.177921@base.ty.sabi.co.UK> Date: Fri, 18 Nov 2005 22:26:45 +0000 X-Face: SMJE]JPYVBO-9UR%/8d'mG.F!@.,l@c[f'[%S8'BZIcbQc3/">GrXDwb#;fTRGNmHr^JFb SAptvwWc,0+z+~p~"Gdr4H$(|N(yF(wwCM2bW0~U?HPEE^fkPGx^u[*[yV.gyB!hDOli}EF[\cW*S H&spRGFL}{`bj1TaD^l/"[ msn( /TH#THs{Hpj>)]f> Subject: Re: RHEL ES 4 In-Reply-To: References: <32927.68.52.44.223.1132279914.squirrel@66.238.243.52> <437D6935.2090905@sgi.com> <1132326431.12165.9.camel@rwthompson.landmarkdigital.com> <437DFBD8.3070106@gmx.net> <437E0297.40807@sgi.com> X-Mailer: VM 7.17 under 21.4 (patch 17) XEmacs Lucid From: pg_xfs@xfs.for.sabi.co.UK (Peter Grandi) X-Disclaimer: This message contains only personal opinions X-archive-position: 6597 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: pg_xfs@xfs.for.sabi.co.UK Precedence: bulk X-list: linux-xfs Content-Length: 1266 Lines: 32 >>> On Fri, 18 Nov 2005 15:16:51 -0500 (EST), Jon Lewis >>> said: [ ... the legendary :-) 120-300TB filesystem ... ] jlewis> One fs this large seems like a recipe for trouble. It is a ''where angels fear to tread'' situation. :-) However, whether one decides to store 300TB as a single fs or rather some less ''optimistic'' way, the sheer amount of data involved requires a massive underlying storage and backup (never mind _offsite_ backup) system. 300GB drives are around 2^38B, and 300TB are around 2^48. This means that one probably is looking at a storage system with around 4*2^(48-38) drives, that is around 4,000 drives (and that factor of 4 is probably a conservative one, in most cases I'd be more comfortable with a factor of 6). jlewis> What are you planning on storing? That's a good question, but it is not even the biggest problem; just the amount of data and of hardware needed to store it are a bigger issue (and I laughed when I read the ''concat of thin RAID5s SANs''), never mind what the data looks like and how it should be stored. I think indeed that a team of experienced large storage system consultants analyzing in depth the whole situation that gives rise to a 300TB storage problem should be looking at it... From owner-linux-xfs@oss.sgi.com Fri Nov 18 23:26:18 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 18 Nov 2005 23:26:21 -0800 (PST) Received: from tyo202.gate.nec.co.jp (TYO202.gate.nec.co.jp [210.143.35.52]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jAJ7QHO0028964 for ; Fri, 18 Nov 2005 23:26:18 -0800 Received: from mailgate3.nec.co.jp (mailgate53.nec.co.jp [10.7.69.161] (may be forged)) by tyo202.gate.nec.co.jp (8.11.7/3.7W01080315) with ESMTP id jAJ7Mjb09620 for ; Sat, 19 Nov 2005 16:22:45 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id jAJ7Mj919295 for linux-xfs@oss.sgi.com; Sat, 19 Nov 2005 16:22:45 +0900 (JST) Received: from secsv2.tnes.nec.co.jp (tnesvc1.tnes.nec.co.jp [10.1.101.14]) by mailsv5.nec.co.jp (8.11.7/3.7W-MAILSV4-NEC) with ESMTP id jAJ7Mjn27003 for ; Sat, 19 Nov 2005 16:22:45 +0900 (JST) Received: from TNESVC1.tnes.nec.co.jp ([10.1.101.14]) by secsv2.tnes.nec.co.jp (ExpressMail 5.10) with SMTP id 20051119.162306.75601980 for ; Sat, 19 Nov 2005 16:23:06 +0900 Received: FROM mailsv.tnes.nec.co.jp BY TNESVC1.tnes.nec.co.jp ; Sat Nov 19 16:23:05 2005 +0900 Received: from rifu.bsd.tnes.nec.co.jp (rifu.bsd.tnes.nec.co.jp [10.1.104.1]) by mailsv.tnes.nec.co.jp (8.11.6/3.7W01031510) with ESMTP id jAJ7Mha23075; Sat, 19 Nov 2005 16:22:44 +0900 (JST) Received: from noshiro.bsd.tnes.nec.co.jp (noshiro.bsd.tnes.nec.co.jp [10.1.104.24]) by rifu.bsd.tnes.nec.co.jp (8.12.11/3.7W/BSD-TNES-MX01) with ESMTP id jAJ7Mhkn021885; Sat, 19 Nov 2005 16:22:43 +0900 Received: from localhost (localhost.localdomain [127.0.0.1]) by noshiro.bsd.tnes.nec.co.jp (Postfix) with ESMTP id 70B6574A9C; Sat, 19 Nov 2005 16:22:43 +0900 (JST) Date: Sat, 19 Nov 2005 16:22:43 +0900 (JST) Message-Id: <20051119.162243.884009747.masano@tnes.nec.co.jp> To: sandeen@sgi.com Cc: linux-xfs@oss.sgi.com Subject: Re: [PATCH] fix deadlock on ENOSPC From: ASANO Masahiro In-Reply-To: <437DF8D8.9060704@sgi.com> References: <20051115.213347.607955969.masano@tnes.nec.co.jp> <20051118.192417.291442852.masano@tnes.nec.co.jp> <437DF8D8.9060704@sgi.com> X-Mailer: Mew version 3.3 on XEmacs 21.4.11 (Native Windows TTY Support) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 6598 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: masano@tnes.nec.co.jp Precedence: bulk X-list: linux-xfs Content-Length: 701 Lines: 26 Hi Eric, > ASANO Masahiro wrote: > >>Hi SGI guys, > >> > >>As I previously reported, XFS has a deadlock problem on a ENOSPC > >>device. > > > > > > No one comments the patch I sent 3 days ago. > > I'd like to know whether someone is looking now, or it's simply > > rejected. > > It's not been rejected, but we need to find some time to look into it. We know > of the bug, but we need a bit of time to review your patch. We do appreciate > your efforts to resolve the problem! Thank you for your reply. We know the XFS allocation mechanism is multifunctional and extraordinary complicated. There is also a kind of balance on it. To fix allocator needs a bit of time. I'll wait. -- masano From owner-linux-xfs@oss.sgi.com Sun Nov 20 10:24:46 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 20 Nov 2005 10:24:55 -0800 (PST) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jAKIOkO0022395 for ; Sun, 20 Nov 2005 10:24:46 -0800 Received: from internal-mail-relay.corp.sgi.com (internal-mail-relay.corp.sgi.com [198.149.32.51]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id jAKJWTDg021351 for ; Sun, 20 Nov 2005 11:32:29 -0800 Received: from naboo.americas.sgi.com (naboo.americas.sgi.com [128.162.233.73]) by internal-mail-relay.corp.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id jAKILL2Z289052437; Sun, 20 Nov 2005 10:21:21 -0800 (PST) Received: from naboo.americas.sgi.com (localhost [127.0.0.1]) by naboo.americas.sgi.com (8.13.3/8.13.3) with ESMTP id jAKILL1q022211; Sun, 20 Nov 2005 12:21:21 -0600 Received: (from hch@localhost) by naboo.americas.sgi.com (8.13.3/8.13.3/Submit) id jAKILLv8022210; Sun, 20 Nov 2005 12:21:21 -0600 Date: Sun, 20 Nov 2005 12:21:21 -0600 From: Christoph Hellwig Message-Id: <200511201821.jAKILLv8022210@naboo.americas.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Subject: TAKE 946028 - Mark some lookup tables const. X-archive-position: 6599 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@relay.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 910 Lines: 21 Thanks to Arjan van de Ven for spotting these. Date: Sun Nov 20 10:21:07 PST 2005 Workarea: naboo.americas.sgi.com:/go/space/hch/xfs-2.6.x Inspected by: arjanv@infradead.org The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: xfs-linux:xfs-kern:202617a fs/xfs/xfs_mount.c - 1.367 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_mount.c.diff?r1=text&tr1=1.367&r2=text&tr2=1.366&f=h fs/xfs/support/debug.c - 1.30 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/support/debug.c.diff?r1=text&tr1=1.30&r2=text&tr2=1.29&f=h fs/xfs/linux-2.6/xfs_stats.c - 1.21 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_stats.c.diff?r1=text&tr1=1.21&r2=text&tr2=1.20&f=h fs/xfs/linux-2.4/xfs_stats.c - 1.22 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_stats.c.diff?r1=text&tr1=1.22&r2=text&tr2=1.21&f=h From owner-linux-xfs@oss.sgi.com Sun Nov 20 15:11:44 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 20 Nov 2005 15:11:49 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id jAKNBhO0009208 for ; Sun, 20 Nov 2005 15:11:44 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA28684; Mon, 21 Nov 2005 10:08:12 +1100 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id jAKN8Mkt6819932; Mon, 21 Nov 2005 10:08:23 +1100 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id jAKN8KSN6814984; Mon, 21 Nov 2005 10:08:20 +1100 (EST) Date: Mon, 21 Nov 2005 10:08:20 +1100 From: Nathan Scott To: Lawrence Walton Cc: linux-kernel , linux-xfs@oss.sgi.com Subject: Re: unable to use dpkg 2.6.15-rc2 Message-ID: <20051121100820.D6790390@wobbly.melbourne.sgi.com> References: <20051120075233.GA20295@the-penguin.otak.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20051120075233.GA20295@the-penguin.otak.com>; from lawrence@the-penguin.otak.com on Sat, Nov 19, 2005 at 11:52:33PM -0800 X-archive-position: 6600 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1908 Lines: 54 Hi there, On Sat, Nov 19, 2005 at 11:52:33PM -0800, Lawrence Walton wrote: > Hi! > > This is the second report of this error. Please CC linux-xfs if you want to be sure XFS people see your report. > It's reproducible in 2.6.15-rc1, 2.6.15-rc1-mm1, 2.6.15-rc1-mm2 and > 2.6.15-rc2. > > It does not occur in 2.6.14. > > Most easily triggered by "make clean" in the Linux source, for those of > you without access to dpkg. But both clean and dpkg will trigger it. So far I've not been able to reproduce this; I'm using "make clean" and it works just fine for me (I'm using the current git tree). > There are no oops. No, it looks like XFS is stuck waiting for an IO to complete. > I'm not sure what to report next, though If I were to guess it is a > interaction between XFS file system and SCSI. I've got another SCSI box > that is very similar that runs rc1, rc1-mm1 and rc1-mm2 just fine, the > only real difference being it has a ext3 file system instead. > > The driver for the SCSI card (aic7xxx) did not appear change. > lspi says it's a Adaptec AIC-7892A U160/m (rev 2) card. From your earlier report with the stack traces included, it looks like XFS is waiting for a log write to complete, but it never does (which is not valid driver behaviour). I'm using the sym53c8xx driver in my testing BTW, which is different to you, so maybe see if this still happens for you with different hardware? (if you can). > Questions, patches, flames are welcome. You could also try to drop the XFS (fs/xfs) code from 2.6.14 into 2.6.15-rc2 and see if your problem persists. There isn't anything I can see from scanning though everything we committed into .15 so far that would explain this. Oh, an easier test you could do would be to try XFS CVS from oss.sgi.com - that has 2.6.14 + all the XFS changes since then, so that should confirm/deny an XFS regression too. Thanks! cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Nov 20 15:46:10 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 20 Nov 2005 15:46:14 -0800 (PST) Received: from mailgate.Cadence.COM (mailgate.Cadence.COM [158.140.2.1]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jAKNk9O0011562 for ; Sun, 20 Nov 2005 15:46:09 -0800 Received: from MAILSJ1.global.cadence.com (exclsj03.Cadence.COM [158.140.128.134]) by mailgate.Cadence.COM (8.9.3/8.9.3) with ESMTP id PAA12584; Sun, 20 Nov 2005 15:42:34 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: unable to use dpkg 2.6.15-rc2 Date: Sun, 20 Nov 2005 15:41:00 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: unable to use dpkg 2.6.15-rc2 Thread-Index: AcXuJ3tGL9uiDxdgQ0K+49GkHFiR2gABGHG5 References: <20051120075233.GA20295@the-penguin.otak.com> <20051121100820.D6790390@wobbly.melbourne.sgi.com> From: "Chris Croswhite" To: "Nathan Scott" , "Lawrence Walton" Cc: "linux-kernel" , X-Received: By mailgate.Cadence.COM as PAA12584 at Sun Nov 20 15:42:34 2005 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id jAKNkAO0011564 X-archive-position: 6601 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: csc@cadence.com Precedence: bulk X-list: linux-xfs Content-Length: 2234 Lines: 67 Just another data point, running 2615rc1/2 I do not have an issue with XFS runing on MPT scsi device. -----Original Message----- From: linux-xfs-bounce@oss.sgi.com on behalf of Nathan Scott Sent: Sun 20-Nov-05 15:08 To: Lawrence Walton Cc: linux-kernel; linux-xfs@oss.sgi.com Subject: Re: unable to use dpkg 2.6.15-rc2 Hi there, On Sat, Nov 19, 2005 at 11:52:33PM -0800, Lawrence Walton wrote: > Hi! > > This is the second report of this error. Please CC linux-xfs if you want to be sure XFS people see your report. > It's reproducible in 2.6.15-rc1, 2.6.15-rc1-mm1, 2.6.15-rc1-mm2 and > 2.6.15-rc2. > > It does not occur in 2.6.14. > > Most easily triggered by "make clean" in the Linux source, for those of > you without access to dpkg. But both clean and dpkg will trigger it. So far I've not been able to reproduce this; I'm using "make clean" and it works just fine for me (I'm using the current git tree). > There are no oops. No, it looks like XFS is stuck waiting for an IO to complete. > I'm not sure what to report next, though If I were to guess it is a > interaction between XFS file system and SCSI. I've got another SCSI box > that is very similar that runs rc1, rc1-mm1 and rc1-mm2 just fine, the > only real difference being it has a ext3 file system instead. > > The driver for the SCSI card (aic7xxx) did not appear change. > lspi says it's a Adaptec AIC-7892A U160/m (rev 2) card. From your earlier report with the stack traces included, it looks like XFS is waiting for a log write to complete, but it never does (which is not valid driver behaviour). I'm using the sym53c8xx driver in my testing BTW, which is different to you, so maybe see if this still happens for you with different hardware? (if you can). > Questions, patches, flames are welcome. You could also try to drop the XFS (fs/xfs) code from 2.6.14 into 2.6.15-rc2 and see if your problem persists. There isn't anything I can see from scanning though everything we committed into .15 so far that would explain this. Oh, an easier test you could do would be to try XFS CVS from oss.sgi.com - that has 2.6.14 + all the XFS changes since then, so that should confirm/deny an XFS regression too. Thanks! cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Nov 20 22:47:13 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 20 Nov 2005 22:47:15 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id jAL6lBO0016990 for ; Sun, 20 Nov 2005 22:47:12 -0800 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA07740; Mon, 21 Nov 2005 17:43:42 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id B2E3349A5DA9; Mon, 21 Nov 2005 17:43:41 +1100 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 946042 - libdm Message-Id: <20051121064341.B2E3349A5DA9@chook.melbourne.sgi.com> Date: Mon, 21 Nov 2005 17:43:41 +1100 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 6602 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1185 Lines: 25 Resolve getdents/getdents64 and various build issues from libdm using kernel types directly. Date: Mon Nov 21 17:43:07 AEDT 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-cmds Inspected by: bobo@sgi.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:24519a dmapi/libdm/getdents.h - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/dmapi/libdm/getdents.h dmapi/libdm/getdents.c - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/dmapi/libdm/getdents.c dmapi/include/dmapi.h - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/dmapi/include/dmapi.h.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h dmapi/libdm/dm_handle2path.c - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/dmapi/libdm/dm_handle2path.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h dmapi/libdm/dm_handle.c - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/dmapi/libdm/dm_handle.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h dmapi/libdm/Makefile - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/dmapi/libdm/Makefile.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h From owner-linux-xfs@oss.sgi.com Mon Nov 21 06:19:56 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 21 Nov 2005 06:20:03 -0800 (PST) Received: from host82-191.pool8547.interbusiness.it (host82-191.pool8547.interbusiness.it [85.47.191.82]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id jALEJfO4005475; Mon, 21 Nov 2005 06:19:53 -0800 Received: (from apache@) by ..com (4.13.0/8.12.1/Submit) id j31CkQBj384821; Mon, 21 Nov 2005 18:14:29 +0400 Date: Mon, 21 Nov 2005 17:15:29 +0300 Message-Id: <286504011246.j31CkQBj030964@..com> Date: Mon, 21 Nov 2005 09:10:29 -0500 From: "Bruno Grove" Subject: Only Cailis Help dB X-Mailer: Mulberry/2.1.0a3 (Win32 Demo) To: kernprof-bounce@oss.sgi.com X-Bugzilla-Reason: X-archive-position: 6604 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ghtlrwvfiohk@yahoo.com Precedence: bulk X-list: linux-xfs Content-Length: 260 Lines: 13 Introducing E-rectiion Pills "Caillis Softabs" which guarantees long lasting pleasures. Safe to take without any side-effect. Satisfaction guuaranteeess... or your money back without question ask. http://uk.geocities.com/Cyrillus96618Farrel18339/ z1eAyN From owner-linux-xfs@oss.sgi.com Mon Nov 21 06:47:13 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 21 Nov 2005 06:47:20 -0800 (PST) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jALElDO0008043 for ; Mon, 21 Nov 2005 06:47:13 -0800 Received: from internal-mail-relay.corp.sgi.com (internal-mail-relay.corp.sgi.com [198.149.32.51]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id jALFt3XJ019482 for ; Mon, 21 Nov 2005 07:55:03 -0800 Received: from naboo.americas.sgi.com (naboo.americas.sgi.com [128.162.233.73]) by internal-mail-relay.corp.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id jALEgm2Z289498899; Mon, 21 Nov 2005 06:42:48 -0800 (PST) Received: from naboo.americas.sgi.com (localhost [127.0.0.1]) by naboo.americas.sgi.com (8.13.3/8.13.3) with ESMTP id jALEgmYm021922; Mon, 21 Nov 2005 08:42:48 -0600 Received: (from hch@localhost) by naboo.americas.sgi.com (8.13.3/8.13.3/Submit) id jALEgm5p021921; Mon, 21 Nov 2005 08:42:48 -0600 Date: Mon, 21 Nov 2005 08:42:48 -0600 From: Christoph Hellwig Message-Id: <200511211442.jALEgm5p021921@naboo.americas.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Subject: TAKE 945483 - Write log dummy record when freezing filesystem X-archive-position: 6605 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@relay.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 667 Lines: 17 Date: Mon Nov 21 06:42:36 PST 2005 Workarea: naboo.americas.sgi.com:/go/space/hch/xfs-2.6.x 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:202638a fs/xfs/xfs_vfsops.c - 1.489 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vfsops.c.diff?r1=text&tr1=1.489&r2=text&tr2=1.488&f=h fs/xfs/xfs_fsops.h - 1.29 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_fsops.h.diff?r1=text&tr1=1.29&r2=text&tr2=1.28&f=h fs/xfs/xfs_fsops.c - 1.111 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_fsops.c.diff?r1=text&tr1=1.111&r2=text&tr2=1.110&f=h From owner-linux-xfs@oss.sgi.com Mon Nov 21 09:12:54 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 21 Nov 2005 09:12:57 -0800 (PST) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jALHCrO0024111 for ; Mon, 21 Nov 2005 09:12:54 -0800 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id jALH9SxT012721 for ; Mon, 21 Nov 2005 11:09:28 -0600 Received: from wrlarun (sshgate.corp.sgi.com [198.149.36.12]) by cthulhu.engr.sgi.com (SGI-8.12.5/8.12.5) with SMTP id jALH9Qws28391637; Mon, 21 Nov 2005 09:09:27 -0800 (PST) Message-ID: <00de01c5eebe$325d2810$6f00a8c0@comcast.net> From: "John Hawkes" To: "Nathan Scott" , "Lawrence Walton" Cc: "linux-kernel" , References: <20051120075233.GA20295@the-penguin.otak.com> <20051121100820.D6790390@wobbly.melbourne.sgi.com> Subject: Re: unable to use dpkg 2.6.15-rc2 Date: Mon, 21 Nov 2005 09:08:29 -0800 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 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-archive-position: 6607 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hawkes@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2912 Lines: 67 From: "Nathan Scott" > > It's reproducible in 2.6.15-rc1, 2.6.15-rc1-mm1, 2.6.15-rc1-mm2 and > > 2.6.15-rc2. > > > > It does not occur in 2.6.14. > > > > Most easily triggered by "make clean" in the Linux source, for those of > > you without access to dpkg. But both clean and dpkg will trigger it. > > So far I've not been able to reproduce this; I'm using "make clean" > and it works just fine for me (I'm using the current git tree). I can reproduce this using with 2.6.15-rc1 using AIM7 or AIM9. I forced a corefile for one of the AIM7 threads that hung during close doing the disk_cp subtest. The AIM9 run hung doing disk_src (running each subtest for 100 seconds). I didn't coredump that one, but rather I got into kdb and did a backtrace on the AIM9 "singleuser" thread. [1]kdb> btp 16155 Stack traceback for pid 16155 0xe000003864630000 16155 16116 0 1 D 0xe000003864630330 singleuser 0xa000000100778800 schedule+0x1300 args (0xe000003864637b10, 0x7fffffffffffffff, 0xa00000010039c710, 0xa00000010077d740, 0x205) 0xa00000010077b430 schedule_timeout+0x170 args (0x7fffffffffffffff, 0xa00000010039c6f0, 0xa00000010095c680, 0xa00000010039c710, 0x60f) 0xa00000010039c710 xlog_grant_log_space+0x670 args (0xe00000347a9a6100, 0xe00000347a9db2c0, 0xa0000001008c57e0, 0xe000003864637b70, 0xe00000347a9db2f7) 0xa000000100397760 xfs_log_reserve+0x1c0 args (0xe00000347a9db2c0, 0x0, 0x2, 0xe0000038624d23d8, 0x69) 0xa0000001003b11c0 xfs_trans_reserve+0xe0 args (0xe0000038624d2388, 0x29, 0x268b8, 0x0, 0x4) 0xa0000001003c2e50 xfs_create+0x550 args (0xe000003c6cbaa0c8, 0xe0000038625b17ec, 0xe000003864637c30, 0xe000003864637db0, 0x0) 0xa0000001003dcbd0 linvfs_mknod+0x630 args (0xe000003c6de8a6e8, 0xe0000038625b1730, 0x81ed, 0x0, 0x0) 0xa0000001003dcd30 linvfs_create+0x30 args (0xe000003c6de8a6e8, 0xe0000038625b1730, 0x81ff, 0xa000000100191dc0, 0x40c) 0xa000000100191dc0 vfs_create+0x1c0 args (0xe000003c6de8a6e8, 0xe0000038625b1730, 0x81ff, 0xe0000038625b1768, 0xa000000100d35550) 0xa0000001001933c0 open_namei+0xea0 args (0xe0000038625b1730, 0x8242, 0x1ff, 0xe000003864637dd0, 0xe0000038625b35e0) 0xa000000100168a80 filp_open+0x40 args (0xe0000038604df000, 0x8241, 0x1ff, 0xa0000001001692b0, 0x38b) 0xa0000001001692b0 do_sys_open+0xb0 args (0xe0000038604df000, 0x8241, 0x20, 0xfffffffffffffc18, 0x5) 0xa000000100169430 sys_open+0x50 args (0x600000000005b180, 0x241, 0x1ff, 0x0, 0x8) 0xa000000100169490 sys_creat+0x30 args (0x600000000005b180, 0x1ff, 0x607fffffffd394a0, 0xc00000000000048d, 0x600000000005a9c0) 0xa00000010000b800 ia64_ret_from_syscall args (0x600000000005b180, 0x1ff, 0x607fffffffd394a0, 0xc00000000000048d) 0xa000000000004000 __kernel_syscall_via_break args (0x600000000005b180, 0x1ff, 0x607fffffffd394a0, 0xc00000000000048d) From owner-linux-xfs@oss.sgi.com Mon Nov 21 10:25:59 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 21 Nov 2005 10:26:03 -0800 (PST) Received: from the-penguin.otak.com (the-penguin.otak.com [65.37.126.18]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jALIPxO0029160 for ; Mon, 21 Nov 2005 10:25:59 -0800 Received: from lawrence by the-penguin.otak.com with local (Exim 4.54) id 1EeGJK-0007Ju-SG; Mon, 21 Nov 2005 10:22:38 -0800 Date: Mon, 21 Nov 2005 10:22:38 -0800 From: Lawrence Walton To: Nathan Scott Cc: linux-xfs Subject: Re: unable to use dpkg 2.6.15-rc2 Message-ID: <20051121182238.GA28020@the-penguin.otak.com> References: <20051120075233.GA20295@the-penguin.otak.com> <20051121100820.D6790390@wobbly.melbourne.sgi.com> <20051121173356.A6818393@wobbly.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vtzGhvizbBRQ85DL" Content-Disposition: inline In-Reply-To: <20051121173356.A6818393@wobbly.melbourne.sgi.com> X-Operating-System: Linux 2.6.15-rc1-mm1 on an i686 User-Agent: Mutt/1.5.11 X-archive-position: 6608 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lawrence@the-penguin.otak.com Precedence: bulk X-list: linux-xfs Content-Length: 1437 Lines: 52 --vtzGhvizbBRQ85DL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Nathan Scott [nathans@sgi.com] wrote: > On Mon, Nov 21, 2005 at 10:08:20AM +1100, Nathan Scott wrote: > > You could also try to drop the XFS (fs/xfs) code from 2.6.14 into > > 2.6.15-rc2 and see if your problem persists. There isn't anything > > I can see from scanning though everything we committed into .15 so > > far that would explain this. Oh, an easier test you could do would > > be to try XFS CVS from oss.sgi.com - that has 2.6.14 + all the XFS > > changes since then, so that should confirm/deny an XFS regression > > too. Thanks! >=20 > Also, could you send me the .config file you're using please? >=20 > thanks. >=20 > --=20 > Nathan I can conferm the same behavior in the cvs version, as of this morning. =20 --=20 *--* Mail: lawrence@otak.com *--* Voice: 425.739.4247 *--* Fax: 425.827.9577 *--* HTTP://the-penguin.otak.com/~lawrence -------------------------------------- - - - - - - O t a k i n c . - - - - -=20 --vtzGhvizbBRQ85DL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDghBusgPkFxgrWYkRAmwhAKCZqETHKBHTpOZmB9/izJxLdSvCewCbBAII ssRZdsI8LchvXpINMNeaVs4= =vwAn -----END PGP SIGNATURE----- --vtzGhvizbBRQ85DL-- From owner-linux-xfs@oss.sgi.com Tue Nov 22 09:23:49 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 22 Nov 2005 09:23:55 -0800 (PST) Received: from mail-relay-3.tiscali.it (mail-relay-3.tiscali.it [213.205.33.43]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jAMHNmO0013922 for ; Tue, 22 Nov 2005 09:23:48 -0800 Received: from dreamland.darkstar.lan (84.222.34.250) by mail-relay-3.tiscali.it (7.2.069.1) id 43830B470000E2A4; Tue, 22 Nov 2005 18:20:17 +0100 Received: by dreamland.darkstar.lan (Postfix, from userid 1000) id 90CE91E64A; Tue, 22 Nov 2005 18:20:27 +0100 (CET) Date: Tue, 22 Nov 2005 18:20:27 +0100 From: Luca To: linux-kernel@vger.kernel.org Cc: linux-xfs@oss.sgi.com Subject: Re: unable to use dpkg 2.6.15-rc2 Message-ID: <20051122172027.GA11219@dreamland.darkstar.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051121100820.D6790390@wobbly.melbourne.sgi.com> User-Agent: Mutt/1.5.10i X-archive-position: 6610 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kronos@kronoz.cjb.net Precedence: bulk X-list: linux-xfs Content-Length: 4116 Lines: 106 (please CC me, I'm not subscribed) Nathan Scott ha scritto: >> It's reproducible in 2.6.15-rc1, 2.6.15-rc1-mm1, 2.6.15-rc1-mm2 and >> 2.6.15-rc2. >> >> It does not occur in 2.6.14. >> >> Most easily triggered by "make clean" in the Linux source, for those of >> you without access to dpkg. But both clean and dpkg will trigger it. > > So far I've not been able to reproduce this; I'm using "make clean" > and it works just fine for me (I'm using the current git tree). Confirmed here with 2.6.15-rc1 an IDE disk. Kernel is UP with CONFIG_PREEMPT and 8KB stack. The following debug options are enabled: CONFIG_DEBUG_KERNEL=y CONFIG_MAGIC_SYSRQ=y CONFIG_DEBUG_PREEMPT=y CONFIG_DEBUG_SPINLOCK=y CONFIG_DEBUG_SPINLOCK_SLEEP=y CONFIG_DEBUG_BUGVERBOSE=y CONFIG_FRAME_POINTER=y CONFIG_EARLY_PRINTK=y CONFIG_DEBUG_STACKOVERFLOW=y should I try and enable something else to gather more informations? The first time the system hung during shutdown, with kernel stuck in pdflush (probably waked up by sync): pdflush D E3A593A8 0 27641 6 27650 1233 (L-TLB) d6a099fc 00000001 00000003 e3a593a8 00000296 00000001 d6a099d8 c01174af 00000000 00000000 d0cb7570 0001226c 268d47fe 00001648 cc890590 cc8906b8 7fffffff eef27240 d6a09a68 d6a09a38 c030a734 efa70c00 d6a09a18 d6a09a1c Call Trace: [] schedule_timeout+0x94/0xa0 [] xlog_grant_log_space+0x1dd/0x370 [xfs] [] xfs_log_reserve+0x77/0xb0 [xfs] [] xfs_trans_reserve+0x7c/0x1a0 [xfs] [] xfs_iomap_write_allocate+0x10c/0x4d0 [xfs] [] xfs_iomap+0x3be/0x470 [xfs] [] xfs_bmap+0x2c/0x40 [xfs] [] xfs_map_blocks+0x3c/0x90 [xfs] [] xfs_page_state_convert+0x4e0/0x610 [xfs] [] linvfs_writepage+0x5e/0xf0 [xfs] [] mpage_writepages+0x242/0x3d0 [] do_writepages+0x2a/0x30 [] __sync_single_inode+0x70/0x200 [] __writeback_single_inode+0xc4/0x1a0 [] sync_sb_inodes+0x167/0x2c0 [] writeback_inodes+0xf5/0x140 [] wb_kupdate+0xb2/0x130 [] __pdflush+0xd5/0x200 [] pdflush+0x29/0x30 [] kthread+0x95/0xd0 [] kernel_thread_helper+0x5/0x18 The second time happened while I was doing a "rm -rf" of a kernel tree: rm D E4913E38 0 2831 2825 (NOTLB) e4cefdb0 00000001 00000003 e4913e38 00000296 00000003 e4cefd8c c01174af 00000000 00000000 e4b3e030 0005f191 cdb3c946 00000028 e4c98090 e4c981b8 7fffffff ef1069d8 e4cefe1c e4cefdec c030a734 eee2f800 e4cefdcc e4cefdd0 Call Trace: [] schedule_timeout+0x94/0xa0 [] xlog_grant_log_space+0x1dd/0x370 [xfs] [] xfs_log_reserve+0x77/0xb0 [xfs] [] xfs_trans_reserve+0x7c/0x1a0 [xfs] [] xfs_inactive+0x34d/0x4d0 [xfs] [] linvfs_clear_inode+0x68/0x90 [xfs] [] clear_inode+0xf4/0x100 [] generic_delete_inode+0xed/0x110 [] generic_drop_inode+0xf/0x20 [] iput+0x56/0x80 [] sys_unlink+0xcc/0x120 [] syscall_call+0x7/0xb At the time of the rm -rf the partition was somewhat full: root@dreamland:~# df /usr Filesystem 1K-blocks Used Available Use% Mounted on /dev/hda8 33996740 33549488 447252 99% /usr root@dreamland:~# df -i /usr Filesystem Inodes IUsed IFree IUse% Mounted on /dev/hda8 1997584 148695 1848889 8% /usr The first time there was a lot more of free space though (a couple of GB). > From your earlier report with the stack traces included, it looks > like XFS is waiting for a log write to complete, but it never > does (which is not valid driver behaviour). I'm using the sym53c8xx > driver in my testing BTW, which is different to you, so maybe see if > this still happens for you with different hardware? (if you can). Here it happens with an IDE disk, connected to VT8233A southbridge. Luca -- Home: http://kronoz.cjb.net Carpe diem, quam minimum credula postero. (Q. Horatius Flaccus) From owner-linux-xfs@oss.sgi.com Tue Nov 22 13:49:37 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 22 Nov 2005 13:49:46 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id jAMLnZO0004057 for ; Tue, 22 Nov 2005 13:49:36 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA01006; Wed, 23 Nov 2005 08:46:00 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id jAMLk6kt6863797; Wed, 23 Nov 2005 08:46:09 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id jAMLinl8000846; Wed, 23 Nov 2005 08:44:50 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id jAMLihw2000844; Wed, 23 Nov 2005 08:44:43 +1100 Date: Wed, 23 Nov 2005 08:44:43 +1100 From: Nathan Scott To: Lawrence Walton , John Hawkes , Luca Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: unable to use dpkg 2.6.15-rc2 Message-ID: <20051122214443.GA781@frodo> References: <20051121100820.D6790390@wobbly.melbourne.sgi.com> <20051122172027.GA11219@dreamland.darkstar.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051122172027.GA11219@dreamland.darkstar.lan> User-Agent: Mutt/1.5.3i X-archive-position: 6611 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 998 Lines: 31 On Tue, Nov 22, 2005 at 06:20:27PM +0100, Luca wrote: > (please CC me, I'm not subscribed) > > Nathan Scott ha scritto: > >> It's reproducible in 2.6.15-rc1, 2.6.15-rc1-mm1, 2.6.15-rc1-mm2 and > >> 2.6.15-rc2. > >> > >> It does not occur in 2.6.14. > >> > >> Most easily triggered by "make clean" in the Linux source, for those of > >> you without access to dpkg. But both clean and dpkg will trigger it. > > > > So far I've not been able to reproduce this; I'm using "make clean" > > and it works just fine for me (I'm using the current git tree). > > Confirmed here with 2.6.15-rc1 an IDE disk. Kernel is UP with > CONFIG_PREEMPT and 8KB stack. The following debug options are enabled: > Keith Owens has managed to reproduce this locally, and has been working on tracking it back to a single change - so, we'll start trying to figure out whats gone wrong here shortly, and will get a fix merged as soon as we can. Thanks for reporting the problem. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Fri Nov 25 01:02:03 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 25 Nov 2005 01:02:07 -0800 (PST) Received: from ws15.citiz.net (ws15.citiz.net [218.1.66.100]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id jAP920O0022415 for ; Fri, 25 Nov 2005 01:02:02 -0800 Received: (umta 2655 invoked by alias); 25 Nov 2005 08:58:41 -0000 X-Lasthop: 218.25.172.144 Received: from unknown (HELO d3zhangyue) (unknown@218.25.172.144) by localhost with SMTP; 25 Nov 2005 08:58:41 -0000 Message-ID: <005501c5f19e$680e1f90$6100040a@d3zhangyue> From: "meiyoutt" To: Subject: why 9 million TB for xfs Date: Fri, 25 Nov 2005 16:58:27 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.2180 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit X-archive-position: 6612 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: meiyoutt@citiz.net Precedence: bulk X-list: linux-xfs Content-Length: 177 Lines: 5 For xfs_sb.sb_dblocks is u64, so I don't know why xfs limit is 9 million TB. I think 16 million of blocks in xfs, so why it's 9 million TB. [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Fri Nov 25 01:29:49 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 25 Nov 2005 01:29:57 -0800 (PST) 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 jAP9TmO0024897 for ; Fri, 25 Nov 2005 01:29:48 -0800 Received: from from [127.0.0.1] (helo=base.ty.sabi.co.UK) by ty.sabi.co.UK with esmtp(Exim 4.54 #1) id 1EfZm1-0002q4-1O for ; Fri, 25 Nov 2005 09:21:41 +0000 From: pg_mh@sabi.co.UK (Peter Grandi) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17286.55204.731170.103839@base.ty.sabi.co.UK> Date: Fri, 25 Nov 2005 09:21:40 +0000 X-Face: SMJE]JPYVBO-9UR%/8d'mG.F!@.,l@c[f'[%S8'BZIcbQc3/">GrXDwb#;fTRGNmHr^JFb SAptvwWc,0+z+~p~"Gdr4H$(|N(yF(wwCM2bW0~U?HPEE^fkPGx^u[*[yV.gyB!hDOli}EF[\cW*S H&spRGFL}{`bj1TaD^l/"[ msn( /TH#THs{Hpj>)]f> Subject: Re: why 9 million TB for xfs In-Reply-To: <005501c5f19e$680e1f90$6100040a@d3zhangyue> References: <005501c5f19e$680e1f90$6100040a@d3zhangyue> X-Mailer: VM 7.17 under 21.4 (patch 17) XEmacs Lucid Fom: pg_xfs@xfs.for.sabi.co.UK (Peter Grandi) X-Disclaimer: This message contains only personal opinions X-archive-position: 6613 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: pg_mh@sabi.co.UK Precedence: bulk X-list: linux-xfs Content-Length: 575 Lines: 16 >>> On Fri, 25 Nov 2005 16:58:27 +0800, "meiyoutt" >>> said: meiyoutt> For xfs_sb.sb_dblocks is u64, so I don't know why xfs meiyoutt> limit is 9 million TB. I think 16 million of blocks meiyoutt> in xfs, so why it's 9 million TB. It is not as simple as that, and a filesystem cannot be larger than the block device on which it is stored... Thus maximum sizes depend on: * Whether the kernel is 32 or 64 bit. * Whether they are expressed in tibibytes or terabytes. * Whether the kernel IO/cache subsystem uses signed or unsigned 32/64 bit 'int's. From owner-linux-xfs@oss.sgi.com Fri Nov 25 17:57:14 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 25 Nov 2005 17:57:19 -0800 (PST) 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 jAQ1vDO0010256 for ; Fri, 25 Nov 2005 17:57:14 -0800 Received: from g1538.g.pppool.de ([80.185.21.56] helo=mail.housecafe.de) by mail.g-house.de with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1EfpFw-0001M5-0y for linux-xfs@oss.sgi.com; Sat, 26 Nov 2005 02:53:36 +0100 Received: from prinz64.housecafe.de ([192.168.10.11] helo=[127.0.0.1]) by mail.housecafe.de with esmtp (Exim 4.54) id 1EfpFc-0006ic-QO for linux-xfs@oss.sgi.com; Sat, 26 Nov 2005 02:53:16 +0100 Message-ID: <4387BFED.4020400@gmx.net> Date: Sat, 26 Nov 2005 02:52:45 +0100 From: "evilninja@gmx.net" User-Agent: Thunderbird 1.6a1 (Windows/20051117) MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: unable to use dpkg 2.6.15-rc2 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 0547-4, 24.11.2005), Outbound message X-Antivirus-Status: Clean X-archive-position: 6614 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: evilninja@gmx.net Precedence: bulk X-list: linux-xfs Content-Length: 751 Lines: 25 hi, i just wanted to confirm this issue and provide additional information. i can trigger the bug quite reliably when trying to "mv" directories to or within an xfs-partition. the last directory was only 40MB containing 8000 files (a git-repo). the "mv" process stays in "D" state, is unkillable and strace'ing the process makes strace going into "D" state. fwiw, i've strace'd the strace: http://nerdbynature.de/bits/sheep/2.6.15-rc2/mv.strace the box is running 2.6.15-rc2 (i386) with CONFIG_PREEMPT_NONE=y and CONFIG_4KSTACKS=y. more details here: http://nerdbynature.de/bits/sheep/2.6.15-rc2/ no raid-controller involved. thanks, Christian. -- BOFH excuse #84: Someone is standing on the ethernet cable, causing a kink in the cable From owner-linux-xfs@oss.sgi.com Sat Nov 26 20:12:47 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 26 Nov 2005 20:12:49 -0800 (PST) Received: from mail.matrix.odessa.ua (mail.matrix.farlep.net [217.146.241.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jAR4CjO0000946 for ; Sat, 26 Nov 2005 20:12:46 -0800 Received: from shaolin (kempston.ppp.matrix.private [10.64.20.138]) by mail.matrix.odessa.ua with SMTP id 1EgDme-0006R6-S6 for linux-xfs@oss.sgi.com; Sun, 27 Nov 2005 06:05:00 +0200 Message-ID: <001801c5f308$55fe1510$010aa8c0@shaolin> From: "kempston" To: Subject: Date: Sun, 27 Nov 2005 06:09:17 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit X-archive-position: 6615 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kempston@mail.ru Precedence: bulk X-list: linux-xfs Content-Length: 363 Lines: 6 Today i found strange errors on my xfs drive: some files were locatable only in ls output, but inaccessable from any other command (giving file not found). I did xfs_check and xfs_repair and as result, now i have no files on my drive at all (except empty lost+found folder) Is there anything i can do to get my files back ? [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Sun Nov 27 00:18:35 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 27 Nov 2005 00:18:39 -0800 (PST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.207]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jAR8IZO0018111 for ; Sun, 27 Nov 2005 00:18:35 -0800 Received: by wproxy.gmail.com with SMTP id 69so2064236wri for ; Sun, 27 Nov 2005 00:15:01 -0800 (PST) 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=duSildWxfhfQakzJbg8Iytyt94yuZU1AkkUd4FjpzCouYdoSkihEKY5y+/th7zuf7DJNFCwxFqIIvyG2FYNVC66KN/zKXefOOPjNYHHdy0IBJn4l2UydKqkP5wQjLB7qk1QbwLGBQuhRyDsxGk6TtrE+puCchhd0ff4Dh+cVYkk= Received: by 10.65.15.10 with SMTP id s10mr1436353qbi; Sun, 27 Nov 2005 00:15:01 -0800 (PST) Received: by 10.64.249.3 with HTTP; Sun, 27 Nov 2005 00:15:01 -0800 (PST) Message-ID: <723e46dd0511270015i3c77ca59i5d2cab00a01f4766@mail.gmail.com> Date: Sun, 27 Nov 2005 13:45:01 +0530 From: prithviraj bagchi To: linux-xfs@oss.sgi.com Subject: internate MIME-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit X-archive-position: 6616 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: prithviraj999@gmail.com Precedence: bulk X-list: linux-xfs Content-Length: 120 Lines: 6 sir i have linux fedora 4 and have broadbrand connection but i can not connect it [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Sun Nov 27 00:37:58 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 27 Nov 2005 00:38:00 -0800 (PST) Received: from mail.matrix.odessa.ua (mail.matrix.farlep.net [217.146.241.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jAR8bvO0023713 for ; Sun, 27 Nov 2005 00:37:58 -0800 Received: from shaolin (kempston.ppp.matrix.private [10.64.20.138]) by mail.matrix.odessa.ua with SMTP id 1EgHvF-0000j5-Rg for linux-xfs@oss.sgi.com; Sun, 27 Nov 2005 10:30:09 +0200 Message-ID: <006201c5f32d$611e9800$010aa8c0@shaolin> From: "kempston" To: Subject: Date: Sun, 27 Nov 2005 10:34:27 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit X-archive-position: 6617 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kempston@mail.ru Precedence: bulk X-list: linux-xfs Content-Length: 42 Lines: 4 test [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Sun Nov 27 08:28:00 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 27 Nov 2005 08:28:04 -0800 (PST) Received: from kolozsvar.ro ([218.71.250.27]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id jARGRtO0026510; Sun, 27 Nov 2005 08:27:56 -0800 Message-ID: Date: Sat, 26 Nov 2005 21:22:33 +0900 From: "amberly flores" User-Agent: Netscape6/6.1b1 MIME-Version: 1.0 To: "Lazaro Little" Subject: Get rid of everything you are indebted for with out sending an other cent Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-archive-position: 6619 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: eisenmann@kolozsvar.ro Precedence: bulk X-list: linux-xfs Content-Length: 1009 Lines: 22 Eliminate all you owe without mailing another dollar. Stop the harrasing calls. Bring a stop to the sending of payments! Believe it or not almost all lending orgizations are operating illegally. Unbelievable but true! Visit us for detailed information about our structure at N O expense or responsibility. You have naught to loose and lots to achieve. http://au.geocities.com/kelleebarabas/?v=AE5.Eradicate all that you are indebted for with out mailing an other dollar Detailed info or to cease getting or to view postal address Increase leads and business presence quickly through experienced , large quantity online mail advertising Use the most experienced judicialunion@gawab.com Finding it impossible to converse with the chief, Rob took refuge in the sign language. He turned his pockets wrong side out, showed the red welts left upon his wrists by the tight cord, and then shook his fists angrily in the direction of the town In return the Tatar nodded gravely and issued an order to his men From owner-linux-xfs@oss.sgi.com Sun Nov 27 08:25:50 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 27 Nov 2005 08:25:57 -0800 (PST) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id jARGPkO0026352 for ; Sun, 27 Nov 2005 08:25:49 -0800 Received: (qmail invoked by alias); 27 Nov 2005 16:22:18 -0000 Received: from G1953.g.pppool.de (EHLO [192.168.10.11]) [80.185.25.83] by mail.gmx.net (mp035) with SMTP; 27 Nov 2005 17:22:18 +0100 X-Authenticated: #2986359 Message-ID: <4389DD36.2030407@gmx.net> Date: Sun, 27 Nov 2005 17:22:14 +0100 From: evilninja User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: kempston CC: linux-xfs@oss.sgi.com Subject: Re: References: <001801c5f308$55fe1510$010aa8c0@shaolin> In-Reply-To: <001801c5f308$55fe1510$010aa8c0@shaolin> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-archive-position: 6618 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: evilninja@gmx.net Precedence: bulk X-list: linux-xfs Content-Length: 692 Lines: 15 kempston schrieb: > Today i found strange errors on my xfs drive: some files were locatable only in ls output, but inaccessable from any other command (giving file not found). > I did xfs_check and xfs_repair and as result, now i have no files on my drive at all (except empty lost+found folder) > Is there anything i can do to get my files back ? please give more details about kernel, arch, kernel-errors and some output from xfs_check if possible. do you have any idea what could've caused the errors? disk problems? power-failure? did you check your memory.... and a well chosen subject line in emails does not hurt either ;-) -- BOFH excuse #448: vi needs to be upgraded to vii From owner-linux-xfs@oss.sgi.com Sun Nov 27 16:28:44 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 27 Nov 2005 16:28:52 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id jAS0SgO0032317 for ; Sun, 27 Nov 2005 16:28:43 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA10199; Mon, 28 Nov 2005 11:25:10 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id jAS0PHkt7028752; Mon, 28 Nov 2005 11:25:19 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id jAS0Nsvi001263; Mon, 28 Nov 2005 11:23:55 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id jAS0No7n001261; Mon, 28 Nov 2005 11:23:50 +1100 Date: Mon, 28 Nov 2005 11:23:50 +1100 From: Nathan Scott To: Lawrence Walton , John Hawkes , Luca Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: unable to use dpkg 2.6.15-rc2 Message-ID: <20051128002350.GC841@frodo> References: <20051121100820.D6790390@wobbly.melbourne.sgi.com> <20051122172027.GA11219@dreamland.darkstar.lan> <20051122214443.GA781@frodo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051122214443.GA781@frodo> User-Agent: Mutt/1.5.3i X-archive-position: 6621 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1132 Lines: 32 On Wed, Nov 23, 2005 at 08:44:43AM +1100, Nathan Scott wrote: > On Tue, Nov 22, 2005 at 06:20:27PM +0100, Luca wrote: > > (please CC me, I'm not subscribed) > > > > Nathan Scott ha scritto: > > >> It's reproducible in 2.6.15-rc1, 2.6.15-rc1-mm1, 2.6.15-rc1-mm2 and > > >> 2.6.15-rc2. > > >> > > >> It does not occur in 2.6.14. > > >> > > >> Most easily triggered by "make clean" in the Linux source, for those of > > >> you without access to dpkg. But both clean and dpkg will trigger it. > > > > > > So far I've not been able to reproduce this; I'm using "make clean" > > > and it works just fine for me (I'm using the current git tree). > > > > Confirmed here with 2.6.15-rc1 an IDE disk. Kernel is UP with > > CONFIG_PREEMPT and 8KB stack. The following debug options are enabled: > > > > Keith Owens has managed to reproduce this locally, and has been > working on tracking it back to a single change - so, we'll start > trying to figure out whats gone wrong here shortly, and will get > a fix merged as soon as we can. FYI - this problem is now fixed in Linus' current git tree. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Nov 27 16:27:11 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 27 Nov 2005 16:27:14 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id jAS0R9O0032131 for ; Sun, 27 Nov 2005 16:27:10 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA10172; Mon, 28 Nov 2005 11:23:36 +1100 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id jAS0Nlkt7018537; Mon, 28 Nov 2005 11:23:47 +1100 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id jAS0NjoS7022700; Mon, 28 Nov 2005 11:23:45 +1100 (EST) Date: Mon, 28 Nov 2005 11:23:45 +1100 From: Nathan Scott To: Wu Fengguang Cc: linux-xfs@oss.sgi.com Subject: Re: processes stuck in D state Message-ID: <20051128112345.A7027041@wobbly.melbourne.sgi.com> References: <20051128003625.GA3645@mail.ustc.edu.cn> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20051128003625.GA3645@mail.ustc.edu.cn>; from wfg@mail.ustc.edu.cn on Mon, Nov 28, 2005 at 08:36:25AM +0800 X-archive-position: 6620 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 489 Lines: 16 On Mon, Nov 28, 2005 at 08:36:25AM +0800, Wu Fengguang wrote: > Hello, > > In the kernel 2.6.15-rc2-ck2 with adaptive readahead patch, some processes are > stuck in D state. Since the last functions of the two D process happened to be > the same set of XFS functions, I resend the bug report here. The original report > can be found in the -ck kernel mailing list: > http://bhhdoa.org.au/pipermail/ck/2005-November/004839.html This is now fixed in Linus' git tree. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Nov 27 16:33:14 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 27 Nov 2005 16:33:17 -0800 (PST) Received: from mx1.ustc.edu.cn (ns.ustc.edu.cn [202.38.64.1]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jAS0XDO0000460 for ; Sun, 27 Nov 2005 16:33:14 -0800 Received: from localhost.localdomain ([210.45.70.153]) by mx1.ustc.edu.cn (8.11.6/8.11.6) with ESMTP id jAS0QHD21938; Mon, 28 Nov 2005 08:26:17 +0800 Received: from wfg by localhost.localdomain with local (Exim 4.50) id 1EgX9r-00013T-Lx; Mon, 28 Nov 2005 08:46:15 +0800 Date: Mon, 28 Nov 2005 08:46:15 +0800 From: Wu Fengguang To: Nathan Scott Cc: linux-xfs@oss.sgi.com Subject: Re: processes stuck in D state Message-ID: <20051128004615.GA4022@mail.ustc.edu.cn> References: <20051128003625.GA3645@mail.ustc.edu.cn> <20051128112345.A7027041@wobbly.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051128112345.A7027041@wobbly.melbourne.sgi.com> User-Agent: Mutt/1.5.11 X-archive-position: 6622 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: wfg@mail.ustc.edu.cn Precedence: bulk X-list: linux-xfs Content-Length: 562 Lines: 15 On Mon, Nov 28, 2005 at 11:23:45AM +1100, Nathan Scott wrote: > On Mon, Nov 28, 2005 at 08:36:25AM +0800, Wu Fengguang wrote: > > Hello, > > > > In the kernel 2.6.15-rc2-ck2 with adaptive readahead patch, some processes are > > stuck in D state. Since the last functions of the two D process happened to be > > the same set of XFS functions, I resend the bug report here. The original report > > can be found in the -ck kernel mailing list: > > http://bhhdoa.org.au/pipermail/ck/2005-November/004839.html > > This is now fixed in Linus' git tree. Thanks! Wu From owner-linux-xfs@oss.sgi.com Sun Nov 27 19:06:10 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 27 Nov 2005 19:06:13 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id jAS369O0017392 for ; Sun, 27 Nov 2005 19:06:10 -0800 Received: (qmail invoked by alias); 28 Nov 2005 03:02:41 -0000 Received: from G1953.g.pppool.de (EHLO [192.168.10.11]) [80.185.25.83] by mail.gmx.net (mp027) with SMTP; 28 Nov 2005 04:02:41 +0100 X-Authenticated: #2986359 Message-ID: <438A734D.3070009@gmx.net> Date: Mon, 28 Nov 2005 04:02:37 +0100 From: evilninja User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com CC: Nathan Scott Subject: Re: unable to use dpkg 2.6.15-rc2 References: <20051121100820.D6790390@wobbly.melbourne.sgi.com> <20051122172027.GA11219@dreamland.darkstar.lan> <20051122214443.GA781@frodo> <20051128002350.GC841@frodo> In-Reply-To: <20051128002350.GC841@frodo> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-archive-position: 6623 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: evilninja@gmx.net Precedence: bulk X-list: linux-xfs Content-Length: 192 Lines: 9 Nathan Scott schrieb: > FYI - this problem is now fixed in Linus' current git tree. thanks! -- BOFH excuse #222: I'm not sure. Try calling the Internet's head office -- it's in the book. From owner-linux-xfs@oss.sgi.com Mon Nov 28 07:10:15 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 28 Nov 2005 07:10:22 -0800 (PST) Received: from mail.matrix.odessa.ua (mail.matrix.farlep.net [217.146.241.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jASFADO0020468 for ; Mon, 28 Nov 2005 07:10:14 -0800 Received: from shaolin (kempston.ppp.matrix.private [10.64.20.138]) by mail.matrix.odessa.ua with SMTP id 1EgkaU-000104-KK; Mon, 28 Nov 2005 17:06:38 +0200 Message-ID: <030201c5f42d$59279880$010aa8c0@shaolin> From: "kempston" To: Cc: "evilninja" References: <001801c5f308$55fe1510$010aa8c0@shaolin> <4389DD36.2030407@gmx.net> Subject: Re: Date: Mon, 28 Nov 2005 17:06:45 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-archive-position: 6624 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kempston@mail.ru Precedence: bulk X-list: linux-xfs Content-Length: 5439 Lines: 215 System is Debian Sarge. Kernel is 2.4.27-2-386 I'm quite sure it's not hardware fault. Some people told me it was not a good idea to use 2.4 with xfs. They are probably right, but now question is how to get my files back. xfs_check says nothing xfs_check -v produces 3045M output of this kind ------------------------ setting block 0/0 to sb setting block 0/1 to agf setting block 0/2 to agi setting block 0/3 to agfl setting block 0/5 to btbno setting block 0/7 to free1 setting block 0/8 to free1 setting block 0/9 to free1 setting block 0/10 to free1 setting block 0/11 to free1 setting block 0/16 to free1 setting block 0/17 to free1 setting block 0/18 to free1 setting block 0/19 to free1 setting block 0/20 to free1 ... ------------------------ xfs_repair says ------------------------ Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... XFS: totally zeroed 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 - agno = 16 - agno = 17 - agno = 18 - agno = 19 - agno = 20 - agno = 21 - agno = 22 - agno = 23 - agno = 24 - agno = 25 - agno = 26 - agno = 27 - agno = 28 - agno = 29 - agno = 30 - agno = 31 - agno = 32 - agno = 33 - agno = 34 - agno = 35 - agno = 36 - agno = 37 - agno = 38 - agno = 39 - agno = 40 - agno = 41 - agno = 42 - agno = 43 - agno = 44 - agno = 45 - agno = 46 - agno = 47 - agno = 48 - agno = 49 - agno = 50 - agno = 51 - agno = 52 - agno = 53 - agno = 54 - agno = 55 - agno = 56 - agno = 57 - agno = 58 - agno = 59 - agno = 60 - agno = 61 - agno = 62 - agno = 63 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - clear lost+found (if it exists) ... - clearing existing "lost+found" inode - deleting existing "lost+found" entry - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 - agno = 16 - agno = 17 - agno = 18 - agno = 19 - agno = 20 - agno = 21 - agno = 22 - agno = 23 - agno = 24 - agno = 25 - agno = 26 - agno = 27 - agno = 28 - agno = 29 - agno = 30 - agno = 31 - agno = 32 - agno = 33 - agno = 34 - agno = 35 - agno = 36 - agno = 37 - agno = 38 - agno = 39 - agno = 40 - agno = 41 - agno = 42 - agno = 43 - agno = 44 - agno = 45 - agno = 46 - agno = 47 - agno = 48 - agno = 49 - agno = 50 - agno = 51 - agno = 52 - agno = 53 - agno = 54 - agno = 55 - agno = 56 - agno = 57 - agno = 58 - agno = 59 - agno = 60 - agno = 61 - agno = 62 - agno = 63 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 / ... - traversal finished ... - traversing all unattached subtrees ... - traversals finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... done ------------------------ ----- Original Message ----- From: "evilninja" To: "kempston" Cc: Sent: Sunday, November 27, 2005 6:22 PM Subject: Re: > kempston schrieb: >> Today i found strange errors on my xfs drive: some files were locatable >> only in ls output, but inaccessable from any other command (giving file >> not found). >> I did xfs_check and xfs_repair and as result, now i have no files on my >> drive at all (except empty lost+found folder) >> Is there anything i can do to get my files back ? > > please give more details about kernel, arch, kernel-errors and some output > from xfs_check if possible. do you have any idea what could've caused the > errors? disk problems? power-failure? did you check your memory.... > > and a well chosen subject line in emails does not hurt either ;-) > -- > BOFH excuse #448: > > vi needs to be upgraded to vii > From owner-linux-xfs@oss.sgi.com Mon Nov 28 14:28:44 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 28 Nov 2005 14:28:48 -0800 (PST) Received: from mail.lst.de (verein.lst.de [213.95.11.210]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jASMSgO0007836 for ; Mon, 28 Nov 2005 14:28:44 -0800 Received: from verein.lst.de (localhost [127.0.0.1]) by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id jASMP16t007287 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 28 Nov 2005 23:25:02 +0100 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id jASMP1X9007285; Mon, 28 Nov 2005 23:25:01 +0100 Date: Mon, 28 Nov 2005 23:25:01 +0100 From: Christoph Hellwig To: akpm@osdl.org Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: [PATCH] remove broken direct I/O size ioctl Message-ID: <20051128222501.GA7238@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-archive-position: 6625 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: linux-xfs Content-Length: 669 Lines: 20 This ioctl tries to second guess direct I/O parameters which aren't a filesystem drivers business and shouldn't be exposed as an ioctl to start with. Signed-off-by: Christoph Hellwig Index: linux-2.6/fs/xfs/linux-2.6/xfs_ioctl32.c =================================================================== --- linux-2.6.orig/fs/xfs/linux-2.6/xfs_ioctl32.c 2005-11-18 10:29:41.000000000 +0100 +++ linux-2.6/fs/xfs/linux-2.6/xfs_ioctl32.c 2005-11-28 23:21:39.000000000 +0100 @@ -115,7 +115,6 @@ vnode_t *vp = LINVFS_GET_VP(inode); switch (cmd) { - case XFS_IOC_DIOINFO: case XFS_IOC_FSGEOMETRY_V1: case XFS_IOC_FSGEOMETRY: case XFS_IOC_GETVERSION: From owner-linux-xfs@oss.sgi.com Mon Nov 28 14:47:28 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 28 Nov 2005 14:47:34 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id jASMlPO0009283 for ; Mon, 28 Nov 2005 14:47:27 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA06113; Tue, 29 Nov 2005 09:43:52 +1100 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id jASMi1kt7050794; Tue, 29 Nov 2005 09:44:02 +1100 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id jASMhvWT7050668; Tue, 29 Nov 2005 09:43:57 +1100 (EST) Date: Tue, 29 Nov 2005 09:43:57 +1100 From: Nathan Scott To: Christoph Hellwig Cc: akpm@osdl.org, linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: [PATCH] remove broken direct I/O size ioctl Message-ID: <20051129094357.G7047179@wobbly.melbourne.sgi.com> References: <20051128222501.GA7238@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20051128222501.GA7238@lst.de>; from hch@lst.de on Mon, Nov 28, 2005 at 11:25:01PM +0100 X-archive-position: 6626 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 606 Lines: 17 On Mon, Nov 28, 2005 at 11:25:01PM +0100, Christoph Hellwig wrote: > This ioctl tries to second guess direct I/O parameters which aren't > a filesystem drivers business and shouldn't be exposed as an ioctl > to start with. Unfortunately there are some applications that will now start to see errors from this ioctl if we go this route - whereas before they would've been "functional", now they will break. So, I think we need a different solution here. Yes, I agree its a stupid call to have on Linux, but here we are, and apps ported straight from IRIX have been made to use this. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Nov 28 16:39:42 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 28 Nov 2005 16:39:44 -0800 (PST) Received: from mx1.suse.de (mail.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jAT0dfO0021967 for ; Mon, 28 Nov 2005 16:39:42 -0800 Received: from Relay1.suse.de (mail2.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.suse.de (Postfix) with ESMTP id 2B2ABEA9E for ; Tue, 29 Nov 2005 01:36:12 +0100 (CET) Date: Tue, 29 Nov 2005 01:36:11 +0100 From: Andi Kleen To: linux-xfs@oss.sgi.com Subject: XFS unhappy with large holey loopback and syncs Message-ID: <20051129003611.GF7209@brahms.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-archive-position: 6627 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: linux-xfs Content-Length: 2750 Lines: 65 I just found an new exciting way to break XFS. Or rather the version that's in 2.6.13. But might be a interesting try anyways. You likely need a 64bit system for this. I created a large holey file on XFS with # (the funny number is about the maximum that ext2 supports) dd if=/dev/zero of=LARGE bs=1 count=4096 seek=$[8*1024*1024*1024*1024-2*4096] losetup /dev/loop0 LARGE mkfs.ext2 /dev/loop0 now wait until it has written a few thousands of its inode tables and then press ctrl-c. mkfs.ext2 will close the loop device which causes a sync. And then it will hang for a very long time until loop starts spewing out IO errors and then it deadlocks completely. The mkfs process is busy waiting for its sync, loop0 does: xfssyncd S 0000000000000a7c 0 8846 15 8861 8845 (L-TLB) ffff81013e179e38 0000000000000046 0000000000000000 ffff81013fda14f8 00000000000df8f8 ffffffff80558800 ffffffff80558800 ffffffff80170fea 0000000000000100 00000000000000cb Call Trace:{pagevec_lookup_tag+26} {lock_tim er_base+41} {schedule_timeout+150} {process_timeo ut+0} {:xfs:xfssyncd+105} {:xfs:xfssyncd+0} {keventd_create_kthread+0} {kthread+2 43} {schedule_tail+64} {child_rip+8} {keventd_create_kthread+0} {kthread+0 } {child_rip+0} loop0 D ffff8100057a00f0 0 8856 1 7860 (L-TLB) ffff81013e297a38 0000000000000046 0000000000000000 ffffffff8842a880 ffff81013e297b98 ffffffff80558800 ffffffff80558800 ffff81013e297b78 0000000000000001 0000000000000437 Call Trace:{:xfs:xfs_bmap_search_extents+128} {lock_timer_base+41} {__mod_timer+216 } {schedule_timeout+150} {process_timeo ut+0} {:xfs:xfs_flush_device+90} {:xfs:xfs_ iomap_write_delay+1150} {smp_send_reschedule+63} {__down_writ e+51} {:xfs:xfs_iomap+700} {:xfs:__linvfs_g et_block+134} {child_rip+8} {loop_thread+0} {child_rip+0} and it's completely stuck. The machine I tested this one had quite a lot of memory (8GB), so it might be related to that. I don't think it was an OOM issue though, other terminals were still perfectly responsive. Anyways, filling that many holes and then syncing seems to send XFS into a frenzy. -Andi From owner-linux-xfs@oss.sgi.com Mon Nov 28 19:33:32 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 28 Nov 2005 19:33:38 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id jAT3XUO0003364 for ; Mon, 28 Nov 2005 19:33:31 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA12706; Tue, 29 Nov 2005 14:29:48 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id jAT3Tdnp18266627; Tue, 29 Nov 2005 14:29:40 +1100 (EST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id jAT3Tb3F18633597; Tue, 29 Nov 2005 14:29:37 +1100 (EST) Date: Tue, 29 Nov 2005 14:29:37 +1100 From: David Chinner To: Andi Kleen Cc: linux-xfs@oss.sgi.com Subject: Re: XFS unhappy with large holey loopback and syncs Message-ID: <20051129032937.GZ501696@melbourne.sgi.com> References: <20051129003611.GF7209@brahms.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051129003611.GF7209@brahms.suse.de> User-Agent: Mutt/1.4.2.1i X-archive-position: 6628 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2714 Lines: 67 On Tue, Nov 29, 2005 at 01:36:11AM +0100, Andi Kleen wrote: > > I just found an new exciting way to break XFS. Or rather the > version that's in 2.6.13. But might be a interesting try anyways. So I just ran this on a handy altix I had lying about between other testing ;) It's currently not running 2.6.13, but I'm going to run this again against 2.6.14 just to make sure it's not a regression. I suspect that the problem is that you're generating a highly fragmented file which requires high-order memory allocations to hold the extent list. > You likely need a 64bit system for this. Check. > I created a large holey file on XFS with > > # (the funny number is about the maximum that ext2 supports) > dd if=/dev/zero of=LARGE bs=1 count=4096 seek=$[8*1024*1024*1024*1024-2*4096] > losetup /dev/loop0 LARGE > mkfs.ext2 /dev/loop0 > > now wait until it has written a few thousands of its inode tables > and then press ctrl-c. mkfs.ext2 will close the loop device which > causes a sync. And then it will hang for a very long time > until loop starts spewing out IO errors and then it deadlocks completely. > The mkfs process is busy waiting for its sync, loop0 does: First I tried aborting the mkfs but I didn't see any hangs, so I let mkfs.ext2 run to completion - it dirtied all of memory (~23GiB) and then it spent most of the time writing to disk at 300-400MB/s: budgie:~ # vmstat 5 procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu---- r b swpd free buff cache si so bi bo in cs us sy id wa 7 0 416096 27760 17509664 5153888 45 6 66 397116 5725 11054 0 45 46 9 3 0 416096 28096 17299648 5363776 51 10 98 393118 5638 6693 1 46 43 10 10 0 416096 27984 16831344 5831968 26 0 38 440788 5627 11416 0 50 42 7 2 0 416096 21712 17438816 5241232 22 19 246 362036 5737 8968 1 38 51 10 7 0 416096 27312 18031552 4631792 67 0 193 347848 5574 7725 0 37 51 11 And kept more than a million pages under writeback for the entire runtime. As the number of inode tables had been written out increased, the write out rate slows a bit. When mkfs completes, a sync is done and everything is good. But I can now guess why a smaller machine might hang on this test - you're creating a file with a massive number of extents: budgie:/usr/local/aspen/loadgen # xfs_bmap -v /mnt/dgc/stripe/LARGE |wc -l 217708 budgie:/usr/local/aspen/loadgen # Which is what makes me think you're having problems with high order memory allocations at substantially lower numbers of extents. You're testing on a machine with 4k pages, right? Cheers, Dave. -- Dave Chinner R&D Software Enginner SGI Australian Software Group From owner-linux-xfs@oss.sgi.com Tue Nov 29 01:16:32 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Nov 2005 01:16:35 -0800 (PST) Received: from mx1.suse.de (mx1.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jAT9GVO0006584 for ; Tue, 29 Nov 2005 01:16:32 -0800 Received: from Relay2.suse.de (mail2.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.suse.de (Postfix) with ESMTP id 8D842E8A4; Tue, 29 Nov 2005 10:13:02 +0100 (CET) Date: Tue, 29 Nov 2005 10:13:02 +0100 From: Andi Kleen To: David Chinner Cc: Andi Kleen , linux-xfs@oss.sgi.com Subject: Re: XFS unhappy with large holey loopback and syncs Message-ID: <20051129091302.GB19515@wotan.suse.de> References: <20051129003611.GF7209@brahms.suse.de> <20051129032937.GZ501696@melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051129032937.GZ501696@melbourne.sgi.com> X-archive-position: 6629 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: linux-xfs Content-Length: 1222 Lines: 31 On Tue, Nov 29, 2005 at 02:29:37PM +1100, David Chinner wrote: > On Tue, Nov 29, 2005 at 01:36:11AM +0100, Andi Kleen wrote: > > > > I just found an new exciting way to break XFS. Or rather the > > version that's in 2.6.13. But might be a interesting try anyways. > > So I just ran this on a handy altix I had lying about between other > testing ;) > > It's currently not running 2.6.13, but I'm going to run this again > against 2.6.14 just to make sure it's not a regression. I suspect that > the problem is that you're generating a highly fragmented file > which requires high-order memory allocations to hold the extent list. Hmm - i didn't see any of the processes blocking in the memory allocator, but maybe I just didn't look closely enough. > budgie:/usr/local/aspen/loadgen # xfs_bmap -v /mnt/dgc/stripe/LARGE |wc -l > 217708 > budgie:/usr/local/aspen/loadgen # > > Which is what makes me think you're having problems with high order > memory allocations at substantially lower numbers of extents. You're > testing on a machine with 4k pages, right? Yep - on x86-64. But the machine had 8GB of RAM, so if even that runs out of memory something is wrong imho. How large allocations would it need? -Andi From owner-linux-xfs@oss.sgi.com Tue Nov 29 06:59:32 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Nov 2005 06:59:37 -0800 (PST) Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jATExVO0004094 for ; Tue, 29 Nov 2005 06:59:31 -0800 Received: from Relay2.suse.de (mail2.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx2.suse.de (Postfix) with ESMTP id E39DD1D7A1; Tue, 29 Nov 2005 15:56:01 +0100 (CET) Date: Tue, 29 Nov 2005 15:56:01 +0100 From: Andi Kleen To: Steve Lord Cc: Andi Kleen , David Chinner , linux-xfs@oss.sgi.com Subject: Re: XFS unhappy with large holey loopback and syncs Message-ID: <20051129145601.GF19515@wotan.suse.de> References: <20051129003611.GF7209@brahms.suse.de> <20051129032937.GZ501696@melbourne.sgi.com> <20051129091302.GB19515@wotan.suse.de> <438C6B5D.1070604@xfs.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <438C6B5D.1070604@xfs.org> X-archive-position: 6631 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: linux-xfs Content-Length: 441 Lines: 18 On Tue, Nov 29, 2005 at 08:53:17AM -0600, Steve Lord wrote: > Andi Kleen wrote: > > > > > >Yep - on x86-64. But the machine had 8GB of RAM, so if even that > >runs out of memory something is wrong imho. How large allocations > >would it need? > > > >-Andi > > > > 28 bytes per extent so in this case rather a lot. This could be Assuming it created 300k extents that would be only ~8MB. That should be no problem for a 8GB machine. -Andi From owner-linux-xfs@oss.sgi.com Tue Nov 29 06:56:50 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Nov 2005 06:56:54 -0800 (PST) Received: from relay04.roc.ny.frontiernet.net (relay04.roc.ny.frontiernet.net [66.133.182.167]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jATEuoO0003770 for ; Tue, 29 Nov 2005 06:56:50 -0800 Received: from [192.168.1.101] (67-137-96-87.dsl2.brv.mn.frontiernet.net [67.137.96.87]) by relay04.roc.ny.frontiernet.net (Postfix) with ESMTP id 68AE93581D7; Tue, 29 Nov 2005 14:53:17 +0000 (UTC) Message-ID: <438C6B5D.1070604@xfs.org> Date: Tue, 29 Nov 2005 08:53:17 -0600 From: Steve Lord User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andi Kleen CC: David Chinner , linux-xfs@oss.sgi.com Subject: Re: XFS unhappy with large holey loopback and syncs References: <20051129003611.GF7209@brahms.suse.de> <20051129032937.GZ501696@melbourne.sgi.com> <20051129091302.GB19515@wotan.suse.de> In-Reply-To: <20051129091302.GB19515@wotan.suse.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6630 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 619 Lines: 23 Andi Kleen wrote: > > > Yep - on x86-64. But the machine had 8GB of RAM, so if even that > runs out of memory something is wrong imho. How large allocations > would it need? > > -Andi > 28 bytes per extent so in this case rather a lot. This could be compressed some at the cost of bit manipulation when looking up extents. I used to rack my brain about how to make xfs work with a partial in memory extent map. At least reorganizing the data structure to avoid the large memory requirement would be good. You probably didn't see it in the allocator because it was delaying between retrying the allocate. Steve From owner-linux-xfs@oss.sgi.com Tue Nov 29 07:19:35 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Nov 2005 07:19:42 -0800 (PST) Received: from relay04.roc.ny.frontiernet.net (relay04.roc.ny.frontiernet.net [66.133.182.167]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jATFJZO0005890 for ; Tue, 29 Nov 2005 07:19:35 -0800 Received: from [192.168.1.101] (67-137-96-87.dsl2.brv.mn.frontiernet.net [67.137.96.87]) by relay04.roc.ny.frontiernet.net (Postfix) with ESMTP id E213C35832B; Tue, 29 Nov 2005 15:16:04 +0000 (UTC) Message-ID: <438C70B3.5080709@xfs.org> Date: Tue, 29 Nov 2005 09:16:03 -0600 From: Steve Lord User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andi Kleen CC: David Chinner , linux-xfs@oss.sgi.com Subject: Re: XFS unhappy with large holey loopback and syncs References: <20051129003611.GF7209@brahms.suse.de> <20051129032937.GZ501696@melbourne.sgi.com> <20051129091302.GB19515@wotan.suse.de> <438C6B5D.1070604@xfs.org> <20051129145601.GF19515@wotan.suse.de> In-Reply-To: <20051129145601.GF19515@wotan.suse.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6632 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 669 Lines: 28 Andi Kleen wrote: > On Tue, Nov 29, 2005 at 08:53:17AM -0600, Steve Lord wrote: > >>Andi Kleen wrote: >> >>> >>>Yep - on x86-64. But the machine had 8GB of RAM, so if even that >>>runs out of memory something is wrong imho. How large allocations >>>would it need? >>> >>>-Andi >>> >> >>28 bytes per extent so in this case rather a lot. This could be > > > Assuming it created 300k extents that would be only ~8MB. That should > be no problem for a 8GB machine. > > -Andi > Well, since it wants it as a single chunk of kernel memory..... that gets hard to do in linux. Actually it probably has one large chunk and is doing a realloc to get a larger chunk. Steve From owner-linux-xfs@oss.sgi.com Tue Nov 29 07:25:19 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Nov 2005 07:25:22 -0800 (PST) Received: from mx1.suse.de (cantor.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jATFPIO0006776 for ; Tue, 29 Nov 2005 07:25:19 -0800 Received: from Relay2.suse.de (mail2.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.suse.de (Postfix) with ESMTP id 0C4AEEDE2; Tue, 29 Nov 2005 16:21:49 +0100 (CET) Date: Tue, 29 Nov 2005 16:21:48 +0100 From: Andi Kleen To: Steve Lord Cc: Andi Kleen , David Chinner , linux-xfs@oss.sgi.com Subject: Re: XFS unhappy with large holey loopback and syncs Message-ID: <20051129152148.GH19515@wotan.suse.de> References: <20051129003611.GF7209@brahms.suse.de> <20051129032937.GZ501696@melbourne.sgi.com> <20051129091302.GB19515@wotan.suse.de> <438C6B5D.1070604@xfs.org> <20051129145601.GF19515@wotan.suse.de> <438C70B3.5080709@xfs.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <438C70B3.5080709@xfs.org> X-archive-position: 6633 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: linux-xfs Content-Length: 431 Lines: 11 > Well, since it wants it as a single chunk of kernel memory..... that > gets hard to do in linux. Actually it probably has one large chunk and > is doing a realloc to get a larger chunk. For that it should use vmalloc - also no problem because it is backed in distributed order 0 4k pages. On 32bit the vmalloc space is a bit limited, but 8MB is still only a small part of it On x86-64 it's VmallocTotal: 34359738367 kB -Andi From owner-linux-xfs@oss.sgi.com Tue Nov 29 07:35:02 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Nov 2005 07:35:09 -0800 (PST) Received: from web34112.mail.mud.yahoo.com (web34112.mail.mud.yahoo.com [66.163.178.110]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id jATFZ2O0007654 for ; Tue, 29 Nov 2005 07:35:02 -0800 Received: (qmail 42579 invoked by uid 60001); 29 Nov 2005 15:31:33 -0000 Message-ID: <20051129153133.42577.qmail@web34112.mail.mud.yahoo.com> Received: from [66.192.136.59] by web34112.mail.mud.yahoo.com via HTTP; Tue, 29 Nov 2005 07:31:33 PST X-RocketYMMF: thebs413 Date: Tue, 29 Nov 2005 07:31:33 -0800 (PST) From: "Bryan J. Smith" Reply-To: b.j.smith@ieee.org Subject: Re: XFS unhappy with large holey loopback and syncs -- [OT] vmalloc 45-bit/32PiB address limit To: Steve Lord Cc: Andi Kleen , David Chinner , linux-xfs@oss.sgi.com In-Reply-To: <20051129152148.GH19515@wotan.suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-archive-position: 6634 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: b.j.smith@ieee.org Precedence: bulk X-list: linux-xfs Content-Length: 704 Lines: 23 Andi Kleen wrote: > For that it should use vmalloc - also no problem because it > is backed in distributed order 0 4k pages. On 32bit the vmalloc > space is a bit limited, but 8MB is still only a small part of > it On x86-64 it's VmallocTotal: 34359738367 kB If I'm reading that correctly, that's 45-bit/32PiB addressing. Where does that limit come from? Is that the limit of Linux's new, 4-level page table logic in x86-64 (the old 3-level page table being capable of 39-bit/512GiB), or is it something else? Just curious. -- Bryan J. Smith | Sent from Yahoo Mail mailto:b.j.smith@ieee.org | (please excuse any http://thebs413.blogspot.com/ | missing headers) From owner-linux-xfs@oss.sgi.com Tue Nov 29 07:45:10 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Nov 2005 07:45:14 -0800 (PST) Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jATFj8O0008654 for ; Tue, 29 Nov 2005 07:45:09 -0800 Received: from Relay2.suse.de (mail2.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx2.suse.de (Postfix) with ESMTP id CAB671C005; Tue, 29 Nov 2005 16:41:39 +0100 (CET) Date: Tue, 29 Nov 2005 16:41:39 +0100 From: Andi Kleen To: "Bryan J. Smith" Cc: Steve Lord , Andi Kleen , David Chinner , linux-xfs@oss.sgi.com Subject: Re: XFS unhappy with large holey loopback and syncs -- [OT] vmalloc 45-bit/32PiB address limit Message-ID: <20051129154139.GI19515@wotan.suse.de> References: <20051129152148.GH19515@wotan.suse.de> <20051129153133.42577.qmail@web34112.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051129153133.42577.qmail@web34112.mail.mud.yahoo.com> X-archive-position: 6635 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: linux-xfs Content-Length: 705 Lines: 19 On Tue, Nov 29, 2005 at 07:31:33AM -0800, Bryan J. Smith wrote: > Andi Kleen wrote: > > For that it should use vmalloc - also no problem because it > > is backed in distributed order 0 4k pages. On 32bit the > vmalloc > > space is a bit limited, but 8MB is still only a small part > of > > it On x86-64 it's VmallocTotal: 34359738367 kB > > If I'm reading that correctly, that's 45-bit/32PiB > addressing. Where does that limit come from? x86-64 supports 48bits of address space. Half of it is for user space, the other half for the kernel. Of the kernel half half is for physical memory, and half of the other half is for kernel text and holes. This leaves 45bits for vmalloc. -Andi From owner-linux-xfs@oss.sgi.com Tue Nov 29 07:50:16 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Nov 2005 07:50:19 -0800 (PST) Received: from web34105.mail.mud.yahoo.com (web34105.mail.mud.yahoo.com [66.163.178.103]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id jATFoFO0009276 for ; Tue, 29 Nov 2005 07:50:15 -0800 Received: (qmail 393 invoked by uid 60001); 29 Nov 2005 15:46:46 -0000 Message-ID: <20051129154646.391.qmail@web34105.mail.mud.yahoo.com> Received: from [66.192.136.59] by web34105.mail.mud.yahoo.com via HTTP; Tue, 29 Nov 2005 07:46:46 PST X-RocketYMMF: thebs413 Date: Tue, 29 Nov 2005 07:46:46 -0800 (PST) From: "Bryan J. Smith" Reply-To: b.j.smith@ieee.org Subject: Re: XFS unhappy with large holey loopback and syncs -- [OT] vmalloc 45-bit/32PiB address limit To: Andi Kleen Cc: Steve Lord , David Chinner , linux-xfs@oss.sgi.com In-Reply-To: <20051129154139.GI19515@wotan.suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-archive-position: 6636 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: b.j.smith@ieee.org Precedence: bulk X-list: linux-xfs Content-Length: 707 Lines: 22 Andi Kleen wrote: > x86-64 supports 48bits of address space. Half of it is for > user space, the other half for the kernel. Of the kernel > half half is for physical memory, and half of the other > half is for kernel text and holes. This leaves 45bits for > vmalloc. Ahhh, that makes sense. I knew x86-64 "Long Mode" is 48-bit (linear segment+offset register/i486 TLB compatible, hence how it can run 32-bit applications), but never stopped to think about the mapping of kernel and user-space memory. Thanx for explaining it! -- Bryan J. Smith | Sent from Yahoo Mail mailto:b.j.smith@ieee.org | (please excuse any http://thebs413.blogspot.com/ | missing headers) From owner-linux-xfs@oss.sgi.com Tue Nov 29 08:24:22 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Nov 2005 08:24:28 -0800 (PST) Received: from mail-relay-3.tiscali.it (mail-relay-3.tiscali.it [213.205.33.43]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jATGOLO0016737 for ; Tue, 29 Nov 2005 08:24:21 -0800 Received: from dreamland.darkstar.lan (84.222.32.109) by mail-relay-3.tiscali.it (7.2.069.1) id 438439FE000D7E78; Tue, 29 Nov 2005 17:20:51 +0100 Received: by dreamland.darkstar.lan (Postfix, from userid 1000) id 950741B7B7; Tue, 29 Nov 2005 17:21:06 +0100 (CET) Date: Tue, 29 Nov 2005 17:21:06 +0100 From: Luca To: Nathan Scott Cc: John Hawkes , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: unable to use dpkg 2.6.15-rc2 Message-ID: <20051129162106.GA5002@dreamland.darkstar.lan> References: <20051121100820.D6790390@wobbly.melbourne.sgi.com> <20051122172027.GA11219@dreamland.darkstar.lan> <20051122214443.GA781@frodo> <20051128002350.GC841@frodo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051128002350.GC841@frodo> User-Agent: Mutt/1.5.10i X-archive-position: 6637 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kronos@kronoz.cjb.net Precedence: bulk X-list: linux-xfs Content-Length: 1472 Lines: 37 Il Mon, Nov 28, 2005 at 11:23:50AM +1100, Nathan Scott ha scritto: > On Wed, Nov 23, 2005 at 08:44:43AM +1100, Nathan Scott wrote: > > On Tue, Nov 22, 2005 at 06:20:27PM +0100, Luca wrote: > > > (please CC me, I'm not subscribed) > > > > > > Nathan Scott ha scritto: > > > >> It's reproducible in 2.6.15-rc1, 2.6.15-rc1-mm1, 2.6.15-rc1-mm2 and > > > >> 2.6.15-rc2. > > > >> > > > >> It does not occur in 2.6.14. > > > >> > > > >> Most easily triggered by "make clean" in the Linux source, for those of > > > >> you without access to dpkg. But both clean and dpkg will trigger it. > > > > > > > > So far I've not been able to reproduce this; I'm using "make clean" > > > > and it works just fine for me (I'm using the current git tree). > > > > > > Confirmed here with 2.6.15-rc1 an IDE disk. Kernel is UP with > > > CONFIG_PREEMPT and 8KB stack. The following debug options are enabled: > > > > > > > Keith Owens has managed to reproduce this locally, and has been > > working on tracking it back to a single change - so, we'll start > > trying to figure out whats gone wrong here shortly, and will get > > a fix merged as soon as we can. > > FYI - this problem is now fixed in Linus' current git tree. Great, I'll give it a try ASAP. BTW why using a macro instead of an inline function makes any difference? I don't understand... Luca -- Home: http://kronoz.cjb.net "Su cio` di cui non si puo` parlare e` bene tacere". Ludwig Wittgenstein From owner-linux-xfs@oss.sgi.com Tue Nov 29 09:28:29 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Nov 2005 09:28:33 -0800 (PST) Received: from cfa.harvard.edu (cfa.harvard.edu [131.142.10.1]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jATHSTO0021729 for ; Tue, 29 Nov 2005 09:28:29 -0800 Received: from titan (titan [131.142.24.40]) by cfa.harvard.edu (8.12.9-20030924/8.12.9/cfunix Mast-Sol 1.0) with ESMTP id jATHOwbh025670 for ; Tue, 29 Nov 2005 12:24:58 -0500 (EST) Date: Tue, 29 Nov 2005 12:24:58 -0500 (EST) From: Gaspar Bakos Reply-To: gbakos@cfa.harvard.edu To: linux-xfs@oss.sgi.com Subject: XFS internal error xfs_da_do_buf(2) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 6638 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: gbakos@cfa.harvard.edu Precedence: bulk X-list: linux-xfs Content-Length: 1506 Lines: 28 Dear all, I found scary system logs this morning on one of the computers I am running: Nov 29 04:09:42 mkhat8 kernel: 0x0: 82 9f 82 9f 82 a9 82 a2 82 a9 82 c2 82 fe 82 d8 Nov 29 04:09:42 mkhat8 kernel: Filesystem "ide0(3,65)": XFS internal error xfs_da_do_buf(2) at line 2280 of file xfs_da_btree.c. Caller 0xc0197d67 Nov 29 04:09:42 mkhat8 kernel: c31cfc90 c01978e9 c03198a4 00000001 df331800 c03197ab 000008e8 c0197d67 Nov 29 04:09:42 mkhat8 kernel: c0197d67 c31cfcf8 00000000 c01977e9 00000001 c31cfd20 c019ec8f 00000060 Nov 29 04:09:42 mkhat8 kernel: 00000018 00800000 00000000 00000001 00000000 df331800 c31cfd14 00000001 Nov 29 04:09:42 mkhat8 kernel: Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] This is an old system, RH9.0 with 2.4.22 kernel, running XFS from 2003-10-10. ( I was not able to update this system since the installation due to realtime-linux patches and various special kernel drivers we use for robotic control. In any case, it has been working fine for two years...) Question: what to do? Is this a sign of hdd failure, or memory problems, or some known bug with XFS? The filesystem is on a single disk. The entire disk is one big partition. Cheers gaspar From owner-linux-xfs@oss.sgi.com Tue Nov 29 10:23:18 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Nov 2005 10:23:22 -0800 (PST) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jATINHO0026975 for ; Tue, 29 Nov 2005 10:23:18 -0800 Received: from hastur.corp.sgi.com (hastur.corp.sgi.com [198.149.32.33]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id jATIJmxT024968 for ; Tue, 29 Nov 2005 12:19:48 -0600 Received: from naboo.americas.sgi.com (naboo.americas.sgi.com [128.162.233.73]) by hastur.corp.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id jATIJfeS219847866; Tue, 29 Nov 2005 10:19:41 -0800 (PST) Received: from naboo.americas.sgi.com (localhost [127.0.0.1]) by naboo.americas.sgi.com (8.13.3/8.13.3) with ESMTP id jATIJlel015444; Tue, 29 Nov 2005 12:19:47 -0600 Received: (from hch@localhost) by naboo.americas.sgi.com (8.13.3/8.13.3/Submit) id jATIJluQ015442; Tue, 29 Nov 2005 12:19:47 -0600 Date: Tue, 29 Nov 2005 12:19:47 -0600 From: Christoph Hellwig Message-Id: <200511291819.jATIJluQ015442@naboo.americas.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Subject: TAKE 946205 - make some xlog helpers real functions instead of macros X-archive-position: 6640 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@relay.sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 601 Lines: 17 The real functions give us proper type checking and dreases .text about 1k. Date: Tue Nov 29 10:19:21 PST 2005 Workarea: naboo.americas.sgi.com:/go/space/hch/xfs-2.6.x Inspected by: tes The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: xfs-linux:xfs-kern:202923a fs/xfs/xfs_log.c - 1.313 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_log.c.diff?r1=text&tr1=1.313&r2=text&tr2=1.312&f=h fs/xfs/xfs_log_priv.h - 1.112 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_log_priv.h.diff?r1=text&tr1=1.112&r2=text&tr2=1.111&f=h From owner-linux-xfs@oss.sgi.com Tue Nov 29 13:00:17 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Nov 2005 13:00:23 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id jATL0FO0011432 for ; Tue, 29 Nov 2005 13:00:16 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id HAA02611; Wed, 30 Nov 2005 07:56:44 +1100 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id jATKuskt7081115; Wed, 30 Nov 2005 07:56:54 +1100 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id jATKuonO7079723; Wed, 30 Nov 2005 07:56:50 +1100 (EST) Date: Wed, 30 Nov 2005 07:56:50 +1100 From: Nathan Scott To: Luca Cc: John Hawkes , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: unable to use dpkg 2.6.15-rc2 Message-ID: <20051130075650.A7058184@wobbly.melbourne.sgi.com> References: <20051121100820.D6790390@wobbly.melbourne.sgi.com> <20051122172027.GA11219@dreamland.darkstar.lan> <20051122214443.GA781@frodo> <20051128002350.GC841@frodo> <20051129162106.GA5002@dreamland.darkstar.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20051129162106.GA5002@dreamland.darkstar.lan>; from kronos@kronoz.cjb.net on Tue, Nov 29, 2005 at 05:21:06PM +0100 X-archive-position: 6641 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 388 Lines: 15 On Tue, Nov 29, 2005 at 05:21:06PM +0100, Luca wrote: > > Great, I'll give it a try ASAP. BTW why using a macro instead of an > inline function makes any difference? I don't understand... > The initial conversion from macro ->inline was subtely broken (macro changed the value of a parameter, not picked up in the conversion), so we reverted that change for now. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Nov 29 15:44:37 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Nov 2005 15:44:45 -0800 (PST) Received: from mx1.suse.de (ns1.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jATNiaO0023845 for ; Tue, 29 Nov 2005 15:44:37 -0800 Received: from Relay1.suse.de (mail2.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.suse.de (Postfix) with ESMTP id 5B64AEF67; Wed, 30 Nov 2005 00:41:07 +0100 (CET) Date: Wed, 30 Nov 2005 00:41:07 +0100 From: Andi Kleen To: David Chinner Cc: Andi Kleen , linux-xfs@oss.sgi.com Subject: Re: XFS unhappy with large holey loopback and syncs Message-ID: <20051129234107.GX19515@wotan.suse.de> References: <20051129003611.GF7209@brahms.suse.de> <20051129032937.GZ501696@melbourne.sgi.com> <20051129233804.GB19154461@melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051129233804.GB19154461@melbourne.sgi.com> X-archive-position: 6643 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: linux-xfs Content-Length: 435 Lines: 14 > FYI, this test passes without problems on 2.6.14 on the same altix. > Hmmm - I need to find an x86-64 box, I guess.... Thanks for testing. Build an altix kernel with 4k pages? I'm a bit sceptical the memory allocation theory is true though (see my other mails) Or perhaps it was an race and depends on specific timings :/ Anyways, if it cannot be reproduced it's fine for me to ignore. I just though I should report it. -Andi From owner-linux-xfs@oss.sgi.com Tue Nov 29 15:41:58 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Nov 2005 15:42:01 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id jATNfuO0023551 for ; Tue, 29 Nov 2005 15:41:57 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA06565; Wed, 30 Nov 2005 10:38:16 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id jATNc6np18619549; Wed, 30 Nov 2005 10:38:07 +1100 (EST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id jATNc47D19132293; Wed, 30 Nov 2005 10:38:04 +1100 (EST) Date: Wed, 30 Nov 2005 10:38:04 +1100 From: David Chinner To: Andi Kleen Cc: linux-xfs@oss.sgi.com Subject: Re: XFS unhappy with large holey loopback and syncs Message-ID: <20051129233804.GB19154461@melbourne.sgi.com> References: <20051129003611.GF7209@brahms.suse.de> <20051129032937.GZ501696@melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051129032937.GZ501696@melbourne.sgi.com> User-Agent: Mutt/1.4.2.1i X-archive-position: 6642 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 686 Lines: 23 On Tue, Nov 29, 2005 at 02:29:37PM +1100, David Chinner wrote: > On Tue, Nov 29, 2005 at 01:36:11AM +0100, Andi Kleen wrote: > > > > I just found an new exciting way to break XFS. Or rather the > > version that's in 2.6.13. But might be a interesting try anyways. > > So I just ran this on a handy altix I had lying about between other > testing ;) > > It's currently not running 2.6.13, but I'm going to run this again > against 2.6.14 just to make sure it's not a regression. FYI, this test passes without problems on 2.6.14 on the same altix. Hmmm - I need to find an x86-64 box, I guess.... Cheers, Dave. -- Dave Chinner R&D Software Enginner SGI Australian Software Group From owner-linux-xfs@oss.sgi.com Tue Nov 29 18:03:50 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Nov 2005 18:03:54 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id jAU23lO0006384 for ; Tue, 29 Nov 2005 18:03:48 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA10089; Wed, 30 Nov 2005 13:00:09 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id jAU201np19180189; Wed, 30 Nov 2005 13:00:01 +1100 (EST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id jAU1xxNE19157986; Wed, 30 Nov 2005 12:59:59 +1100 (EST) Date: Wed, 30 Nov 2005 12:59:59 +1100 From: David Chinner To: Andi Kleen Cc: linux-xfs@oss.sgi.com Subject: Re: XFS unhappy with large holey loopback and syncs Message-ID: <20051130015959.GC19154461@melbourne.sgi.com> References: <20051129003611.GF7209@brahms.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051129003611.GF7209@brahms.suse.de> User-Agent: Mutt/1.4.2.1i X-archive-position: 6644 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 6846 Lines: 155 On Tue, Nov 29, 2005 at 01:36:11AM +0100, Andi Kleen wrote: > > I just found an new exciting way to break XFS. Or rather the > version that's in 2.6.13. But might be a interesting try anyways. Spending the time to understand these ugly looking stack traces a bit (give me kdb anyday), it seems there's no deadlock in XFS here. > xfssyncd S 0000000000000a7c 0 8846 15 8861 8845 (L-TLB) > {schedule_timeout+150} > {:xfs:xfssyncd+105} > {:xfs:xfssyncd+0} > {keventd_create_kthread+0} > {kthread+243} so xfssynd is asleep. It's idle as far as i can tell. > loop0 D ffff8100057a00f0 0 8856 1 7860 (L-TLB) > {__mod_timer+216} > {schedule_timeout+150} > {:xfs:xfs_flush_device+90} > {:xfs:xfs_iomap_write_delay+1150} > {:xfs:xfs_iomap+700} > {:xfs:__linvfs_get_block+134} And loop0 is in an uninterruptible sleep waiting for 500ms in xfs_flush_device(): igrab(inode); xfs_syncd_queue_work(vfs, inode, xfs_flush_device_work); delay(msecs_to_jiffies(500)); xfs_log_force(ip->i_mount, (xfs_lsn_t)0, XFS_LOG_FORCE|XFS_LOG_SYNC); And xfs_flush_device_work(), which is executed by xfssyncd does: sync_blockdev(vfs->vfs_super->s_bdev); iput((struct inode *)inode); but seeing that xfssyncd is idle, I would assume that this is complete. Now, the key here is where xfs_flush_device() gets called from xfs_iomap_write_delay() via xfs_flush_space(). It disk block _reservation_ for delalloc writes fails 3-4 times in a row for the same allocation. i.e. ENOSPC So, in terms of disk blocks: budgie:~ # ls -lsh /mnt/dgc/stripe/LARGE 23G -rw-r--r-- 1 root root 8.0T Nov 30 10:15 /mnt/dgc/stripe/LARGE You need at least 23GiB of disk space for the test to run. Given the filesytem i tested on was ~8.5TB, I guess I wouldn't have seen this. So I ran the test on a 1GiB filesystem, and it got 5224 inode tables in before hanging with the above error message: Nov 30 11:23:53 budgie kernel: Buffer I/O error on device loop0, logical block 16581037 Nov 30 11:23:53 budgie kernel: lost page write due to I/O error on loop0 Nov 30 11:23:54 budgie kernel: Buffer I/O error on device loop0, logical block 16581038 Nov 30 11:23:54 budgie kernel: lost page write due to I/O error on loop0 Nov 30 11:23:55 budgie kernel: Buffer I/O error on device loop0, logical block 16581041 Nov 30 11:23:55 budgie kernel: lost page write due to I/O error on loop0 And loop0 is doing: [0]kdb> btt 0xe000003065da0000 Stack traceback for pid 20095 0xe000003065da0000 20095 1 0 3 D 0xe000003065da0330 loop0 0xa000000100715a80 schedule+0x1480 0xa0000001007179d0 schedule_timeout+0xf0 0xa000000100717aa0 schedule_timeout_uninterruptible+0x20 0xa0000001003a3840 xfs_flush_device+0x80 0xa0000001003917c0 xfs_iomap_write_delay+0x3a0 0xa000000100392f70 xfs_iomap+0xad0 0xa00000010039f320 xfs_bmap+0x40 0xa000000100393d20 __linvfs_get_block+0x120 0xa0000001003942e0 linvfs_get_block+0x40 0xa000000100160f20 __block_prepare_write+0x640 0xa0000001001613a0 block_prepare_write+0x40 0xa000000100396ad0 linvfs_prepare_write+0x30 0xa0000001005004b0 do_lo_send_aops+0x190 0xa000000100500150 loop_thread+0x710 0xa000000100010ee0 kernel_thread_helper+0xe0 0xa000000100009120 start_kernel_thread+0x20 And the inode it's writing to: [0]kdb> inode 0xe000003017edac48 struct inode at 0xe000003017edac48 i_ino = 1539 i_count = 1 i_size 8796093018112 i_mode = 0100644 i_nlink = 1 i_rdev = 0x0 i_hash.nxt = 0x0000000000000000 i_hash.pprev = 0xa0000002021cbe50 i_list.nxt = 0xe000003016d81648 i_list.prv = 0xe00000301184f1a8 i_dentry.nxt = 0xe0000039eec604d0 i_dentry.prv = 0xe0000039eec604d0 i_sb = 0xe0000039ebd8e300 i_op = 0xa00000010094e5f8 i_data = 0xe000003017edad78 nrpages = 65587 i_fop= 0xa00000010094e2c8 i_flock = 0x0000000000000000 i_mapping = 0xe000003017edad78 i_flags 0x0 i_state 0x0 [] fs specific info @ 0xe000003017edaeb8 has about 1GB of pages attached to it. So i'd say this is a bug in the loopback driver in handling ENOSPC of the underlying filesystem..... mkfs.ext2 has hung at this point here: [0]kdb> btt 0xe000003423220000 Stack traceback for pid 20101 0xe000003423220000 20101 19053 0 2 D 0xe000003423220330 mkfs.ext2 0xa000000100715a80 schedule+0x1480 args (0xe000003423227b00, 0x1001e20d2, 0xe00000b003015e80, 0xe000003423227b30, 0x0) 0xa0000001007179d0 schedule_timeout+0xf0 args (0x19, 0x1001e20d2, 0xa0000001008cc080, 0xa000000100713cc0, 0x286) 0xa000000100713cc0 io_schedule_timeout+0x80 args (0xe00000b003015b74, 0xe000003423227b60, 0xa0000001004e1dc0, 0x309, 0x309) 0xa0000001004e1dc0 blk_congestion_wait+0x100 args (0x1, 0x19, 0xa00000010095a200, 0xa0000001001169f0, 0xb1a) 0xa0000001001169f0 balance_dirty_pages_ratelimited+0x2d0 args (0xe0000039ef731070, 0xe000003423227ba0, 0x180, 0xe000003423227bd8, 0xe000003423227c08) 0xa000000100108300 generic_file_buffered_write+0x660 args (0xe000003423227d40, 0x60000000000210d0, 0x1, 0xa340110000, 0xe000003423227e38) 0xa000000100108f00 __generic_file_aio_write_nolock+0x660 args (0xe000003423227d40, 0xe000003423227e20, 0x0, 0xe000003423227e38, 0x8000) 0xa000000100109880 generic_file_aio_write_nolock+0x60 args (0xe0000039ea6c0a00, 0xe000003423227e20, 0xe0000039ef731070, 0xa34010a000, 0xe0000039ef730f40) 0xa000000100109b10 generic_file_write_nolock+0xf0 args (0xe0000039ea6c0a00, 0xe000003423227e20, 0x1, 0xe000003423227e38, 0xa00000010016c310) 0xa00000010016c310 blkdev_file_write+0x50 args (0xe0000039ea6c0a00, 0x600000000001b0d0, 0x8000, 0xe000003423227e38, 0xa000000100158080) 0xa000000100158080 vfs_write+0x1c0 args (0xe0000039ea6c0a00, 0x600000000001b0d0, 0x8000, 0xe000003423227e38, 0xe0000039ea6c0a20) 0xa0000001001583c0 sys_write+0x80 args (0x4, 0x600000000001b0d0, 0x8000, 0x200000000006f5c0, 0xc000000000000592) 0xa00000010000bb20 ia64_ret_from_syscall args (0x4, 0x600000000001b0d0, 0x8000, 0x200000000006f5c0, 0xc000000000000592) 0xa000000000010640 __kernel_syscall_via_break args (0x4, 0x600000000001b0d0, 0x8000, 0x200000000006f5c0, 0xc000000000000592) Which tends to implicate that the loop0 blockdev is stuck because it hasn't handled the ENOSPC from the underlying fs properly. I can't test this on ext3 or reiserfs because they don't appear to support sparse files larger than the filesytem itself. I'd try running this on a larger XFS filesystem (e.g. 30GB) and see if the problem goes away. Cheers, Dave. -- Dave Chinner R&D Software Enginner SGI Australian Software Group From owner-linux-xfs@oss.sgi.com Tue Nov 29 18:20:31 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Nov 2005 18:20:36 -0800 (PST) Received: from mx1.suse.de (mx1.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jAU2KUO0008052 for ; Tue, 29 Nov 2005 18:20:31 -0800 Received: from Relay2.suse.de (mail2.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.suse.de (Postfix) with ESMTP id 5F0DCEDAB; Wed, 30 Nov 2005 03:17:01 +0100 (CET) Date: Wed, 30 Nov 2005 03:17:01 +0100 From: Andi Kleen To: David Chinner Cc: Andi Kleen , linux-xfs@oss.sgi.com Subject: Re: XFS unhappy with large holey loopback and syncs Message-ID: <20051130021701.GG19515@wotan.suse.de> References: <20051129003611.GF7209@brahms.suse.de> <20051130015959.GC19154461@melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051130015959.GC19154461@melbourne.sgi.com> X-archive-position: 6645 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: linux-xfs Content-Length: 541 Lines: 19 > You need at least 23GiB of disk space for the test to run. Given the > filesytem i tested on was ~8.5TB, I guess I wouldn't have seen this. Hmm, the fs was indeed smaller. That would probably explain it right. I wouldn't have expected that it needed that much data. > I can't test this on ext3 or reiserfs because they don't appear to support sparse > files larger than the filesytem itself. JFS does. > > I'd try running this on a larger XFS filesystem (e.g. 30GB) and see if the > problem goes away. Will do later thanks. -Andi From owner-linux-xfs@oss.sgi.com Tue Nov 29 19:50:15 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 29 Nov 2005 19:50:20 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id jAU3oDO0014341 for ; Tue, 29 Nov 2005 19:50:14 -0800 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA12558; Wed, 30 Nov 2005 14:46:40 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id F093A49E5F39; Wed, 30 Nov 2005 14:46:39 +1100 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 912426 - disable barriers by default Message-Id: <20051130034639.F093A49E5F39@chook.melbourne.sgi.com> Date: Wed, 30 Nov 2005 14:46:39 +1100 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 6646 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 458 Lines: 14 Disable write barriers for now till intermittent IO errors are understood. Date: Tue Nov 29 19:46:11 PST 2005 Workarea: chook.melbourne.sgi.com:/build/nathans/us-xfs-linux Inspected by: hch The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:202962a xfs_vfsops.c - 1.491 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vfsops.c.diff?r1=text&tr1=1.491&r2=text&tr2=1.490&f=h From owner-linux-xfs@oss.sgi.com Wed Nov 30 05:55:02 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Nov 2005 05:55:06 -0800 (PST) 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 jAUDt0O0008677 for ; Wed, 30 Nov 2005 05:55:02 -0800 Received: from minion.mpc.local ([172.16.11.112] helo=moving-picture.com) by moving-picture.com with esmtp (Exim 4.43) id 1EhSMs-00007p-N3 for linux-xfs@oss.sgi.com; Wed, 30 Nov 2005 13:51:30 +0000 Message-ID: <438DAE62.6050101@moving-picture.com> Date: Wed, 30 Nov 2005 13:51:30 +0000 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: linux-xfs@oss.sgi.com Subject: Re: RHEL4 2.6.9-22EL xfs module src.rpm for testing 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: 6647 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: james-p@moving-picture.com Precedence: bulk X-list: linux-xfs Content-Length: 353 Lines: 16 > Hey, let's give it a whirl. No promises, but please do let me know how it > works out. XFS_VERSION_STRING in linux-2.6/xfs_version.h from the src.rpm states: "SGI-XFS CVS-2004-10-17_05:00_UTC" which doesn't seem right ... many of the other source files have "Copyright 2005" in them. How 'old' (or recent) is this code? Thanks James Pearson From owner-linux-xfs@oss.sgi.com Wed Nov 30 07:30:31 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Nov 2005 07:30:33 -0800 (PST) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jAUFUUO0019556 for ; Wed, 30 Nov 2005 07:30:31 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [198.149.16.14]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id jAUHUeBl010200 for ; Wed, 30 Nov 2005 09:30:40 -0800 Received: from [128.162.232.50] (stout.americas.sgi.com [128.162.232.50]) by ledzep.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id jAUFQ0sL26311955; Wed, 30 Nov 2005 09:26:00 -0600 (CST) Message-ID: <438DC488.8060502@sgi.com> Date: Wed, 30 Nov 2005 09:26:00 -0600 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0.6-1.1.fc4 (X11/20050720) X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Pearson CC: linux-xfs@oss.sgi.com Subject: Re: RHEL4 2.6.9-22EL xfs module src.rpm for testing References: <438DAE62.6050101@moving-picture.com> In-Reply-To: <438DAE62.6050101@moving-picture.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6648 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 783 Lines: 30 James Pearson wrote: >> Hey, let's give it a whirl. No promises, but please do let me know >> how it works out. > > > XFS_VERSION_STRING in linux-2.6/xfs_version.h from the src.rpm states: > > "SGI-XFS CVS-2004-10-17_05:00_UTC" > > which doesn't seem right ... many of the other source files have > "Copyright 2005" in them. > > How 'old' (or recent) is this code? Don't worry too much about that timestamp. This code is actually from recent SuSE kernels, which we (er, Nathan, actually) keeps quite up to date, plus patches which get things going on RHEL4. That timestamp was probably way back when SuSE originally pulled xfs from cvs, but they have had many updates since then. We could tidy up the string, but it's harmless. -Eric > Thanks > > James Pearson > From owner-linux-xfs@oss.sgi.com Wed Nov 30 07:37:33 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Nov 2005 07:37:36 -0800 (PST) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jAUFbXO0020370 for ; Wed, 30 Nov 2005 07:37:33 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id jAUHbgka011511 for ; Wed, 30 Nov 2005 09:37:43 -0800 Received: from [128.162.232.50] (stout.americas.sgi.com [128.162.232.50]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id jAUFX2DN20819582; Wed, 30 Nov 2005 09:33:02 -0600 (CST) Message-ID: <438DC62E.1000601@sgi.com> Date: Wed, 30 Nov 2005 09:33:02 -0600 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0.6-1.1.fc4 (X11/20050720) X-Accept-Language: en-us, en MIME-Version: 1.0 To: gbakos@cfa.harvard.edu CC: linux-xfs@oss.sgi.com Subject: Re: XFS internal error xfs_da_do_buf(2) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 6649 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 884 Lines: 23 Gaspar Bakos wrote: > This is an old system, RH9.0 with 2.4.22 kernel, running XFS from 2003-10-10. hmmm, old it is....! > ( I was not able to update this system since the installation due to > realtime-linux patches and various special kernel drivers we use for > robotic control. In any case, it has been working fine for two > years...) > > Question: what to do? Is this a sign of hdd failure, or memory > problems, or some known bug with XFS? You could run S.M.A.R.T. to see if the drive is dying, and of course look in your logs for any IO errors. Run memchk etc if you think the memory might be suspect. It could be an xfs bug too. hard to say. Basically this error means that xfs read something which it did not expect to find (think bad magic number). I'd first try an xfs_repair. You should probably get a repair binary that is less than 2 years old :) -Eric From owner-linux-xfs@oss.sgi.com Wed Nov 30 08:38:05 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Nov 2005 08:38:13 -0800 (PST) Received: from pne-smtpout2-sn2.hy.skanova.net (pne-smtpout2-sn2.hy.skanova.net [81.228.8.164]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jAUGc3O0028634 for ; Wed, 30 Nov 2005 08:38:05 -0800 Received: from safari.iki.fi (80.223.105.208) by pne-smtpout2-sn2.hy.skanova.net (7.2.060.1) id 438CA4140005166E for linux-xfs@oss.sgi.com; Wed, 30 Nov 2005 17:34:28 +0100 Received: (qmail 5093 invoked by uid 500); 30 Nov 2005 16:34:26 -0000 Date: Wed, 30 Nov 2005 18:34:25 +0200 From: Sami Farin To: XFS Mailing List Subject: fixing SELINUX-support in XFS-2.6.14 Message-ID: <20051130163424.GA4724@m.safari.iki.fi> Mail-Followup-To: XFS Mailing List Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11 X-archive-position: 6650 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: safari-xfs@safari.iki.fi Precedence: bulk X-list: linux-xfs Content-Length: 279 Lines: 11 Does XFS team have plans to make 2.6.14 work with SELINUX? http://marc.theaimsgroup.com/?l=selinux&m=112653995009765&w=2 Would be fun if the fix was included in next 2.6.14.4 or something. (If fix is in 2.6.15-rc, sorry for not finding that from 2.3 MBs of changelogs.) -- From owner-linux-xfs@oss.sgi.com Wed Nov 30 13:33:43 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Nov 2005 13:33:52 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id jAULXgO0023185 for ; Wed, 30 Nov 2005 13:33:43 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA04880; Thu, 1 Dec 2005 08:30:08 +1100 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id jAULUIkt7109078; Thu, 1 Dec 2005 08:30:19 +1100 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id jAULR9cU7059504; Thu, 1 Dec 2005 08:27:09 +1100 (EST) Date: Thu, 1 Dec 2005 08:27:09 +1100 From: Nathan Scott To: XFS Mailing List Cc: Stephen Smalley Subject: Re: fixing SELINUX-support in XFS-2.6.14 Message-ID: <20051201082709.C7104341@wobbly.melbourne.sgi.com> References: <20051130163424.GA4724@m.safari.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20051130163424.GA4724@m.safari.iki.fi>; from safari-xfs@safari.iki.fi on Wed, Nov 30, 2005 at 06:34:25PM +0200 X-archive-position: 6651 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1288 Lines: 34 On Wed, Nov 30, 2005 at 06:34:25PM +0200, Sami Farin wrote: > Does XFS team have plans to make 2.6.14 work with SELINUX? > http://marc.theaimsgroup.com/?l=selinux&m=112653995009765&w=2 > > Would be fun if the fix was included in next 2.6.14.4 or > something. > > (If fix is in 2.6.15-rc, sorry for not finding that > from 2.3 MBs of changelogs.) It is not, we have not fixed this in XFS yet. We have plans to resolve the underlying issue here in XFS (an atomic create with attributes), but this is not trivial and not top of the list of things to do at this stage. Stephen, from your mail that Sami has pointed to: | I had actually suggested that the patch removing the old post hooks from | the VFS be deferred until after 2.6.14 to avoid breaking the unconverted | filesystems while still allowing the converted ones to use the new | support, but it seems my request was misunderstood. We could possibly | ask to have the removal patch reverted Please do that, we are not going to be able to fix this quickly in XFS, as there is an underlying issue here that makes this alot more tricky to resolve in XFS. But we are aware of the problem and do plan to fix it, so if you could cater for XFS/SE-Linux users for a little while longer, that would be great. Thanks! -- Nathan From owner-linux-xfs@oss.sgi.com Wed Nov 30 15:53:19 2005 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 30 Nov 2005 15:53:21 -0800 (PST) Received: from mail.davidb.org (adsl-64-172-240-129.dsl.sndg02.pacbell.net [64.172.240.129]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id jAUNrIO0032757 for ; Wed, 30 Nov 2005 15:53:19 -0800 Received: from davidb by mail.davidb.org with local (Exim 4.54 #1 (Debian)) id 1Ehbhs-0001HK-Q9 for ; Wed, 30 Nov 2005 15:49:48 -0800 Date: Wed, 30 Nov 2005 15:49:48 -0800 From: David Brown To: linux-xfs@oss.sgi.com Subject: xfsdump slight problem with LVM snapshots. Message-ID: <20051130234947.GA4224@old.davidb.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11 X-archive-position: 6652 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: xfs@davidb.org Precedence: bulk X-list: linux-xfs Content-Length: 1105 Lines: 36 Using xfsdump to backup snapshot volumes (I'm using LVM2, but it doesn't really matter), can occasionally miss changes in subsequent dumps. Consider the following sequence. % make snapshot of /foo % wait a bit % touch /foo/special file % xfsdump -l 0 /foosnap ... % undo snapshot % make snapshot of /foo % xfsdump -l 1 /foosnap ... % undo snapshot The file 'special' will not be included in the level 1 dump. The problem is that xfsdump is using as its backup time the time that xfsdump was run, where it really needs to be using the time that the snapshot was made. The easiest solution is to add an option to xfsdump that allows it to base the dump date on the mtime of a specified file rather than the current time. e.g.: % touch /tmp/snapstamp % make snapshot of /foo % xfsdump -l n -t /tmp/snapstamp /foo ... This will instruct xfsdump to consider "now" to be the time that snapstamp was touched, rather than the current time, avoiding the missed changes. This should be fairly easy to add, since the gh_timestamp field is only set in one place. Thanks, David Brown