From owner-xfs@oss.sgi.com Sat Dec 1 05:04:32 2007 Received: with ECARTIS (v1.0.0; list xfs); Sat, 01 Dec 2007 05:04:38 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_46 autolearn=no version=3.3.0-r574664 Received: from mail.integraonline.com (relay1.integra.net [204.130.255.180]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id lB1D4STk015160 for ; Sat, 1 Dec 2007 05:04:31 -0800 Received: (qmail 22988 invoked from network); 1 Dec 2007 13:04:37 -0000 Received: from unknown (HELO ?192.168.1.107?) (76.164.13.124) by 0 with SMTP; 1 Dec 2007 13:04:37 -0000 In-Reply-To: <20071130230435.GA12626@puku.stupidest.org> References: <20071114070400.GA25708@puku.stupidest.org> <20071125163014.GA17922@infradead.org> <474FBA21.4070201@sgi.com> <165B249C-FE97-4B27-927B-B39DE316CB23@xfs.org> <20071130230435.GA12626@puku.stupidest.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Timothy Shimmin , Christoph Hellwig , linux-xfs@oss.sgi.com, LKML Content-Transfer-Encoding: 7bit From: Stephen Lord Subject: Re: [PATCH] xfs: revert to double-buffering readdir Date: Sat, 1 Dec 2007 07:04:27 -0600 To: Chris Wedgwood X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV 0.91.2/4967/Sat Dec 1 03:21:28 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13834 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lord@xfs.org Precedence: bulk X-list: xfs On Nov 30, 2007, at 5:04 PM, Chris Wedgwood wrote: > On Fri, Nov 30, 2007 at 04:36:25PM -0600, Stephen Lord wrote: > >> Looks like the readdir is in the bowels of the btree code when >> filldir gets called here, there are probably locks on several >> buffers in the btree at this point. This will only show up for large >> directories I bet. > > I see it for fairly small directories. Larger than what you can stuff > into an inode but less than a block (I'm not checking but fairly sure > that's the case). I told you I did not read any code..... once a directory is out of the inode and into disk blocks, there will be a lock on the buffer while the contents are copied out. > >> Just rambling, not a single line of code was consulted in writing >> this message. > > Can you explain why the offset is capped and treated in an 'odd way' > at all? > > + curr_offset = filp->f_pos; > + if (curr_offset == 0x7fffffff) > + offset = 0xffffffff; > + else > + offset = filp->f_pos; > > and later the offset to filldir is masked. Is that some restriction > in filldir? Too long ago to remember exact reasons. The only thing I do recall is issues with glibc readdir code which wanted to remember positions in a dir and seek backwards. It was translating structures and could end up with more data from the kernel than would fit in the user buffer. This may have something to do with that and special values used as eof markers in the getdents output and signed 32 bit arguments to lseek. In the original xfs directory code, the offset of an entry was a 64 bit hash+offset value, that really confused things when glibc attempted to do math on it. I also recall that the offsets in the directory fields had different meanings on different OS's. Sometimes it was the offset of the entry itself, sometimes it was the offset of the next entry, that was one of the reasons for the translation layer I think. Steve From owner-xfs@oss.sgi.com Sat Dec 1 07:21:38 2007 Received: with ECARTIS (v1.0.0; list xfs); Sat, 01 Dec 2007 07:21:42 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=AWL,BAYES_50,URIBL_GREY autolearn=no version=3.3.0-r574664 Received: from umail.ru (fe01-umail.mtu.ru [62.5.255.15]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id lB1FLZjl030135 for ; Sat, 1 Dec 2007 07:21:37 -0800 Subject: Undeliverable mail: Delivery reports about your e-mail From: To: Date: Sat, 01 Dec 2007 18:06:41 +0300 Message-ID: X-MAPI-Message-Class: REPORT.IPM.Note.NDR MIME-Version: 1.0 Content-Type: multipart/report; report-type="delivery-status"; boundary="_===296660670====fe01-umail.umail.ru===_" X-Virus-Scanned: ClamAV 0.91.2/4969/Sat Dec 1 06:24:46 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13835 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: MAILER-DAEMON@umail.ru Precedence: bulk X-list: xfs --_===296660670====fe01-umail.umail.ru===_ Content-Type: text/plain; charset="utf-8" Failed to deliver to 'olgaefimova@mtu-net.ru' LOCAL module(account olgaefimova@mtu-net.ru) reports: account is full (quota exceeded) --_===296660670====fe01-umail.umail.ru===_ Content-Type: message/delivery-status Reporting-MTA: dns; fe01-umail.umail.ru Original-Recipient: rfc822; Final-Recipient: LOCAL; Action: failed Status: 4.0.0 --_===296660670====fe01-umail.umail.ru===_ Content-Type: text/rfc822-headers Received: from [195.34.34.242] (HELO so01.mtu.ru) by fe01-umail.umail.ru (CommuniGate Pro SMTP 5.1.10) with ESMTP id 296660668 for olgaefimova@mtu-net.ru; Sat, 01 Dec 2007 18:06:41 +0300 Received: from localhost (localhost.mtu.ru [127.0.0.1]) by so01.mtu.ru (Postfix) with ESMTP id 5ADA6BA9A48 for ; Sat, 1 Dec 2007 18:06:40 +0300 (MSK) X-Spam-Flag: YES X-Spam-Yversion: Spamooborona 1.7.0-isp Received: from smtp04.mtu.ru (alt-proxy-1.mtu.ru [62.5.255.74]) by so01.mtu.ru (Postfix) with ESMTP id 4EB8ABA9A32 for ; Sat, 1 Dec 2007 18:06:40 +0300 (MSK) Received: from oss.sgi.com (ppp128-106.dialup.mtu-net.ru [62.118.128.106]) by smtp04.mtu.ru (Postfix) with ESMTP id EBC967FFFB0 for ; Sat, 1 Dec 2007 18:06:14 +0300 (MSK) From: linux-xfs@oss.sgi.com To: olgaefimova@mtu-net.ru Subject: Delivery reports about your e-mail Date: Thu, 7 Sep 2006 06:38:22 +0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0012_F8133FED.84A7BAAB" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-Id: <20071201150614.EBC967FFFB0@smtp04.mtu.ru> --_===296660670====fe01-umail.umail.ru===_-- From owner-xfs@oss.sgi.com Sun Dec 2 14:31:11 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 02 Dec 2007 14:31:14 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id lB2MV6kc029272 for ; Sun, 2 Dec 2007 14:31:10 -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 JAA06581; Mon, 3 Dec 2007 09:31:11 +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 lB2MV9dD129824881; Mon, 3 Dec 2007 09:31:10 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id lB2MV5ZE127129737; Mon, 3 Dec 2007 09:31:05 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Mon, 3 Dec 2007 09:31:05 +1100 From: David Chinner To: Jan Engelhardt Cc: xfs@oss.sgi.com Subject: Re: ACL limit Message-ID: <20071202223105.GS119954183@sgi.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/4976/Sun Dec 2 12:00:39 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13836 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Fri, Nov 30, 2007 at 07:07:26PM +0100, Jan Engelhardt wrote: > Hi, > > > is there any way to raise the number of ACLs that can be stored? The > current limit of 25 is quite tight, where ext3 allows 124 and jfs 8192. > Would increasing XFS_ACL_MAX_ENTRIES work (yes, using potentially more > memory), i.e. not interfering with the on-disk format? It would be an on disk format change - older kernels would error out (-EINVAL) on > 25 ACLs and not check any of them. Hence we'd probably need a superblock feature bit to indicate that >25 ACEs are supported in a given ACL. But we can work around that (superblock feature bit) and should be able to extend this out to ~8190 entries. We're doing an ACL rework ATM, so > 25 entry support should fall out of that.... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Sun Dec 2 15:39:35 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 02 Dec 2007 15:39:39 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id lB2NdT88008780 for ; Sun, 2 Dec 2007 15:39:32 -0800 Received: from cxfsmac10.melbourne.sgi.com (cxfsmac10.melbourne.sgi.com [134.14.55.100]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA07548; Mon, 3 Dec 2007 10:23:25 +1100 Message-ID: <47533E6E.1010508@sgi.com> Date: Mon, 03 Dec 2007 10:23:26 +1100 From: Donald Douwsma User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Christoph Hellwig CC: xfs@oss.sgi.com Subject: Re: current cvs doesn't compile References: <20071130101153.GA4150@lst.de> <20071130101824.GA4419@lst.de> In-Reply-To: <20071130101824.GA4419@lst.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4978/Sun Dec 2 14:38:55 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13837 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: donaldd@sgi.com Precedence: bulk X-list: xfs Christoph Hellwig wrote: > On Fri, Nov 30, 2007 at 11:11:53AM +0100, Christoph Hellwig wrote: >> xfs_mark_inode_dirty_sync is used in xfs_inode_item_format but isn't >> actually declared anywhere. > > Sorry, this was due to me having some old patch applied still. > >> Btw, we also still have the bug that fs/xfs/Kbuild exists as an empty >> files and without removing it nothing is recompiled at all. > > But this is still a real issue.. Hi Christoph, http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/xfs/ Doesn't snow fs/xfs/Kbuild (except in the archives). I also did a fresh cvs checkout of linux-2.6-xfs and its not there ether. Seems like this is only happening when updating an existing workarea. There could be a stale entry in fs/xfs/CVS/Entries that is not being removed by an update/checkout. Could you send us your Entries file so we can figure out whats happening? Don From owner-xfs@oss.sgi.com Sun Dec 2 15:45:01 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 02 Dec 2007 15:45:05 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id lB2NiwK3009939 for ; Sun, 2 Dec 2007 15:45:00 -0800 Received: from timothy-shimmins-power-mac-g5.local (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA07908; Mon, 3 Dec 2007 10:45:00 +1100 Message-ID: <475343FB.3060902@sgi.com> Date: Mon, 03 Dec 2007 10:47:07 +1100 From: Timothy Shimmin User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Jan Engelhardt CC: David Chinner , xfs@oss.sgi.com Subject: Re: ACL limit References: <20071202223105.GS119954183@sgi.com> In-Reply-To: <20071202223105.GS119954183@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4978/Sun Dec 2 14:38:55 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13838 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs David Chinner wrote: > On Fri, Nov 30, 2007 at 07:07:26PM +0100, Jan Engelhardt wrote: >> Hi, >> >> >> is there any way to raise the number of ACLs that can be stored? The >> current limit of 25 is quite tight, where ext3 allows 124 and jfs 8192. >> Would increasing XFS_ACL_MAX_ENTRIES work (yes, using potentially more >> memory), i.e. not interfering with the on-disk format? > > It would be an on disk format change - older kernels would error out > (-EINVAL) on > 25 ACLs and not check any of them. Hence we'd > probably need a superblock feature bit to indicate that >25 ACEs are > supported in a given ACL. > > But we can work around that (superblock feature bit) and should > be able to extend this out to ~8190 entries. We're doing an ACL > rework ATM, so > 25 entry support should fall out of that.... > > Cheers, > > Dave. Yeah, it's just an array of entries in an EA value. The EA value is limited to 64K so it's a question of how many entries you can fit into that. (64K - 4)/12 = 5461 (So just have to sort out the ondisk change as mentioned above) --Tim From owner-xfs@oss.sgi.com Sun Dec 2 16:12:11 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 02 Dec 2007 16:12:14 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from sovereign.computergmbh.de (sovereign.computergmbh.de [85.214.69.204]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id lB30CAMR014453 for ; Sun, 2 Dec 2007 16:12:11 -0800 Received: by sovereign.computergmbh.de (Postfix, from userid 25121) id 369D91803F71F; Mon, 3 Dec 2007 01:12:19 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by sovereign.computergmbh.de (Postfix) with ESMTP id 2E7A71CE2615F; Mon, 3 Dec 2007 01:12:19 +0100 (CET) Date: Mon, 3 Dec 2007 01:12:19 +0100 (CET) From: Jan Engelhardt To: Timothy Shimmin cc: David Chinner , xfs@oss.sgi.com Subject: Re: ACL limit In-Reply-To: <475343FB.3060902@sgi.com> Message-ID: References: <20071202223105.GS119954183@sgi.com> <475343FB.3060902@sgi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.91.2/4978/Sun Dec 2 14:38:55 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13839 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jengelh@computergmbh.de Precedence: bulk X-list: xfs On Dec 3 2007 10:47, Timothy Shimmin wrote: > > Yeah, it's just an array of entries in an EA value. > The EA value is limited to 64K so it's a question of how > many entries you can fit into that. > (64K - 4)/12 = 5461 > > (So just have to sort out the ondisk change as mentioned above) I'd already be happy if the ext3 ACL limit (~120) was possibe :-) The rest I can solve with groups (which is also probably faster than 1600 ACL entries). From owner-xfs@oss.sgi.com Sun Dec 2 16:23:50 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 02 Dec 2007 16:23:53 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id lB30NjaP020779 for ; Sun, 2 Dec 2007 16:23: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 LAA08796; Mon, 3 Dec 2007 11:23:52 +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 lB30NpdD130060790; Mon, 3 Dec 2007 11:23:52 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id lB30NnXe129886603; Mon, 3 Dec 2007 11:23:49 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Mon, 3 Dec 2007 11:23:49 +1100 From: David Chinner To: Timothy Shimmin Cc: Jan Engelhardt , David Chinner , xfs@oss.sgi.com Subject: Re: ACL limit Message-ID: <20071203002349.GV119954183@sgi.com> References: <20071202223105.GS119954183@sgi.com> <475343FB.3060902@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <475343FB.3060902@sgi.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/4978/Sun Dec 2 14:38:55 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13840 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Mon, Dec 03, 2007 at 10:47:07AM +1100, Timothy Shimmin wrote: > David Chinner wrote: > >On Fri, Nov 30, 2007 at 07:07:26PM +0100, Jan Engelhardt wrote: > >>Hi, > >> > >> > >>is there any way to raise the number of ACLs that can be stored? The > >>current limit of 25 is quite tight, where ext3 allows 124 and jfs 8192. > >>Would increasing XFS_ACL_MAX_ENTRIES work (yes, using potentially more > >>memory), i.e. not interfering with the on-disk format? > > > >It would be an on disk format change - older kernels would error out > >(-EINVAL) on > 25 ACLs and not check any of them. Hence we'd > >probably need a superblock feature bit to indicate that >25 ACEs are > >supported in a given ACL. > > > >But we can work around that (superblock feature bit) and should > >be able to extend this out to ~8190 entries. We're doing an ACL > >rework ATM, so > 25 entry support should fall out of that.... > > Yeah, it's just an array of entries in an EA value. > The EA value is limited to 64K so it's a question of how > many entries you can fit into that. > (64K - 4)/12 = 5461 Confused - I thought the ACE was 8 bytes: struct posix_acl_entry { short e_tag; unsigned short e_perm; unsigned int e_id; }; Also, JFS only allows 64k for the xattr as well (jfs_xattr.h): /* Macros for defining maxiumum number of bytes supported for EAs */ #define MAXEASIZE 65535 #define MAXEALISTSIZE MAXEASIZE And (64k - 4)/8 = 8191 which is what JFS supports. Oh: typedef __uint16_t xfs_acl_perm_t; typedef __int32_t xfs_acl_type_t; typedef __int32_t xfs_acl_tag_t; typedef __int32_t xfs_acl_id_t; #define XFS_ACL_MAX_ENTRIES 25 #define XFS_ACL_NOT_PRESENT (-1) typedef struct xfs_acl_entry { xfs_acl_tag_t ae_tag; xfs_acl_id_t ae_id; xfs_acl_perm_t ae_perm; } xfs_acl_entry_t; typedef struct xfs_acl { __int32_t acl_cnt; xfs_acl_entry_t acl_entry[XFS_ACL_MAX_ENTRIES]; } xfs_acl_t; An *XFS* ACE is 12 bytes and hence can't be passed directly to the generic code. Tim - are we adding a translation layer or storing the generic posix acl format on disk? Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Sun Dec 2 16:32:14 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 02 Dec 2007 16:33:07 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id lB30WBa6022211 for ; Sun, 2 Dec 2007 16:32:12 -0800 Received: from timothy-shimmins-power-mac-g5.local (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA09029; Mon, 3 Dec 2007 11:32:14 +1100 Message-ID: <47534F0D.4040606@sgi.com> Date: Mon, 03 Dec 2007 11:34:21 +1100 From: Timothy Shimmin User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: David Chinner CC: Jan Engelhardt , xfs@oss.sgi.com Subject: Re: ACL limit References: <20071202223105.GS119954183@sgi.com> <475343FB.3060902@sgi.com> <20071203002349.GV119954183@sgi.com> In-Reply-To: <20071203002349.GV119954183@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4978/Sun Dec 2 14:38:55 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13841 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs David Chinner wrote: > On Mon, Dec 03, 2007 at 10:47:07AM +1100, Timothy Shimmin wrote: >> David Chinner wrote: >>> On Fri, Nov 30, 2007 at 07:07:26PM +0100, Jan Engelhardt wrote: >>>> Hi, >>>> >>>> >>>> is there any way to raise the number of ACLs that can be stored? The >>>> current limit of 25 is quite tight, where ext3 allows 124 and jfs 8192. >>>> Would increasing XFS_ACL_MAX_ENTRIES work (yes, using potentially more >>>> memory), i.e. not interfering with the on-disk format? >>> It would be an on disk format change - older kernels would error out >>> (-EINVAL) on > 25 ACLs and not check any of them. Hence we'd >>> probably need a superblock feature bit to indicate that >25 ACEs are >>> supported in a given ACL. >>> >>> But we can work around that (superblock feature bit) and should >>> be able to extend this out to ~8190 entries. We're doing an ACL >>> rework ATM, so > 25 entry support should fall out of that.... >> Yeah, it's just an array of entries in an EA value. >> The EA value is limited to 64K so it's a question of how >> many entries you can fit into that. >> (64K - 4)/12 = 5461 > > Confused - I thought the ACE was 8 bytes: > > struct posix_acl_entry { > short e_tag; > unsigned short e_perm; > unsigned int e_id; > }; > > Also, JFS only allows 64k for the xattr as well (jfs_xattr.h): > > /* Macros for defining maxiumum number of bytes supported for EAs */ > #define MAXEASIZE 65535 > #define MAXEALISTSIZE MAXEASIZE > > And (64k - 4)/8 = 8191 which is what JFS supports. > > Oh: > > typedef __uint16_t xfs_acl_perm_t; > typedef __int32_t xfs_acl_type_t; > typedef __int32_t xfs_acl_tag_t; > typedef __int32_t xfs_acl_id_t; > > #define XFS_ACL_MAX_ENTRIES 25 > #define XFS_ACL_NOT_PRESENT (-1) > > typedef struct xfs_acl_entry { > xfs_acl_tag_t ae_tag; > xfs_acl_id_t ae_id; > xfs_acl_perm_t ae_perm; > } xfs_acl_entry_t; > > typedef struct xfs_acl { > __int32_t acl_cnt; > xfs_acl_entry_t acl_entry[XFS_ACL_MAX_ENTRIES]; > } xfs_acl_t; > > An *XFS* ACE is 12 bytes and hence can't be passed directly to the > generic code. Tim - are we adding a translation layer or storing > the generic posix acl format on disk? > There is a translation layer and we have preserved the XFS ACL format on disk since the irix days. The only exception to that is on IRIX it actually always stores an array with 25 entries in it (irrespective of the count) which meant for default inode size the irix acls were always out of line - a bit silly. Decided not to continue with that on Linux ;-) So yes, it's the xfs_acl (12 byte aces) we have on disk. --Tim From owner-xfs@oss.sgi.com Sun Dec 2 19:24:24 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 02 Dec 2007 19:24:28 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id lB33OLZp011778 for ; Sun, 2 Dec 2007 19:24:23 -0800 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA12091 for ; Mon, 3 Dec 2007 14:24:30 +1100 Message-ID: <47537709.9040406@sgi.com> Date: Mon, 03 Dec 2007 14:24:57 +1100 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.9 (X11/20071031) MIME-Version: 1.0 To: xfs@oss.sgi.com Subject: Re: 2.6.24-rc3 oopses while mounting fs References: <20071128134523.GF7793@luba> <474E003A.7020000@sgi.com> <20071130223154.GB13589@luba> In-Reply-To: <20071130223154.GB13589@luba> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4980/Sun Dec 2 18:28:55 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13842 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs Okay, sounds like it might be a corrupt log. Can you run xfs_logprint on the device or saved log? Also give xfs_logprint -t -i a go. You've saved the log into a file? You can get the filesystem mounted again by deleting the log with xfs_repair -L . You'll probably need to run xfs_repair over the filesystem to be safe. KELEMEN Peter wrote: > * Lachlan Mcilroy (lachlan@sgi.com) [20071129 10:56]: > > Lachlan, > >> This looks like a problem we've just fixed, try this patch. >> We'll get this to mainline soon. > > Thanks for the patch. Unfortunately, it does not seem to fix my > problem. Attempting to mount the filesystem still results in an > oops. > > Peter > > -----8<--- > SGI XFS with ACLs, security attributes, realtime, large block/inode numbers, no debug enabled > SGI XFS Quota Management subsystem > XFS mounting filesystem sdc > Starting XFS recovery on filesystem: sdc (logdev: internal) > Unable to handle kernel paging request at ffffc20001c9b000 RIP: > [] :xfs:xlog_recover_add_to_trans+0x64/0xef > PGD 15781d067 PUD 15781c067 PMD 130fd3067 PTE 0 > Oops: 0000 [1] SMP > CPU 1 > Modules linked in: xfs sd_mod 3w_9xxx scsi_mod ohci_hcd uhci_hcd ehci_hcd ipv6 bnx2 sky2 r8169 ns838 > 20 dl2k acenic e100 tg3 e1000 mii > Pid: 2431, comm: mount Not tainted 2.6.24-rc3-xfsbuf #2 > RIP: 0010:[] [] :xfs:xlog_recover_add_to_trans+0x64/0xef > RSP: 0018:ffff8101320d9728 EFLAGS: 00010286 > RAX: ffffc20001c9c000 RBX: 000000000020bd78 RCX: 00000000001cc280 > RDX: 0000000000000000 RSI: ffffc20001c9b000 RDI: ffffc20001cdbaf8 > RBP: ffff8101320d9758 R08: ffff810157801652 R09: 0000000000000000 > R10: 0000000000000000 R11: 0000000000000002 R12: ffff8101324633b8 > R13: ffffc20001c5b508 R14: ffff810132463110 R15: ffffc20001c5b4fc > FS: 00002abba6e87b00(0000) GS:ffff810157801708(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b > CR2: ffffc20001c9b000 CR3: 000000013252a000 CR4: 00000000000006e0 > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 > Process mount (pid: 2431, threadinfo ffff8101320d8000, task ffff810131972000) > Stack: 0020bd785769c5e8 000000005769c5e8 000000000000000a ffffc20001c5b508 > 000000000000011e ffffc20001c5b4fc ffff8101320d97b8 ffffffff881c79db > ffffc20001c6a000 00000001881da0bc ffff81013188f000 ffff8101320d9828 > Call Trace: > [] :xfs:xlog_recover_process_data+0x184/0x1d9 > [] :xfs:xlog_do_recovery_pass+0x74b/0x795 > [] :xfs:xlog_do_log_recovery+0x3d/0x82 > [] :xfs:xlog_do_recover+0x12/0x11c > [] :xfs:xlog_recover+0x84/0x92 > [] :xfs:xfs_log_mount+0x8c/0xe4 > [] :xfs:xfs_mountfs+0x67d/0x97b > [] :xfs:xfs_mru_cache_create+0x170/0x1d5 > [] :xfs:xfs_fstrm_free_func+0x0/0x81 > [] :xfs:xfs_ioinit+0xb/0xd > [] :xfs:xfs_mount+0x2bb/0x36b > [] :xfs:xfs_fs_fill_super+0xd2/0x245 > [] get_filesystem+0x17/0x39 > [] sget+0x3fb/0x418 > [] sget+0x403/0x418 > [] set_bdev_super+0x0/0x14 > [] get_sb_bdev+0x123/0x16f > [] :xfs:xfs_fs_fill_super+0x0/0x245 > [] :xfs:xfs_fs_get_sb+0x13/0x18 > [] vfs_kern_mount+0x8f/0x11c > [] do_kern_mount+0x44/0xf4 > [] do_mount+0x6d8/0x71e > [] __up_read+0x93/0x9b > [] up_read+0x23/0x27 > [] do_page_fault+0x42e/0x7c7 > [] zone_statistics+0x64/0x69 > [] __alloc_pages+0x6b/0x311 > [] sys_mount+0x8a/0xcc > [] system_call+0x7e/0x83 > > Code: f3 a4 49 89 c7 49 8b 54 24 08 8b 42 18 85 c0 74 0e 3b 42 14 > From owner-xfs@oss.sgi.com Sun Dec 2 21:32:09 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 02 Dec 2007 21:32:14 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id lB35W5eu001380 for ; Sun, 2 Dec 2007 21:32:07 -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 QAA14700; Mon, 3 Dec 2007 16:32:14 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 1116) id 31B2358C4C0F; Mon, 3 Dec 2007 16:32:14 +1100 (EST) To: xfs@oss.sgi.com, xfs-bugs-internal@sgi.com Subject: TAKE update acl/attr man pages re symlinks Message-Id: <20071203053214.31B2358C4C0F@chook.melbourne.sgi.com> Date: Mon, 3 Dec 2007 16:32:14 +1100 (EST) From: tes@sgi.com (Tim Shimmin) X-Virus-Scanned: ClamAV 0.91.2/4980/Sun Dec 2 18:28:55 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13843 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs Update man pages about tree walking and symlinks. Provided by Andreas G. Date: Mon Dec 3 16:30:10 AEDT 2007 Workarea: chook.melbourne.sgi.com:/build/tes/xfs-cmds Inspected by: agruen@sgi.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:30185a acl/doc/CHANGES - 1.98 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/doc/CHANGES.diff?r1=text&tr1=1.98&r2=text&tr2=1.97&f=h acl/man/man1/getfacl.1 - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/man/man1/getfacl.1.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h acl/man/man1/setfacl.1 - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/man/man1/setfacl.1.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h attr/doc/CHANGES - 1.85 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/doc/CHANGES.diff?r1=text&tr1=1.85&r2=text&tr2=1.84&f=h attr/man/man1/getfattr.1 - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/man/man1/getfattr.1.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h - Update man pages about tree walking and symlinks. From owner-xfs@oss.sgi.com Sun Dec 2 23:43:47 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 02 Dec 2007 23:43:50 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id lB37hi1R017708 for ; Sun, 2 Dec 2007 23:43:46 -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 SAA17039; Mon, 3 Dec 2007 18:43:49 +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 lB37hmdD130131407; Mon, 3 Dec 2007 18:43:49 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id lB37hjQ8130291321; Mon, 3 Dec 2007 18:43:45 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Mon, 3 Dec 2007 18:43:45 +1100 From: David Chinner To: xfs-dev Cc: xfs-oss Subject: Fix xfs_ichgtime mainline breakage. Message-ID: <20071203074345.GW119954183@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/4980/Sun Dec 2 18:28:55 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13844 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Folks, Just noticed with the mainline merge (2.6.24-rc3) to xfs-dev that xfs_ichgtime + xfs_ichgtime_fast are broken. if (!(inode->i_state & I_SYNC)) mark_inode_dirty_sync(inode); that check used to be against I_LOCK, which was arguably broken, but this one will mean newly created files are not put on the dirty list and hence not written back by pdflush. Patch to fix this attached. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group --- fs/xfs/linux-2.6/xfs_iops.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Index: 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_iops.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/linux-2.6/xfs_iops.c 2007-12-03 18:39:52.000000000 +1100 +++ 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_iops.c 2007-12-03 18:40:54.408998073 +1100 @@ -134,7 +134,7 @@ xfs_ichgtime( */ SYNCHRONIZE(); ip->i_update_core = 1; - if (!(inode->i_state & I_SYNC)) + if (!(inode->i_state & I_NEW)) mark_inode_dirty_sync(inode); } @@ -186,7 +186,7 @@ xfs_ichgtime_fast( */ SYNCHRONIZE(); ip->i_update_core = 1; - if (!(inode->i_state & I_SYNC)) + if (!(inode->i_state & I_NEW)) mark_inode_dirty_sync(inode); } From owner-xfs@oss.sgi.com Mon Dec 3 07:47:12 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 03 Dec 2007 07:47:17 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-3.8 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.0-r574664 Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id lB3Fl98x018190 for ; Mon, 3 Dec 2007 07:47:12 -0800 Received: from hch by pentafluge.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1IzCxR-0004oU-QW; Mon, 03 Dec 2007 15:11:42 +0000 Date: Mon, 3 Dec 2007 15:11:41 +0000 From: Christoph Hellwig To: Stephen Lord Cc: Timothy Shimmin , Christoph Hellwig , Chris Wedgwood , linux-xfs@oss.sgi.com, LKML Subject: Re: [PATCH] xfs: revert to double-buffering readdir Message-ID: <20071203151141.GB18082@infradead.org> References: <20071114070400.GA25708@puku.stupidest.org> <20071125163014.GA17922@infradead.org> <474FBA21.4070201@sgi.com> <165B249C-FE97-4B27-927B-B39DE316CB23@xfs.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <165B249C-FE97-4B27-927B-B39DE316CB23@xfs.org> User-Agent: Mutt/1.5.17 (2007-11-01) X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-Virus-Scanned: ClamAV 0.91.2/4980/Sun Dec 2 18:28:55 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13845 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs On Fri, Nov 30, 2007 at 04:36:25PM -0600, Stephen Lord wrote: > Wow, was it really that long ago! > > Looks like the readdir is in the bowels of the btree code when filldir gets > called > here, there are probably locks on several buffers in the btree at this > point. This > will only show up for large directories I bet. Chris saw it with block-form directories. I've verified it works fine with short-form directories, and the leaf code looks like it could happen aswell. I also remember gfs2 running into a similar problem. > The xfs readdir code has the complete xfs inode number in its hands at this > point > (filldir is not necessarily getting all the bits of it). All we are doing > the lookup > for really is to get the inode number back again so we can get the inode > and get the attributes. Rather dumb really. There has got to be a way of > doing a callout structure here so that the inode number can be pushed > through filldir and back into an fs specific call. The fs then can do a > lookup > by id - which is what it does most of the time for resolving nfs handles > anyway. Should be more efficient than the current scheme. Yes, a lot more efficient. But it means adding a new operation for use by the nfs server. From owner-xfs@oss.sgi.com Mon Dec 3 07:48:11 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 03 Dec 2007 07:48:14 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-3.8 required=5.0 tests=AWL,BAYES_00, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.0-r574664 Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id lB3Fm9f9018429 for ; Mon, 3 Dec 2007 07:48:10 -0800 Received: from hch by pentafluge.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1IzCuw-0004lT-1B; Mon, 03 Dec 2007 15:09:06 +0000 Date: Mon, 3 Dec 2007 15:09:05 +0000 From: Christoph Hellwig To: Timothy Shimmin Cc: Christoph Hellwig , Chris Wedgwood , linux-xfs@oss.sgi.com, LKML Subject: Re: [PATCH] xfs: revert to double-buffering readdir Message-ID: <20071203150905.GA18082@infradead.org> References: <20071114070400.GA25708@puku.stupidest.org> <20071125163014.GA17922@infradead.org> <474FBA21.4070201@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <474FBA21.4070201@sgi.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-Virus-Scanned: ClamAV 0.91.2/4980/Sun Dec 2 18:28:55 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13846 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs On Fri, Nov 30, 2007 at 06:22:09PM +1100, Timothy Shimmin wrote: > Hmmm, don't see the point of "eof" local var now. > Previously bhv_vop_readdir() returned eof. > I presume if we don't move the offset (offset == startoffset) then > we're done and break out? > So we lost eof when going to the filldir in the getdents code etc... Yes, it's just copy & paste. We can trivially kill the variable. From owner-xfs@oss.sgi.com Mon Dec 3 13:16:18 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 03 Dec 2007 13:16:21 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id lB3LGEfE013330 for ; Mon, 3 Dec 2007 13:16:16 -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 IAA06743; Tue, 4 Dec 2007 08:16:22 +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 lB3LGLdD130513410; Tue, 4 Dec 2007 08:16:21 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id lB3LGKPH131022564; Tue, 4 Dec 2007 08:16:20 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Tue, 4 Dec 2007 08:16:20 +1100 From: David Chinner To: xfs-oss Cc: xfs-dev Subject: [Patch] xfs_lowbit64 broken on ia32 Message-ID: <20071203211620.GN115527101@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/4984/Mon Dec 3 09:37:48 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13847 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs The recent change to the internals of xfs_lowbit64 broke it on ia32 - the code treats the 64bit value as an unsigned long which is only 32 bits on ia32 and hence throws away the high 32 bits. 64 bit platforms are not affected. Tested with a userspace implementation comparing the original code with the new code. Signed-off-by: Dave Chinner --- fs/xfs/xfs_bit.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Index: 2.6.x-xfs-new/fs/xfs/xfs_bit.h =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/xfs_bit.h 2007-11-02 13:44:45.000000000 +1100 +++ 2.6.x-xfs-new/fs/xfs/xfs_bit.h 2007-12-03 14:43:33.169851481 +1100 @@ -68,8 +68,8 @@ static inline int xfs_lowbit32(__uint32_ /* Get low bit set out of 64-bit argument, -1 if none set */ static inline int xfs_lowbit64(__uint64_t v) { - unsigned long t = v; - return (v) ? find_first_bit(&t, 64) : -1; + unsigned long long t = v; + return (v) ? find_first_bit((unsigned long *)&t, 64) : -1; } /* Return whether bitmap is empty (1 == empty) */ From owner-xfs@oss.sgi.com Mon Dec 3 14:02:05 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 03 Dec 2007 14:02:10 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from ninsei.hu (ninsei.hu [212.92.23.158]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id lB3M21ja018837 for ; Mon, 3 Dec 2007 14:02:05 -0800 Received: from luba (lns-bzn-35-82-250-243-147.adsl.proxad.net [82.250.243.147]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by chatsubo.ninsei.hu (Postfix) with ESMTP id B941D7A8D for ; Mon, 3 Dec 2007 23:01:27 +0100 (CET) Received: by luba (Postfix, from userid 32266) id 7AB7910B4C1; Mon, 3 Dec 2007 23:01:59 +0100 (CET) Date: Mon, 3 Dec 2007 23:02:00 +0100 From: KELEMEN Peter To: xfs@oss.sgi.com Subject: Re: 2.6.24-rc3 oopses while mounting fs Message-ID: <20071203220200.GC13667@luba> Mail-Followup-To: xfs@oss.sgi.com References: <20071128134523.GF7793@luba> <474E003A.7020000@sgi.com> <20071130223154.GB13589@luba> <47537709.9040406@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <47537709.9040406@sgi.com> Organization: CERN European Laboratory for Particle Physics, Switzerland X-GPG-KeyID: 1024D/9FF0CABE 2004-04-03 X-GPG-Fingerprint: 6C9E 5917 3B06 E4EE 6356 7BF0 8F3E CAB6 9FF0 CABE X-Comment: Personal opinion. Paragraphs might have been reformatted. X-Copyright: Forwarding or publishing without permission is prohibited. X-Accept-Language: hu,en User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: ClamAV 0.91.2/4984/Mon Dec 3 09:37:48 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13848 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Peter.Kelemen@cern.ch Precedence: bulk X-list: xfs * Lachlan Mcilroy (lachlan@sgi.com) [20071203 14:24]: Lachlan, > Okay, sounds like it might be a corrupt log. Yep. > Can you run xfs_logprint on the device or saved log? Sure. http://cern.ch/fuji/lxfsre1103/xfs_logprint1.txt.bz2 It aborted though, with the following message: xfs_logprint: unknown log operation type (343b) Bad data in log > Also give xfs_logprint -t -i a go. http://cern.ch/fuji/lxfsre1103/xfs_logprint2.txt.bz2 > You've saved the log into a file? You can get the filesystem > mounted again by deleting the log with xfs_repair -L . > You'll probably need to run xfs_repair over the filesystem to be > safe. I conserved this filesystem away for further analysis, I'm not sure how helpful it can be. Thanks, Peter -- .+'''+. .+'''+. .+'''+. .+'''+. .+'' Kelemen Péter / \ / \ Peter.Kelemen@cern.ch .+' `+...+' `+...+' `+...+' `+...+' From owner-xfs@oss.sgi.com Mon Dec 3 16:08:49 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 03 Dec 2007 16:08:54 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id lB408ka2002388 for ; Mon, 3 Dec 2007 16:08:48 -0800 Received: from timothy-shimmins-power-mac-g5.local (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA11891 for ; Tue, 4 Dec 2007 11:08:55 +1100 Message-ID: <47549B1A.4070508@sgi.com> Date: Tue, 04 Dec 2007 11:11:06 +1100 From: Timothy Shimmin User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: xfs@oss.sgi.com Subject: Re: 2.6.24-rc3 oopses while mounting fs References: <20071128134523.GF7793@luba> <474E003A.7020000@sgi.com> <20071130223154.GB13589@luba> <47537709.9040406@sgi.com> <20071203220200.GC13667@luba> In-Reply-To: <20071203220200.GC13667@luba> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4987/Mon Dec 3 14:00:21 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13849 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs Hi Peter, FYI Just a couple of things in case you weren't aware. Often it is simplest to save the log using the -C option to a file. -C filename Copy the log from the filesystem to the file filename. The log itself is not printed. The log can then be analysed in various ways later. Running logprint in operation mode (the default mode without options) (non-transaction mode without -t) is really pretty useless without the -s option. If you use the -s option then one needs to know where to seek to (you can use -t to find the head/tail or -d to see where log records start). The problem here is that if you do logprint like this (no options) then it will start at offset zero and will invariably have trouble decoding if the log has wrapped around (the general case) as you'll start in the middle of a record. So the -t option is often a more interesting starting point as it will operate more like the file system recovery does, finding the head and tail, and processing from the tail to the head of the log. If you want to save the filesystem away for possible metadata debugging later, then xfs_metadump is your friend. Cheers, Tim. KELEMEN Peter wrote: > * Lachlan Mcilroy (lachlan@sgi.com) [20071203 14:24]: > > Lachlan, > >> Okay, sounds like it might be a corrupt log. > > Yep. > >> Can you run xfs_logprint on the device or saved log? > > Sure. > > http://cern.ch/fuji/lxfsre1103/xfs_logprint1.txt.bz2 > It aborted though, with the following message: > > xfs_logprint: unknown log operation type (343b) > Bad data in log > >> Also give xfs_logprint -t -i a go. > > http://cern.ch/fuji/lxfsre1103/xfs_logprint2.txt.bz2 > >> You've saved the log into a file? You can get the filesystem >> mounted again by deleting the log with xfs_repair -L . >> You'll probably need to run xfs_repair over the filesystem to be >> safe. > > I conserved this filesystem away for further analysis, I'm not > sure how helpful it can be. > > Thanks, > Peter > From owner-xfs@oss.sgi.com Mon Dec 3 19:21:24 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 03 Dec 2007 19:21:28 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id lB43LKGr030936 for ; Mon, 3 Dec 2007 19:21:23 -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 OAA16095; Tue, 4 Dec 2007 14:21:25 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 1116) id 352D358C4C0F; Tue, 4 Dec 2007 14:21:25 +1100 (EST) To: sgi.bugs.xfs@engr.sgi.com, xfs@oss.sgi.com Subject: PARTIAL TAKE 973591 - attr update for tree walking Message-Id: <20071204032125.352D358C4C0F@chook.melbourne.sgi.com> Date: Tue, 4 Dec 2007 14:21:25 +1100 (EST) From: tes@sgi.com (Tim Shimmin) X-Virus-Scanned: ClamAV 0.91.2/4990/Mon Dec 3 16:38:56 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13850 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs Add some code to the tree walking to better handle file descriptors. Date: Tue Dec 4 14:19:53 AEDT 2007 Workarea: chook.melbourne.sgi.com:/build/tes/xfs-cmds Inspected by: agruen@suse.de The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:30192a attr/VERSION - 1.71 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/VERSION.diff?r1=text&tr1=1.71&r2=text&tr2=1.70&f=h attr/doc/CHANGES - 1.86 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/doc/CHANGES.diff?r1=text&tr1=1.86&r2=text&tr2=1.85&f=h xfstests/062.out - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/062.out.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h attr/getfattr/getfattr.c - 1.28 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/getfattr/getfattr.c.diff?r1=text&tr1=1.28&r2=text&tr2=1.27&f=h attr/test/getfattr.test - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/test/getfattr.test.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h attr/libmisc/walk_tree.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/libmisc/walk_tree.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h attr/include/walk_tree.h - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/include/walk_tree.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h From owner-xfs@oss.sgi.com Mon Dec 3 20:09:46 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 03 Dec 2007 20:09:51 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id lB449hAI005525 for ; Mon, 3 Dec 2007 20:09:45 -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 PAA17103; Tue, 4 Dec 2007 15:09:49 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 1116) id C5EF658C4C0F; Tue, 4 Dec 2007 15:09:49 +1100 (EST) To: sgi.bugs.xfs@engr.sgi.com, xfs@oss.sgi.com Subject: TAKE 973591 - add more code to acl tree walking Message-Id: <20071204040949.C5EF658C4C0F@chook.melbourne.sgi.com> Date: Tue, 4 Dec 2007 15:09:49 +1100 (EST) From: tes@sgi.com (Tim Shimmin) X-Virus-Scanned: ClamAV 0.91.2/4990/Mon Dec 3 16:38:56 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13851 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs Add some code to the tree walking to better handle file descriptors. Provided by Andreas G. Date: Tue Dec 4 15:08:45 AEDT 2007 Workarea: chook.melbourne.sgi.com:/build/tes/xfs-cmds Inspected by: agruen@suse.de The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:30195a acl/VERSION - 1.87 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/VERSION.diff?r1=text&tr1=1.87&r2=text&tr2=1.86&f=h acl/doc/CHANGES - 1.99 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/doc/CHANGES.diff?r1=text&tr1=1.99&r2=text&tr2=1.98&f=h acl/setfacl/setfacl.c - 1.22 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/setfacl/setfacl.c.diff?r1=text&tr1=1.22&r2=text&tr2=1.21&f=h acl/setfacl/do_set.c - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/setfacl/do_set.c.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h acl/getfacl/getfacl.c - 1.22 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/getfacl/getfacl.c.diff?r1=text&tr1=1.22&r2=text&tr2=1.21&f=h acl/libmisc/walk_tree.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/libmisc/walk_tree.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h acl/include/walk_tree.h - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/acl/include/walk_tree.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h From owner-xfs@oss.sgi.com Mon Dec 3 23:07:57 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 03 Dec 2007 23:08:00 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_52 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id lB477qsW008591 for ; Mon, 3 Dec 2007 23:07:55 -0800 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA20893; Tue, 4 Dec 2007 18:07:57 +1100 Message-ID: <4754FCEC.30906@sgi.com> Date: Tue, 04 Dec 2007 18:08:28 +1100 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.9 (X11/20071031) MIME-Version: 1.0 To: Timothy Shimmin CC: xfs@oss.sgi.com Subject: Re: 2.6.24-rc3 oopses while mounting fs References: <20071128134523.GF7793@luba> <474E003A.7020000@sgi.com> <20071130223154.GB13589@luba> <47537709.9040406@sgi.com> <20071203220200.GC13667@luba> <47549B1A.4070508@sgi.com> In-Reply-To: <47549B1A.4070508@sgi.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/4990/Mon Dec 3 16:38:56 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13852 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs The transactional view appears to be truncated. ============================================================================ TRANS: tid:0x5769cb28 type:STRAT_WRITE #items:5 trans:0x0 q:0x56dfa0 INO: cnt:3 total:3 a:0x56f5e0 len:56 a:0x56f570 len:96 a:0x56df80 len:16 INODE: #regs:3 ino:0x1400005c flags:0x5 dsize:16 CORE inode: magic:IN mode:0x8180 ver:1 format:2 onlink:1 uid:14029 gid:1474 nlink:1 projid:0 atime:1192671344 mtime:1192672095 ctime:1192672095 flushiter:20 size:0x20700000 nblks:0x20740 exsize:0 nextents:1 anextents:0 forkoff:0 dmevmask:0x0 dmstate:0 flags:0x0 gen:4 DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x56dc50 len:24 a:0x56dca0 len:128 BUF: #regs:2 start blkno:0x24610701 len:1 bmap size:1 flags:0x0 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x56ddc0 len:28 a:0x56dd30 len:128 BUF: #regs:2 start blkno:0x24610708 len:8 bmap size:2 flags:0x0 BUF DATA BUF: cnt:3 total:3 a:0x56df20 len:28 a:0x56f010 len:128 a:0x56f160 len:256 BUF: #regs:3 start blkno:0x24610710 len:8 bmap size:2 flags:0x0 BUF DATA BUF DATA BUF: cnt:2 total:2 a:0x56ddf0 len:24 a:0x56f0a0 len:128 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 flags:0x0 SUPER Block Buffer: LOG REC AT LSN cycle 154 block 5248 (0x9a, 0x1480) ... just stops there. Looking at the non-transactional view at this point: ============================================================================ cycle: 154 version: 2 lsn: 154,5248 tail_lsn: 153,253056 length of Log Record: 61440 prev offset: 5120 num ops: 303 uuid: b02fc6bd-662f-40a5-8f0c-e260a881a3e7 format: little endian linux h_size: 262144 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ extended-header: cycle: 154 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ extended-header: cycle: 154 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ extended-header: cycle: 154 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ extended-header: cycle: 154 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ extended-header: cycle: 154 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ extended-header: cycle: 154 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ extended-header: cycle: 154 ---------------------------------------------------------------------------- Oper (0): tid: 5769cd60 len: 0 clientid: TRANS flags: START ---------------------------------------------------------------------------- Oper (1): tid: 5769cd60 len: 16 clientid: TRANS flags: none TRAN: type: STRAT_WRITE tid: 0 num_items: 5 ---------------------------------------------------------------------------- Oper (2): tid: 5769cd60 len: 56 clientid: TRANS flags: none INODE: #regs: 3 ino: 0x1400005c flags: 0x5 dsize: 16 blkno: 610338736 len: 16 boff: 4096 Oper (3): tid: 5769cd60 len: 96 clientid: TRANS flags: none INODE CORE magic 0x494e mode 0100600 version 1 format 2 nlink 1 uid 14029 gid 1474 atime 0x4716b870 mtime 0x4716bade ctime 0x4716bade size 0x1ce00000 nblocks 0x1c840 extsize 0x0 nextents 0x1 naextents 0x0 forkoff 0 dmevmask 0x0 dmstate 0x0 flags 0x0 gen 0x4 Oper (4): tid: 5769cd60 len: 16 clientid: TRANS flags: none EXTENTS inode data ---------------------------------------------------------------------------- Oper (5): tid: 5769cf18 len: 24 clientid: TRANS flags: none BUF: #regs: 2 start blkno: 610338561 (0x24610701) len: 1 bmap size: 1 flags: 0x0 Oper (6): tid: 5769cf18 len: 128 clientid: TRANS flags: none AGF Buffer: XAGF ver: 1 seq#: 5 len: 15258464 root BNO: 1 CNT: 2 level BNO: 1 CNT: 1 1st: 0 last: 3 cnt: 4 freeblks: 2491090 longest: 581471 ---------------------------------------------------------------------------- Oper (7): tid: 5769cf18 len: 28 clientid: TRANS flags: none BUF: #regs: 2 start blkno: 610338568 (0x24610708) len: 8 bmap size: 2 flags: 0x0 Oper (8): tid: 5769cf18 len: 128 clientid: TRANS flags: none BUF DATA ---------------------------------------------------------------------------- Oper (9): tid: 5769cf18 len: 28 clientid: TRANS flags: none BUF: #regs: 3 start blkno: 610338576 (0x24610710) len: 8 bmap size: 2 flags: 0x0 Oper (10): tid: 5769cf18 len: 128 clientid: TRANS flags: none BUF DATA Oper (11): tid: 5769cf18 len: 256 clientid: TRANS flags: none BUF DATA ---------------------------------------------------------------------------- Oper (12): tid: 5769cf18 len: 24 clientid: TRANS flags: none BUF: #regs: 2 start blkno: 8647474234504773632 (0x7802000000000000) len: 1 bmap size: 1 flags: 0x0 Oper (13): tid: 5769cf18 len: 128 clientid: TRANS flags: none BUF DATA ---------------------------------------------------------------------------- Oper (14): tid: 5769cf18 len: 0 clientid: TRANS flags: COMMIT ---------------------------------------------------------------------------- Oper (15): tid: 5769c5e8 len: 0 clientid: TRANS flags: START ---------------------------------------------------------------------------- Oper (16): tid: 5769c5e8 len: 16 clientid: TRANS flags: none TRAN: type: STRAT_WRITE tid: 0 num_items: 5 ---------------------------------------------------------------------------- Oper (17): tid: 5769c5e8 len: 2145656 clientid: TRANS flags: none ********************************************************************** * ERROR: data block=5255 * ********************************************************************** We should have 5 more items in this transaction plus the commit and then another 286 operations. The operation number and transaction id are correct but the length is bogus. The first item in a STRAT_WRITE transaction should be an inode and the length should be 56. Tim, does this ring any bells with you? The only validation we do on the length is an ASSERT in xlog_recover_process_data() which isn't much good here. I don't know why the value is wrong but we can do better than crashing the system. I would like to know how much more data is corrupt beyond this point. Peter, can you try xfs_logprint -c ...? Timothy Shimmin wrote: > Hi Peter, > > FYI > > Just a couple of things in case you weren't aware. > Often it is simplest to save the log using the -C option to a file. > -C filename > Copy the log from the filesystem to the file filename. > The log itself is not printed. > The log can then be analysed in various ways later. > > Running logprint in operation mode (the default mode without options) > (non-transaction mode without -t) > is really pretty useless without the -s option. > If you use the -s option then one needs to know where to seek to > (you can use -t to find the head/tail or -d to see where log records > start). > The problem here is that if you do logprint > like this (no options) then it will start at offset zero and will > invariably have > trouble decoding if the log has wrapped around (the general case) as > you'll start in the middle of a record. > So the -t option is often a more interesting starting point as it > will operate more like the file system recovery does, finding the head > and tail, > and processing from the tail to the head of the log. > > If you want to save the filesystem away for possible metadata debugging > later, > then xfs_metadump is your friend. > > Cheers, > Tim. > > KELEMEN Peter wrote: >> * Lachlan Mcilroy (lachlan@sgi.com) [20071203 14:24]: >> >> Lachlan, >> >>> Okay, sounds like it might be a corrupt log. >> >> Yep. >> >>> Can you run xfs_logprint on the device or saved log? >> >> Sure. >> >> http://cern.ch/fuji/lxfsre1103/xfs_logprint1.txt.bz2 >> It aborted though, with the following message: >> >> xfs_logprint: unknown log operation type (343b) >> Bad data in log >> >>> Also give xfs_logprint -t -i a go. >> >> http://cern.ch/fuji/lxfsre1103/xfs_logprint2.txt.bz2 >> >>> You've saved the log into a file? You can get the filesystem >>> mounted again by deleting the log with xfs_repair -L . >>> You'll probably need to run xfs_repair over the filesystem to be >>> safe. >> >> I conserved this filesystem away for further analysis, I'm not >> sure how helpful it can be. >> >> Thanks, >> Peter >> > > > From owner-xfs@oss.sgi.com Tue Dec 4 01:57:09 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 04 Dec 2007 01:57:14 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_33 autolearn=no version=3.3.0-r574664 Received: from ninsei.hu (ninsei.hu [212.92.23.158]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id lB49v6ps007078 for ; Tue, 4 Dec 2007 01:57:09 -0800 Received: from luba (pb-d-128-141-57-222.cern.ch [128.141.57.222]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by chatsubo.ninsei.hu (Postfix) with ESMTP id C0E9C7A97 for ; Tue, 4 Dec 2007 10:56:38 +0100 (CET) Received: by luba (Postfix, from userid 32266) id E488710A790; Tue, 4 Dec 2007 10:57:10 +0100 (CET) Date: Tue, 4 Dec 2007 10:57:10 +0100 From: KELEMEN Peter To: xfs@oss.sgi.com Subject: Re: 2.6.24-rc3 oopses while mounting fs Message-ID: <20071204095710.GD2074@luba> Mail-Followup-To: xfs@oss.sgi.com References: <20071128134523.GF7793@luba> <474E003A.7020000@sgi.com> <20071130223154.GB13589@luba> <47537709.9040406@sgi.com> <20071203220200.GC13667@luba> <47549B1A.4070508@sgi.com> <4754FCEC.30906@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4754FCEC.30906@sgi.com> Organization: CERN European Laboratory for Particle Physics, Switzerland X-GPG-KeyID: 1024D/9FF0CABE 2004-04-03 X-GPG-Fingerprint: 6C9E 5917 3B06 E4EE 6356 7BF0 8F3E CAB6 9FF0 CABE X-Comment: Personal opinion. Paragraphs might have been reformatted. X-Copyright: Forwarding or publishing without permission is prohibited. X-Accept-Language: hu,en User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: ClamAV 0.91.2/4991/Tue Dec 4 00:18:25 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13854 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Peter.Kelemen@cern.ch Precedence: bulk X-list: xfs * Lachlan Mcilroy (lachlan@sgi.com) [20071204 18:08]: Lachlan, > The transactional view appears to be truncated. [...] > Peter, can you try xfs_logprint -c ...? xfs_logprint -c -t -i produces an identical transactional dump than what you have seen. http://cern.ch/fuji/lxfsre1103/xfs_logprint_c_t_i.txt You can grab the whole saved log from here (128M uncompressed): http://cern.ch/fuji/lxfsre1103/sdc.xlg.bz2 88a6906567ab44994a0b5c4255c5c619428405dc sdc.xlg HTH, Peter -- .+'''+. .+'''+. .+'''+. .+'''+. .+'' Kelemen Péter / \ / \ Peter.Kelemen@cern.ch .+' `+...+' `+...+' `+...+' `+...+' From owner-xfs@oss.sgi.com Tue Dec 4 01:57:09 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 04 Dec 2007 01:57:14 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from ninsei.hu (ninsei.hu [212.92.23.158]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id lB49v6Op007074 for ; Tue, 4 Dec 2007 01:57:09 -0800 Received: from luba (pb-d-128-141-57-222.cern.ch [128.141.57.222]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by chatsubo.ninsei.hu (Postfix) with ESMTP id 6656F7A92 for ; Tue, 4 Dec 2007 10:56:37 +0100 (CET) Received: by luba (Postfix, from userid 32266) id 4581210A958; Tue, 4 Dec 2007 10:42:28 +0100 (CET) Date: Tue, 4 Dec 2007 10:42:29 +0100 From: KELEMEN Peter To: xfs@oss.sgi.com Subject: Re: 2.6.24-rc3 oopses while mounting fs Message-ID: <20071204094229.GC2074@luba> Mail-Followup-To: xfs@oss.sgi.com References: <20071128134523.GF7793@luba> <474E003A.7020000@sgi.com> <20071130223154.GB13589@luba> <47537709.9040406@sgi.com> <20071203220200.GC13667@luba> <47549B1A.4070508@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <47549B1A.4070508@sgi.com> Organization: CERN European Laboratory for Particle Physics, Switzerland X-GPG-KeyID: 1024D/9FF0CABE 2004-04-03 X-GPG-Fingerprint: 6C9E 5917 3B06 E4EE 6356 7BF0 8F3E CAB6 9FF0 CABE X-Comment: Personal opinion. Paragraphs might have been reformatted. X-Copyright: Forwarding or publishing without permission is prohibited. X-Accept-Language: hu,en User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: ClamAV 0.91.2/4991/Tue Dec 4 00:18:25 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13853 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Peter.Kelemen@cern.ch Precedence: bulk X-list: xfs * Timothy Shimmin (tes@sgi.com) [20071204 11:11]: Timothy, Thanks for the recommendations. > Often it is simplest to save the log using the -C option to a > file. -C filename [...] The log can then be analysed in various > ways later. I did that (I played with it and did the same thing with dd(1), too). > If you want to save the filesystem away for possible metadata > debugging later, then xfs_metadump is your friend. I'll check this out. I watched Barry implement the thing but we were stuck in the past for a while with xfsprogs-2.6.x. Peter -- .+'''+. .+'''+. .+'''+. .+'''+. .+'' Kelemen Péter / \ / \ Peter.Kelemen@cern.ch .+' `+...+' `+...+' `+...+' `+...+' From owner-xfs@oss.sgi.com Tue Dec 4 18:11:01 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 04 Dec 2007 18:11:06 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id lB52AvuZ015172 for ; Tue, 4 Dec 2007 18:11:00 -0800 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA22820; Wed, 5 Dec 2007 13:11:03 +1100 Message-ID: <475608D8.4070402@sgi.com> Date: Wed, 05 Dec 2007 13:11:36 +1100 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.9 (X11/20071031) MIME-Version: 1.0 To: David Chinner CC: xfs-oss , xfs-dev Subject: Re: [Patch] xfs_lowbit64 broken on ia32 References: <20071203211620.GN115527101@sgi.com> In-Reply-To: <20071203211620.GN115527101@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/5001/Tue Dec 4 16:37:12 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13855 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs David Chinner wrote: > The recent change to the internals of xfs_lowbit64 broke it on > ia32 - the code treats the 64bit value as an unsigned long > which is only 32 bits on ia32 and hence throws away the high 32 > bits. 64 bit platforms are not affected. > > Tested with a userspace implementation comparing the original > code with the new code. > > Signed-off-by: Dave Chinner > --- > fs/xfs/xfs_bit.h | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > Index: 2.6.x-xfs-new/fs/xfs/xfs_bit.h > =================================================================== > --- 2.6.x-xfs-new.orig/fs/xfs/xfs_bit.h 2007-11-02 13:44:45.000000000 +1100 > +++ 2.6.x-xfs-new/fs/xfs/xfs_bit.h 2007-12-03 14:43:33.169851481 +1100 > @@ -68,8 +68,8 @@ static inline int xfs_lowbit32(__uint32_ > /* Get low bit set out of 64-bit argument, -1 if none set */ > static inline int xfs_lowbit64(__uint64_t v) > { > - unsigned long t = v; > - return (v) ? find_first_bit(&t, 64) : -1; > + unsigned long long t = v; Why create a local copy? Why not just pass v into find_first_bit()? > + return (v) ? find_first_bit((unsigned long *)&t, 64) : -1; > } > > /* Return whether bitmap is empty (1 == empty) */ > > > From owner-xfs@oss.sgi.com Tue Dec 4 18:31:31 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 04 Dec 2007 18:31:35 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id lB52VOVU018143 for ; Tue, 4 Dec 2007 18:31:30 -0800 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA23338; Wed, 5 Dec 2007 13:31:30 +1100 Message-ID: <47560DA4.4090605@sgi.com> Date: Wed, 05 Dec 2007 13:32:04 +1100 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.9 (X11/20071031) MIME-Version: 1.0 To: David Chinner CC: xfs-dev , xfs-oss Subject: Re: Fix xfs_ichgtime mainline breakage. References: <20071203074345.GW119954183@sgi.com> In-Reply-To: <20071203074345.GW119954183@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/5001/Tue Dec 4 16:37:12 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13856 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs Looks good Dave. Thanks for catching that. David Chinner wrote: > Folks, > > Just noticed with the mainline merge (2.6.24-rc3) to xfs-dev that > xfs_ichgtime + xfs_ichgtime_fast are broken. > > if (!(inode->i_state & I_SYNC)) > mark_inode_dirty_sync(inode); > > that check used to be against I_LOCK, which was arguably broken, > but this one will mean newly created files are not put on the dirty > list and hence not written back by pdflush. > > Patch to fix this attached. > > Cheers, > > Dave. From owner-xfs@oss.sgi.com Tue Dec 4 19:21:29 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 04 Dec 2007 19:21:33 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id lB53LPY8024338 for ; Tue, 4 Dec 2007 19:21:28 -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 OAA24352; Wed, 5 Dec 2007 14:21:30 +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 lB53LTdD131726475; Wed, 5 Dec 2007 14:21:29 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id lB53LSGT132723036; Wed, 5 Dec 2007 14:21:28 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Wed, 5 Dec 2007 14:21:28 +1100 From: David Chinner To: Lachlan McIlroy Cc: David Chinner , xfs-oss , xfs-dev Subject: Re: [Patch] xfs_lowbit64 broken on ia32 Message-ID: <20071205032128.GB115527101@sgi.com> References: <20071203211620.GN115527101@sgi.com> <475608D8.4070402@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <475608D8.4070402@sgi.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/5003/Tue Dec 4 18:25:48 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13857 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Wed, Dec 05, 2007 at 01:11:36PM +1100, Lachlan McIlroy wrote: > David Chinner wrote: > >The recent change to the internals of xfs_lowbit64 broke it on > >ia32 - the code treats the 64bit value as an unsigned long > >which is only 32 bits on ia32 and hence throws away the high 32 > >bits. 64 bit platforms are not affected. > > > >Tested with a userspace implementation comparing the original > >code with the new code. > > > >Signed-off-by: Dave Chinner > >--- > > fs/xfs/xfs_bit.h | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > >Index: 2.6.x-xfs-new/fs/xfs/xfs_bit.h > >=================================================================== > >--- 2.6.x-xfs-new.orig/fs/xfs/xfs_bit.h 2007-11-02 > >13:44:45.000000000 +1100 > >+++ 2.6.x-xfs-new/fs/xfs/xfs_bit.h 2007-12-03 14:43:33.169851481 +1100 > >@@ -68,8 +68,8 @@ static inline int xfs_lowbit32(__uint32_ > > /* Get low bit set out of 64-bit argument, -1 if none set */ > > static inline int xfs_lowbit64(__uint64_t v) > > { > >- unsigned long t = v; > >- return (v) ? find_first_bit(&t, 64) : -1; > >+ unsigned long long t = v; > Why create a local copy? Why not just pass v into find_first_bit()? Because I thought that taking the address of a function parameter was a big no-no because the result is undefined (i.e. platform and compiler dependent)? Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Tue Dec 4 21:36:26 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 04 Dec 2007 21:36:54 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id lB55aMrf013615 for ; Tue, 4 Dec 2007 21:36:24 -0800 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA26779; Wed, 5 Dec 2007 16:36:27 +1100 Message-ID: <475638FD.9090208@sgi.com> Date: Wed, 05 Dec 2007 16:37:01 +1100 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.9 (X11/20071031) MIME-Version: 1.0 To: David Chinner CC: xfs-oss , xfs-dev Subject: Re: [Patch] xfs_lowbit64 broken on ia32 References: <20071203211620.GN115527101@sgi.com> <475608D8.4070402@sgi.com> <20071205032128.GB115527101@sgi.com> In-Reply-To: <20071205032128.GB115527101@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/5004/Tue Dec 4 19:43:23 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13858 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs David Chinner wrote: > On Wed, Dec 05, 2007 at 01:11:36PM +1100, Lachlan McIlroy wrote: >> David Chinner wrote: >>> The recent change to the internals of xfs_lowbit64 broke it on >>> ia32 - the code treats the 64bit value as an unsigned long >>> which is only 32 bits on ia32 and hence throws away the high 32 >>> bits. 64 bit platforms are not affected. >>> >>> Tested with a userspace implementation comparing the original >>> code with the new code. >>> >>> Signed-off-by: Dave Chinner >>> --- >>> fs/xfs/xfs_bit.h | 4 ++-- >>> 1 file changed, 2 insertions(+), 2 deletions(-) >>> >>> Index: 2.6.x-xfs-new/fs/xfs/xfs_bit.h >>> =================================================================== >>> --- 2.6.x-xfs-new.orig/fs/xfs/xfs_bit.h 2007-11-02 >>> 13:44:45.000000000 +1100 >>> +++ 2.6.x-xfs-new/fs/xfs/xfs_bit.h 2007-12-03 14:43:33.169851481 +1100 >>> @@ -68,8 +68,8 @@ static inline int xfs_lowbit32(__uint32_ >>> /* Get low bit set out of 64-bit argument, -1 if none set */ >>> static inline int xfs_lowbit64(__uint64_t v) >>> { >>> - unsigned long t = v; >>> - return (v) ? find_first_bit(&t, 64) : -1; >>> + unsigned long long t = v; >> Why create a local copy? Why not just pass v into find_first_bit()? > > Because I thought that taking the address of a function parameter > was a big no-no because the result is undefined (i.e. platform and > compiler dependent)? > Really? Didn't occur to me but then I can't say for sure I've ever used the address of an argument. If we need a local copy then why not use __unit64_t instead of unsigned long long? From owner-xfs@oss.sgi.com Tue Dec 4 21:44:23 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 04 Dec 2007 21:44:37 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id lB55iG6T015068 for ; Tue, 4 Dec 2007 21:44:21 -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 QAA26957; Wed, 5 Dec 2007 16:44:22 +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 lB55iMdD130080993; Wed, 5 Dec 2007 16:44:22 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id lB55iLXb132842042; Wed, 5 Dec 2007 16:44:21 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Wed, 5 Dec 2007 16:44:21 +1100 From: David Chinner To: Lachlan McIlroy Cc: David Chinner , xfs-oss , xfs-dev Subject: Re: [Patch] xfs_lowbit64 broken on ia32 Message-ID: <20071205054421.GD115527101@sgi.com> References: <20071203211620.GN115527101@sgi.com> <475608D8.4070402@sgi.com> <20071205032128.GB115527101@sgi.com> <475638FD.9090208@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <475638FD.9090208@sgi.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/5004/Tue Dec 4 19:43:23 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13859 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Wed, Dec 05, 2007 at 04:37:01PM +1100, Lachlan McIlroy wrote: > David Chinner wrote: > >On Wed, Dec 05, 2007 at 01:11:36PM +1100, Lachlan McIlroy wrote: > >>David Chinner wrote: > >>>The recent change to the internals of xfs_lowbit64 broke it on > >>>ia32 - the code treats the 64bit value as an unsigned long > >>>which is only 32 bits on ia32 and hence throws away the high 32 > >>>bits. 64 bit platforms are not affected. > >>> > >>>Tested with a userspace implementation comparing the original > >>>code with the new code. > >>> > >>>Signed-off-by: Dave Chinner > >>>--- > >>>fs/xfs/xfs_bit.h | 4 ++-- > >>>1 file changed, 2 insertions(+), 2 deletions(-) > >>> > >>>Index: 2.6.x-xfs-new/fs/xfs/xfs_bit.h > >>>=================================================================== > >>>--- 2.6.x-xfs-new.orig/fs/xfs/xfs_bit.h 2007-11-02 > >>>13:44:45.000000000 +1100 > >>>+++ 2.6.x-xfs-new/fs/xfs/xfs_bit.h 2007-12-03 14:43:33.169851481 +1100 > >>>@@ -68,8 +68,8 @@ static inline int xfs_lowbit32(__uint32_ > >>>/* Get low bit set out of 64-bit argument, -1 if none set */ > >>>static inline int xfs_lowbit64(__uint64_t v) > >>>{ > >>>- unsigned long t = v; > >>>- return (v) ? find_first_bit(&t, 64) : -1; > >>>+ unsigned long long t = v; > >>Why create a local copy? Why not just pass v into find_first_bit()? > > > >Because I thought that taking the address of a function parameter > >was a big no-no because the result is undefined (i.e. platform and > >compiler dependent)? > > > > Really? Didn't occur to me but then I can't say for sure I've ever > used the address of an argument. If we need a local copy then why > not use __unit64_t instead of unsigned long long? Whatever. They are both the same. xfs/xfs_types.h 41 typedef unsigned long long int __uint64_t; Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Tue Dec 4 21:46:57 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 04 Dec 2007 21:47:16 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id lB55kqRF015590 for ; Tue, 4 Dec 2007 21:46:55 -0800 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA27144; Wed, 5 Dec 2007 16:46:58 +1100 Message-ID: <47563B73.2030403@sgi.com> Date: Wed, 05 Dec 2007 16:47:31 +1100 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.9 (X11/20071031) MIME-Version: 1.0 To: lachlan@sgi.com CC: Timothy Shimmin , xfs@oss.sgi.com Subject: Re: 2.6.24-rc3 oopses while mounting fs References: <20071128134523.GF7793@luba> <474E003A.7020000@sgi.com> <20071130223154.GB13589@luba> <47537709.9040406@sgi.com> <20071203220200.GC13667@luba> <47549B1A.4070508@sgi.com> <4754FCEC.30906@sgi.com> In-Reply-To: <4754FCEC.30906@sgi.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/5004/Tue Dec 4 19:43:23 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13860 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs > ============================================================================ > > cycle: 154 version: 2 lsn: 154,5248 tail_lsn: 153,253056 > length of Log Record: 61440 prev offset: 5120 num ops: 303 > uuid: b02fc6bd-662f-40a5-8f0c-e260a881a3e7 format: little endian linux > h_size: 262144 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > extended-header: cycle: 154 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > extended-header: cycle: 154 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > extended-header: cycle: 154 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > extended-header: cycle: 154 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > extended-header: cycle: 154 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > extended-header: cycle: 154 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > extended-header: cycle: 154 > ---------------------------------------------------------------------------- > > Oper (0): tid: 5769cd60 len: 0 clientid: TRANS flags: START > ---------------------------------------------------------------------------- > > Oper (1): tid: 5769cd60 len: 16 clientid: TRANS flags: none > TRAN: type: STRAT_WRITE tid: 0 num_items: 5 > ---------------------------------------------------------------------------- > > Oper (2): tid: 5769cd60 len: 56 clientid: TRANS flags: none > INODE: #regs: 3 ino: 0x1400005c flags: 0x5 dsize: 16 > blkno: 610338736 len: 16 boff: 4096 > Oper (3): tid: 5769cd60 len: 96 clientid: TRANS flags: none > INODE CORE > magic 0x494e mode 0100600 version 1 format 2 > nlink 1 uid 14029 gid 1474 > atime 0x4716b870 mtime 0x4716bade ctime 0x4716bade > size 0x1ce00000 nblocks 0x1c840 extsize 0x0 nextents 0x1 > naextents 0x0 forkoff 0 dmevmask 0x0 dmstate 0x0 > flags 0x0 gen 0x4 > Oper (4): tid: 5769cd60 len: 16 clientid: TRANS flags: none > EXTENTS inode data > ---------------------------------------------------------------------------- Another interesting point is that the transaction id has changed between these operations from 5769cd60 to 5769cf18. It should stay the same. We may be reading old log data. > > Oper (5): tid: 5769cf18 len: 24 clientid: TRANS flags: none > BUF: #regs: 2 start blkno: 610338561 (0x24610701) len: 1 bmap size: > 1 flags: 0x0 > Oper (6): tid: 5769cf18 len: 128 clientid: TRANS flags: none > AGF Buffer: XAGF > ver: 1 seq#: 5 len: 15258464 > root BNO: 1 CNT: 2 > level BNO: 1 CNT: 1 > 1st: 0 last: 3 cnt: 4 freeblks: 2491090 longest: 581471 > ---------------------------------------------------------------------------- > > Oper (7): tid: 5769cf18 len: 28 clientid: TRANS flags: none > BUF: #regs: 2 start blkno: 610338568 (0x24610708) len: 8 bmap size: > 2 flags: 0x0 > Oper (8): tid: 5769cf18 len: 128 clientid: TRANS flags: none > BUF DATA > ---------------------------------------------------------------------------- > From owner-xfs@oss.sgi.com Tue Dec 4 22:36:08 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 04 Dec 2007 22:36:26 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id lB56a3HG022599 for ; Tue, 4 Dec 2007 22:36:05 -0800 Received: from timothy-shimmins-power-mac-g5.local (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA28209; Wed, 5 Dec 2007 17:36:09 +1100 Message-ID: <47564761.9070805@sgi.com> Date: Wed, 05 Dec 2007 17:38:25 +1100 From: Timothy Shimmin User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: lachlan@sgi.com CC: xfs@oss.sgi.com Subject: Re: 2.6.24-rc3 oopses while mounting fs References: <20071128134523.GF7793@luba> <474E003A.7020000@sgi.com> <20071130223154.GB13589@luba> <47537709.9040406@sgi.com> <20071203220200.GC13667@luba> <47549B1A.4070508@sgi.com> <4754FCEC.30906@sgi.com> <47563B73.2030403@sgi.com> In-Reply-To: <47563B73.2030403@sgi.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/5004/Tue Dec 4 19:43:23 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13862 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs Lachlan, An aside... I think I see why we couldn't get "xfs_logprint -t" to work on a file (-f). > xfs_logprint -t -f ~/debug/sdc.xlg xfs_logprint: data device: 0xffffffffffffffff log device: 0xffffffffffffffff daddr: 0 length: 262144 XFS: Log inconsistent (didn't find previous header) XFS: failed to find log head xfs_logprint: failed to find head and tail, error: 5 The problem is that it is using the superblock to determine if it is version 1 or version 2 logs in order to find out the maximum size of the iclog (log record). And for -f there is no superblock to look at. The version number is, however, in the log record header. So when it looks in the undefined data it comes up with _not_ version 2, and so assumes to look back for the hdr to only 32K when it really needs to look back to 64k (for v2 it would limit at 256K). Hence, it can't find the magic# in the header. The debugging... ==================================================== Breakpoint 1, xlog_find_verify_log_record (log=0x607ffffffea96be0, start_blk=5312, last_blk=0x607ffffffea96bc0, extra_bblks=0) at xfs_log_recover.c:234 234 if (!(bp = xlog_get_bp(log, num_blks))) { (gdb) bt #0 xlog_find_verify_log_record (log=0x607ffffffea96be0, start_blk=5312, last_blk=0x607ffffffea96bc0, extra_bblks=0) at xfs_log_recover.c:234 #1 0x4000000000092020 in xlog_find_head (log=0x607ffffffea96be0, return_head_blk=0x607ffffffea96bd0) at xfs_log_recover.c:527 #2 0x4000000000094000 in xlog_find_tail (log=0x607ffffffea96be0, head_blk=0x607ffffffea96bd0, tail_blk=0x607ffffffea96bd8, readonly=0) at xfs_log_recover.c:616 #3 0x40000000000100a0 in xfs_log_print_trans (log=0x607ffffffea96be0, print_block_start=-1) at log_print_trans.c:49 #4 0x4000000000003600 in main (argc=, argv=) at logprint.c:240 (gdb) print *last_blk $1 = 5376 start_blk = 5312 last_blk = 5376 extra_bblks = 0 Goes from 5376..5312 looking for magic# at start of sector. Errors out if can't find one. Which is true since the next magic# is at 5248. logprint -d output: 4992 HEADER Cycle 154 tail 153:253056 len 61440 ops 105 5120 HEADER Cycle 154 tail 153:253056 len 61440 ops 344 5248 HEADER Cycle 154 tail 153:253056 len 61440 ops 303 <--- previous block 5376 HEADER Cycle 153 tail 153:253056 len 0 ops 0 <--- hdr [00000 - 05376] Cycle 0x0000009a New Cycle 0x00000099 5377 HEADER Cycle 153 tail 153:253056 len 0 ops 0 5378 HEADER Cycle 153 tail 153:253056 len 0 ops 0 So why is it using a start_blk of 5312? 522 num_scan_bblks = XLOG_REC_SHIFT(log); 523 if (head_blk >= num_scan_bblks) { 524 start_blk = head_blk - num_scan_bblks; /* don't read head_blk */ 525 526 /* start ptr at last block ptr before head_blk */ ->527 if ((error = xlog_find_verify_log_record(log, start_blk, 528 &head_blk, 0)) == -1) { #define XLOG_REC_SHIFT(log) \ BTOBB(1 << (XFS_SB_VERSION_HASLOGV2(&log->l_mp->m_sb) ? \ XLOG_MAX_RECORD_BSHIFT : XLOG_BIG_RECORD_BSHIFT)) #define XLOG_BIG_RECORD_BSHIFT 15 /* 32k == 1 << 15 */ #define XLOG_MAX_RECORD_BSHIFT 18 /* 256k == 1 << 18 */ Number of blocks between rec-hdrs from -d output: 5376-5248 = 128 BB Looks like it used 5312 = 5376 - num_scan_bblks => num_scan_bblks = 64 Yep (gdb) p num_scan_bblks $3 = 64 32K i.e. it thinks it has v1 logs (gdb) p *(log->l_mp) $9 = {m_sb = {sb_magicnum = 0, sb_blocksize = 0, sb_dblocks = 0, sb_rblocks = 0, sb_rextents = 0, sb_uuid = '\0' , sb_logstart = 2305843009213997776, sb_rootino = 6953557824646229696, sb_rbmino = 6953557824646229688, sb_rsumino = 6953557824646229680, sb_rextsize = 284472, sb_agblocks = 536870912, sb_agcount = 4281151176, sb_rbmblocks = 1619001343, sb_logblocks = 0, sb_versionnum = 0, sb_sectsize = 0, sb_inodesize = 38256, sb_inopblock = 4, sb_fname = "\000\000\000 H?\a\000\000\000\000 ", sb_blocklog = 0 '\0', etc... it is not set Okay, need to file a bug for this part so that -f can be useful here. It needs to be using a LR h_version number for this somehow. --Tim Lachlan McIlroy wrote: >> ============================================================================ >> >> cycle: 154 version: 2 lsn: 154,5248 tail_lsn: 153,253056 >> length of Log Record: 61440 prev offset: 5120 num ops: 303 >> uuid: b02fc6bd-662f-40a5-8f0c-e260a881a3e7 format: little endian linux >> h_size: 262144 >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> >> extended-header: cycle: 154 >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> >> extended-header: cycle: 154 >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> >> extended-header: cycle: 154 >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> >> extended-header: cycle: 154 >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> >> extended-header: cycle: 154 >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> >> extended-header: cycle: 154 >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> >> extended-header: cycle: 154 >> ---------------------------------------------------------------------------- >> >> Oper (0): tid: 5769cd60 len: 0 clientid: TRANS flags: START >> ---------------------------------------------------------------------------- >> >> Oper (1): tid: 5769cd60 len: 16 clientid: TRANS flags: none >> TRAN: type: STRAT_WRITE tid: 0 num_items: 5 >> ---------------------------------------------------------------------------- >> >> Oper (2): tid: 5769cd60 len: 56 clientid: TRANS flags: none >> INODE: #regs: 3 ino: 0x1400005c flags: 0x5 dsize: 16 >> blkno: 610338736 len: 16 boff: 4096 >> Oper (3): tid: 5769cd60 len: 96 clientid: TRANS flags: none >> INODE CORE >> magic 0x494e mode 0100600 version 1 format 2 >> nlink 1 uid 14029 gid 1474 >> atime 0x4716b870 mtime 0x4716bade ctime 0x4716bade >> size 0x1ce00000 nblocks 0x1c840 extsize 0x0 nextents 0x1 >> naextents 0x0 forkoff 0 dmevmask 0x0 dmstate 0x0 >> flags 0x0 gen 0x4 >> Oper (4): tid: 5769cd60 len: 16 clientid: TRANS flags: none >> EXTENTS inode data >> ---------------------------------------------------------------------------- > > > Another interesting point is that the transaction id has changed between > these operations from 5769cd60 to 5769cf18. It should stay the same. > We may be reading old log data. > >> >> Oper (5): tid: 5769cf18 len: 24 clientid: TRANS flags: none >> BUF: #regs: 2 start blkno: 610338561 (0x24610701) len: 1 bmap >> size: 1 flags: 0x0 >> Oper (6): tid: 5769cf18 len: 128 clientid: TRANS flags: none >> AGF Buffer: XAGF >> ver: 1 seq#: 5 len: 15258464 >> root BNO: 1 CNT: 2 >> level BNO: 1 CNT: 1 >> 1st: 0 last: 3 cnt: 4 freeblks: 2491090 longest: 581471 >> ---------------------------------------------------------------------------- >> >> Oper (7): tid: 5769cf18 len: 28 clientid: TRANS flags: none >> BUF: #regs: 2 start blkno: 610338568 (0x24610708) len: 8 bmap >> size: 2 flags: 0x0 >> Oper (8): tid: 5769cf18 len: 128 clientid: TRANS flags: none >> BUF DATA >> ---------------------------------------------------------------------------- >> From owner-xfs@oss.sgi.com Tue Dec 4 22:35:19 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 04 Dec 2007 22:35:51 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id lB56ZDcw022473 for ; Tue, 4 Dec 2007 22:35:18 -0800 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA28193; Wed, 5 Dec 2007 17:35:18 +1100 Message-ID: <475646C8.6070700@sgi.com> Date: Wed, 05 Dec 2007 17:35:52 +1100 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.9 (X11/20071031) MIME-Version: 1.0 To: David Chinner CC: xfs-oss , xfs-dev Subject: Re: [Patch] xfs_lowbit64 broken on ia32 References: <20071203211620.GN115527101@sgi.com> <475608D8.4070402@sgi.com> <20071205032128.GB115527101@sgi.com> <475638FD.9090208@sgi.com> <20071205054421.GD115527101@sgi.com> In-Reply-To: <20071205054421.GD115527101@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/5004/Tue Dec 4 19:43:23 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13861 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs David Chinner wrote: > On Wed, Dec 05, 2007 at 04:37:01PM +1100, Lachlan McIlroy wrote: >> David Chinner wrote: >>> On Wed, Dec 05, 2007 at 01:11:36PM +1100, Lachlan McIlroy wrote: >>>> David Chinner wrote: >>>>> The recent change to the internals of xfs_lowbit64 broke it on >>>>> ia32 - the code treats the 64bit value as an unsigned long >>>>> which is only 32 bits on ia32 and hence throws away the high 32 >>>>> bits. 64 bit platforms are not affected. >>>>> >>>>> Tested with a userspace implementation comparing the original >>>>> code with the new code. >>>>> >>>>> Signed-off-by: Dave Chinner >>>>> --- >>>>> fs/xfs/xfs_bit.h | 4 ++-- >>>>> 1 file changed, 2 insertions(+), 2 deletions(-) >>>>> >>>>> Index: 2.6.x-xfs-new/fs/xfs/xfs_bit.h >>>>> =================================================================== >>>>> --- 2.6.x-xfs-new.orig/fs/xfs/xfs_bit.h 2007-11-02 >>>>> 13:44:45.000000000 +1100 >>>>> +++ 2.6.x-xfs-new/fs/xfs/xfs_bit.h 2007-12-03 14:43:33.169851481 +1100 >>>>> @@ -68,8 +68,8 @@ static inline int xfs_lowbit32(__uint32_ >>>>> /* Get low bit set out of 64-bit argument, -1 if none set */ >>>>> static inline int xfs_lowbit64(__uint64_t v) >>>>> { >>>>> - unsigned long t = v; >>>>> - return (v) ? find_first_bit(&t, 64) : -1; >>>>> + unsigned long long t = v; >>>> Why create a local copy? Why not just pass v into find_first_bit()? >>> Because I thought that taking the address of a function parameter >>> was a big no-no because the result is undefined (i.e. platform and >>> compiler dependent)? >>> >> Really? Didn't occur to me but then I can't say for sure I've ever >> used the address of an argument. If we need a local copy then why >> not use __unit64_t instead of unsigned long long? > > Whatever. They are both the same. > > xfs/xfs_types.h 41 typedef unsigned long long int __uint64_t; > Figured they would be. Using the same type probably would have avoided the bug in the first place. Otherwise the change is good. From owner-xfs@oss.sgi.com Tue Dec 4 23:03:58 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 04 Dec 2007 23:04:09 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id lB573rkl027788 for ; Tue, 4 Dec 2007 23:03:56 -0800 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA28759; Wed, 5 Dec 2007 18:03:59 +1100 Message-ID: <47564D81.2040204@sgi.com> Date: Wed, 05 Dec 2007 18:04:33 +1100 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.9 (X11/20071031) MIME-Version: 1.0 To: Timothy Shimmin CC: xfs@oss.sgi.com Subject: Re: 2.6.24-rc3 oopses while mounting fs References: <20071128134523.GF7793@luba> <474E003A.7020000@sgi.com> <20071130223154.GB13589@luba> <47537709.9040406@sgi.com> <20071203220200.GC13667@luba> <47549B1A.4070508@sgi.com> <4754FCEC.30906@sgi.com> <47563B73.2030403@sgi.com> <47564761.9070805@sgi.com> In-Reply-To: <47564761.9070805@sgi.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/5007/Tue Dec 4 22:29:27 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13863 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs Thanks Tim. Timothy Shimmin wrote: > Lachlan, > > An aside... > > I think I see why we couldn't get "xfs_logprint -t" to work on a file (-f). > > xfs_logprint -t -f ~/debug/sdc.xlg > xfs_logprint: > data device: 0xffffffffffffffff > log device: 0xffffffffffffffff daddr: 0 length: 262144 > > XFS: Log inconsistent (didn't find previous header) > XFS: failed to find log head > xfs_logprint: failed to find head and tail, error: 5 > > The problem is that it is using the superblock to determine if it is > version 1 > or version 2 logs in order to find out the maximum size of the iclog > (log record). > And for -f there is no superblock to look at. The version number is, > however, in the > log record header. > So when it looks in the undefined data it comes up with _not_ version 2, > and so assumes to look back for the hdr to only 32K when it really needs > to look back to 64k (for v2 it would limit at 256K). > Hence, it can't find the magic# in the header. > > The debugging... > > ==================================================== > Breakpoint 1, xlog_find_verify_log_record (log=0x607ffffffea96be0, > start_blk=5312, last_blk=0x607ffffffea96bc0, extra_bblks=0) > at xfs_log_recover.c:234 > 234 if (!(bp = xlog_get_bp(log, num_blks))) { > (gdb) bt > #0 xlog_find_verify_log_record (log=0x607ffffffea96be0, start_blk=5312, > last_blk=0x607ffffffea96bc0, extra_bblks=0) at xfs_log_recover.c:234 > #1 0x4000000000092020 in xlog_find_head (log=0x607ffffffea96be0, > return_head_blk=0x607ffffffea96bd0) at xfs_log_recover.c:527 > #2 0x4000000000094000 in xlog_find_tail (log=0x607ffffffea96be0, > head_blk=0x607ffffffea96bd0, tail_blk=0x607ffffffea96bd8, readonly=0) > at xfs_log_recover.c:616 > #3 0x40000000000100a0 in xfs_log_print_trans (log=0x607ffffffea96be0, > print_block_start=-1) at log_print_trans.c:49 > #4 0x4000000000003600 in main (argc=, argv= optimized out>) at logprint.c:240 > > (gdb) print *last_blk > $1 = 5376 > > start_blk = 5312 > last_blk = 5376 > extra_bblks = 0 > > Goes from 5376..5312 looking for magic# at start of sector. > Errors out if can't find one. > Which is true since the next magic# is at 5248. > > logprint -d output: > 4992 HEADER Cycle 154 tail 153:253056 len 61440 ops 105 > 5120 HEADER Cycle 154 tail 153:253056 len 61440 ops 344 > 5248 HEADER Cycle 154 tail 153:253056 len 61440 ops 303 <--- > previous block > 5376 HEADER Cycle 153 tail 153:253056 len 0 ops 0 <--- hdr > [00000 - 05376] Cycle 0x0000009a New Cycle 0x00000099 > 5377 HEADER Cycle 153 tail 153:253056 len 0 ops 0 > 5378 HEADER Cycle 153 tail 153:253056 len 0 ops 0 > > So why is it using a start_blk of 5312? > > > 522 num_scan_bblks = XLOG_REC_SHIFT(log); > 523 if (head_blk >= num_scan_bblks) { > 524 start_blk = head_blk - num_scan_bblks; /* don't > read head_blk */ > 525 > 526 /* start ptr at last block ptr before head_blk */ > ->527 if ((error = xlog_find_verify_log_record(log, > start_blk, > 528 > &head_blk, 0)) == -1) { > > #define XLOG_REC_SHIFT(log) \ > BTOBB(1 << (XFS_SB_VERSION_HASLOGV2(&log->l_mp->m_sb) ? \ > XLOG_MAX_RECORD_BSHIFT : XLOG_BIG_RECORD_BSHIFT)) > > #define XLOG_BIG_RECORD_BSHIFT 15 /* 32k == 1 << 15 */ > #define XLOG_MAX_RECORD_BSHIFT 18 /* 256k == 1 << 18 */ > > Number of blocks between rec-hdrs from -d output: > 5376-5248 = 128 BB > > Looks like it used 5312 = 5376 - num_scan_bblks > => num_scan_bblks = 64 > > Yep > (gdb) p num_scan_bblks > $3 = 64 > 32K > i.e. it thinks it has v1 logs > > (gdb) p *(log->l_mp) > $9 = {m_sb = {sb_magicnum = 0, sb_blocksize = 0, sb_dblocks = 0, > sb_rblocks = 0, sb_rextents = 0, sb_uuid = '\0' , > sb_logstart = 2305843009213997776, sb_rootino = 6953557824646229696, > sb_rbmino = 6953557824646229688, sb_rsumino = 6953557824646229680, > sb_rextsize = 284472, sb_agblocks = 536870912, sb_agcount = > 4281151176, sb_rbmblocks = 1619001343, sb_logblocks = 0, sb_versionnum = 0, > sb_sectsize = 0, sb_inodesize = 38256, sb_inopblock = 4, sb_fname = > "\000\000\000 H?\a\000\000\000\000 ", sb_blocklog = 0 '\0', > etc... > it is not set > > Okay, need to file a bug for this part so that -f can be useful here. > It needs to be using a LR h_version number for this somehow. > > --Tim > > > Lachlan McIlroy wrote: >>> ============================================================================ >>> >>> cycle: 154 version: 2 lsn: 154,5248 tail_lsn: 153,253056 >>> length of Log Record: 61440 prev offset: 5120 num ops: 303 >>> uuid: b02fc6bd-662f-40a5-8f0c-e260a881a3e7 format: little endian linux >>> h_size: 262144 >>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> >>> extended-header: cycle: 154 >>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> >>> extended-header: cycle: 154 >>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> >>> extended-header: cycle: 154 >>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> >>> extended-header: cycle: 154 >>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> >>> extended-header: cycle: 154 >>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> >>> extended-header: cycle: 154 >>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> >>> extended-header: cycle: 154 >>> ---------------------------------------------------------------------------- >>> >>> Oper (0): tid: 5769cd60 len: 0 clientid: TRANS flags: START >>> ---------------------------------------------------------------------------- >>> >>> Oper (1): tid: 5769cd60 len: 16 clientid: TRANS flags: none >>> TRAN: type: STRAT_WRITE tid: 0 num_items: 5 >>> ---------------------------------------------------------------------------- >>> >>> Oper (2): tid: 5769cd60 len: 56 clientid: TRANS flags: none >>> INODE: #regs: 3 ino: 0x1400005c flags: 0x5 dsize: 16 >>> blkno: 610338736 len: 16 boff: 4096 >>> Oper (3): tid: 5769cd60 len: 96 clientid: TRANS flags: none >>> INODE CORE >>> magic 0x494e mode 0100600 version 1 format 2 >>> nlink 1 uid 14029 gid 1474 >>> atime 0x4716b870 mtime 0x4716bade ctime 0x4716bade >>> size 0x1ce00000 nblocks 0x1c840 extsize 0x0 nextents 0x1 >>> naextents 0x0 forkoff 0 dmevmask 0x0 dmstate 0x0 >>> flags 0x0 gen 0x4 >>> Oper (4): tid: 5769cd60 len: 16 clientid: TRANS flags: none >>> EXTENTS inode data >>> ---------------------------------------------------------------------------- >> >> >> >> Another interesting point is that the transaction id has changed between >> these operations from 5769cd60 to 5769cf18. It should stay the same. >> We may be reading old log data. >> >>> >>> Oper (5): tid: 5769cf18 len: 24 clientid: TRANS flags: none >>> BUF: #regs: 2 start blkno: 610338561 (0x24610701) len: 1 bmap >>> size: 1 flags: 0x0 >>> Oper (6): tid: 5769cf18 len: 128 clientid: TRANS flags: none >>> AGF Buffer: XAGF >>> ver: 1 seq#: 5 len: 15258464 >>> root BNO: 1 CNT: 2 >>> level BNO: 1 CNT: 1 >>> 1st: 0 last: 3 cnt: 4 freeblks: 2491090 longest: 581471 >>> ---------------------------------------------------------------------------- >>> >>> Oper (7): tid: 5769cf18 len: 28 clientid: TRANS flags: none >>> BUF: #regs: 2 start blkno: 610338568 (0x24610708) len: 8 bmap >>> size: 2 flags: 0x0 >>> Oper (8): tid: 5769cf18 len: 128 clientid: TRANS flags: none >>> BUF DATA >>> ---------------------------------------------------------------------------- >>> > > > From owner-xfs@oss.sgi.com Wed Dec 5 04:26:06 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 05 Dec 2007 04:26:16 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_50,J_CHICKENPOX_23, J_CHICKENPOX_24,J_CHICKENPOX_25,J_CHICKENPOX_27,J_CHICKENPOX_38, J_CHICKENPOX_45 autolearn=no version=3.3.0-r574664 Received: from yergi.telenet-ops.be (yergi.telenet-ops.be [195.130.132.36]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id lB5CQ4OR010596 for ; Wed, 5 Dec 2007 04:26:06 -0800 Received: from astra.telenet-ops.be (unknown [195.130.132.58]) by yergi.telenet-ops.be (Postfix) with ESMTP id EA2BF5CA424 for ; Wed, 5 Dec 2007 13:16:00 +0100 (CET) Received: from localhost (localhost.localdomain [127.0.0.1]) by astra.telenet-ops.be (Postfix) with SMTP id 6AEBC38103 for ; Wed, 5 Dec 2007 13:15:55 +0100 (CET) Received: from [81.164.41.199] (d51A429C7.access.telenet.be [81.164.41.199]) by astra.telenet-ops.be (Postfix) with ESMTP id C9F26380F4 for ; Wed, 5 Dec 2007 13:15:52 +0100 (CET) Message-ID: <475696D3.60007@pandora.be> Date: Wed, 05 Dec 2007 13:17:23 +0100 From: Denis Wegge User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: xfs@oss.sgi.com Subject: XFS unable to mount, recover data Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/5011/Wed Dec 5 01:42:23 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13864 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: denis_wegge@pandora.be Precedence: bulk X-list: xfs Hello I am having trouble with the XFS filesystem on a 320GB Western Digital SATA harddisk. For no obvious reason the partition can no longer be mounted. The following error occurs: knoppix@Knoppix:~$ sudo mount /dev/sda1 /mnt/sda1 mount: /dev/sda1: can't read superblock I tried to repair the filesystem with xfs_repair, but that didn't work. knoppix@Knoppix:~$ sudo xfs_repair /dev/sda1 Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... xfs_repair: read failed: Input/output error I would like to recover the data on that disk. Unfortunately there isn't enough space on any other disk to copy the partition to. I tried to copy it partially with dd, but the image wouldn't mount. Is there any way to recover the data on the partition? The SMART info of the disk doesn't look very good either. Below you can find the following information: - dmesg messages after the failed mount - the output of xfs_repair -n - some outputs of a check for bad blocks - SMART information (with errors!) dmesg: ===================================================================== XFS mounting filesystem sda1 ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 ata3.00: (BMDMA stat 0x20) ata3.00: tag 0 cmd 0x25 Emask 0x9 stat 0x51 err 0x40 (media error) ata3: EH complete ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 ata3.00: (BMDMA stat 0x20) ata3.00: tag 0 cmd 0x25 Emask 0x9 stat 0x51 err 0x40 (media error) ata3: EH complete ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 ata3.00: (BMDMA stat 0x20) ata3.00: tag 0 cmd 0x25 Emask 0x9 stat 0x51 err 0x40 (media error) ata3: EH complete ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 ata3.00: (BMDMA stat 0x20) ata3.00: tag 0 cmd 0x25 Emask 0x9 stat 0x51 err 0x40 (media error) ata3: EH complete ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 ata3.00: (BMDMA stat 0x20) ata3.00: tag 0 cmd 0x25 Emask 0x9 stat 0x51 err 0x40 (media error) ata3: EH complete ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 ata3.00: (BMDMA stat 0x20) ata3.00: tag 0 cmd 0x25 Emask 0x9 stat 0x51 err 0x40 (media error) sd 2:0:0:0: SCSI error: return code = 0x08000002 sda: Current: sense key=0x3 ASC=0x11 ASCQ=0x4 end_request: I/O error, dev sda, sector 312632262 ata3: EH complete I/O error in filesystem ("sda1") meta-data dev sda1 block 0x12a26387 ("xlog_bread") error 5 buf count 512 XFS: failed to find log head XFS: log mount/recovery failed: error 5 XFS: log mount failed xfs_repair -n ===================================================================== knoppix@Knoppix:~$ sudo xfs_repair -n /dev/sda1 Phase 1 - find and verify superblock... Phase 2 - using internal log - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan (but don't 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... - 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 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem starting at / ... - traversal finished ... - traversing all unattached subtrees ... - traversals finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify link counts... No modify flag set, skipping filesystem flush and exiting. badblocks ===================================================================== knoppix@0[knoppix]$ sudo badblocks -v /dev/sda1 10000000 Checking blocks 0 to 10000000 Checking for bad blocks (read-only test): done Pass completed, 0 bad blocks found. knoppix@0[knoppix]$ sudo badblocks -v /dev/sda1 299879969 299879649 Checking blocks 299879649 to 299879969 Checking for bad blocks (read-only test): 299879649879649/ done Pass completed, 12 bad blocks found. knoppix@0[knoppix]$ sudo badblocks -v /dev/sda1 300013300 300013113 Checking blocks 300013113 to 300013300 Checking for bad blocks (read-only test): 300013113013113/ done Pass completed, 15 bad blocks found. knoppix@3[knoppix]$ sudo badblocks -v /dev/sda1 312568641 310000000 Checking blocks 310000000 to 312568641 Checking for bad blocks (read-only test): done 641 Pass completed, 0 bad blocks found. SMART ===================================================================== denis@athena64:~$ sudo smartctl -a /dev/sda smartctl version 5.37 [i686-pc-linux-gnu] Copyright (C) 2002-6 Bruce Allen Home page is http://smartmontools.sourceforge.net/ === START OF INFORMATION SECTION === Model Family: Western Digital Caviar SE16 family Device Model: WDC WD3200KS-00PFB0 Serial Number: WD-WCAPD1467148 Firmware Version: 21.00M21 User Capacity: 320,072,933,376 bytes Device is: In smartctl database [for details use: -P show] ATA Version is: 7 ATA Standard is: Exact ATA specification draft version not indicated Local Time is: Wed Dec 5 13:00:40 2007 CET SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: FAILED! Drive failure expected in less than 24 hours. SAVE ALL DATA. See vendor-specific Attribute list for failed Attributes. General SMART Values: Offline data collection status: (0x84) Offline data collection activity was suspended by an interrupting command from host. Auto Offline Data Collection: Enabled. Self-test execution status: ( 73) The previous self-test completed having a test element that failed and the test element that failed is not known. Total time to complete Offline data collection: (9600) seconds. Offline data collection capabilities: (0x7b) SMART execute Offline immediate. Auto Offline data collection on/off support. Suspend Offline collection upon new command. Offline surface scan supported. Self-test supported. Conveyance Self-test supported. Selective Self-test supported. SMART capabilities: (0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability: (0x01) Error logging supported. General Purpose Logging supported. Short self-test routine recommended polling time: ( 2) minutes. Extended self-test routine recommended polling time: ( 111) minutes. Conveyance self-test routine recommended polling time: ( 6) minutes. SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 200 200 051 Pre-fail Always - 0 3 Spin_Up_Time 0x0003 239 223 021 Pre-fail Always - 3041 4 Start_Stop_Count 0x0032 099 099 000 Old_age Always - 1142 5 Reallocated_Sector_Ct 0x0033 104 104 140 Pre-fail Always FAILING_NOW 763 7 Seek_Error_Rate 0x000f 200 200 051 Pre-fail Always - 0 9 Power_On_Hours 0x0032 095 095 000 Old_age Always - 4326 10 Spin_Retry_Count 0x0013 100 100 051 Pre-fail Always - 0 11 Calibration_Retry_Count 0x0013 100 100 051 Pre-fail Always - 0 12 Power_Cycle_Count 0x0032 099 099 000 Old_age Always - 1139 194 Temperature_Celsius 0x0022 120 001 000 Old_age Always - 30 196 Reallocated_Event_Count 0x0032 001 001 000 Old_age Always - 763 197 Current_Pending_Sector 0x0012 200 187 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0010 200 190 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 0 200 Multi_Zone_Error_Rate 0x0009 001 001 051 Pre-fail Offline FAILING_NOW 55696 SMART Error Log Version: 1 ATA Error Count: 17663 (device log contains only the most recent five errors) CR = Command Register [HEX] FR = Features Register [HEX] SC = Sector Count Register [HEX] SN = Sector Number Register [HEX] CL = Cylinder Low Register [HEX] CH = Cylinder High Register [HEX] DH = Device/Head Register [HEX] DC = Device Command Register [HEX] ER = Error register [HEX] ST = Status register [HEX] Powered_Up_Time is measured from power on, and printed as DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes, SS=sec, and sss=millisec. It "wraps" after 49.710 days. Error 17663 occurred at disk power-on lifetime: 4323 hours (180 days + 3 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 51 01 ce 63 a2 e0 Error: UNC 1 sectors at LBA = 0x00a263ce = 10642382 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- 25 00 01 ce 63 a2 12 00 16:06:59.549 READ DMA EXT ec 00 00 ce 63 a2 00 00 16:06:59.549 IDENTIFY DEVICE 25 00 01 ce 63 a2 12 00 16:06:57.499 READ DMA EXT ec 00 00 ce 63 a2 00 00 16:06:57.499 IDENTIFY DEVICE 25 00 01 ce 63 a2 12 00 16:06:55.264 READ DMA EXT Error 17662 occurred at disk power-on lifetime: 4323 hours (180 days + 3 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 51 01 ce 63 a2 e0 Error: UNC 1 sectors at LBA = 0x00a263ce = 10642382 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- 25 00 01 ce 63 a2 12 00 16:06:57.499 READ DMA EXT ec 00 00 ce 63 a2 00 00 16:06:57.499 IDENTIFY DEVICE 25 00 01 ce 63 a2 12 00 16:06:55.264 READ DMA EXT ec 00 00 ce 63 a2 00 00 16:06:55.264 IDENTIFY DEVICE 25 00 01 ce 63 a2 12 00 16:06:53.212 READ DMA EXT Error 17661 occurred at disk power-on lifetime: 4323 hours (180 days + 3 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 51 01 ce 63 a2 e0 Error: UNC 1 sectors at LBA = 0x00a263ce = 10642382 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- 25 00 01 ce 63 a2 12 00 16:06:55.264 READ DMA EXT ec 00 00 ce 63 a2 00 00 16:06:55.264 IDENTIFY DEVICE 25 00 01 ce 63 a2 12 00 16:06:53.212 READ DMA EXT ec 00 00 ce 63 a2 00 00 16:06:53.212 IDENTIFY DEVICE 25 00 01 ce 63 a2 12 00 16:06:51.165 READ DMA EXT Error 17660 occurred at disk power-on lifetime: 4323 hours (180 days + 3 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 51 01 ce 63 a2 e0 Error: UNC 1 sectors at LBA = 0x00a263ce = 10642382 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- 25 00 01 ce 63 a2 12 00 16:06:53.212 READ DMA EXT ec 00 00 ce 63 a2 00 00 16:06:53.212 IDENTIFY DEVICE 25 00 01 ce 63 a2 12 00 16:06:51.165 READ DMA EXT ec 00 00 ce 63 a2 00 00 16:06:51.165 IDENTIFY DEVICE 25 00 01 ce 63 a2 12 00 16:06:49.280 READ DMA EXT Error 17659 occurred at disk power-on lifetime: 4323 hours (180 days + 3 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 51 01 ce 63 a2 e0 Error: UNC 1 sectors at LBA = 0x00a263ce = 10642382 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- 25 00 01 ce 63 a2 12 00 16:06:51.165 READ DMA EXT ec 00 00 ce 63 a2 00 00 16:06:51.165 IDENTIFY DEVICE 25 00 01 ce 63 a2 12 00 16:06:49.280 READ DMA EXT 25 00 01 be 63 a2 12 00 16:06:49.280 READ DMA EXT 25 00 01 de 63 a2 12 00 16:06:49.264 READ DMA EXT SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Extended offline Completed: unknown failure 90% 4324 - # 2 Conveyance offline Completed: unknown failure 90% 4324 - # 3 Short offline Completed: unknown failure 90% 4323 - # 4 Extended offline Completed: read failure 90% 53 158966062 SMART Selective self-test log data structure revision number 1 SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS 1 0 0 Not_testing 2 0 0 Not_testing 3 0 0 Not_testing 4 0 0 Not_testing 5 0 0 Not_testing Selective self-test flags (0x0): After scanning selected spans, do NOT read-scan remainder of disk. If Selective self-test is pending on power-up, resume after 0 minute delay. From owner-xfs@oss.sgi.com Wed Dec 5 04:46:58 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 05 Dec 2007 04:47:01 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.5 required=5.0 tests=AWL,BAYES_50,SPF_HELO_PASS autolearn=ham version=3.3.0-r574664 Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id lB5Ckt75013901 for ; Wed, 5 Dec 2007 04:46:58 -0800 Received: by lucidpixels.com (Postfix, from userid 1001) id C54681C00023F; Wed, 5 Dec 2007 07:47:05 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id C34884019AA0; Wed, 5 Dec 2007 07:47:05 -0500 (EST) Date: Wed, 5 Dec 2007 07:47:05 -0500 (EST) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: Denis Wegge cc: xfs@oss.sgi.com Subject: Re: XFS unable to mount, recover data In-Reply-To: <475696D3.60007@pandora.be> Message-ID: References: <475696D3.60007@pandora.be> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.91.2/5011/Wed Dec 5 01:42:23 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13865 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs On Wed, 5 Dec 2007, Denis Wegge wrote: > Hello > > I am having trouble with the XFS filesystem on a 320GB Western Digital > SATA harddisk. For no obvious reason the partition can no longer be > mounted. The following error occurs: > > knoppix@Knoppix:~$ sudo mount /dev/sda1 /mnt/sda1 > mount: /dev/sda1: can't read superblock Looks like your disk is dying or dead from your logs. You can try putting it in a plastic airtight bag then put it in the freezer and try again but otherwise if that does not work, its time for the trash bin (after you try) a dd and overwrite the disk but with that many bad sectors it looks like it has really gone south. Insert new disk, restore from backup. Justin. From owner-xfs@oss.sgi.com Wed Dec 5 05:20:51 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 05 Dec 2007 05:20:56 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from relay.sgi.com (relay1.corp.sgi.com [192.26.58.214]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id lB5DKoKN021684 for ; Wed, 5 Dec 2007 05:20:51 -0800 Received: from mtv-amer002e--3.americas.sgi.com (unknown [192.26.64.114]) by relay1.corp.sgi.com (Postfix) with ESMTP id 006A68F805F for ; Wed, 5 Dec 2007 05:01:27 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Patch] xfs_lowbit64 broken on ia32 Date: Wed, 5 Dec 2007 04:14:02 -0800 Message-ID: In-Reply-To: <20071205032128.GB115527101@sgi.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Patch] xfs_lowbit64 broken on ia32 Thread-Index: Acg27iE7ZjejYK+FTOKNqLQattWgwQASYgFA From: "Alex Elder" To: "David Chinner" , "Lachlan Mcllroy" Cc: "xfs-oss" , "xfs-dev" X-Virus-Scanned: ClamAV 0.91.2/5011/Wed Dec 5 01:42:23 2007 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id lB5DKpKN021689 X-archive-position: 13866 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: aelder@sgi.com Precedence: bulk X-list: xfs David Chinner wrote: . . . > > >Index: 2.6.x-xfs-new/fs/xfs/xfs_bit.h > > >=================================================================== > > >--- 2.6.x-xfs-new.orig/fs/xfs/xfs_bit.h 2007-11-02 > > >13:44:45.000000000 +1100 > > >+++ 2.6.x-xfs-new/fs/xfs/xfs_bit.h 2007-12-03 > 14:43:33.169851481 +1100 > > >@@ -68,8 +68,8 @@ static inline int xfs_lowbit32(__uint32_ > > > /* Get low bit set out of 64-bit argument, -1 if none set */ > > > static inline int xfs_lowbit64(__uint64_t v) > > > { > > >- unsigned long t = v; > > >- return (v) ? find_first_bit(&t, 64) : -1; > > >+ unsigned long long t = v; > > Why create a local copy? Why not just pass v into find_first_bit()? > > Because I thought that taking the address of a function parameter > was a big no-no because the result is undefined (i.e. platform and > compiler dependent)? I've never heard of this, and it's incorrect--at least with respect to standard C. (But that's not to say in practice some compiler does it wrong.) Unless it's a real (details known) problem you shouldn't try to work around it. -Alex From owner-xfs@oss.sgi.com Wed Dec 5 05:55:27 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 05 Dec 2007 05:55:30 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.0-r574664 Received: from poptart.bithose.com (poptart.bithose.com [24.97.26.52]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id lB5DtPFJ001538 for ; Wed, 5 Dec 2007 05:55:26 -0800 Received: from poptart.bithose.com (localhost [127.0.0.1]) by poptart.bithose.com (8.12.10/8.12.10) with ESMTP id lB5DiVbO113486 for ; Wed, 5 Dec 2007 08:44:31 -0500 (EST) Received: from localhost (jakari@localhost) by poptart.bithose.com (8.12.10/8.12.10/Submit) with ESMTP id lB5DiVuB113379 for ; Wed, 5 Dec 2007 08:44:31 -0500 (EST) X-Authentication-Warning: poptart.bithose.com: jakari owned process doing -bs Date: Wed, 5 Dec 2007 08:44:31 -0500 (EST) From: Jameel Akari To: xfs-oss Subject: Which (lib)acl for 2.4.35? In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.91.2/5011/Wed Dec 5 01:42:23 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13867 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jakari@bithose.com Precedence: bulk X-list: xfs The story: We have some old RH7.3 machines that had been running the old 2.4.18_SGI_XFS1.1 from back in the day. Moving these to a new version of VMware requires upgrading to something more recent, and 2.4.35.3/SMP was built from the mainline. The situation: Seems to work, except ACL support is broken. I'm pretty sure this is due to the userland libraries and tools being so out of date (machine has 2.0.9-0). Which versions do I need, and where do I get them? CVS? I assume that all the other utilities (things in xfsprogs like mkfs, and xfsdump) will need similar updates as well. The immediate need is to get ACLs working, but it'd be nice if I can patch up the rest of it one last time until we can rebuild these VMs. -- Jameel Akari From owner-xfs@oss.sgi.com Wed Dec 5 16:02:10 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 05 Dec 2007 16:02:15 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id lB6025YB003564 for ; Wed, 5 Dec 2007 16:02:09 -0800 Received: from timothy-shimmins-power-mac-g5.local (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA23110; Thu, 6 Dec 2007 11:02:07 +1100 Message-ID: <47573C8A.1060902@sgi.com> Date: Thu, 06 Dec 2007 11:04:26 +1100 From: Timothy Shimmin User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Alex Elder CC: David Chinner , Lachlan Mcllroy , xfs-oss , xfs-dev Subject: Re: [Patch] xfs_lowbit64 broken on ia32 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/5014/Wed Dec 5 12:24:38 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13868 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs Alex Elder wrote: > David Chinner wrote: > . . . >>>> Index: 2.6.x-xfs-new/fs/xfs/xfs_bit.h >>>> =================================================================== >>>> --- 2.6.x-xfs-new.orig/fs/xfs/xfs_bit.h 2007-11-02 >>>> 13:44:45.000000000 +1100 >>>> +++ 2.6.x-xfs-new/fs/xfs/xfs_bit.h 2007-12-03 >> 14:43:33.169851481 +1100 >>>> @@ -68,8 +68,8 @@ static inline int xfs_lowbit32(__uint32_ >>>> /* Get low bit set out of 64-bit argument, -1 if none set */ >>>> static inline int xfs_lowbit64(__uint64_t v) >>>> { >>>> - unsigned long t = v; >>>> - return (v) ? find_first_bit(&t, 64) : -1; >>>> + unsigned long long t = v; >>> Why create a local copy? Why not just pass v into find_first_bit()? >> Because I thought that taking the address of a function parameter >> was a big no-no because the result is undefined (i.e. platform and >> compiler dependent)? > > I've never heard of this, and it's incorrect--at least with respect > to standard C. (But that's not to say in practice some compiler > does it wrong.) Unless it's a real (details known) problem you > shouldn't try to work around it. > > -Alex > I've never heard of that either. (Then again, I didn't know until recently that they changed C to allow "flexible array members" in C99 http://tigcc.ticalc.org/doc/gnuexts.html#SEC75) --Tim From owner-xfs@oss.sgi.com Wed Dec 5 17:55:55 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 05 Dec 2007 17:55:58 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id lB61tplE020993 for ; Wed, 5 Dec 2007 17:55:53 -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 MAA25549; Thu, 6 Dec 2007 12:55:55 +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 lB61tsdD134208948; Thu, 6 Dec 2007 12:55:55 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id lB61trEQ134099930; Thu, 6 Dec 2007 12:55:53 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Thu, 6 Dec 2007 12:55:53 +1100 From: David Chinner To: Alex Elder Cc: David Chinner , Lachlan Mcllroy , xfs-oss , xfs-dev Subject: Re: [Patch] xfs_lowbit64 broken on ia32 Message-ID: <20071206015553.GI115527101@sgi.com> References: <20071205032128.GB115527101@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/5015/Wed Dec 5 14:49:07 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13869 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Wed, Dec 05, 2007 at 04:14:02AM -0800, Alex Elder wrote: > David Chinner wrote: > . . . > > > >Index: 2.6.x-xfs-new/fs/xfs/xfs_bit.h > > > >=================================================================== > > > >--- 2.6.x-xfs-new.orig/fs/xfs/xfs_bit.h 2007-11-02 > > > >13:44:45.000000000 +1100 > > > >+++ 2.6.x-xfs-new/fs/xfs/xfs_bit.h 2007-12-03 > > 14:43:33.169851481 +1100 > > > >@@ -68,8 +68,8 @@ static inline int xfs_lowbit32(__uint32_ > > > > /* Get low bit set out of 64-bit argument, -1 if none set */ > > > > static inline int xfs_lowbit64(__uint64_t v) > > > > { > > > >- unsigned long t = v; > > > >- return (v) ? find_first_bit(&t, 64) : -1; > > > >+ unsigned long long t = v; > > > Why create a local copy? Why not just pass v into find_first_bit()? > > > > Because I thought that taking the address of a function parameter > > was a big no-no because the result is undefined (i.e. platform and > > compiler dependent)? > > I've never heard of this, and it's incorrect--at least with respect > to standard C. (But that's not to say in practice some compiler > does it wrong.) Unless it's a real (details known) problem you > shouldn't try to work around it. It caused me pain about 10 years ago with gcc 2.? and m68k platform, so I've just avoided doing it ever since. IMO, taking the address of a function parameter is also bad coding practice because it usually indicates a bug in the code. i.e. you should have passed a pointer to the function or you should be using a local variable rather than abusing the function parameter in strange ways. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Wed Dec 5 19:13:01 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 05 Dec 2007 19:13:06 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from relay.sgi.com (relay1.corp.sgi.com [192.26.58.214]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id lB63CxtL028406 for ; Wed, 5 Dec 2007 19:13:01 -0800 Received: from mtv-amer002e--3.americas.sgi.com (unknown [192.26.64.114]) by relay1.corp.sgi.com (Postfix) with ESMTP id 03A428F8065 for ; Wed, 5 Dec 2007 19:13:07 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Patch] xfs_lowbit64 broken on ia32 Date: Wed, 5 Dec 2007 18:15:41 -0800 Message-ID: In-Reply-To: <47573C8A.1060902@sgi.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Patch] xfs_lowbit64 broken on ia32 Thread-Index: Acg3m0KQDutovHuET567HbjpQWpf9AAEZBbg From: "Alex Elder" To: "Timothy Shimmin" Cc: "David Chinner" , "Lachlan Mcllroy" , "xfs-oss" , "xfs-dev" X-Virus-Scanned: ClamAV 0.91.2/5015/Wed Dec 5 14:49:07 2007 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id lB63D1tL028454 X-archive-position: 13870 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: aelder@sgi.com Precedence: bulk X-list: xfs Timothy Shimmin wrote: > I've never heard of that either. > (Then again, I didn't know until recently that they changed C > to allow "flexible array members" in C99 > http://tigcc.ticalc.org/doc/gnuexts.html#SEC75) Yeah there's lots of fancy new stuff in C99. Like variable length arrays, language-supported complex (sqrt(-1)) data types, C++ style initializations (mid-functions). And you can declare your loop index variable inside a for loop's parentheses (its scope is defined only for the loop). I'm not ready to use most of that; it has less value than some of the "old" extensions like (void *) and 0-length arrays. But some things are defined very precisely and that's good. -Alex From owner-xfs@oss.sgi.com Wed Dec 5 19:30:51 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 05 Dec 2007 19:30:54 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from relay.sgi.com (netops-testserver-3.corp.sgi.com [192.26.57.72]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id lB63UpAR031884 for ; Wed, 5 Dec 2007 19:30:51 -0800 Received: from mtv-amer002e--3.americas.sgi.com (unknown [192.26.64.114]) by netops-testserver-3.corp.sgi.com (Postfix) with ESMTP id 2D004908A9 for ; Wed, 5 Dec 2007 19:11:02 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Patch] xfs_lowbit64 broken on ia32 Date: Wed, 5 Dec 2007 18:22:04 -0800 Message-ID: In-Reply-To: <20071206015553.GI115527101@sgi.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Patch] xfs_lowbit64 broken on ia32 Thread-Index: Acg3qydYcgjRYNBUTfmQIM6OVt3regAA4bgg From: "Alex Elder" To: "David Chinner" Cc: "Lachlan Mcllroy" , "xfs-oss" , "xfs-dev" X-Virus-Scanned: ClamAV 0.91.2/5015/Wed Dec 5 14:49:07 2007 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id lB63UpAR031889 X-archive-position: 13871 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: aelder@sgi.com Precedence: bulk X-list: xfs David Chinner wrote: > On Wed, Dec 05, 2007 at 04:14:02AM -0800, Alex Elder wrote: > > David Chinner wrote: > > . . . > > > > >Index: 2.6.x-xfs-new/fs/xfs/xfs_bit.h > > > > > >=================================================================== > > > > >--- 2.6.x-xfs-new.orig/fs/xfs/xfs_bit.h 2007-11-02 > > > > >13:44:45.000000000 +1100 > > > > >+++ 2.6.x-xfs-new/fs/xfs/xfs_bit.h 2007-12-03 > > > 14:43:33.169851481 +1100 > > > > >@@ -68,8 +68,8 @@ static inline int xfs_lowbit32(__uint32_ > > > > > /* Get low bit set out of 64-bit argument, -1 if none set */ > > > > > static inline int xfs_lowbit64(__uint64_t v) > > > > > { > > > > >- unsigned long t = v; > > > > >- return (v) ? find_first_bit(&t, 64) : -1; > > > > >+ unsigned long long t = v; > > > > Why create a local copy? Why not just pass v into > find_first_bit()? > > > > > > Because I thought that taking the address of a function parameter > > > was a big no-no because the result is undefined (i.e. platform and > > > compiler dependent)? > > > > I've never heard of this, and it's incorrect--at least with respect > > to standard C. (But that's not to say in practice some compiler > > does it wrong.) Unless it's a real (details known) problem you > > shouldn't try to work around it. > > It caused me pain about 10 years ago with gcc 2.? and m68k platform, > so I've just avoided doing it ever since. I figured an experience like this was behind it. > IMO, taking the address of a function parameter is also bad coding > practice because it usually indicates a bug in the code. i.e. you > should have passed a pointer to the function or you should be using > a local variable rather than abusing the function parameter in strange > ways. I'm undecided. I agree there's something aesthetically wrong about it. Technically I'm not so sure. Maybe a longjmp() can lead bad things happening when you do this, I don't know. Anyway, this is pretty picky. The change was fine. -Alex From owner-xfs@oss.sgi.com Wed Dec 5 21:18:00 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 05 Dec 2007 21:18:04 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id lB65Hsqr015425 for ; Wed, 5 Dec 2007 21:17:59 -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 QAA00980; Thu, 6 Dec 2007 16:17:56 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 16346) id A822558FA1B8; Thu, 6 Dec 2007 16:17:56 +1100 (EST) To: sgi.bugs.xfs@engr.sgi.com Cc: xfs@oss.sgi.com Subject: TAKE 973377 - cleanup to use generic linux filldir causes nfsd hang Message-Id: <20071206051756.A822558FA1B8@chook.melbourne.sgi.com> Date: Thu, 6 Dec 2007 16:17:56 +1100 (EST) From: dgc@sgi.com (David Chinner) X-Virus-Scanned: ClamAV 0.91.2/5017/Wed Dec 5 20:09:47 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13872 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs revert to double-buffering readdir The current readdir implementation deadlocks on a btree buffers locks because nfsd calls back into ->lookup from the filldir callback. The only short-term fix for this is to revert to the old inefficient double-buffering scheme. Signed-off-by: Christoph Hellwig Date: Thu Dec 6 16:17:12 AEDT 2007 Workarea: chook.melbourne.sgi.com:/build/dgc/isms/2.6.x-xfs Inspected by: hch@lst.de The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:30201a fs/xfs/linux-2.6/xfs_file.c - 1.159 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_file.c.diff?r1=text&tr1=1.159&r2=text&tr2=1.158&f=h - revert the readdir code to using double buffering to work around a deadlock with nfsd calling back into the lookup code from filldir. From owner-xfs@oss.sgi.com Wed Dec 5 21:29:47 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 05 Dec 2007 21:29:51 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id lB65Tdix016568 for ; Wed, 5 Dec 2007 21:29:46 -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 QAA01163; Thu, 6 Dec 2007 16:29:46 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 16346) id 0F59358FA249; Thu, 6 Dec 2007 16:29:46 +1100 (EST) To: sgi.bugs.xfs@engr.sgi.com Cc: xfs@oss.sgi.com Subject: TAKE 974005 - xfs_lowbit64 broken on 32bit platforms Message-Id: <20071206052946.0F59358FA249@chook.melbourne.sgi.com> Date: Thu, 6 Dec 2007 16:29:46 +1100 (EST) From: dgc@sgi.com (David Chinner) X-Virus-Scanned: ClamAV 0.91.2/5017/Wed Dec 5 20:09:47 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13873 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Fix xfs_lowbit64 xfs_lowbit64 was broken on 32 bit platforms in a recent cleanup of the xfs bitops. Fix it back up again. Date: Thu Dec 6 16:28:59 AEDT 2007 Workarea: chook.melbourne.sgi.com:/build/dgc/isms/2.6.x-xfs Inspected by: lachlan@sgi.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:30202a fs/xfs/xfs_bit.h - 1.22 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bit.h.diff?r1=text&tr1=1.22&r2=text&tr2=1.21&f=h - make the temporary variable in xfs_lowbit64 the correct type so that 32bit platforms work as well. From owner-xfs@oss.sgi.com Wed Dec 5 21:39:52 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 05 Dec 2007 21:39:55 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id lB65dmUU017556 for ; Wed, 5 Dec 2007 21:39:51 -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 QAA01519; Thu, 6 Dec 2007 16:39:50 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 16346) id CDF2258FA249; Thu, 6 Dec 2007 16:39:50 +1100 (EST) To: sgi.bugs.xfs@engr.sgi.com Cc: xfs@oss.sgi.com Subject: TAKE 974224 - xfsbufd doesn't freeze Message-Id: <20071206053950.CDF2258FA249@chook.melbourne.sgi.com> Date: Thu, 6 Dec 2007 16:39:50 +1100 (EST) From: dgc@sgi.com (David Chinner) X-Virus-Scanned: ClamAV 0.91.2/5017/Wed Dec 5 20:09:47 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13874 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Make xfsbufd threads freezable Fix breakage caused by commit 831441862956fffa17b9801db37e6ea1650b0f69 that did not introduce the necessary call to set_freezable() in xfs/linux-2.6/xfs_buf.c . Signed-off-by: Rafael J. Wysocki Date: Thu Dec 6 16:38:20 AEDT 2007 Workarea: chook.melbourne.sgi.com:/build/dgc/isms/2.6.x-xfs Inspected by: rjw@sisk.pl The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:30203a fs/xfs/linux-2.6/xfs_buf.c - 1.252 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_buf.c.diff?r1=text&tr1=1.252&r2=text&tr2=1.251&f=h - Make xfsbufd freezable again. From owner-xfs@oss.sgi.com Wed Dec 5 22:00:46 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 05 Dec 2007 22:00:51 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id lB660TnY019466 for ; Wed, 5 Dec 2007 22:00:45 -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 RAA02088; Thu, 6 Dec 2007 17:00:35 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 16346) id 428E258FA249; Thu, 6 Dec 2007 17:00:35 +1100 (EST) To: sgi.bugs.xfs@engr.sgi.com Cc: xfs@oss.sgi.com Subject: TAKE 974225 - Fix xfs_ichgtime()s broken usage of I_SYNC Message-Id: <20071206060035.428E258FA249@chook.melbourne.sgi.com> Date: Thu, 6 Dec 2007 17:00:35 +1100 (EST) From: dgc@sgi.com (David Chinner) X-Virus-Scanned: ClamAV 0.91.2/5017/Wed Dec 5 20:09:47 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13875 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Fix xfs_ichgtime()s broken usage of I_SYNC The recent I_LOCK->I_SYNC changes mistakenly changed xfs_ichgtime to look at I_SYNC instead of I_LOCK. This was incorrect and prevents newly created inodes from moving to the dirty list. Change this to the correct check which is for I_NEW, not I_LOCK or I_SYNC so that behaviour is correct. Date: Thu Dec 6 16:59:52 AEDT 2007 Workarea: chook.melbourne.sgi.com:/build/dgc/isms/2.6.x-xfs Inspected by: lachlan@sgi.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:30204a fs/xfs/linux-2.6/xfs_iops.c - 1.271 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_iops.c.diff?r1=text&tr1=1.271&r2=text&tr2=1.270&f=h - Use I_NEW in xfs_ichgtime instead of I_SYNC so that new inodes are moved to the dirty list correctly. From owner-xfs@oss.sgi.com Thu Dec 6 08:20:39 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 06 Dec 2007 08:20:45 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: * X-Spam-Status: No, score=1.6 required=5.0 tests=BAYES_50,J_CHICKENPOX_45, WHOIS_MYPRIVREG autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id lB6GKZ0a030146 for ; Thu, 6 Dec 2007 08:20:39 -0800 X-ASG-Debug-ID: 1196957422-668403a60000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from kuber.nabble.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 22D364512BD for ; Thu, 6 Dec 2007 08:10:22 -0800 (PST) Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by cuda.sgi.com with ESMTP id caOm7pgk3QeRjrbi for ; Thu, 06 Dec 2007 08:10:22 -0800 (PST) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1J0JIr-0003kq-GD for xfs@oss.sgi.com; Thu, 06 Dec 2007 08:10:21 -0800 Message-ID: <14194915.post@talk.nabble.com> Date: Thu, 6 Dec 2007 08:10:21 -0800 (PST) From: Kingghost To: xfs@oss.sgi.com X-ASG-Orig-Subj: XFS_Repair PRoblem Subject: XFS_Repair PRoblem MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: mrlitres@gmail.com X-Barracuda-Connect: kuber.nabble.com[216.139.236.158] X-Barracuda-Start-Time: 1196957423 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0001 1.0000 -2.0204 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.52 X-Barracuda-Spam-Status: No, SCORE=-1.52 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests=BSF_RULE7568M X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.35875 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.50 BSF_RULE7568M BODY: Custom Rule 7568M X-Virus-Scanned: ClamAV 0.91.2/5020/Wed Dec 5 22:21:18 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13876 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mrlitres@gmail.com Precedence: bulk X-list: xfs Hello, So I was seeing my serial link go up and down so I rebooted and everything was working fine, except my vg0 wouldnt mount. So I tried to xfs_repair it and this is the output I recieved. slutb0x:/# xfs_repair -o assume_xfs /dev/vg0/media Phase 1 - find and verify superblock... sb root inode value 18446744073709551615 (NULLFSINO) inconsistent with calculated value 128 resetting superblock root inode pointer to 128 sb realtime bitmap inode 18446744073709551615 (NULLFSINO) inconsistent with calculated value 129 resetting superblock realtime bitmap ino pointer to 129 sb realtime summary inode 18446744073709551615 (NULLFSINO) inconsistent with calculated value 130 resetting superblock realtime summary ino pointer to 130 Phase 2 - using internal log - zero log... missing inbetween rebuilding directory inode 1225702584 bad hash table for directory inode 1342177425 (no data entry): rebuilding rebuilding directory inode 1342177425 bad hash table for directory inode 1344688512 (no data entry): rebuilding rebuilding directory inode 1344688512 bad hash table for directory inode 1344689011 (no data entry): rebuilding rebuilding directory inode 1344689011 bad hash table for directory inode 1347027107 (no data entry): rebuilding rebuilding directory inode 1347027107 bad hash table for directory inode 1347297139 (no data entry): rebuilding rebuilding directory inode 1347297139 bad hash table for directory inode 1348463898 (no data entry): rebuilding rebuilding directory inode 1348463898 bad hash table for directory inode 1386426400 (no data entry): rebuilding rebuilding directory inode 1386426400 bad hash table for directory inode 1407214284 (no data entry): rebuilding rebuilding directory inode 1407214284 rebuilding directory inode 1409980307 bad hash table for directory inode 1476395171 (no data entry): rebuilding rebuilding directory inode 1476395171 bad hash table for directory inode 1482430980 (no data entry): rebuilding rebuilding directory inode 1482430980 bad hash table for directory inode 1483051225 (no data entry): rebuilding rebuilding directory inode 1483051225 bad hash table for directory inode 1485162665 (no data entry): rebuilding rebuilding directory inode 1485162665 bad hash table for directory inode 1490611323 (no data entry): rebuilding rebuilding directory inode 1490611323 rebuilding directory inode 1545482625 bad hash table for directory inode 1546105138 (no data entry): rebuilding rebuilding directory inode 1546105138 bad hash table for directory inode 1546563350 (no data entry): rebuilding rebuilding directory inode 1546563350 bad hash table for directory inode 1576719133 (no data entry): rebuilding rebuilding directory inode 1576719133 bad hash table for directory inode 1610612892 (no data entry): rebuilding rebuilding directory inode 1610612892 bad hash table for directory inode 1618357762 (no data entry): rebuilding rebuilding directory inode 1618357762 bad hash table for directory inode 1619798333 (no data entry): rebuilding rebuilding directory inode 1619798333 bad hash table for directory inode 1669673937 (no data entry): rebuilding rebuilding directory inode 1669673937 bad hash table for directory inode 1754694080 (no data entry): rebuilding rebuilding directory inode 1754694080 bad hash table for directory inode 1756293956 (no data entry): rebuilding rebuilding directory inode 1756293956 bad hash table for directory inode 1793985071 (no data entry): rebuilding rebuilding directory inode 1793985071 bad hash table for directory inode 1879048358 (no data entry): rebuilding rebuilding directory inode 1879048358 bad hash table for directory inode 1879480988 (no data entry): rebuilding rebuilding directory inode 1879480988 bad hash table for directory inode 1884893322 (no data entry): rebuilding rebuilding directory inode 1884893322 bad hash table for directory inode 1885854162 (no data entry): rebuilding rebuilding directory inode 1885854162 bad hash table for directory inode 1888390172 (no data entry): rebuilding rebuilding directory inode 1888390172 bad hash table for directory inode 1892569223 (no data entry): rebuilding rebuilding directory inode 1892569223 bad hash table for directory inode 2015614187 (no data entry): rebuilding rebuilding directory inode 2015614187 bad hash table for directory inode 2019037629 (no data entry): rebuilding rebuilding directory inode 2019037629 bad hash table for directory inode 2027745957 (no data entry): rebuilding rebuilding directory inode 2027745957 bad hash table for directory inode 2027745991 (no data entry): rebuilding rebuilding directory inode 2027745991 bad hash table for directory inode 2041763187 (no data entry): rebuilding rebuilding directory inode 2041763187 - traversal finished ... - moving disconnected inodes to lost+found ... disconnected dir inode 134217856, moving to lost+found disconnected dir inode 159404583, moving to lost+found disconnected dir inode 188928448, moving to lost+found disconnected dir inode 188935323, moving to lost+found disconnected inode 209057354, moving to lost+found disconnected inode 209057355, moving to lost+found disconnected inode 209057356, moving to lost+found disconnected dir inode 209513188, moving to lost+found disconnected dir inode 209513245, moving to lost+found disconnected dir inode 209513344, moving to lost+found disconnected dir inode 209513395, moving to lost+found disconnected dir inode 209513490, moving to lost+found disconnected dir inode 209513584, moving to lost+found disconnected dir inode 209677569, moving to lost+found disconnected dir inode 213712676, moving to lost+found disconnected inode 262129013, moving to lost+found disconnected inode 262129014, moving to lost+found disconnected inode 262129016, moving to lost+found disconnected dir inode 262132666, moving to lost+found disconnected dir inode 262141188, moving to lost+found disconnected inode 279860753, moving to lost+found disconnected inode 279860754, moving to lost+found disconnected dir inode 279860755, moving to lost+found disconnected inode 279860757, moving to lost+found disconnected inode 279860758, moving to lost+found disconnected inode 279860759, moving to lost+found disconnected inode 279860760, moving to lost+found disconnected inode 279860761, moving to lost+found disconnected inode 279860762, moving to lost+found disconnected inode 279860763, moving to lost+found disconnected inode 279860764, moving to lost+found disconnected inode 279860766, moving to lost+found disconnected inode 279860767, moving to lost+found disconnected inode 279860770, moving to lost+found disconnected inode 279860771, moving to lost+found disconnected inode 279860772, moving to lost+found disconnected inode 279860773, moving to lost+found disconnected inode 279860774, moving to lost+found disconnected inode 279860776, moving to lost+found disconnected dir inode 279874575, moving to lost+found disconnected inode 292512566, moving to lost+found disconnected inode 292512567, moving to lost+found disconnected inode 292512568, moving to lost+found disconnected inode 292512569, moving to lost+found disconnected dir inode 292519637, moving to lost+found disconnected inode 292519660, moving to lost+found disconnected inode 292774410, moving to lost+found disconnected inode 292774412, moving to lost+found disconnected inode 292774413, moving to lost+found disconnected dir inode 307451136, moving to lost+found disconnected inode 342075439, moving to lost+found disconnected dir inode 342357112, moving to lost+found disconnected inode 345352743, moving to lost+found disconnected inode 345352744, moving to lost+found disconnected inode 345352745, moving to lost+found disconnected inode 345352746, moving to lost+found disconnected dir inode 350201220, moving to lost+found disconnected dir inode 404630767, moving to lost+found disconnected inode 404635207, moving to lost+found disconnected dir inode 467834646, moving to lost+found disconnected dir inode 468060626, moving to lost+found disconnected inode 497816685, moving to lost+found disconnected inode 497816686, moving to lost+found disconnected inode 497816687, moving to lost+found disconnected inode 497816688, moving to lost+found disconnected inode 497816689, moving to lost+found disconnected inode 497816690, moving to lost+found disconnected inode 497816691, moving to lost+found disconnected inode 497816692, moving to lost+found disconnected inode 497816702, moving to lost+found disconnected dir inode 500814219, moving to lost+found disconnected dir inode 500815365, moving to lost+found disconnected dir inode 527158122, moving to lost+found disconnected dir inode 536871084, moving to lost+found disconnected dir inode 538001664, moving to lost+found disconnected dir inode 541074254, moving to lost+found disconnected dir inode 541664864, moving to lost+found disconnected dir inode 541770349, moving to lost+found disconnected dir inode 551347552, moving to lost+found disconnected dir inode 677133324, moving to lost+found disconnected dir inode 681949599, moving to lost+found disconnected dir inode 683059743, moving to lost+found disconnected inode 683118797, moving to lost+found disconnected inode 683118798, moving to lost+found disconnected inode 683118799, moving to lost+found disconnected dir inode 683118800, moving to lost+found disconnected inode 730956960, moving to lost+found disconnected inode 730956961, moving to lost+found disconnected inode 730956962, moving to lost+found disconnected inode 730956963, moving to lost+found disconnected inode 730956964, moving to lost+found disconnected inode 730956965, moving to lost+found disconnected inode 730956966, moving to lost+found disconnected inode 730956967, moving to lost+found disconnected inode 730956968, moving to lost+found disconnected inode 730956969, moving to lost+found disconnected inode 730956970, moving to lost+found disconnected inode 730956971, moving to lost+found disconnected inode 730956972, moving to lost+found disconnected inode 730956973, moving to lost+found disconnected inode 730956974, moving to lost+found disconnected inode 730956975, moving to lost+found disconnected inode 730956976, moving to lost+found disconnected inode 730956977, moving to lost+found disconnected inode 730956978, moving to lost+found disconnected inode 730956979, moving to lost+found disconnected inode 730956980, moving to lost+found disconnected inode 730956981, moving to lost+found disconnected inode 730956982, moving to lost+found disconnected inode 730956983, moving to lost+found disconnected inode 730956984, moving to lost+found disconnected inode 730956985, moving to lost+found disconnected inode 730956986, moving to lost+found disconnected inode 730956987, moving to lost+found disconnected inode 730956988, moving to lost+found disconnected inode 730956989, moving to lost+found disconnected inode 730956990, moving to lost+found disconnected inode 730956991, moving to lost+found disconnected inode 730956992, moving to lost+found disconnected inode 730956993, moving to lost+found disconnected inode 730956994, moving to lost+found disconnected inode 730956995, moving to lost+found disconnected inode 730956996, moving to lost+found disconnected inode 730956997, moving to lost+found disconnected inode 730956998, moving to lost+found disconnected inode 730956999, moving to lost+found disconnected inode 730957000, moving to lost+found disconnected inode 730957001, moving to lost+found disconnected inode 730957002, moving to lost+found disconnected inode 730957003, moving to lost+found disconnected inode 730957004, moving to lost+found disconnected inode 730957005, moving to lost+found disconnected inode 730957006, moving to lost+found disconnected inode 730957007, moving to lost+found disconnected inode 730957008, moving to lost+found disconnected inode 730957009, moving to lost+found disconnected inode 730957010, moving to lost+found disconnected inode 730957011, moving to lost+found disconnected inode 730957012, moving to lost+found disconnected inode 730957013, moving to lost+found disconnected inode 730957014, moving to lost+found disconnected inode 730957015, moving to lost+found disconnected inode 730957016, moving to lost+found disconnected inode 730957017, moving to lost+found disconnected inode 730957018, moving to lost+found disconnected inode 730957019, moving to lost+found disconnected inode 730957020, moving to lost+found disconnected inode 730957021, moving to lost+found disconnected inode 730957022, moving to lost+found disconnected dir inode 730957023, moving to lost+found disconnected dir inode 730975064, moving to lost+found disconnected dir inode 731107961, moving to lost+found disconnected dir inode 731173866, moving to lost+found disconnected dir inode 731229206, moving to lost+found disconnected dir inode 731317750, moving to lost+found disconnected dir inode 752117594, moving to lost+found disconnected dir inode 752117670, moving to lost+found disconnected inode 809433019, moving to lost+found disconnected dir inode 823780059, moving to lost+found disconnected dir inode 823780089, moving to lost+found fatal error -- creation of .. entry failed (117), filesystem may be out of space The thing is I have free space, its weird. -- View this message in context: http://www.nabble.com/XFS_Repair-PRoblem-tf4956832.html#a14194915 Sent from the Xfs - General mailing list archive at Nabble.com. From owner-xfs@oss.sgi.com Thu Dec 6 08:50:34 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 06 Dec 2007 08:50:40 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_50 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id lB6GoW5g000647 for ; Thu, 6 Dec 2007 08:50:34 -0800 X-ASG-Debug-ID: 1196959204-793f00880000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from hobbit.corpit.ru (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 443A4AED0CC for ; Thu, 6 Dec 2007 08:40:04 -0800 (PST) Received: from hobbit.corpit.ru (hobbit.corpit.ru [81.13.94.6]) by cuda.sgi.com with ESMTP id YZC2orqAp5qZCiMR for ; Thu, 06 Dec 2007 08:40:04 -0800 (PST) Received: from [192.168.1.1] (paltus.tls.msk.ru [192.168.1.1]) by hobbit.corpit.ru (Postfix) with ESMTP id 1D6B32B079; Thu, 6 Dec 2007 19:39:29 +0300 (MSK) (envelope-from mjt@tls.msk.ru) Message-ID: <475825C0.4070605@msgid.tls.msk.ru> Date: Thu, 06 Dec 2007 19:39:28 +0300 From: Michael Tokarev User-Agent: Icedove 1.5.0.12 (X11/20070607) MIME-Version: 1.0 To: Dragos CC: David Greaves , linux-raid@vger.kernel.org, xfs@oss.sgi.com X-ASG-Orig-Subj: Re: assemble vs create an array....... Subject: Re: assemble vs create an array....... References: <474F869D.5040503@mpigani.org> <18255.41044.614676.410107@notabene.brown> <47501D7E.7000804@dgreaves.com> <475552D2.4000802@mpigani.org> <47568DE1.1050108@dgreaves.com> <4758129D.40600@mpigani.org> In-Reply-To: <4758129D.40600@mpigani.org> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: hobbit.corpit.ru[81.13.94.6] X-Barracuda-Start-Time: 1196959205 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0007 1.0000 -2.0162 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.35878 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5020/Wed Dec 5 22:21:18 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13877 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mjt@tls.msk.ru Precedence: bulk X-list: xfs [Cc'd to xfs list as it contains something related] Dragos wrote: > Thank you. > I want to make sure I understand. [Some background for XFS list. The talk is about a broken linux software raid (the reason for breakage isn't relevant anymore). The OP seems to lost the order of drives in his array, and now tries to create new array ontop, trying different combinations of drives. The filesystem there WAS XFS. One point is that linux refuses to mount it, saying "structure needs cleaning". This all is mostly md-related, but there are several XFS-related questions and concerns too.] > > 1- Does it matter which permutation of drives I use for xfs_repair (as > long as it tells me that the Structure needs cleaning)? When it comes to > linux I consider myself at intermediate level, but I am a beginner when > it comes to raid and filesystem issues. The permutation DOES MATTER - for all the devices. Linux, when mounting an fs, only looks at the superblock of the filesystem, which is usually located at the beginning of the device. So in each case linux actually recognizes the filesystem (instead of seeing complete garbage), the same device is the first one - I.e, this way you found your first device. The rest may be still out of order. Raid5 data is laid like this (with 3 drives for simplicity, it's similar with more drives): DiskA DiskB DiskC Blk0 Data0 Data1 P0 Blk1 P1 Data2 Data3 Blk2 Data4 P2 Data5 Blk3 Data6 Data7 P3 ... and so on ....................... where your actual data blocks are Data0, Data1, ... DataN, and PX are parity blocks. As long as DiskA remains in this position, the beginning of the array is Data0 block, -- hence linux sees the beginning of the filesystem and recognizes it. But you can switch DiskB and DiskC still, and the rest of the data will be complete garbage, only data blocks on DiskA will be in place. So you still need to find order of the other drives (you found your first drive, DriveA, already). Note also that if Data1 block is all-zeros (a situation which is unlikely for a non-empty filesystem), P0 (first parity block) will be exactly the same as Data0, because XORing anything with zeros gives the same "anything" again (XOR is the operation used to calculate parity blocks in RAID5). So there's still a remote chance you've TWO "first" disks... What to do is to give repairfs a try for each permutation, but again without letting it to actually fix anything. Just run it in read-only mode and see which combination of drives gives less errors, or no fatal errors (there may be several similar combinations, with the same order of drives but with different drive "missing"). It's sad that xfs refuses mount when "structure needs cleaning" - the best way here is to actually mount it and see how it looks like, instead of trying repair tools. Is there some option to force-mount it still (in readonly mode, knowing it may OOPs kernel etc)? I'm not very familiar with xfs yet - it seems to be much faster than ext3 for our workload (mostly databases), and I'm experimenting with it slowly. But this very thread prompted me to think. If I can't force-mount it (or browse it using other ways) as I can almost always do with (somewhat?) broken ext[23] just to examine things, maybe I'm trying it before it's mature enough? ;) Note the smile, but note there's a bit of joke in every joke... :) > 2- After I do it, assuming that it worked, how do I reintegrate the > 'missing' drive while keeping my data? Just add it back -- mdadm --add /dev/mdX /dev/sdYZ. But don't do that till you actually see your data. /mjt From owner-xfs@oss.sgi.com Thu Dec 6 09:30:36 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 06 Dec 2007 09:30:46 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id lB6HUZDY004773 for ; Thu, 6 Dec 2007 09:30:35 -0800 X-ASG-Debug-ID: 1196961128-0a8601c20000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id B518A4519CF for ; Thu, 6 Dec 2007 09:12:08 -0800 (PST) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id RIwE1U8KpjEGx6vD for ; Thu, 06 Dec 2007 09:12:08 -0800 (PST) Received: from Liberator.local (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 7A1AE1800FF5B; Thu, 6 Dec 2007 11:12:06 -0600 (CST) Message-ID: <47582D65.4000808@sandeen.net> Date: Thu, 06 Dec 2007 11:12:05 -0600 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Michael Tokarev CC: Dragos , David Greaves , linux-raid@vger.kernel.org, xfs@oss.sgi.com X-ASG-Orig-Subj: Re: assemble vs create an array....... Subject: Re: assemble vs create an array....... References: <474F869D.5040503@mpigani.org> <18255.41044.614676.410107@notabene.brown> <47501D7E.7000804@dgreaves.com> <475552D2.4000802@mpigani.org> <47568DE1.1050108@dgreaves.com> <4758129D.40600@mpigani.org> <475825C0.4070605@msgid.tls.msk.ru> In-Reply-To: <475825C0.4070605@msgid.tls.msk.ru> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1196961129 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.35879 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5021/Thu Dec 6 07:40:41 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13878 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Michael Tokarev wrote: > It's sad that xfs refuses mount when "structure needs > cleaning" - the best way here is to actually mount it > and see how it looks like, instead of trying repair > tools. Is there some option to force-mount it still > (in readonly mode, knowing it may OOPs kernel etc)? depends what went wrong, but in general that error means that metadata corruption was encountered which was sufficient for xfs to abort whatever it was doing. It's not done lightly; it's likely bailing out because it had no other choice. You can't "force mount" something which is sufficiently corrupted that xfs can't understand it anymore... IOW you can't traverse and read corrupted/scrambled metadata, no mount option can help you. :) If the shutdown were encountered during use, you could maybe avoid the bad metadata. If it's during mount that's probably a more fundamental problem. kernel messages when you get the "structure needs cleaning" error would be a clue as to what it actually hit. -Eric From owner-xfs@oss.sgi.com Thu Dec 6 13:06:42 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 06 Dec 2007 13:06:49 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_45 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id lB6L6YaU030872 for ; Thu, 6 Dec 2007 13:06:41 -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 IAA23079; Fri, 7 Dec 2007 08:06:40 +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 lB6L6ddD135190643; Fri, 7 Dec 2007 08:06:39 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id lB6L6aRc105554571; Fri, 7 Dec 2007 08:06:36 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Fri, 7 Dec 2007 08:06:36 +1100 From: David Chinner To: Kingghost Cc: xfs@oss.sgi.com Subject: Re: XFS_Repair PRoblem Message-ID: <20071206210636.GM115527101@sgi.com> References: <14194915.post@talk.nabble.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <14194915.post@talk.nabble.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/5023/Thu Dec 6 11:37:18 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13879 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Thu, Dec 06, 2007 at 08:10:21AM -0800, Kingghost wrote: > > Hello, > > So I was seeing my serial link go up and down so I rebooted and everything > was working fine, except my vg0 wouldnt mount. So I tried to xfs_repair it > and this is the output I recieved. > > slutb0x:/# xfs_repair -o assume_xfs /dev/vg0/media > Phase 1 - find and verify superblock... > sb root inode value 18446744073709551615 (NULLFSINO) inconsistent with > calculated value 128 NULLFSINO? Something has overwritten your superblock with a bunch of -1 values? > resetting superblock root inode pointer to 128 > sb realtime bitmap inode 18446744073709551615 (NULLFSINO) inconsistent with > calculated value 129 > resetting superblock realtime bitmap ino pointer to 129 > sb realtime summary inode 18446744073709551615 (NULLFSINO) inconsistent with > calculated value 130 > resetting superblock realtime summary ino pointer to 130 > Phase 2 - using internal log > - zero log... Uh-oh - you ran a xfs_repair -L, didn't you? > > missing inbetween > > rebuilding directory inode 1225702584 > bad hash table for directory inode 1342177425 (no data entry): rebuilding And a bunch of trashed directory structures... > disconnected dir inode 752117670, moving to lost+found > disconnected inode 809433019, moving to lost+found > disconnected dir inode 823780059, moving to lost+found > disconnected dir inode 823780089, moving to lost+found > > fatal error -- creation of .. entry failed (117), filesystem may be out of > space 117 = EUCLEAN - corrupted filesystem. Sounds like there's more corruption there than was discovered or the underlying disk is still corruption blocks. What version of repair are you running ? This is a dying disk you're trying to repair right? Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Thu Dec 6 13:22:31 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 06 Dec 2007 13:22:39 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_210 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id lB6LMSdS000420 for ; Thu, 6 Dec 2007 13:22:30 -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 IAA23594; Fri, 7 Dec 2007 08:22:33 +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 lB6LMTdD131164940; Fri, 7 Dec 2007 08:22:31 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id lB6LMPeI135277070; Fri, 7 Dec 2007 08:22:25 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Fri, 7 Dec 2007 08:22:25 +1100 From: David Chinner To: Michael Tokarev Cc: Dragos , David Greaves , linux-raid@vger.kernel.org, xfs@oss.sgi.com Subject: Re: assemble vs create an array....... Message-ID: <20071206212225.GN115527101@sgi.com> References: <474F869D.5040503@mpigani.org> <18255.41044.614676.410107@notabene.brown> <47501D7E.7000804@dgreaves.com> <475552D2.4000802@mpigani.org> <47568DE1.1050108@dgreaves.com> <4758129D.40600@mpigani.org> <475825C0.4070605@msgid.tls.msk.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <475825C0.4070605@msgid.tls.msk.ru> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/5023/Thu Dec 6 11:37:18 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13880 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Thu, Dec 06, 2007 at 07:39:28PM +0300, Michael Tokarev wrote: > What to do is to give repairfs a try for each permutation, > but again without letting it to actually fix anything. > Just run it in read-only mode and see which combination > of drives gives less errors, or no fatal errors (there > may be several similar combinations, with the same order > of drives but with different drive "missing"). Ugggh. > It's sad that xfs refuses mount when "structure needs > cleaning" - the best way here is to actually mount it > and see how it looks like, instead of trying repair > tools. It self protection - if you try to write to a corrupted filesystem, you'll only make the corruption worse. Mounting involves log recovery, which writes to the filesystem.... > Is there some option to force-mount it still > (in readonly mode, knowing it may OOPs kernel etc)? Sure you can: mount -o ro,norecovery But it you hit corruption it will still shut down on you. If the machine oopses then that is a bug. > thread prompted me to think. If I can't force-mount it > (or browse it using other ways) as I can almost always > do with (somewhat?) broken ext[23] just to examine things, > maybe I'm trying it before it's mature enough? ;) Hehe ;) For maximum uber-XFS-guru points, learn to browse your filesystem with xfs_db. :P Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Thu Dec 6 16:29:24 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 06 Dec 2007 16:29:29 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id lB70THWo022155 for ; Thu, 6 Dec 2007 16:29:22 -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 LAA28520; Fri, 7 Dec 2007 11:29:24 +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 lB70TNdD135206957; Fri, 7 Dec 2007 11:29:23 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id lB70TMYC135376756; Fri, 7 Dec 2007 11:29:22 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Fri, 7 Dec 2007 11:29:22 +1100 From: David Chinner To: Vlad Apostolov Cc: Christoph Hellwig , David Chinner , Mark Goodwin , xfs-dev , xfs-oss Subject: Re: DMAPI problem with the new filldir implementation Message-ID: <20071207002922.GQ115527101@sgi.com> References: <475879DB.40705@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <475879DB.40705@sgi.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/5023/Thu Dec 6 11:37:18 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13881 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs (cc xfs-dev and xfs@oss) On Fri, Dec 07, 2007 at 09:38:19AM +1100, Vlad Apostolov wrote: > Hi Christoph and Dave, > > It looks like we may have a problem caused by this patch: > > http://oss.sgi.com/archives/xfs/2007-07/msg00338.html > > It makes XFS test 144 to fail if the inode size is 2k. I did > some investigation and I think xfs_readdir() returns incorrect > next location for shortform directories. When the inode size is > 2k, more dir entries fit inline in the inode and test 144 > dm_get_dirattrs() starts using the shortform. > > I think this code here > > if (filldir(dirent, sfep->name, sfep->namelen, > off + xfs_dir2_data_entsize(sfep->namelen), > ino, DT_UNKNOWN)) { > > adds some offset "xfs_dir2_data_entsize(sfep->namelen)" to the > next location pointer, which appears to be incorrect and causes > directory entries to be skipped on the next call of dm_get_dirattrs(). It's supposed to be the offset of the next dirent: On Linux, the dirent structure is defined as follows: struct dirent { ino_t d_ino; /* inode number */ >>>>>> off_t d_off; /* offset to the next dirent */ unsigned short d_reclen; /* length of this record */ unsigned char d_type; /* type of file */ char d_name[256]; /* filename */ }; However, looking at the generic filldir() implementation in fs/readdir.c, I see that it: dirent = buf->previous; if (dirent) { if (__put_user(offset, &dirent->d_off)) goto efault; } Puts the offset in the *previous* dirent, not the current one. That means that the three calls to XFs makes to filldir() are all incorrect; they should be passing the offset of the current object, not the next object as teh filldir code stuffs it in the previous dirent. The reason that dmapi is failing here is that it uses teh offset as the cookie to to indicate the next inode to read. However, getdents uses the filp->f_pos: error = vfs_readdir(file, filldir, &buf); if (error < 0) goto out_putf; error = buf.error; lastdirent = buf.previous; if (lastdirent) { if (put_user(file->f_pos, &lastdirent->d_off)) error = -EFAULT; else error = count - buf.count; } and xfs_file_readdir uses that as teh offset for lookups and keeps it up to date correctly. hence the getdents code is overwritting the incorrect value XFS has been stuffing in there and hence we haven't seen this on normal syscalls. > I tried this simple patch > > --- a/fs/xfs/dmapi/xfs_dm.c 2007-12-03 14:04:10.000000000 +1100 > +++ b/fs/xfs/dmapi/xfs_dm.c 2007-12-03 11:55:12.000000000 +1100 > @@ -1910,7 +1910,6 @@ > goto out_kfree; > } > > - loc = cb->lastoff; Ok, which is using the offset returned by xfs_readdir (the offset of the last dirent successfully read) instead of that used in dm_filldir which is the offset of the next dir. > > error = -EFAULT; > if (cb->lastbuf && put_user(0, &cb->lastbuf->_link)) > > and it seams to fix the problem. > > Because I don't fully understand the new filldir implementation I would > like to ask you if you could have a look at it and see what would be > the best way to fix the problem. Ok, patch attached. passes 144 on all inode sizes, otherwise mostly untested. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group --- fs/xfs/dmapi/xfs_dm.c | 4 ---- fs/xfs/xfs_dir2_block.c | 6 ++---- fs/xfs/xfs_dir2_leaf.c | 2 +- fs/xfs/xfs_dir2_sf.c | 9 +++------ 4 files changed, 6 insertions(+), 15 deletions(-) Index: 2.6.x-xfs-new/fs/xfs/xfs_dir2_block.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/xfs_dir2_block.c 2007-08-23 23:03:09.000000000 +1000 +++ 2.6.x-xfs-new/fs/xfs/xfs_dir2_block.c 2007-12-07 10:23:14.933645761 +1100 @@ -508,7 +508,7 @@ xfs_dir2_block_getdents( continue; cook = xfs_dir2_db_off_to_dataptr(mp, mp->m_dirdatablk, - ptr - (char *)block); + (char *)dep - (char *)block); ino = be64_to_cpu(dep->inumber); #if XFS_BIG_INUMS ino += mp->m_inoadd; @@ -519,9 +519,7 @@ xfs_dir2_block_getdents( */ if (filldir(dirent, dep->name, dep->namelen, cook, ino, DT_UNKNOWN)) { - *offset = xfs_dir2_db_off_to_dataptr(mp, - mp->m_dirdatablk, - (char *)dep - (char *)block); + *offset = cook; xfs_da_brelse(NULL, bp); return 0; } Index: 2.6.x-xfs-new/fs/xfs/xfs_dir2_leaf.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/xfs_dir2_leaf.c 2007-08-24 22:24:45.000000000 +1000 +++ 2.6.x-xfs-new/fs/xfs/xfs_dir2_leaf.c 2007-12-07 10:18:17.623544813 +1100 @@ -1091,7 +1091,7 @@ xfs_dir2_leaf_getdents( * Won't fit. Return to caller. */ if (filldir(dirent, dep->name, dep->namelen, - xfs_dir2_byte_to_dataptr(mp, curoff + length), + xfs_dir2_byte_to_dataptr(mp, curoff), ino, DT_UNKNOWN)) break; Index: 2.6.x-xfs-new/fs/xfs/xfs_dir2_sf.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/xfs_dir2_sf.c 2007-08-23 23:03:09.000000000 +1000 +++ 2.6.x-xfs-new/fs/xfs/xfs_dir2_sf.c 2007-12-07 10:20:57.887115812 +1100 @@ -752,7 +752,7 @@ xfs_dir2_sf_getdents( #if XFS_BIG_INUMS ino += mp->m_inoadd; #endif - if (filldir(dirent, ".", 1, dotdot_offset, ino, DT_DIR)) { + if (filldir(dirent, ".", 1, dot_offset, ino, DT_DIR)) { *offset = dot_offset; return 0; } @@ -762,13 +762,11 @@ xfs_dir2_sf_getdents( * Put .. entry unless we're starting past it. */ if (*offset <= dotdot_offset) { - off = xfs_dir2_db_off_to_dataptr(mp, mp->m_dirdatablk, - XFS_DIR2_DATA_FIRST_OFFSET); ino = xfs_dir2_sf_get_inumber(sfp, &sfp->hdr.parent); #if XFS_BIG_INUMS ino += mp->m_inoadd; #endif - if (filldir(dirent, "..", 2, off, ino, DT_DIR)) { + if (filldir(dirent, "..", 2, dotdot_offset, ino, DT_DIR)) { *offset = dotdot_offset; return 0; } @@ -793,8 +791,7 @@ xfs_dir2_sf_getdents( #endif if (filldir(dirent, sfep->name, sfep->namelen, - off + xfs_dir2_data_entsize(sfep->namelen), - ino, DT_UNKNOWN)) { + off, ino, DT_UNKNOWN)) { *offset = off; return 0; } Index: 2.6.x-xfs-new/fs/xfs/dmapi/xfs_dm.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/dmapi/xfs_dm.c 2007-12-03 17:11:46.000000000 +1100 +++ 2.6.x-xfs-new/fs/xfs/dmapi/xfs_dm.c 2007-12-07 11:25:42.678472255 +1100 @@ -1772,7 +1772,6 @@ xfs_dm_get_dioinfo( typedef struct dm_readdir_cb { xfs_mount_t *mp; - xfs_off_t lastoff; char __user *ubuf; dm_stat_t __user *lastbuf; size_t spaceleft; @@ -1834,7 +1833,6 @@ dm_filldir(void *__buf, const char *name cb->spaceleft -= statp->_link; cb->nwritten += statp->_link; cb->ubuf += statp->_link; - cb->lastoff = offset; return 0; @@ -1910,8 +1908,6 @@ xfs_dm_get_dirattrs_rvp( goto out_kfree; } - loc = cb->lastoff; - error = -EFAULT; if (cb->lastbuf && put_user(0, &cb->lastbuf->_link)) goto out_kfree; From owner-xfs@oss.sgi.com Thu Dec 6 16:51:21 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 06 Dec 2007 16:51:25 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.3 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_45, WHOIS_MYPRIVREG autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id lB70pHtx024668 for ; Thu, 6 Dec 2007 16:51:21 -0800 X-ASG-Debug-ID: 1196988685-74ef01930000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from kuber.nabble.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 3116C4544FC for ; Thu, 6 Dec 2007 16:51:25 -0800 (PST) Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by cuda.sgi.com with ESMTP id ah4iGxa3RBnnByQz for ; Thu, 06 Dec 2007 16:51:25 -0800 (PST) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1J0RR6-0004yc-Ay for xfs@oss.sgi.com; Thu, 06 Dec 2007 16:51:24 -0800 Message-ID: <14204640.post@talk.nabble.com> Date: Thu, 6 Dec 2007 16:51:24 -0800 (PST) From: Kingghost To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS_Repair PRoblem Subject: Re: XFS_Repair PRoblem In-Reply-To: <20071206210636.GM115527101@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: mrlitres@gmail.com References: <14194915.post@talk.nabble.com> <20071206210636.GM115527101@sgi.com> X-Barracuda-Connect: kuber.nabble.com[216.139.236.158] X-Barracuda-Start-Time: 1196988688 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.52 X-Barracuda-Spam-Status: No, SCORE=-1.52 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests=BSF_RULE7568M X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.35911 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.50 BSF_RULE7568M BODY: Custom Rule 7568M X-Virus-Scanned: ClamAV 0.91.2/5023/Thu Dec 6 11:37:18 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13882 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mrlitres@gmail.com Precedence: bulk X-list: xfs Hello, Ya it said if I couldnt mount it to use -L so I did. Apparently this was a mistake. I dd_rescued all the data to a new drive, so drive isnt the issue anymore. David Chinner wrote: > > On Thu, Dec 06, 2007 at 08:10:21AM -0800, Kingghost wrote: >> >> Hello, >> >> So I was seeing my serial link go up and down so I rebooted and >> everything >> was working fine, except my vg0 wouldnt mount. So I tried to xfs_repair >> it >> and this is the output I recieved. >> >> slutb0x:/# xfs_repair -o assume_xfs /dev/vg0/media >> Phase 1 - find and verify superblock... >> sb root inode value 18446744073709551615 (NULLFSINO) inconsistent with >> calculated value 128 > > NULLFSINO? Something has overwritten your superblock with a bunch of -1 > values? > >> resetting superblock root inode pointer to 128 >> sb realtime bitmap inode 18446744073709551615 (NULLFSINO) inconsistent >> with >> calculated value 129 >> resetting superblock realtime bitmap ino pointer to 129 >> sb realtime summary inode 18446744073709551615 (NULLFSINO) inconsistent >> with >> calculated value 130 >> resetting superblock realtime summary ino pointer to 130 >> Phase 2 - using internal log >> - zero log... > > Uh-oh - you ran a xfs_repair -L, didn't you? >> >> missing inbetween >> >> rebuilding directory inode 1225702584 >> bad hash table for directory inode 1342177425 (no data entry): rebuilding > > And a bunch of trashed directory structures... > >> disconnected dir inode 752117670, moving to lost+found >> disconnected inode 809433019, moving to lost+found >> disconnected dir inode 823780059, moving to lost+found >> disconnected dir inode 823780089, moving to lost+found >> >> fatal error -- creation of .. entry failed (117), filesystem may be out >> of >> space > > 117 = EUCLEAN - corrupted filesystem. Sounds like there's more corruption > there than was discovered or the underlying disk is still corruption > blocks. > What version of repair are you running ? > > This is a dying disk you're trying to repair right? > > Cheers, > > Dave. > -- > Dave Chinner > Principal Engineer > SGI Australian Software Group > > > > -- View this message in context: http://www.nabble.com/XFS_Repair-PRoblem-tf4956832.html#a14204640 Sent from the Xfs - General mailing list archive at Nabble.com. From owner-xfs@oss.sgi.com Thu Dec 6 17:49:43 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 06 Dec 2007 17:49:46 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_66 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id lB71nZ5X030067 for ; Thu, 6 Dec 2007 17:49:41 -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 MAA00486; Fri, 7 Dec 2007 12:49:42 +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 lB71ngdD135262204; Fri, 7 Dec 2007 12:49:42 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id lB71ne9E135089781; Fri, 7 Dec 2007 12:49:40 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Fri, 7 Dec 2007 12:49:40 +1100 From: David Chinner To: David Chinner Cc: Vlad Apostolov , Christoph Hellwig , Mark Goodwin , xfs-dev , xfs-oss Subject: Re: DMAPI problem with the new filldir implementation Message-ID: <20071207014940.GS115527101@sgi.com> References: <475879DB.40705@sgi.com> <20071207002922.GQ115527101@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071207002922.GQ115527101@sgi.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/5023/Thu Dec 6 11:37:18 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13883 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Fri, Dec 07, 2007 at 11:29:22AM +1100, David Chinner wrote: > (cc xfs-dev and xfs@oss) > > On Fri, Dec 07, 2007 at 09:38:19AM +1100, Vlad Apostolov wrote: > > Hi Christoph and Dave, > > > > It looks like we may have a problem caused by this patch: > > > > http://oss.sgi.com/archives/xfs/2007-07/msg00338.html > > > > It makes XFS test 144 to fail if the inode size is 2k. I did > > some investigation and I think xfs_readdir() returns incorrect > > next location for shortform directories. When the inode size is > > 2k, more dir entries fit inline in the inode and test 144 > > dm_get_dirattrs() starts using the shortform. > > > > I think this code here > > > > if (filldir(dirent, sfep->name, sfep->namelen, > > off + xfs_dir2_data_entsize(sfep->namelen), > > ino, DT_UNKNOWN)) { > > > > adds some offset "xfs_dir2_data_entsize(sfep->namelen)" to the > > next location pointer, which appears to be incorrect and causes > > directory entries to be skipped on the next call of dm_get_dirattrs(). > > It's supposed to be the offset of the next dirent: > > On Linux, the dirent structure is defined as follows: > > struct dirent { > ino_t d_ino; /* inode number */ > >>>>>> off_t d_off; /* offset to the next dirent */ > unsigned short d_reclen; /* length of this record */ > unsigned char d_type; /* type of file */ > char d_name[256]; /* filename */ > }; > > However, looking at the generic filldir() implementation in fs/readdir.c, > I see that it: > > dirent = buf->previous; > if (dirent) { > if (__put_user(offset, &dirent->d_off)) > goto efault; > } > > Puts the offset in the *previous* dirent, not the current one. That > means that the three calls to XFs makes to filldir() are all incorrect; > they should be passing the offset of the current object, not the next > object as teh filldir code stuffs it in the previous dirent. > > The reason that dmapi is failing here is that it uses teh offset as the > cookie to to indicate the next inode to read. However, getdents uses the > filp->f_pos: > > error = vfs_readdir(file, filldir, &buf); > if (error < 0) > goto out_putf; > error = buf.error; > lastdirent = buf.previous; > if (lastdirent) { > if (put_user(file->f_pos, &lastdirent->d_off)) > error = -EFAULT; > else > error = count - buf.count; > } > > and xfs_file_readdir uses that as teh offset for lookups and keeps it up > to date correctly. hence the getdents code is overwritting the incorrect > value XFS has been stuffing in there and hence we haven't seen this > on normal syscalls. Except that the hack to go back to double buffering relies on the filldir offset being pushed off to be the next dirent, and hence with the patch I sent we set filp->f_pos incorrectly in xfs_file_readdir()..... > Ok, patch attached. passes 144 on all inode sizes, otherwise mostly > untested. I did say mostly untested :/ Updated patch below (which passes 006 but is still mostly untested). Cheers, dave. -- Dave Chinner Principal Engineer SGI Australian Software Group --- fs/xfs/dmapi/xfs_dm.c | 4 ---- fs/xfs/linux-2.6/xfs_file.c | 4 ++-- fs/xfs/xfs_dir2_block.c | 6 ++---- fs/xfs/xfs_dir2_leaf.c | 2 +- fs/xfs/xfs_dir2_sf.c | 9 +++------ 5 files changed, 8 insertions(+), 17 deletions(-) Index: 2.6.x-xfs-new/fs/xfs/xfs_dir2_block.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/xfs_dir2_block.c 2007-08-23 23:03:09.000000000 +1000 +++ 2.6.x-xfs-new/fs/xfs/xfs_dir2_block.c 2007-12-07 10:23:14.933645761 +1100 @@ -508,7 +508,7 @@ xfs_dir2_block_getdents( continue; cook = xfs_dir2_db_off_to_dataptr(mp, mp->m_dirdatablk, - ptr - (char *)block); + (char *)dep - (char *)block); ino = be64_to_cpu(dep->inumber); #if XFS_BIG_INUMS ino += mp->m_inoadd; @@ -519,9 +519,7 @@ xfs_dir2_block_getdents( */ if (filldir(dirent, dep->name, dep->namelen, cook, ino, DT_UNKNOWN)) { - *offset = xfs_dir2_db_off_to_dataptr(mp, - mp->m_dirdatablk, - (char *)dep - (char *)block); + *offset = cook; xfs_da_brelse(NULL, bp); return 0; } Index: 2.6.x-xfs-new/fs/xfs/xfs_dir2_leaf.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/xfs_dir2_leaf.c 2007-08-24 22:24:45.000000000 +1000 +++ 2.6.x-xfs-new/fs/xfs/xfs_dir2_leaf.c 2007-12-07 10:18:17.623544813 +1100 @@ -1091,7 +1091,7 @@ xfs_dir2_leaf_getdents( * Won't fit. Return to caller. */ if (filldir(dirent, dep->name, dep->namelen, - xfs_dir2_byte_to_dataptr(mp, curoff + length), + xfs_dir2_byte_to_dataptr(mp, curoff), ino, DT_UNKNOWN)) break; Index: 2.6.x-xfs-new/fs/xfs/xfs_dir2_sf.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/xfs_dir2_sf.c 2007-08-23 23:03:09.000000000 +1000 +++ 2.6.x-xfs-new/fs/xfs/xfs_dir2_sf.c 2007-12-07 10:20:57.887115812 +1100 @@ -752,7 +752,7 @@ xfs_dir2_sf_getdents( #if XFS_BIG_INUMS ino += mp->m_inoadd; #endif - if (filldir(dirent, ".", 1, dotdot_offset, ino, DT_DIR)) { + if (filldir(dirent, ".", 1, dot_offset, ino, DT_DIR)) { *offset = dot_offset; return 0; } @@ -762,13 +762,11 @@ xfs_dir2_sf_getdents( * Put .. entry unless we're starting past it. */ if (*offset <= dotdot_offset) { - off = xfs_dir2_db_off_to_dataptr(mp, mp->m_dirdatablk, - XFS_DIR2_DATA_FIRST_OFFSET); ino = xfs_dir2_sf_get_inumber(sfp, &sfp->hdr.parent); #if XFS_BIG_INUMS ino += mp->m_inoadd; #endif - if (filldir(dirent, "..", 2, off, ino, DT_DIR)) { + if (filldir(dirent, "..", 2, dotdot_offset, ino, DT_DIR)) { *offset = dotdot_offset; return 0; } @@ -793,8 +791,7 @@ xfs_dir2_sf_getdents( #endif if (filldir(dirent, sfep->name, sfep->namelen, - off + xfs_dir2_data_entsize(sfep->namelen), - ino, DT_UNKNOWN)) { + off, ino, DT_UNKNOWN)) { *offset = off; return 0; } Index: 2.6.x-xfs-new/fs/xfs/dmapi/xfs_dm.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/dmapi/xfs_dm.c 2007-12-03 17:11:46.000000000 +1100 +++ 2.6.x-xfs-new/fs/xfs/dmapi/xfs_dm.c 2007-12-07 11:25:42.678472255 +1100 @@ -1772,7 +1772,6 @@ xfs_dm_get_dioinfo( typedef struct dm_readdir_cb { xfs_mount_t *mp; - xfs_off_t lastoff; char __user *ubuf; dm_stat_t __user *lastbuf; size_t spaceleft; @@ -1834,7 +1833,6 @@ dm_filldir(void *__buf, const char *name cb->spaceleft -= statp->_link; cb->nwritten += statp->_link; cb->ubuf += statp->_link; - cb->lastoff = offset; return 0; @@ -1910,8 +1908,6 @@ xfs_dm_get_dirattrs_rvp( goto out_kfree; } - loc = cb->lastoff; - error = -EFAULT; if (cb->lastbuf && put_user(0, &cb->lastbuf->_link)) goto out_kfree; Index: 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_file.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/linux-2.6/xfs_file.c 2007-12-03 18:41:26.000000000 +1100 +++ 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_file.c 2007-12-07 12:36:52.123061435 +1100 @@ -357,13 +357,13 @@ xfs_file_readdir( reclen = sizeof(struct hack_dirent) + de->namlen; size -= reclen; - curr_offset = de->offset /* & 0x7fffffff */; de = (struct hack_dirent *)((char *)de + reclen); + curr_offset = de->offset /* & 0x7fffffff */; } } done: - if (!error) { + if (!error) { if (size == 0) filp->f_pos = offset & 0x7fffffff; else if (de) From owner-xfs@oss.sgi.com Mon Dec 10 13:54:56 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Dec 2007 13:55:18 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00,WEIRD_PORT autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id lBALsjUY013424 for ; Mon, 10 Dec 2007 13:54: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 RAA19975; Mon, 10 Dec 2007 17:19:46 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 44625) id C08AD58C4C34; Mon, 10 Dec 2007 17:19:46 +1100 (EST) Date: Mon, 10 Dec 2007 17:19:46 +1100 To: torvalds@linux-foundation.org Cc: linux-kernel@vger.kernel.org, xfs@oss.sgi.com, akpm@linux-foundation.org Subject: [GIT PULL] XFS update for 2.6.24-rc5 User-Agent: nail 11.25 7/29/05 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20071210061946.C08AD58C4C34@chook.melbourne.sgi.com> From: lachlan@sgi.com (Lachlan McIlroy) X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13885 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs Please pull from the for-linus branch: git pull git://oss.sgi.com:8090/xfs/xfs-2.6.git for-linus This will update the following files: fs/xfs/linux-2.6/xfs_buf.c | 37 +++++------- fs/xfs/linux-2.6/xfs_file.c | 124 ++++++++++++++++++++++++++++++++++++++++ fs/xfs/linux-2.6/xfs_ioctl.c | 20 +++---- fs/xfs/linux-2.6/xfs_ioctl32.c | 3 + fs/xfs/linux-2.6/xfs_iops.c | 4 +- fs/xfs/quota/xfs_qm.c | 3 + fs/xfs/xfs_iget.c | 2 +- fs/xfs/xfs_itable.c | 43 +++++++++----- 8 files changed, 186 insertions(+), 50 deletions(-) through these commits: commit cf10e82bdc0d38d09dfaf46d0daf56136138ef3f Author: David Chinner Date: Fri Dec 7 14:09:11 2007 +1100 [XFS] Fix xfs_ichgtime()s broken usage of I_SYNC The recent I_LOCK->I_SYNC changes mistakenly changed xfs_ichgtime to look at I_SYNC instead of I_LOCK. This was incorrect and prevents newly created inodes from moving to the dirty list. Change this to the correct check which is for I_NEW, not I_LOCK or I_SYNC so that behaviour is correct. SGI-PV: 974225 SGI-Modid: xfs-linux-melb:xfs-kern:30204a Signed-off-by: David Chinner Signed-off-by: Lachlan McIlroy commit 978c7b2ff49597ab76ff7529a933bd366941ac25 Author: Rafael J. Wysocki Date: Fri Dec 7 14:09:02 2007 +1100 [XFS] Make xfsbufd threads freezable Fix breakage caused by commit 831441862956fffa17b9801db37e6ea1650b0f69 that did not introduce the necessary call to set_freezable() in xfs/linux-2.6/xfs_buf.c . SGI-PV: 974224 SGI-Modid: xfs-linux-melb:xfs-kern:30203a Signed-off-by: Rafael J. Wysocki Signed-off-by: David Chinner Signed-off-by: Lachlan McIlroy commit e89bc612d61edbcefaeb6f2244f86c0f3ec89d23 Author: Christoph Hellwig Date: Fri Dec 7 14:07:53 2007 +1100 [XFS] revert to double-buffering readdir The current readdir implementation deadlocks on a btree buffers locks because nfsd calls back into ->lookup from the filldir callback. The only short-term fix for this is to revert to the old inefficient double-buffering scheme. SGI-PV: 973377 SGI-Modid: xfs-linux-melb:xfs-kern:30201a Signed-off-by: Christoph Hellwig Signed-off-by: David Chinner Signed-off-by: Lachlan McIlroy commit a7430847fcb19297d6db833f35b9c9645c4a6395 Author: David Chinner Date: Fri Nov 23 16:30:23 2007 +1100 [XFS] Fix broken inode cluster setup. The radix tree based inode caches did away with the inode cluster hashes, replacing them with a bunch of masking and gang lookups on the radix tree. This masking got broken when moving the code to per-ag radix trees and indexing by agino # rather than straight inode number. The result is clustered inode writeback does not cluster and things can go extremely slowly when there are lots of inodes to write. Fix it up by comparing the agino # of the inode we just looked up to the index of the cluster we are looking for. Tested-by: Torsten Kaiser SGI-PV: 972915 SGI-Modid: xfs-linux-melb:xfs-kern:30033a Signed-off-by: David Chinner Signed-off-by: Lachlan McIlroy commit 77be55a5a13d9c7ddf780a93861f2fba33f8be1a Author: Lachlan McIlroy Date: Fri Nov 23 16:31:00 2007 +1100 [XFS] Clear XBF_READ_AHEAD flag on I/O completion. SGI-PV: 972554 SGI-Modid: xfs-linux-melb:xfs-kern:30128a Signed-off-by: Lachlan McIlroy Signed-off-by: Christoph Hellwig commit d1afb678ce77b930334a8a640a05b8e68178a377 Author: Lachlan McIlroy Date: Tue Nov 27 17:01:24 2007 +1100 [XFS] Fixed a few bugs in xfs_buf_associate_memory() - calculation of 'page_count' was incorrect as it did not consider the offset of 'mem' into the first page. The logic to bump 'page_count' didn't work if 'len' was <= PAGE_CACHE_SIZE (ie offset = 3k, len = 2k). - setting b_buffer_length to 'len' is incorrect if 'offset' is > 0. Set it to the total length of the buffer. - I suspect that passing a non-aligned address into mem_to_page() for the first page may have been causing issues - don't know but just tidy up that code anyway. SGI-PV: 971596 SGI-Modid: xfs-linux-melb:xfs-kern:30143a Signed-off-by: Lachlan McIlroy Signed-off-by: Christoph Hellwig commit cd57e594adc624dd9ee4c0ded3949da21ec24b2f Author: Lachlan McIlroy Date: Fri Nov 23 16:30:32 2007 +1100 [XFS] 971064 Various fixups for xfs_bulkstat(). - sanity check for NULL user buffer in xfs_ioc_bulkstat[_compat]() - remove the special case for XFS_IOC_FSBULKSTAT with count == 1. This special case causes bulkstat to fail because the special case uses xfs_bulkstat_single() instead of xfs_bulkstat() and the two functions have different semantics. xfs_bulkstat() will return the next inode after the one supplied while skipping internal inodes (ie quota inodes). xfs_bulkstate_single() will only lookup the inode supplied and return an error if it is an internal inode. - in xfs_bulkstat(), need to initialise 'lastino' to the inode supplied so in cases were we return without examining any inodes the scan wont restart back at zero. - sanity check for valid *ubcountp values. Cannot sanity check for valid ubuffer here because some users of xfs_bulkstat() don't supply a buffer. - checks against 'ubleft' (the space left in the user's buffer) should be against 'statstruct_size' which is the supplied minimum object size. The mixture of checks against statstruct_size and 0 was one of the reasons we were skipping inodes. - if the formatter function returns BULKSTAT_RV_NOTHING and an error and the error is not ENOENT or EINVAL then we need to abort the scan. ENOENT is for inodes that are no longer valid and we just skip them. EINVAL is returned if we try to lookup an internal inode so we skip them too. For a DMF scan if the inode and DMF attribute cannot fit into the space left in the user's buffer it would return ERANGE. We didn't handle this error and skipped the inode. We would continue to skip inodes until one fitted into the user's buffer or we completed the scan. - put back the recalculation of agino (that got removed with the last fix) at the end of the while loop. This is because the code at the start of the loop expects agino to be the last inode examined if it is non-zero. - if we found some inodes but then encountered an error, return success this time and the error next time. If the formatter aborted with ENOMEM we will now return this error but only if we couldn't read any inodes. Previously if we encountered ENOMEM without reading any inodes we returned a zero count and no error which falsely indicated the scan was complete. SGI-PV: 973431 SGI-Modid: xfs-linux-melb:xfs-kern:30089a Signed-off-by: Lachlan McIlroy Signed-off-by: David Chinner commit d757762bf2f6aea954745c76b4d767067b85be9d Author: Donald Douwsma Date: Fri Nov 23 16:27:42 2007 +1100 [XFS] Fix dbflush panic in xfs_qm_sync. The recent behaviour layer removal dropped the check for quotas that have been requested at mount time but have subsequently been turned off. This results in a panic when accessing m_quotainfo which has been freed. This patch adds the check originally made by xfs_qm_syncall() to xfs_qm_sync(). SGI-PV: 969769 SGI-Modid: xfs-linux-melb:xfs-kern:29908a Signed-off-by: Donald Douwsma Signed-off-by: David Chinner Signed-off-by: Lachlan McIlroy From owner-xfs@oss.sgi.com Mon Dec 10 13:54:53 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Dec 2007 13:55:16 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_66 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id lBALsjUW013424 for ; Mon, 10 Dec 2007 13:54:50 -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 SAA20648; Mon, 10 Dec 2007 18:05:00 +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 lBA750IN3262737; Mon, 10 Dec 2007 18:05:00 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id lBA74wJO3143061; Mon, 10 Dec 2007 18:04:58 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Mon, 10 Dec 2007 18:04:58 +1100 From: David Chinner To: David Chinner Cc: Vlad Apostolov , Christoph Hellwig , Mark Goodwin , xfs-dev , xfs-oss Subject: [review please] Re: DMAPI problem with the new filldir implementation Message-ID: <20071210070458.GI4714@sgi.com> References: <475879DB.40705@sgi.com> <20071207002922.GQ115527101@sgi.com> <20071207014940.GS115527101@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071207014940.GS115527101@sgi.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13884 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs This passes xfsqa and various other handrolled tests I've thrown at it. Can i get some eyeballs on this, please? Cheers, Dave. On Fri, Dec 07, 2007 at 12:49:40PM +1100, David Chinner wrote: > On Fri, Dec 07, 2007 at 11:29:22AM +1100, David Chinner wrote: > > (cc xfs-dev and xfs@oss) > > > > On Fri, Dec 07, 2007 at 09:38:19AM +1100, Vlad Apostolov wrote: > > > Hi Christoph and Dave, > > > > > > It looks like we may have a problem caused by this patch: > > > > > > http://oss.sgi.com/archives/xfs/2007-07/msg00338.html > > > > > > It makes XFS test 144 to fail if the inode size is 2k. I did > > > some investigation and I think xfs_readdir() returns incorrect > > > next location for shortform directories. When the inode size is > > > 2k, more dir entries fit inline in the inode and test 144 > > > dm_get_dirattrs() starts using the shortform. > > > > > > I think this code here > > > > > > if (filldir(dirent, sfep->name, sfep->namelen, > > > off + xfs_dir2_data_entsize(sfep->namelen), > > > ino, DT_UNKNOWN)) { > > > > > > adds some offset "xfs_dir2_data_entsize(sfep->namelen)" to the > > > next location pointer, which appears to be incorrect and causes > > > directory entries to be skipped on the next call of dm_get_dirattrs(). > > > > It's supposed to be the offset of the next dirent: > > > > On Linux, the dirent structure is defined as follows: > > > > struct dirent { > > ino_t d_ino; /* inode number */ > > >>>>>> off_t d_off; /* offset to the next dirent */ > > unsigned short d_reclen; /* length of this record */ > > unsigned char d_type; /* type of file */ > > char d_name[256]; /* filename */ > > }; > > > > However, looking at the generic filldir() implementation in fs/readdir.c, > > I see that it: > > > > dirent = buf->previous; > > if (dirent) { > > if (__put_user(offset, &dirent->d_off)) > > goto efault; > > } > > > > Puts the offset in the *previous* dirent, not the current one. That > > means that the three calls to XFs makes to filldir() are all incorrect; > > they should be passing the offset of the current object, not the next > > object as teh filldir code stuffs it in the previous dirent. > > > > The reason that dmapi is failing here is that it uses teh offset as the > > cookie to to indicate the next inode to read. However, getdents uses the > > filp->f_pos: > > > > error = vfs_readdir(file, filldir, &buf); > > if (error < 0) > > goto out_putf; > > error = buf.error; > > lastdirent = buf.previous; > > if (lastdirent) { > > if (put_user(file->f_pos, &lastdirent->d_off)) > > error = -EFAULT; > > else > > error = count - buf.count; > > } > > > > and xfs_file_readdir uses that as teh offset for lookups and keeps it up > > to date correctly. hence the getdents code is overwritting the incorrect > > value XFS has been stuffing in there and hence we haven't seen this > > on normal syscalls. > > Except that the hack to go back to double buffering relies on the > filldir offset being pushed off to be the next dirent, and hence > with the patch I sent we set filp->f_pos incorrectly in > xfs_file_readdir()..... > > > > > Ok, patch attached. passes 144 on all inode sizes, otherwise mostly > > untested. > > I did say mostly untested :/ > > Updated patch below (which passes 006 but is still mostly untested). > > Cheers, > > dave. > -- > Dave Chinner > Principal Engineer > SGI Australian Software Group > > --- > fs/xfs/dmapi/xfs_dm.c | 4 ---- > fs/xfs/linux-2.6/xfs_file.c | 4 ++-- > fs/xfs/xfs_dir2_block.c | 6 ++---- > fs/xfs/xfs_dir2_leaf.c | 2 +- > fs/xfs/xfs_dir2_sf.c | 9 +++------ > 5 files changed, 8 insertions(+), 17 deletions(-) > > Index: 2.6.x-xfs-new/fs/xfs/xfs_dir2_block.c > =================================================================== > --- 2.6.x-xfs-new.orig/fs/xfs/xfs_dir2_block.c 2007-08-23 23:03:09.000000000 +1000 > +++ 2.6.x-xfs-new/fs/xfs/xfs_dir2_block.c 2007-12-07 10:23:14.933645761 +1100 > @@ -508,7 +508,7 @@ xfs_dir2_block_getdents( > continue; > > cook = xfs_dir2_db_off_to_dataptr(mp, mp->m_dirdatablk, > - ptr - (char *)block); > + (char *)dep - (char *)block); > ino = be64_to_cpu(dep->inumber); > #if XFS_BIG_INUMS > ino += mp->m_inoadd; > @@ -519,9 +519,7 @@ xfs_dir2_block_getdents( > */ > if (filldir(dirent, dep->name, dep->namelen, cook, > ino, DT_UNKNOWN)) { > - *offset = xfs_dir2_db_off_to_dataptr(mp, > - mp->m_dirdatablk, > - (char *)dep - (char *)block); > + *offset = cook; > xfs_da_brelse(NULL, bp); > return 0; > } > Index: 2.6.x-xfs-new/fs/xfs/xfs_dir2_leaf.c > =================================================================== > --- 2.6.x-xfs-new.orig/fs/xfs/xfs_dir2_leaf.c 2007-08-24 22:24:45.000000000 +1000 > +++ 2.6.x-xfs-new/fs/xfs/xfs_dir2_leaf.c 2007-12-07 10:18:17.623544813 +1100 > @@ -1091,7 +1091,7 @@ xfs_dir2_leaf_getdents( > * Won't fit. Return to caller. > */ > if (filldir(dirent, dep->name, dep->namelen, > - xfs_dir2_byte_to_dataptr(mp, curoff + length), > + xfs_dir2_byte_to_dataptr(mp, curoff), > ino, DT_UNKNOWN)) > break; > > Index: 2.6.x-xfs-new/fs/xfs/xfs_dir2_sf.c > =================================================================== > --- 2.6.x-xfs-new.orig/fs/xfs/xfs_dir2_sf.c 2007-08-23 23:03:09.000000000 +1000 > +++ 2.6.x-xfs-new/fs/xfs/xfs_dir2_sf.c 2007-12-07 10:20:57.887115812 +1100 > @@ -752,7 +752,7 @@ xfs_dir2_sf_getdents( > #if XFS_BIG_INUMS > ino += mp->m_inoadd; > #endif > - if (filldir(dirent, ".", 1, dotdot_offset, ino, DT_DIR)) { > + if (filldir(dirent, ".", 1, dot_offset, ino, DT_DIR)) { > *offset = dot_offset; > return 0; > } > @@ -762,13 +762,11 @@ xfs_dir2_sf_getdents( > * Put .. entry unless we're starting past it. > */ > if (*offset <= dotdot_offset) { > - off = xfs_dir2_db_off_to_dataptr(mp, mp->m_dirdatablk, > - XFS_DIR2_DATA_FIRST_OFFSET); > ino = xfs_dir2_sf_get_inumber(sfp, &sfp->hdr.parent); > #if XFS_BIG_INUMS > ino += mp->m_inoadd; > #endif > - if (filldir(dirent, "..", 2, off, ino, DT_DIR)) { > + if (filldir(dirent, "..", 2, dotdot_offset, ino, DT_DIR)) { > *offset = dotdot_offset; > return 0; > } > @@ -793,8 +791,7 @@ xfs_dir2_sf_getdents( > #endif > > if (filldir(dirent, sfep->name, sfep->namelen, > - off + xfs_dir2_data_entsize(sfep->namelen), > - ino, DT_UNKNOWN)) { > + off, ino, DT_UNKNOWN)) { > *offset = off; > return 0; > } > Index: 2.6.x-xfs-new/fs/xfs/dmapi/xfs_dm.c > =================================================================== > --- 2.6.x-xfs-new.orig/fs/xfs/dmapi/xfs_dm.c 2007-12-03 17:11:46.000000000 +1100 > +++ 2.6.x-xfs-new/fs/xfs/dmapi/xfs_dm.c 2007-12-07 11:25:42.678472255 +1100 > @@ -1772,7 +1772,6 @@ xfs_dm_get_dioinfo( > > typedef struct dm_readdir_cb { > xfs_mount_t *mp; > - xfs_off_t lastoff; > char __user *ubuf; > dm_stat_t __user *lastbuf; > size_t spaceleft; > @@ -1834,7 +1833,6 @@ dm_filldir(void *__buf, const char *name > cb->spaceleft -= statp->_link; > cb->nwritten += statp->_link; > cb->ubuf += statp->_link; > - cb->lastoff = offset; > > return 0; > > @@ -1910,8 +1908,6 @@ xfs_dm_get_dirattrs_rvp( > goto out_kfree; > } > > - loc = cb->lastoff; > - > error = -EFAULT; > if (cb->lastbuf && put_user(0, &cb->lastbuf->_link)) > goto out_kfree; > Index: 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_file.c > =================================================================== > --- 2.6.x-xfs-new.orig/fs/xfs/linux-2.6/xfs_file.c 2007-12-03 18:41:26.000000000 +1100 > +++ 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_file.c 2007-12-07 12:36:52.123061435 +1100 > @@ -357,13 +357,13 @@ xfs_file_readdir( > > reclen = sizeof(struct hack_dirent) + de->namlen; > size -= reclen; > - curr_offset = de->offset /* & 0x7fffffff */; > de = (struct hack_dirent *)((char *)de + reclen); > + curr_offset = de->offset /* & 0x7fffffff */; > } > } > > done: > - if (!error) { > + if (!error) { > if (size == 0) > filp->f_pos = offset & 0x7fffffff; > else if (de) -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Mon Dec 10 13:54:59 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Dec 2007 13:55:19 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with SMTP id lBALsjUa013424 for ; Mon, 10 Dec 2007 13:54:57 -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 QAA19545; Mon, 10 Dec 2007 16:59:55 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 44625) id 0F96358C4C34; Mon, 10 Dec 2007 16:59:55 +1100 (EST) To: sgi.bugs.xfs@engr.sgi.com, xfs@oss.sgi.com Subject: TAKE 964002 - Don't wait for pending I/Os when purging blocks beyond eof. Message-Id: <20071210055955.0F96358C4C34@chook.melbourne.sgi.com> Date: Mon, 10 Dec 2007 16:59:55 +1100 (EST) From: lachlan@sgi.com (Lachlan McIlroy) X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13886 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs Don't wait for pending I/Os when purging blocks beyond eof. On last close of a file we purge blocks beyond eof. The same code is used when we truncate the file size down. In this case we need to wait for any pending I/Os for dirty pages beyond the new eof. For the last close case we are not changing the file size and therefore do not need to wait for any I/Os to complete. This fixes a performance bottleneck where writes into the page cache and cache flushes can become mutually exclusive. Date: Mon Dec 10 16:59:09 AEDT 2007 Workarea: redback.melbourne.sgi.com:/home/lachlan/isms/2.6.x-vniowait Inspected by: pleckie Author: lachlan The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:30220a fs/xfs/xfs_inode.c - 1.489 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode.c.diff?r1=text&tr1=1.489&r2=text&tr2=1.488&f=h - Don't wait for pending I/Os when purging blocks beyond eof. From owner-xfs@oss.sgi.com Mon Dec 10 14:10:07 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Dec 2007 14:10:11 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_43 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id lBAMA6cH016919 for ; Mon, 10 Dec 2007 14:10:07 -0800 X-ASG-Debug-ID: 1197323942-602000770000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from wa-out-1112.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id D997FB24AE1 for ; Mon, 10 Dec 2007 13:59:02 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.176]) by cuda.sgi.com with ESMTP id NkbCM7XRFwH2IHg1 for ; Mon, 10 Dec 2007 13:59:02 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id k22so3863136waf for ; Mon, 10 Dec 2007 13:59:01 -0800 (PST) Received: by 10.115.58.1 with SMTP id l1mr4601683wak.1197142954884; Sat, 08 Dec 2007 11:42:34 -0800 (PST) Received: by 10.114.255.19 with HTTP; Sat, 8 Dec 2007 11:42:34 -0800 (PST) Message-ID: <5d96567b0712081142r4ebb4f2dk25c8b00c30afe0b5@mail.gmail.com> Date: Sat, 8 Dec 2007 21:42:34 +0200 From: Raz To: "Chris Wedgwood" X-ASG-Orig-Subj: Re: mounting raid5 with different unit values Subject: Re: mounting raid5 with different unit values Cc: linux-xfs@oss.sgi.com, "Linux RAID Mailing List" In-Reply-To: <20071008004513.GA13543@puku.stupidest.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <5d96567b0710070015j723810aag20dc3e2866868684@mail.gmail.com> <20071007145213.GA4504@puku.stupidest.org> <20071008004513.GA13543@puku.stupidest.org> X-Barracuda-Connect: wa-out-1112.google.com[209.85.146.176] X-Barracuda-Start-Time: 1197323943 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36260 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13887 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: raziebe@gmail.com Precedence: bulk X-list: xfs Well... this thing actually works just fine with a newer kernel ( 2.6.18-8-el5 centos5 ). I managed to mount / mkfs.xfs over raid5 with a pseudo raid5 unit size, and with the appropriate raid 5 patches and user space access-pattern, I elimintaed in 99% cases the read penalty . I sincerly hope I won't be getting any crashes with this file system tunnings. so ... first, chris and all you xfs guys, many many thanks. Chris, How "dangerous" these tunnings are ? Am I to expect "weird" behaviour of the file system ? On 10/8/07, Chris Wedgwood wrote: > On Sun, Oct 07, 2007 at 11:48:14AM -0400, Justin Piszcz wrote: > > > man mount :) > > Ah of course. > > But those will be more restrictive that what you can specify when you > make the file-system (because mkfs.xfs can aligned the AGs to suit). > -- Raz From owner-xfs@oss.sgi.com Mon Dec 10 14:20:08 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Dec 2007 14:20:27 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id lBAMK5U2018101 for ; Mon, 10 Dec 2007 14:20:08 -0800 X-ASG-Debug-ID: 1197324137-679800540000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from pentafluge.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 64E5EB24B48 for ; Mon, 10 Dec 2007 14:02:17 -0800 (PST) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by cuda.sgi.com with ESMTP id LwaN1nTpRez42lo4 for ; Mon, 10 Dec 2007 14:02:17 -0800 (PST) Received: from hch by pentafluge.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1J1pY4-0007Dv-Dz; Mon, 10 Dec 2007 20:48:20 +0000 Date: Mon, 10 Dec 2007 20:48:20 +0000 From: Christoph Hellwig To: David Chinner Cc: Vlad Apostolov , Christoph Hellwig , Mark Goodwin , xfs-dev , xfs-oss X-ASG-Orig-Subj: Re: DMAPI problem with the new filldir implementation Subject: Re: DMAPI problem with the new filldir implementation Message-ID: <20071210204820.GA27456@infradead.org> References: <475879DB.40705@sgi.com> <20071207002922.GQ115527101@sgi.com> <20071207014940.GS115527101@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071207014940.GS115527101@sgi.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: pentafluge.infradead.org[213.146.154.40] X-Barracuda-Start-Time: 1197324138 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36260 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13888 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs Looks good to me. Might be worth to add a test that does a readdir with a small buffer where only "." fits so we don't regress that special case. From owner-xfs@oss.sgi.com Mon Dec 10 14:20:08 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Dec 2007 14:20:29 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_50 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id lBAMK7l9018129 for ; Mon, 10 Dec 2007 14:20:08 -0800 X-ASG-Debug-ID: 1197324032-6780004e0000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.gmx.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with SMTP id 27D6BB24B0B for ; Mon, 10 Dec 2007 14:00:32 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by cuda.sgi.com with SMTP id uBG2TS0yRDZlXYv2 for ; Mon, 10 Dec 2007 14:00:32 -0800 (PST) Received: (qmail invoked by alias); 10 Dec 2007 21:33:49 -0000 Received: from e182066231.adsl.alicedsl.de (EHLO anheuser) [85.182.66.231] by mail.gmx.net (mp052) with SMTP; 10 Dec 2007 22:33:49 +0100 X-Authenticated: #7882761 X-Provags-ID: V01U2FsdGVkX19V1sxegOlVthzsfD/qVoXG7FVfcEw4FKHEfQQiYU OXnRpMsM4TRX3t From: "Chris" To: X-ASG-Orig-Subj: Unexpected XFS SB number 0x00000000 Subject: Unexpected XFS SB number 0x00000000 Date: Mon, 10 Dec 2007 22:33:35 +0100 Message-ID: <002a01c83b74$52060330$f6120990$@de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acg7dFFfjrt8dob8TBqlN3KkO+00lw== Content-Language: de X-Y-GMX-Trusted: 0 X-Barracuda-Connect: mail.gmx.net[213.165.64.20] X-Barracuda-Start-Time: 1197324034 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36260 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13889 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hsvchris@gmx.de Precedence: bulk X-list: xfs Hello! I'm running a home file server with Debian GNU/Linux 4.0 4.0r1 etch (2.6.18-5-amd64 Kernel) and an Areca ARC-1220 hardware RAID controller. I used to have 4 750GB HDDs connected and set up as RAID 5 array, single volume, single XFS partition (set up during the installation of Debian). No problems so far. Now I added another 750GB HDD to the array, online capacity/volume expansion by the controller finished just fine. My plan was to add the extra space to the above mentioned XFS partition. So I unmounted the partition, started cfdisk, removed the partition table and wrote a new one that included the new free space. After rebooting the partition wasn't mounted, so I couldn't use xfs_growth to expand the filesystem. xfs_check: unexpected XFS SB magic number 0x00000000 xfs_repair -n: Phase 1 - find and verify superblock... bad primary superblock - bad magic number !!! attempting to find secondary superblock.......[...].............found candidate secondary superblock...unable to verify superblock, continuing..........[...]................ .......Sorry, could not find valid secondary superblock Exciting now. I realize the magic number 0x00000000 is probably not a good thing and maybe using fdisk to write a new table was not the way to do it? Any suggestions on restoring the old partition table / magic number or how to proceed? Is there an easy fix or is this a serious problem? Kind Regards, Chris From owner-xfs@oss.sgi.com Mon Dec 10 15:10:08 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Dec 2007 15:10:16 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id lBANA7mg022230 for ; Mon, 10 Dec 2007 15:10:08 -0800 X-ASG-Debug-ID: 1197327349-742f00f90000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from lucidpixels.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 829F646768D for ; Mon, 10 Dec 2007 14:55:49 -0800 (PST) Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by cuda.sgi.com with ESMTP id U5FoYK4DRjlGJqna for ; Mon, 10 Dec 2007 14:55:49 -0800 (PST) Received: by lucidpixels.com (Postfix, from userid 1001) id 790F01C000292; Mon, 10 Dec 2007 17:55:17 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id 75F514019355; Mon, 10 Dec 2007 17:55:17 -0500 (EST) Date: Mon, 10 Dec 2007 17:55:17 -0500 (EST) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: Chris cc: linux-xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Unexpected XFS SB number 0x00000000 Subject: Re: Unexpected XFS SB number 0x00000000 In-Reply-To: <002a01c83b74$52060330$f6120990$@de> Message-ID: References: <002a01c83b74$52060330$f6120990$@de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Barracuda-Connect: lucidpixels.com[75.144.35.66] X-Barracuda-Start-Time: 1197327349 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36264 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13890 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs On Mon, 10 Dec 2007, Chris wrote: > Hello! > > I'm running a home file server with Debian GNU/Linux 4.0 4.0r1 etch > (2.6.18-5-amd64 Kernel) and an Areca ARC-1220 hardware RAID controller. > I used to have 4 750GB HDDs connected and set up as RAID 5 array, single > volume, single XFS partition (set up during the installation of Debian). No > problems so far. > > Now I added another 750GB HDD to the array, online capacity/volume expansion > by the controller finished just fine. > My plan was to add the extra space to the above mentioned XFS partition. So > I unmounted the partition, started cfdisk, removed the partition table and > wrote a new one that included the new free space. > After rebooting the partition wasn't mounted, so I couldn't use xfs_growth > to expand the filesystem. > > xfs_check: unexpected XFS SB magic number 0x00000000 > > xfs_repair -n: > Phase 1 - find and verify superblock... > bad primary superblock - bad magic number !!! > attempting to find secondary superblock.......[...].............found > candidate secondary superblock...unable to verify superblock, > continuing..........[...]................ > .......Sorry, could not find valid secondary superblock > Exciting now. > > I realize the magic number 0x00000000 is probably not a good thing and maybe > using fdisk to write a new table was not the way to do it? > Any suggestions on restoring the old partition table / magic number or how > to proceed? Is there an easy fix or is this a serious problem? > > Kind Regards, > Chris > > When I grew mine, I used mdadm/raid5, expanded the array and then you run xfs_growfs on the mounted filesystem and it worked. Wiping out the partition is not the way to do it. Justin. From owner-xfs@oss.sgi.com Mon Dec 10 15:20:10 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Dec 2007 15:20:13 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id lBANK8mU023305 for ; Mon, 10 Dec 2007 15:20:09 -0800 X-ASG-Debug-ID: 1197327669-746d00ea0000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mx1.redhat.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 72BE14679D2 for ; Mon, 10 Dec 2007 15:01:09 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by cuda.sgi.com with ESMTP id Eb6l5DziQ3rbjaYC for ; Mon, 10 Dec 2007 15:01:09 -0800 (PST) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.1) with ESMTP id lBAMeNgv007821; Mon, 10 Dec 2007 17:40:23 -0500 Received: from lacrosse.corp.redhat.com (lacrosse.corp.redhat.com [172.16.52.154]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id lBAMeNXd029435; Mon, 10 Dec 2007 17:40:23 -0500 Received: from neon.msp.redhat.com (neon.msp.redhat.com [10.15.80.10]) by lacrosse.corp.redhat.com (8.12.11.20060308/8.11.6) with ESMTP id lBAMeMqp019877; Mon, 10 Dec 2007 17:40:22 -0500 Message-ID: <475DC056.3000502@sandeen.net> Date: Mon, 10 Dec 2007 16:40:22 -0600 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Chris CC: linux-xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Unexpected XFS SB number 0x00000000 Subject: Re: Unexpected XFS SB number 0x00000000 References: <002a01c83b74$52060330$f6120990$@de> In-Reply-To: <002a01c83b74$52060330$f6120990$@de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: mx1.redhat.com[66.187.233.31] X-Barracuda-Start-Time: 1197327670 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36264 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13891 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Chris wrote: > Hello! > > I'm running a home file server with Debian GNU/Linux 4.0 4.0r1 etch > (2.6.18-5-amd64 Kernel) and an Areca ARC-1220 hardware RAID controller. > I used to have 4 750GB HDDs connected and set up as RAID 5 array, single > volume, single XFS partition (set up during the installation of Debian). No > problems so far. > > Now I added another 750GB HDD to the array, online capacity/volume expansion > by the controller finished just fine. > My plan was to add the extra space to the above mentioned XFS partition. So > I unmounted the partition, started cfdisk, removed the partition table and > wrote a new one that included the new free space. > After rebooting the partition wasn't mounted, so I couldn't use xfs_growth > to expand the filesystem. > > xfs_check: unexpected XFS SB magic number 0x00000000 Did your new partition table start in exactly the same place? Can you find the string "XFSB" anywhere near where your old partition started? -Eric From owner-xfs@oss.sgi.com Mon Dec 10 15:30:08 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Dec 2007 15:30:15 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: **** X-Spam-Status: No, score=4.0 required=5.0 tests=BAYES_99 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id lBANU7tg024291 for ; Mon, 10 Dec 2007 15:30:08 -0800 X-ASG-Debug-ID: 1197328649-6030012a0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from smtp-out3.libero.it (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 6FB9CB26028 for ; Mon, 10 Dec 2007 15:17:29 -0800 (PST) Received: from smtp-out3.libero.it (smtp-out3.libero.it [212.52.84.43]) by cuda.sgi.com with ESMTP id 7IX7T3sqJz2UMKO5 for ; Mon, 10 Dec 2007 15:17:29 -0800 (PST) Received: from mailrelay11.libero.it (192.168.32.128) by smtp-out3.libero.it (7.3.120) id 4688F31B10B7E5FE for xfs@oss.sgi.com; Sun, 9 Dec 2007 18:52:06 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtYjAA+6W0dTLLte/2dsb2JhbAAIiXY Received: from unknown (HELO libero.it) ([192.168.17.13]) by outrelay11.libero.it with ESMTP; 09 Dec 2007 18:52:06 +0100 Date: Sun, 9 Dec 2007 18:52:06 +0100 Message-Id: X-ASG-Orig-Subj: Serial number: 6666/05 Subject: Serial number: 6666/05 MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: text/plain; charset=iso-8859-1 From: "msperrymichel" X-XaM3-API-Version: 4.3 (R1) (B3pl19) X-SenderIP: 83.44.187.94 X-Barracuda-Connect: smtp-out3.libero.it[212.52.84.43] X-Barracuda-Start-Time: 1197328650 X-Barracuda-Bayes: INNOCENT GLOBAL 0.4679 1.0000 0.0000 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.32 X-Barracuda-Spam-Status: No, SCORE=0.32 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests=MISSING_HEADERS, TO_CC_NONE X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36265 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.19 MISSING_HEADERS Missing To: header 0.13 TO_CC_NONE No To: or Cc: header To: undisclosed-recipients:; X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id lBANU8tg024314 X-archive-position: 13892 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: msperrymichel@libero.it Precedence: bulk X-list: xfs Serial number: 6666/05 Your winning information’s for €500,000.00 in category 'A' email lottery are as below. ticket number: 1001-558962-5899. Serial number: 6666/05 Reference number: 7743909/es Contact Mr.Richard Halbert Tel: + 34-635-112-356 Fax: +34-605-196-898 Email:claimdepatminfoes@yahoo.es Yours Sincerely, Mrs. Seville Antonio. From owner-xfs@oss.sgi.com Mon Dec 10 15:49:52 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Dec 2007 15:49:59 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id lBANnmEo025882 for ; Mon, 10 Dec 2007 15:49:52 -0800 X-ASG-Debug-ID: 1197330598-7499016e0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mx1.redhat.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 2A688467BDE; Mon, 10 Dec 2007 15:49:58 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by cuda.sgi.com with ESMTP id 9EoTdWDQIIauOags; Mon, 10 Dec 2007 15:49:58 -0800 (PST) Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.1) with ESMTP id lBAHojHV013965; Mon, 10 Dec 2007 12:50:45 -0500 Received: from lacrosse.corp.redhat.com (lacrosse.corp.redhat.com [172.16.52.154]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id lBAHojFo006098; Mon, 10 Dec 2007 12:50:45 -0500 Received: from neon.msp.redhat.com (neon.msp.redhat.com [10.15.80.10]) by lacrosse.corp.redhat.com (8.12.11.20060308/8.11.6) with ESMTP id lBAHoiOt014580; Mon, 10 Dec 2007 12:50:44 -0500 Message-ID: <475D7C74.6080004@sandeen.net> Date: Mon, 10 Dec 2007 11:50:44 -0600 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: David Chinner CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: TAKE 972756 - Implement fallocate. Subject: Re: TAKE 972756 - Implement fallocate. References: <20071102024314.9BF3458C38F7@chook.melbourne.sgi.com> In-Reply-To: <20071102024314.9BF3458C38F7@chook.melbourne.sgi.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: mx1.redhat.com[66.187.233.31] X-Barracuda-Start-Time: 1197330599 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36268 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13893 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs David Chinner wrote: > Implement fallocate. > > Implement the new generic callout for file preallocation. > Atomically change the file size if requested. > > > Date: Fri Nov 2 13:42:52 AEDT 2007 > Workarea: chook.melbourne.sgi.com:/build/dgc/isms/2.6.x-xfs > Inspected by: hch@infradead.org > > The following file(s) were checked into: > longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb > > > Modid: xfs-linux-melb:xfs-kern:30009a > fs/xfs/linux-2.6/xfs_iops.c - 1.268 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/> linux-2.6/xfs_iops.c.diff?r1=text&tr1=1.268&r2=text&tr2=1.267&f=h > http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_iops.c.diff?r1=text&tr1=1.268&r2=text&tr2=1.267&f=h > - implement ->fallocate() > > > Is this ever going to go upstream...? -eric From owner-xfs@oss.sgi.com Mon Dec 10 16:41:19 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Dec 2007 16:41:24 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.10/SuSE Linux 0.7) with ESMTP id lBB0fHWR001623 for ; Mon, 10 Dec 2007 16:41:19 -0800 X-ASG-Debug-ID: 1197333683-677e02120000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.gmx.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with SMTP id 009CBB26F1F for ; Mon, 10 Dec 2007 16:41:24 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by cuda.sgi.com with SMTP id 4x1upPEhdFTqWUUK for ; Mon, 10 Dec 2007 16:41:24 -0800 (PST) Received: (qmail invoked by alias); 11 Dec 2007 00:41:21 -0000 Received: from e182066231.adsl.alicedsl.de (EHLO anheuser) [85.182.66.231] by mail.gmx.net (mp042) with SMTP; 11 Dec 2007 01:41:21 +0100 X-Authenticated: #7882761 X-Provags-ID: V01U2FsdGVkX1/ggLhhBC3gTL2n4RunhCKoxoRDLFx5W7DwZGsQ7v /3dqPxEdxY8UXt From: "Chris" To: "'Eric Sandeen'" Cc: References: <002a01c83b74$52060330$f6120990$@de> <475DC056.3000502@sandeen.net> In-Reply-To: <475DC056.3000502@sandeen.net> X-ASG-Orig-Subj: AW: Unexpected XFS SB number 0x00000000 Subject: AW: Unexpected XFS SB number 0x00000000 Date: Tue, 11 Dec 2007 01:41:07 +0100 Message-ID: <003401c83b8e$84c1d730$8e458590$@de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acg7fajbbY3qepCUTHyavxeML5xisgAC5Avw Content-Language: de X-Y-GMX-Trusted: 0 X-Barracuda-Connect: mail.gmx.net[213.165.64.20] X-Barracuda-Start-Time: 1197333689 X-Barracuda-Bayes: INNOCENT GLOBAL 0.3569 1.0000 -0.1288 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -0.13 X-Barracuda-Spam-Status: No, SCORE=-0.13 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36271 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13894 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hsvchris@gmx.de Precedence: bulk X-list: xfs > Did your new partition table start in exactly the same place? > I assumed it would be in the same place... I guess there is no way to find out what the old one looked like? > Can you find the string "XFSB" anywhere near where your old partition > started? > I can try to do so...how? :) When I look into the partition with cfdisk, I can see what cylinders/heads/sectors it uses. But I'm sure there are other tools? Interestingly, after a reboot cfdisk shows me a 801575.31 MB partition and 2199023.26 MB free space, although I wrote a single partition of 3000598.57 MB into the table before rebooting. From owner-xfs@oss.sgi.com Mon Dec 10 17:06:53 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Dec 2007 17:06:57 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBB16qoT003988 for ; Mon, 10 Dec 2007 17:06:53 -0800 X-ASG-Debug-ID: 1197335221-675500070000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.gmx.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with SMTP id B55D4B26DFD for ; Mon, 10 Dec 2007 17:07:02 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by cuda.sgi.com with SMTP id sjBUCivXJi2OK1Ne for ; Mon, 10 Dec 2007 17:07:02 -0800 (PST) Received: (qmail invoked by alias); 11 Dec 2007 01:06:59 -0000 Received: from e182066231.adsl.alicedsl.de (EHLO anheuser) [85.182.66.231] by mail.gmx.net (mp018) with SMTP; 11 Dec 2007 02:06:59 +0100 X-Authenticated: #7882761 X-Provags-ID: V01U2FsdGVkX19HDOx3buRHQHF55ZPvdgGEAgyj6muuDdIW/kQCJk l2jFD/skpzBO0T From: "Chris" To: "'Eric Sandeen'" Cc: References: <002a01c83b74$52060330$f6120990$@de> <475DC056.3000502@sandeen.net> In-Reply-To: X-ASG-Orig-Subj: Re: Unexpected XFS SB number 0x00000000 Subject: Re: Unexpected XFS SB number 0x00000000 Date: Tue, 11 Dec 2007 02:06:43 +0100 Message-ID: <000301c83b92$191f6110$4b5e2330$@de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acg7fajbbY3qepCUTHyavxeML5xisgAC5AvwAAHnh9A= Content-Language: de X-Y-GMX-Trusted: 0 X-Barracuda-Connect: mail.gmx.net[213.165.64.20] X-Barracuda-Start-Time: 1197335223 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0989 1.0000 -1.3991 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.40 X-Barracuda-Spam-Status: No, SCORE=-1.40 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36273 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13895 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hsvchris@gmx.de Precedence: bulk X-list: xfs > > Did your new partition table start in exactly the same place? > > > > I assumed it would be in the same place... > I guess there is no way to find out what the old one looked like? > > > Can you find the string "XFSB" anywhere near where your old partition > > started? > > > > I can try to do so...how? :) > When I look into the partition with cfdisk, I can see what cylinders/heads/sectors it uses. But I'm > sure there are other tools? > > Interestingly, after a reboot cfdisk shows me a 801575.31 MB partition and 2199023.26 MB free space, > although I wrote a single partition of 3000598.57 MB into the table before rebooting. I just tested some more and using parted found out the following: (parted) print Warning: /dev/sdb contains GPT signatures, indicating that is has a GPT table. However, it does not have a valid fake msdos partition table, as it should. Perhaps it was corrupted -- possibly by a program that doesn't understand GPT partition tables. Or perhaps you deleted the GPT table, and are now using an msdos partition table. Is this a GPT partition table? Yes/No? y Disk /dev/sdb: 3001GB Sector size (logical/physical): 512B/512B Partition Table: gpt Number Start End Size File system Name Flags 1 17.4kB 22250GB 22250GB xfs So it seems that parted can still "see" the old table. But it doesn't have support for resizing xfs partitions... From owner-xfs@oss.sgi.com Mon Dec 10 17:26:55 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Dec 2007 17:26:59 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBB1QrD9005610 for ; Mon, 10 Dec 2007 17:26:55 -0800 X-ASG-Debug-ID: 1197336423-574300860000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 4AB45468342 for ; Mon, 10 Dec 2007 17:27:03 -0800 (PST) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id BRg3RdE14tDwlKJT for ; Mon, 10 Dec 2007 17:27:03 -0800 (PST) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 2B3DB18234C9E; Mon, 10 Dec 2007 19:26:31 -0600 (CST) Message-ID: <475DE745.9040907@sandeen.net> Date: Mon, 10 Dec 2007 19:26:29 -0600 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Chris CC: linux-xfs@oss.sgi.com X-ASG-Orig-Subj: Re: AW: Unexpected XFS SB number 0x00000000 Subject: Re: AW: Unexpected XFS SB number 0x00000000 References: <002a01c83b74$52060330$f6120990$@de> <475DC056.3000502@sandeen.net> <003401c83b8e$84c1d730$8e458590$@de> In-Reply-To: <003401c83b8e$84c1d730$8e458590$@de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1197336424 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36274 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13896 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Chris wrote: >> Did your new partition table start in exactly the same place? >> > > I assumed it would be in the same place... > I guess there is no way to find out what the old one looked like? > >> Can you find the string "XFSB" anywhere near where your old partition >> started? >> > > I can try to do so...how? :) > When I look into the partition with cfdisk, I can see what > cylinders/heads/sectors it uses. But I'm sure there are other tools? > > Interestingly, after a reboot cfdisk shows me a 801575.31 MB partition and > 2199023.26 MB free space, although I wrote a single partition of 3000598.57 > MB into the table before rebooting. fat partitions can't be > 2T -Eric From owner-xfs@oss.sgi.com Mon Dec 10 18:13:22 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Dec 2007 18:13:26 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBB2DJuF008176 for ; Mon, 10 Dec 2007 18:13:22 -0800 X-ASG-Debug-ID: 1197339209-1c35002c0000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 331204687CD for ; Mon, 10 Dec 2007 18:13:29 -0800 (PST) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id TPazJcRCm8a9fV3E for ; Mon, 10 Dec 2007 18:13:29 -0800 (PST) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 8D79B18004494; Mon, 10 Dec 2007 20:12:57 -0600 (CST) Message-ID: <475DF228.80306@sandeen.net> Date: Mon, 10 Dec 2007 20:12:56 -0600 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Chris CC: linux-xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Unexpected XFS SB number 0x00000000 Subject: Re: Unexpected XFS SB number 0x00000000 References: <002a01c83b74$52060330$f6120990$@de> <475DC056.3000502@sandeen.net> <000301c83b92$191f6110$4b5e2330$@de> In-Reply-To: <000301c83b92$191f6110$4b5e2330$@de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1197339210 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0004 1.0000 -2.0186 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36276 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13897 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Chris wrote: > I just tested some more and using parted found out the following: > > (parted) print > Warning: /dev/sdb contains GPT signatures, indicating that is has a GPT > table. However, it does not have a valid fake msdos partition table, as it > should. Perhaps it was corrupted -- possibly by a program that doesn't > understand GPT partition tables. Or perhaps you deleted the GPT table, and > are now using an msdos partition table. Is this a GPT partition table? > Yes/No? y > > Disk /dev/sdb: 3001GB > Sector size (logical/physical): 512B/512B > Partition Table: gpt > > Number Start End Size File system Name > Flags > 1 17.4kB 22250GB 22250GB xfs > > > So it seems that parted can still "see" the old table. But it doesn't have > support for resizing xfs partitions... So, did you originally have a gpt or an msdos partition table? From owner-xfs@oss.sgi.com Mon Dec 10 18:53:30 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Dec 2007 18:53:34 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id lBB2rPCs011039 for ; Mon, 10 Dec 2007 18:53:29 -0800 Received: from timothy-shimmins-power-mac-g5.local (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA18108; Tue, 11 Dec 2007 13:53:24 +1100 Message-ID: <475DFC42.1080300@sgi.com> Date: Tue, 11 Dec 2007 13:56:02 +1100 From: Timothy Shimmin User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Christoph Hellwig CC: xfs@oss.sgi.com Subject: Re: [PATCH] xfs: kill last 2.4 ifdef leftover References: <20071130093836.GA2949@lst.de> In-Reply-To: <20071130093836.GA2949@lst.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13898 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs Christoph Hellwig wrote: > Signed-off-by: Christoph Hellwig > > Index: linux-2.6-xfs/fs/xfs/xfs.h > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/xfs.h 2007-09-29 11:48:48.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/xfs.h 2007-09-29 11:49:03.000000000 +0200 > @@ -41,11 +41,6 @@ > #define XFS_FILESTREAMS_TRACE 1 > #endif > > -#include > -#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,0) > #include > -#else > -#include > -#endif > > #endif /* __XFS_H__ */ > I'll check it in. Ta. --Tim From owner-xfs@oss.sgi.com Mon Dec 10 20:24:55 2007 Received: with ECARTIS (v1.0.0; list xfs); Mon, 10 Dec 2007 20:24:59 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id lBB4OoiY022127 for ; Mon, 10 Dec 2007 20:24: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 PAA19873; Tue, 11 Dec 2007 15:24:56 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 1116) id 7758F58C4C34; Tue, 11 Dec 2007 15:24:56 +1100 (EST) To: xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: PARTIAL TAKE 971186 - kill last 2.4 ifdef leftover Message-Id: <20071211042456.7758F58C4C34@chook.melbourne.sgi.com> Date: Tue, 11 Dec 2007 15:24:56 +1100 (EST) From: tes@sgi.com (Tim Shimmin) X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13899 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs kill last 2.4 ifdef leftover Signed-off-by: Christoph Hellwig Date: Tue Dec 11 15:24:15 AEDT 2007 Workarea: chook.melbourne.sgi.com:/build/tes/2.6.x-xfs-quilt Inspected by: hch@lst.de The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:30226a fs/xfs/xfs.h - 1.51 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs.h.diff?r1=text&tr1=1.51&r2=text&tr2=1.50&f=h - kill last 2.4 ifdef leftover From owner-xfs@oss.sgi.com Tue Dec 11 00:11:12 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 11 Dec 2007 00:11:17 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBB8B906007037 for ; Tue, 11 Dec 2007 00:11:12 -0800 X-ASG-Debug-ID: 1197360678-154500ae0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from pentafluge.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 87E9346987C; Tue, 11 Dec 2007 00:11:19 -0800 (PST) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by cuda.sgi.com with ESMTP id r2hXjCKxuChlnRJT; Tue, 11 Dec 2007 00:11:19 -0800 (PST) Received: from hch by pentafluge.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1J20Cz-00052n-K4; Tue, 11 Dec 2007 08:11:17 +0000 Date: Tue, 11 Dec 2007 08:11:17 +0000 From: Christoph Hellwig To: Lachlan McIlroy Cc: sgi.bugs.xfs@engr.sgi.com, xfs@oss.sgi.com X-ASG-Orig-Subj: Re: TAKE 964002 - Don't wait for pending I/Os when purging blocks beyond eof. Subject: Re: TAKE 964002 - Don't wait for pending I/Os when purging blocks beyond eof. Message-ID: <20071211081117.GB19213@infradead.org> References: <20071210055955.0F96358C4C34@chook.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071210055955.0F96358C4C34@chook.melbourne.sgi.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: pentafluge.infradead.org[213.146.154.40] X-Barracuda-Start-Time: 1197360680 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36299 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5083/Mon Dec 10 22:22:03 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13900 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs On Mon, Dec 10, 2007 at 04:59:55PM +1100, Lachlan McIlroy wrote: > Don't wait for pending I/Os when purging blocks beyond eof. > > On last close of a file we purge blocks beyond eof. The same > code is used when we truncate the file size down. In this case > we need to wait for any pending I/Os for dirty pages beyond the > new eof. For the last close case we are not changing the file > size and therefore do not need to wait for any I/Os to complete. > This fixes a performance bottleneck where writes into the page > cache and cache flushes can become mutually exclusive. I think I shortened from of this should be in the comment above the conditional vn_iowait intead of the current /* wait for the completion of any pending DIOs */ which is wrong given that we don't wait for all pending direct I/O requests.. (and vn_iowait doesn't wait for direct I/O anyway) From owner-xfs@oss.sgi.com Tue Dec 11 03:36:32 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 11 Dec 2007 03:36:36 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBBBaVG3028616 for ; Tue, 11 Dec 2007 03:36:32 -0800 X-ASG-Debug-ID: 1197372999-3e8800d00000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from puma.mxtelecom.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id CB3AE459796 for ; Tue, 11 Dec 2007 03:36:39 -0800 (PST) Received: from puma.mxtelecom.com (mx1.mxtelecom.com [87.86.212.101]) by cuda.sgi.com with ESMTP id Hg8e1QwsQM5EqJEn for ; Tue, 11 Dec 2007 03:36:39 -0800 (PST) Received: from wings.mxtelecom.com ([192.168.2.111] helo=[127.0.0.1]) by puma.mxtelecom.com with esmtp (Exim 4.66) (envelope-from ) id 1J23Pg-0005AI-Lu; Tue, 11 Dec 2007 11:36:36 +0000 Message-ID: <475E76AB.705@mxtelecom.com> Date: Tue, 11 Dec 2007 11:38:19 +0000 From: Matthew Hodgson Organization: MX Telecom Ltd User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: xfs@oss.sgi.com X-ASG-Orig-Subj: Zero-copy Block IO with XFS Subject: Zero-copy Block IO with XFS Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: mx1.mxtelecom.com[87.86.212.101] X-Barracuda-Start-Time: 1197373002 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36309 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5090/Tue Dec 11 02:08:19 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13901 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: matthew@mxtelecom.com Precedence: bulk X-list: xfs Hi all, I'm experimenting with using XFS with a network block device (DST), and have come up against the problem that when writing data to the network, it uses kernel_sendpage to hand the page presented at the BIO layer to the network stack. It then completes the block IO request. The problem arises when XFS proceeds to then reuse that page before the NIC actually sends it. Particularly if TX checksumming or TCP segmentation is being offloaded to the NIC, it seems that the NIC will try to access to page after the BIO request has returned, and so operate on stale data. I assume the same problem might happen in the case of TCP retransmits or similar. The motivation for using sendpage rather than sendmsg (or using sendpage on a copy of the original page) is to try to ensure speed by a zero-copy path through the subsystem. Is there any way at all in which XFS would be able to (theoretically) expose an API to allow an underlying block device to retain ownership of pages until it's done with them, so as to avoid a potentially needless copy? Or is there another way of achieving this? thanks in advance, Matthew. -- Matthew Hodgson Media & Systems Project Manager Tel: +44 (0) 845 666 7778 http://www.mxtelecom.com From owner-xfs@oss.sgi.com Tue Dec 11 04:47:54 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 11 Dec 2007 04:47:59 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBBClrKr007559 for ; Tue, 11 Dec 2007 04:47:54 -0800 X-ASG-Debug-ID: 1197377281-22d900830000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.gmx.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with SMTP id 9FD6746A4F1 for ; Tue, 11 Dec 2007 04:48:01 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by cuda.sgi.com with SMTP id m9PnsxGhtKCjVmYK for ; Tue, 11 Dec 2007 04:48:01 -0800 (PST) Received: (qmail invoked by alias); 11 Dec 2007 12:47:59 -0000 Received: from d191156.adsl.hansenet.de (EHLO anheuser) [80.171.191.156] by mail.gmx.net (mp016) with SMTP; 11 Dec 2007 13:47:59 +0100 X-Authenticated: #7882761 X-Provags-ID: V01U2FsdGVkX19/0rgJKt5/8hoIEdkhMrO3o54VYP65aZhg/2TfTl SQMu9otQ7xVX96 From: "Chris" To: "'Chris'" Cc: References: In-Reply-To: X-ASG-Orig-Subj: Re: Unexpected XFS SB number 0x00000000 Subject: Re: Unexpected XFS SB number 0x00000000 Date: Tue, 11 Dec 2007 13:47:44 +0100 Message-ID: <000001c83bf4$06a8bd80$13fa3880$@de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acg7dFFfjrt8dob8TBqlN3KkO+00lwAfmlAQ Content-Language: de X-Y-GMX-Trusted: 0 X-Barracuda-Connect: mail.gmx.net[213.165.64.20] X-Barracuda-Start-Time: 1197377284 X-Barracuda-Bayes: INNOCENT GLOBAL 0.4166 1.0000 0.0000 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36317 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5090/Tue Dec 11 02:08:19 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13902 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hsvchris@gmx.de Precedence: bulk X-list: xfs Seems like using parted to write a new partition table did the job for me. Used 17.4kB as start and 3000GB as end. Now being able to mount the partition successfully I ran xfs_growfs. Afterwards, I still had to do an xfs_repair though, because there were a lot of (seemingly) random errors when accessing certain files. Everthing normal now... From owner-xfs@oss.sgi.com Tue Dec 11 08:39:10 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 11 Dec 2007 08:39:16 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.7 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBBGd894031048 for ; Tue, 11 Dec 2007 08:39:10 -0800 X-ASG-Debug-ID: 1197391152-21c201b80000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from nz-out-0506.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 5F83FB30921 for ; Tue, 11 Dec 2007 08:39:12 -0800 (PST) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.237]) by cuda.sgi.com with ESMTP id 71Iumilisj8860sl for ; Tue, 11 Dec 2007 08:39:12 -0800 (PST) Received: by nz-out-0506.google.com with SMTP id x3so810090nzd for ; Tue, 11 Dec 2007 08:39:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=EoQhLH3d07lasgLt0Vbjoy2ne3lzjoRe1JHABrO0rLM=; b=sxv/wdEllur2XekfJdSeNrJU8xDS3qGSAn2U/x8ZPFAkqDGsSmZVduNp5wSwSKw9sBsJM8lhpsfJ/iG9UP7aI7O9u8s1eITWDhJ6Kgq9j/8hPCNEA3LOMY8x/BrMsrimyMu2ym0a+5poz+BZPCQmQHF6NgCVfHKteiYNswXuSF8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=NGJzMK/4cjvR6/2vSznV6kV9IKLBAg1kms4ZelagjXp2dYgkUUFG/HOEXsAP2vocriYbmxbvL8qp3QmWBuZEpx1ORpFkKh224XwZql8t0Tz2lz9gR782fCf4QvVFunzM6ykEvmsvH2FrM+0/ubMgZYQetAxBNYV294/NpPwPZ9U= Received: by 10.142.102.5 with SMTP id z5mr3711360wfb.1197391145820; Tue, 11 Dec 2007 08:39:05 -0800 (PST) Received: by 10.142.162.19 with HTTP; Tue, 11 Dec 2007 08:39:05 -0800 (PST) Message-ID: Date: Tue, 11 Dec 2007 22:09:05 +0530 From: "Bhagi rathi" To: "Matthew Hodgson" X-ASG-Orig-Subj: Re: Zero-copy Block IO with XFS Subject: Re: Zero-copy Block IO with XFS Cc: xfs@oss.sgi.com In-Reply-To: <475E76AB.705@mxtelecom.com> MIME-Version: 1.0 References: <475E76AB.705@mxtelecom.com> X-Barracuda-Connect: nz-out-0506.google.com[64.233.162.237] X-Barracuda-Start-Time: 1197391159 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36332 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message X-Virus-Scanned: ClamAV 0.91.2/5091/Tue Dec 11 04:41:37 2007 on oss.sgi.com X-Virus-Status: Clean Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-length: 1878 X-archive-position: 13903 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jahnu77@gmail.com Precedence: bulk X-list: xfs On Dec 11, 2007 5:08 PM, Matthew Hodgson wrote: > Hi all, > > I'm experimenting with using XFS with a network block device (DST), and > have come up against the problem that when writing data to the network, > it uses kernel_sendpage to hand the page presented at the BIO layer to > the network stack. It then completes the block IO request. Actually, you can pass a sendpage read actor which takes a reference on the page which ensures valid page exists with you. As long as you have ref on the page and no truncate to the same file, you can safely access the file. Once NIC sends the data over wire, you can do put_page. This should work. By the way, linux sendfile does something similar to the above. Look into read actor of nfs server sendfile usage. -Cheers, Bhagi. > > > The problem arises when XFS proceeds to then reuse that page before the > NIC actually sends it. Particularly if TX checksumming or TCP > segmentation is being offloaded to the NIC, it seems that the NIC will > try to access to page after the BIO request has returned, and so operate > on stale data. I assume the same problem might happen in the case of > TCP retransmits or similar. The motivation for using sendpage rather > than sendmsg (or using sendpage on a copy of the original page) is to > try to ensure speed by a zero-copy path through the subsystem. > > Is there any way at all in which XFS would be able to (theoretically) > expose an API to allow an underlying block device to retain ownership of > pages until it's done with them, so as to avoid a potentially needless > copy? Or is there another way of achieving this? > > thanks in advance, > > Matthew. > > > -- > Matthew Hodgson > Media & Systems Project Manager > Tel: +44 (0) 845 666 7778 > http://www.mxtelecom.com > > > [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Tue Dec 11 08:52:15 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 11 Dec 2007 08:52:20 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.7 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, J_CHICKENPOX_42 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBBGqBXF032588 for ; Tue, 11 Dec 2007 08:52:15 -0800 X-ASG-Debug-ID: 1197391937-174200160000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from nz-out-0506.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 55D1446BC2E for ; Tue, 11 Dec 2007 08:52:17 -0800 (PST) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.229]) by cuda.sgi.com with ESMTP id f25HHsNt7cPClegT for ; Tue, 11 Dec 2007 08:52:17 -0800 (PST) Received: by nz-out-0506.google.com with SMTP id x3so815140nzd for ; Tue, 11 Dec 2007 08:52:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=BarU9r+mLohefHrHql1ZEq+PtqPr8gaEahVjFXw+qCM=; b=nI8PlZKMr7I2kSaQAVcdSrEZ8SStn7pOqEcVcVGHkuBJ2ssuA5xQKt7q4oTawnouwnKieoIfatdr/fWEPJQEtEiYUd1X1je54M/uxHfGOJlVJXCBVeiOU4NY1/cDmjUeTx2LhZysMcmDt16ILBXhGE8Hl1t2CqudA4KoQLpXxUM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=j6EkM4nN+evwpYTUD+N6Yfwwm11z4wYXNIeMUPjTjlf6P/B2P9VxaChlxFJR+k0h8dFmw+1cxIQetqWD4XY4hwganvnhzdeYogYEg3z5ezP+q+pZYzQ4jXJSS/Z8nZnuYv4EcuHedtGQKSYlLvyRSymoMFpRBudomVJQKe+iOH0= Received: by 10.142.251.9 with SMTP id y9mr3729872wfh.1197391934673; Tue, 11 Dec 2007 08:52:14 -0800 (PST) Received: by 10.142.162.19 with HTTP; Tue, 11 Dec 2007 08:52:14 -0800 (PST) Message-ID: Date: Tue, 11 Dec 2007 22:22:14 +0530 From: "Bhagi rathi" To: "Lachlan McIlroy" X-ASG-Orig-Subj: Re: TAKE 964002 - Don't wait for pending I/Os when purging blocks beyond eof. Subject: Re: TAKE 964002 - Don't wait for pending I/Os when purging blocks beyond eof. Cc: sgi.bugs.xfs@engr.sgi.com, xfs@oss.sgi.com In-Reply-To: <20071210055955.0F96358C4C34@chook.melbourne.sgi.com> MIME-Version: 1.0 References: <20071210055955.0F96358C4C34@chook.melbourne.sgi.com> X-Barracuda-Connect: nz-out-0506.google.com[64.233.162.229] X-Barracuda-Start-Time: 1197391941 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36333 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message X-Virus-Scanned: ClamAV 0.91.2/5091/Tue Dec 11 04:41:37 2007 on oss.sgi.com X-Virus-Status: Clean Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-length: 2098 X-archive-position: 13904 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jahnu77@gmail.com Precedence: bulk X-list: xfs On Dec 10, 2007 11:29 AM, Lachlan McIlroy wrote: > Don't wait for pending I/Os when purging blocks beyond eof. > > On last close of a file we purge blocks beyond eof. The same > code is used when we truncate the file size down. In this case > we need to wait for any pending I/Os for dirty pages beyond the > new eof. For the last close case we are not changing the file > size and therefore do not need to wait for any I/Os to complete. > This fixes a performance bottleneck where writes into the page > cache and cache flushes can become mutually exclusive. Lachlan, How the following is addressed if we don't wait for I/O to complete during close of the file and issue truncate: - We didn't waited for the I/O to complete - Truncated blocks beyond EOF. - These blocks are re-used for another transaction as meta-data. - Meta-data flush was induced. However the flush of meta-data reached first before the data I/O because of some issues with under-lying driver. Later the file I/O over-written the meta-data I/O. We have corruption of data. It seems the corruption could be in various ways. Isn't this the reason why truncate has to wait for the I/O to complete? I believe fundamental problem is once the blocks are free'ed, the re-association should not expect some I/O in concurrent to those same block addresses. -Cheers, Bhagi. > > > Date: Mon Dec 10 16:59:09 AEDT 2007 > Workarea: redback.melbourne.sgi.com:/home/lachlan/isms/2.6.x-vniowait > Inspected by: pleckie > Author: lachlan > > The following file(s) were checked into: > longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb > > > Modid: xfs-linux-melb:xfs-kern:30220a > fs/xfs/xfs_inode.c - 1.489 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/> xfs_inode.c.diff?r1=text&tr1=1.489&r2=text&tr2=1.488&f=h > > http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode.c.diff?r1=text&tr1=1.489&r2=text&tr2=1.488&f=h > - Don't wait for pending I/Os when purging blocks beyond eof. > > > > > [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Tue Dec 11 10:27:56 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 11 Dec 2007 10:28:00 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBBIRtse009039 for ; Tue, 11 Dec 2007 10:27:56 -0800 X-ASG-Debug-ID: 1197397683-4a5200f80000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.ukfsn.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id C62C3B33EA3 for ; Tue, 11 Dec 2007 10:28:03 -0800 (PST) Received: from mail.ukfsn.org (s2.ukfsn.org [217.158.120.143]) by cuda.sgi.com with ESMTP id 4FnMeQq8gQesLcAj for ; Tue, 11 Dec 2007 10:28:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.ukfsn.org (Postfix) with ESMTP id 01D19DF073 for ; Tue, 11 Dec 2007 18:28:47 +0000 (GMT) Received: from mail.ukfsn.org ([127.0.0.1]) by localhost (smtp-filter.ukfsn.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XwnWAqdnny6l for ; Tue, 11 Dec 2007 18:28:47 +0000 (GMT) Received: from elm.dgreaves.com (i-83-67-36-194.freedom2surf.net [83.67.36.194]) by mail.ukfsn.org (Postfix) with ESMTP id 5B9D3DF3E0 for ; Tue, 11 Dec 2007 18:28:21 +0000 (GMT) Received: from ash.dgreaves.com ([10.0.0.90]) by elm.dgreaves.com with esmtp (Exim 4.62) (envelope-from ) id 1J29ol-0002Zh-KQ for xfs@oss.sgi.com; Tue, 11 Dec 2007 18:26:55 +0000 Message-ID: <475ED66F.40800@dgreaves.com> Date: Tue, 11 Dec 2007 18:26:55 +0000 From: David Greaves User-Agent: Mozilla-Thunderbird 2.0.0.6 (X11/20071009) MIME-Version: 1.0 To: xfs@oss.sgi.com X-ASG-Orig-Subj: XFS internal error xfs_btree_check_sblock Subject: XFS internal error xfs_btree_check_sblock X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: s2.ukfsn.org[217.158.120.143] X-Barracuda-Start-Time: 1197397686 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36338 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5092/Tue Dec 11 08:35:26 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13905 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: david@dgreaves.com Precedence: bulk X-list: xfs Hi I've been having problems with this filesystem for a while now. I upgraded to 2.6.23 to see if it's improved (no). Once every 2 or 3 cold boots I get this in dmesg as the user logs in and accesses the /scratch filesystem. If the error doesn't occur as the user logs in then it won't happen at all. Filesystem "dm-0": XFS internal error xfs_btree_check_sblock at line 334 of file fs/xfs/xfs_btree.c. Caller 0xc01b7bc1 [] show_trace_log_lvl+0x1a/0x30 [] show_trace+0x12/0x20 [] dump_stack+0x15/0x20 [] xfs_error_report+0x4f/0x60 [] xfs_btree_check_sblock+0x56/0xd0 [] xfs_alloc_lookup+0x181/0x390 [] xfs_alloc_lookup_eq+0x13/0x20 [] xfs_free_ag_extent+0x2f4/0x690 [] xfs_free_extent+0xb4/0xd0 [] xfs_bmap_finish+0x119/0x170 [] xfs_remove+0x247/0x4f0 [] xfs_vn_unlink+0x22/0x50 [] vfs_unlink+0x68/0xa0 [] do_unlinkat+0xb9/0x140 [] sys_unlink+0x10/0x20 [] syscall_call+0x7/0xb ======================= xfs_force_shutdown(dm-0,0x8) called from line 4274 of file fs/xfs/xfs_bmap.c. Return address = 0xc0214dae Filesystem "dm-0": Corruption of in-memory data detected. Shutting down filesystem: dm-0 Please umount the filesystem, and rectify the problem(s) I ssh in as root, umount, mount, umount and run xfs_repair. This is what I got this time: Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... ir_freecount/free mismatch, inode chunk 59/5027968, freecount 27 nfree 26 - found root inode chunk All the rest was clean. It is possible this fs suffered in the 2.6.17 timeframe It is also possible something got broken whilst I was having lots of issues with hibernate (which is still unreliable). I wonder if the fs is borked and xfs_repair isn't fixing it? David PS Please cc on replies. From owner-xfs@oss.sgi.com Tue Dec 11 11:43:17 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 11 Dec 2007 11:43:21 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=BAYES_20,J_CHICKENPOX_43 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBBJhEFs016566 for ; Tue, 11 Dec 2007 11:43:17 -0800 X-ASG-Debug-ID: 1197402205-494d01cb0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from pmx2.sophos.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 026DAB34BF3 for ; Tue, 11 Dec 2007 11:43:25 -0800 (PST) Received: from pmx2.sophos.com (pmx2.sophos.com [213.31.172.17]) by cuda.sgi.com with ESMTP id oJn59MDAsc36LzO5 for ; Tue, 11 Dec 2007 11:43:25 -0800 (PST) Received: from pmx2.sophos.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C38612DA94E for ; Tue, 11 Dec 2007 19:42:52 +0000 (GMT) Received: from smtp22.ca.sophos.com (unknown [192.168.3.163]) by pmx2.sophos.com (Postfix) with ESMTP id 3356C2DA929 for ; Tue, 11 Dec 2007 19:42:52 +0000 (GMT) Received: from ca-exchange.ca.sophos.com (ca-exchange.activestate.ca [192.168.3.140]) by smtp.ca.sophos.com (8.13.1/8.13.1) with ESMTP id lBBJgoHQ009552 for ; Tue, 11 Dec 2007 11:42:50 -0800 X-PMWin-Version: 2.6.1, Antivirus-Engine: 2.52.1 thread-index: Acg8LgZH8fwVgNZmTa+E0x1wdRd4XQ== Content-Class: urn:content-classes:message Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992 Received: from [192.168.99.209] ([192.168.99.209]) by ca-exchange.ca.sophos.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Dec 2007 11:42:55 -0800 Message-ID: <475EE83A.3060607@ca.sophos.com> Date: Tue, 11 Dec 2007 11:42:50 -0800 From: "David Sparks" Reply-To: "David Sparks" Organization: SophosLabs User-Agent: Thunderbird 2.0.0.9 (X11/20071206) MIME-Version: 1.0 To: X-ASG-Orig-Subj: mkfs.xfs ... lazy-count=1 ... not mountable by older kernels? Subject: mkfs.xfs ... lazy-count=1 ... not mountable by older kernels? X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Dec 2007 19:42:55.0111 (UTC) FILETIME=[06407970:01C83C2E] X-PMX-Version: 5.3.3.310218, Liza: Liza 1.0 r47, Antispam-Engine: 2.5.2.313940, Antispam-Data: 2007.12.11.112626 X-PMX-QueueID: uk-pmx2.brown.sophos:475EE83C_23949_228_1 X-Barracuda-Connect: pmx2.sophos.com[213.31.172.17] X-Barracuda-Start-Time: 1197402206 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36344 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5093/Tue Dec 11 10:00:45 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13906 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dave@ca.sophos.com Precedence: bulk X-list: xfs Hi all, Is it expected that filesystems made with lazy-count=1 are not mountable by older kernels? I'm installing a system based with install media based on 2.6.19 and mkfs.xfs 2.8.11 (its Gentoo 2007.0). That mkfs.xfs is old so i copied over a 2.9.4 binary and used that to mkfs the filesystem but its unmountable. Removing the lazy-count=1 option makes it mountable. Is this an expected incompatibility or is mix-n-matching xfsprogs a bad idea? Thanks! From owner-xfs@oss.sgi.com Tue Dec 11 14:16:01 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 11 Dec 2007 14:16:05 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_43 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id lBBMFtvx002837 for ; Tue, 11 Dec 2007 14:16:00 -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 JAA12780; Wed, 12 Dec 2007 09:16:00 +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 lBBMFxIN5471993; Wed, 12 Dec 2007 09:15:59 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id lBBMFtOd5470770; Wed, 12 Dec 2007 09:15:55 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Wed, 12 Dec 2007 09:15:55 +1100 From: David Chinner To: David Sparks Cc: xfs@oss.sgi.com Subject: Re: mkfs.xfs ... lazy-count=1 ... not mountable by older kernels? Message-ID: <20071211221554.GC4612@sgi.com> References: <475EE83A.3060607@ca.sophos.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <475EE83A.3060607@ca.sophos.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/5093/Tue Dec 11 10:00:45 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13907 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Tue, Dec 11, 2007 at 11:42:50AM -0800, David Sparks wrote: > Hi all, > > Is it expected that filesystems made with lazy-count=1 are not mountable by > older kernels? That is expected. lazy-count is a mkfs option because it changes the on-disk format slightly, and older kernels do not understand that format. Hence mkfs sets a superblock feature bit to prevent the filesystem from being mounted on kernels that don't understand the slightly different disk format. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Tue Dec 11 14:25:47 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 11 Dec 2007 14:25:50 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id lBBMPhDU003941 for ; Tue, 11 Dec 2007 14:25:45 -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 JAA13464; Wed, 12 Dec 2007 09:25:50 +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 lBBMPmIN5476294; Wed, 12 Dec 2007 09:25:49 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id lBBMPkTS4562020; Wed, 12 Dec 2007 09:25:46 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Wed, 12 Dec 2007 09:25:46 +1100 From: David Chinner To: David Greaves Cc: xfs@oss.sgi.com Subject: Re: XFS internal error xfs_btree_check_sblock Message-ID: <20071211222546.GD4612@sgi.com> References: <475ED66F.40800@dgreaves.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <475ED66F.40800@dgreaves.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/5093/Tue Dec 11 10:00:45 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13908 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Tue, Dec 11, 2007 at 06:26:55PM +0000, David Greaves wrote: > Hi > > I've been having problems with this filesystem for a while now. > > I upgraded to 2.6.23 to see if it's improved (no). > > Once every 2 or 3 cold boots I get this in dmesg as the user logs in and > accesses the /scratch filesystem. If the error doesn't occur as the user logs in > then it won't happen at all. > > Filesystem "dm-0": XFS internal error xfs_btree_check_sblock at line 334 of file > fs/xfs/xfs_btree.c. Caller 0xc01b7bc1 > [] show_trace_log_lvl+0x1a/0x30 > [] show_trace+0x12/0x20 > [] dump_stack+0x15/0x20 > [] xfs_error_report+0x4f/0x60 > [] xfs_btree_check_sblock+0x56/0xd0 > [] xfs_alloc_lookup+0x181/0x390 > [] xfs_alloc_lookup_eq+0x13/0x20 > [] xfs_free_ag_extent+0x2f4/0x690 > [] xfs_free_extent+0xb4/0xd0 > [] xfs_bmap_finish+0x119/0x170 > [] xfs_remove+0x247/0x4f0 > [] xfs_vn_unlink+0x22/0x50 > [] vfs_unlink+0x68/0xa0 > [] do_unlinkat+0xb9/0x140 > [] sys_unlink+0x10/0x20 > [] syscall_call+0x7/0xb > ======================= > xfs_force_shutdown(dm-0,0x8) called from line 4274 of file fs/xfs/xfs_bmap.c. > Return address = 0xc0214dae > Filesystem "dm-0": Corruption of in-memory data detected. Shutting down > filesystem: dm-0 > Please umount the filesystem, and rectify the problem(s) So there's a corrupted freespace btree block. > I ssh in as root, umount, mount, umount and run xfs_repair. > > This is what I got this time: > > Phase 2 - using internal log > - zero log... > - scan filesystem freespace and inode maps... > ir_freecount/free mismatch, inode chunk 59/5027968, freecount 27 nfree 26 > - found root inode chunk > > All the rest was clean. repair doesn't check the freespace btrees - it just rebuilds them from scratch. use xfs_check to tell you what is wrong with the filesystem, then use xfs_repair to fix it.... > It is possible this fs suffered in the 2.6.17 timeframe > It is also possible something got broken whilst I was having lots of issues with > hibernate (which is still unreliable). Suspend does not quiesce filesystems safely, so you risk filesystem corruption every time you suspend and resume no matter what filesystem you use. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Tue Dec 11 15:14:12 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 11 Dec 2007 15:14:17 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBBNEAB3007751 for ; Tue, 11 Dec 2007 15:14:12 -0800 X-ASG-Debug-ID: 1197414860-165600130000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.lichtvoll.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 3644810FA446 for ; Tue, 11 Dec 2007 15:14:20 -0800 (PST) Received: from mail.lichtvoll.de (mondschein.lichtvoll.de [194.150.191.11]) by cuda.sgi.com with ESMTP id SechnEgai1hzDiZq for ; Tue, 11 Dec 2007 15:14:20 -0800 (PST) Received: from [192.168.1.21] (dslb-084-056-075-184.pools.arcor-ip.net [84.56.75.184]) by mail.lichtvoll.de (Postfix) with ESMTP id 3799A5ADDC for ; Tue, 11 Dec 2007 23:40:41 +0100 (CET) From: Martin Steigerwald To: linux-xfs@oss.sgi.com X-ASG-Orig-Subj: write barrier over device mapper supported or not? Subject: write barrier over device mapper supported or not? Date: Tue, 11 Dec 2007 23:42:23 +0100 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200712112342.24094.Martin@lichtvoll.de> X-Barracuda-Connect: mondschein.lichtvoll.de[194.150.191.11] X-Barracuda-Start-Time: 1197414861 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36356 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5093/Tue Dec 11 10:00:45 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13909 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Martin@lichtvoll.de Precedence: bulk X-list: xfs Hello! Are write barriers over device mapper supported or not? On LVM2 xfs tells me: Dec 11 23:00:09 shambala kernel: Filesystem "dm-0": Disabling barriers, not supported by the underlying device Dec 11 23:00:09 shambala kernel: XFS mounting filesystem dm-0 Dec 11 23:00:09 shambala kernel: Ending clean XFS mount for filesystem: dm-0 But when I mount ext3 on LVM2 I get: Dec 11 23:05:34 shambala kernel: kjournald starting. Commit interval 5 seconds Dec 11 23:05:34 shambala kernel: EXT3 FS on dm-1, internal journal Dec 11 23:05:34 shambala kernel: EXT3-fs: mounted filesystem with ordered data mode. even when I explicetely specify "-o barrier=1" which should enable barriers on ext3. As far as I understood from the changelogs as I wrote my Linux-Magazin I thought there should be device mapper support in the kernel, but I can not reproduce that finding anymore at the moment. But back then I also looked at the ext3 / jbd sources and found that jbd issues a warning when barrier support is not available. However I do not find that one either. And when I use reisferfs it also seems that write barriers are not available over LVM2: Dec 11 23:34:58 shambala kernel: ReiserFS: dm-2: found reiserfs format "3.6" with standard journal Dec 11 23:34:58 shambala kernel: ReiserFS: dm-2: using ordered data mode Dec 11 23:34:58 shambala kernel: reiserfs: using flush barriers Dec 11 23:34:58 shambala kernel: ReiserFS: dm-2: journal params: device dm-2, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 Dec 11 23:34:58 shambala kernel: ReiserFS: dm-2: checking transaction log (dm-2) Dec 11 23:35:01 shambala kernel: reiserfs: disabling flush barriers on dm-2 Dec 11 23:35:01 shambala kernel: ReiserFS: dm-2: Using r5 hash to sort names Dec 11 23:35:01 shambala kernel: ReiserFS: dm-2: warning: Created .reiserfs_priv on dm-2 - reserved for xattr storage. Hmmm... too bad... means I will likely not use LVM on my next laptop harddisk. I think I should file a kernel bug report about that. Anyone knows of any plans to support write barriers via device mapper? Well I guess I should ask on dm-devel or so if such a mailinglist exists. Ciao, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 From owner-xfs@oss.sgi.com Tue Dec 11 15:25:23 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 11 Dec 2007 15:25:26 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id lBBNPDQu009047 for ; Tue, 11 Dec 2007 15:25:22 -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 KAA15908; Wed, 12 Dec 2007 10:25:21 +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 lBBNPKIN5496317; Wed, 12 Dec 2007 10:25:20 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id lBBNPHcc5496140; Wed, 12 Dec 2007 10:25:17 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Wed, 12 Dec 2007 10:25:17 +1100 From: David Chinner To: Christoph Hellwig Cc: Lachlan McIlroy , sgi.bugs.xfs@engr.sgi.com, xfs@oss.sgi.com Subject: Re: TAKE 964002 - Don't wait for pending I/Os when purging blocks beyond eof. Message-ID: <20071211232517.GE4612@sgi.com> References: <20071210055955.0F96358C4C34@chook.melbourne.sgi.com> <20071211081117.GB19213@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071211081117.GB19213@infradead.org> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/5093/Tue Dec 11 10:00:45 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13910 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Tue, Dec 11, 2007 at 08:11:17AM +0000, Christoph Hellwig wrote: > On Mon, Dec 10, 2007 at 04:59:55PM +1100, Lachlan McIlroy wrote: > > Don't wait for pending I/Os when purging blocks beyond eof. > > > > On last close of a file we purge blocks beyond eof. The same > > code is used when we truncate the file size down. In this case > > we need to wait for any pending I/Os for dirty pages beyond the > > new eof. For the last close case we are not changing the file > > size and therefore do not need to wait for any I/Os to complete. > > This fixes a performance bottleneck where writes into the page > > cache and cache flushes can become mutually exclusive. > > I think I shortened from of this should be in the comment above > the conditional vn_iowait intead of the current > > /* wait for the completion of any pending DIOs */ > > which is wrong given that we don't wait for all pending direct I/O > requests.. (and vn_iowait doesn't wait for direct I/O anyway) vn_iowait() does wait for direct I/O. That was it's entire purpose - to be able to prevent truncate vs direct I/O write races by tracking direct I/Os. We increment ip->i_iocount in xfs_alloc_ioend() which is called from both the buffered write and direct I/O write path, so vn_iowait() does wait for both buffered and direct writes to complete. FWIW, the freeze code makes use of this functionality (SYNC_IOWAIT) to ensure all pending data writes are complete complete before the freeze is completed.... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Tue Dec 11 15:40:57 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 11 Dec 2007 15:41:07 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBBNetWC011269 for ; Tue, 11 Dec 2007 15:40:57 -0800 X-ASG-Debug-ID: 1197416466-221b00530000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.ukfsn.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id BED3546EDBC for ; Tue, 11 Dec 2007 15:41:06 -0800 (PST) Received: from mail.ukfsn.org (s2.ukfsn.org [217.158.120.143]) by cuda.sgi.com with ESMTP id ZxpIwBWytpxjcrFv for ; Tue, 11 Dec 2007 15:41:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.ukfsn.org (Postfix) with ESMTP id C6576DECB3; Tue, 11 Dec 2007 23:42:27 +0000 (GMT) Received: from mail.ukfsn.org ([127.0.0.1]) by localhost (smtp-filter.ukfsn.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v22fT3e1c33E; Tue, 11 Dec 2007 23:42:27 +0000 (GMT) Received: from elm.dgreaves.com (i-83-67-36-194.freedom2surf.net [83.67.36.194]) by mail.ukfsn.org (Postfix) with ESMTP id 9E266DEF14; Tue, 11 Dec 2007 23:42:25 +0000 (GMT) Received: from ash.dgreaves.com ([10.0.0.90]) by elm.dgreaves.com with esmtp (Exim 4.62) (envelope-from ) id 1J2Eie-0005Y5-Ux; Tue, 11 Dec 2007 23:40:57 +0000 Message-ID: <475F2008.5030702@dgreaves.com> Date: Tue, 11 Dec 2007 23:40:56 +0000 From: David Greaves User-Agent: Mozilla-Thunderbird 2.0.0.6 (X11/20071009) MIME-Version: 1.0 To: David Chinner CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS internal error xfs_btree_check_sblock Subject: Re: XFS internal error xfs_btree_check_sblock References: <475ED66F.40800@dgreaves.com> <20071211222546.GD4612@sgi.com> In-Reply-To: <20071211222546.GD4612@sgi.com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: s2.ukfsn.org[217.158.120.143] X-Barracuda-Start-Time: 1197416466 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36359 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5093/Tue Dec 11 10:00:45 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13911 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: david@dgreaves.com Precedence: bulk X-list: xfs David Chinner wrote: > On Tue, Dec 11, 2007 at 06:26:55PM +0000, David Greaves wrote: >> Once every 2 or 3 cold boots I get this in dmesg as the user logs in and > So there's a corrupted freespace btree block. OK, ta >> I ssh in as root, umount, mount, umount and run xfs_repair. > repair doesn't check the freespace btrees - it just rebuilds them from > scratch. use xfs_check to tell you what is wrong with the filesystem, then > use xfs_repair to fix it.... OK, having repaired it: haze:~# xfs_check /dev/video_vg/video_lv haze:~# So why do I have to do this on a regular basis (ie run xfs_repair)? I am shutting the machine down cleanly (init 0) >> It is possible this fs suffered in the 2.6.17 timeframe >> It is also possible something got broken whilst I was having lots of issues with >> hibernate (which is still unreliable). > > Suspend does not quiesce filesystems safely, so you risk filesystem > corruption every time you suspend and resume no matter what filesystem > you use. Well, FWIW, I've not hibernated this machine for a *long* time. Also my hibernate script used to run xfs_freeze before hibernating (to be on the safe side). This would regularly hang with an xfs_io process (or some such IIRC) in an unkillable state. I was about to edit my init scripts to do a mount, umount, xfs_repair, mount cycle. But then I thought "this is wrong - I'll report it". So is there anything else I should do? David From owner-xfs@oss.sgi.com Tue Dec 11 16:34:57 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 11 Dec 2007 16:35:00 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_43 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id lBC0YrKh021527 for ; Tue, 11 Dec 2007 16:34:56 -0800 Received: from timothy-shimmins-power-mac-g5.local (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA18228; Wed, 12 Dec 2007 11:34:59 +1100 Message-ID: <475F2D54.3090609@sgi.com> Date: Wed, 12 Dec 2007 11:37:40 +1100 From: Timothy Shimmin User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: David Sparks CC: xfs@oss.sgi.com Subject: Re: mkfs.xfs ... lazy-count=1 ... not mountable by older kernels? References: <475EE83A.3060607@ca.sophos.com> <20071211221554.GC4612@sgi.com> In-Reply-To: <20071211221554.GC4612@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/5093/Tue Dec 11 10:00:45 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13912 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs David Chinner wrote: > On Tue, Dec 11, 2007 at 11:42:50AM -0800, David Sparks wrote: >> Hi all, >> >> Is it expected that filesystems made with lazy-count=1 are not mountable by >> older kernels? > > That is expected. lazy-count is a mkfs option because it changes the on-disk > format slightly, and older kernels do not understand that format. Hence > mkfs sets a superblock feature bit to prevent the filesystem from being > mounted on kernels that don't understand the slightly different disk format. > > Cheers, > > Dave. And there will be a message in the logs but it probably isn't overly obvious what it is talking about. Looking at code, I presume it will come from: if (!XFS_SB_GOOD_VERSION(sbp)) { xfs_fs_mount_cmn_err(flags, "bad version"); return XFS_ERROR(EWRONGFS); } so there will be a msg about a "bad version". --Tim From owner-xfs@oss.sgi.com Tue Dec 11 17:53:18 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 11 Dec 2007 17:53:23 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBC1rGYd025876 for ; Tue, 11 Dec 2007 17:53:18 -0800 X-ASG-Debug-ID: 1197424407-668700f10000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from puma.mxtelecom.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id E523710FB12D for ; Tue, 11 Dec 2007 17:53:27 -0800 (PST) Received: from puma.mxtelecom.com (mx1.mxtelecom.com [87.86.212.101]) by cuda.sgi.com with ESMTP id bzeFzLUCTkpiLmXU for ; Tue, 11 Dec 2007 17:53:27 -0800 (PST) Received: from localhost ([127.0.0.1]) by puma.mxtelecom.com with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.66) (envelope-from ) id 1J2GmJ-0002au-3z; Wed, 12 Dec 2007 01:52:51 +0000 Date: Wed, 12 Dec 2007 01:52:48 +0000 (GMT) From: Matthew Hodgson To: xfs@oss.sgi.com cc: Bhagi rathi X-ASG-Orig-Subj: Re: Zero-copy Block IO with XFS Subject: Re: Zero-copy Block IO with XFS In-Reply-To: Message-ID: References: <475E76AB.705@mxtelecom.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Barracuda-Connect: mx1.mxtelecom.com[87.86.212.101] X-Barracuda-Start-Time: 1197424407 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36368 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5093/Tue Dec 11 10:00:45 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13913 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: matthew@mxtelecom.com Precedence: bulk X-list: xfs On Tue, 11 Dec 2007, Bhagi rathi wrote: > On Dec 11, 2007 5:08 PM, Matthew Hodgson wrote: > >> Hi all, >> >> I'm experimenting with using XFS with a network block device (DST), and >> have come up against the problem that when writing data to the network, >> it uses kernel_sendpage to hand the page presented at the BIO layer to >> the network stack. It then completes the block IO request. > > Actually, you can pass a sendpage read actor which takes a reference on > the page which ensures valid page exists with you. Hmm, i'm a little confused as to how one would do that - I can see that sendfile can be passed a read actor for use in the underlying read, but I can't see anywhere where sendpage can be used with a read actor. I see that nfsd/vfs.c:nfsd_read_actor() adjusts the page refcounting to stop them being freed before they are sent - but that only seems to be usable when sending with sendfile. > As long as you have > ref on the page and no truncate to the same file, you can safely access > the file. Once NIC sends the data over wire, you can do put_page. This > should work. I'm not sure that it will help, though. The problem seems to be that XFS itself overwrites the page with new data (rather than the page being freed and reused) whilst the page is waiting to be sent in the TCP stack. Is there any way to prevent XFS from doing this - or have I misunderstood the problem? Along similar lines, is there any way to stop XFS from passing slab pages to the block IO layer? Attempts to pass slab pages over to the TCP stack fail too. thanks, Matthew. From owner-xfs@oss.sgi.com Tue Dec 11 19:36:38 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 11 Dec 2007 19:36:41 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBC3aYA3004415 for ; Tue, 11 Dec 2007 19:36:38 -0800 X-ASG-Debug-ID: 1197430601-668501cf0000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id CA0E9B39CC9 for ; Tue, 11 Dec 2007 19:36:41 -0800 (PST) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id 3Gaevk9r1X3CyR8A for ; Tue, 11 Dec 2007 19:36:41 -0800 (PST) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 2D61018004494; Tue, 11 Dec 2007 21:36:39 -0600 (CST) Message-ID: <475F5746.8080405@sandeen.net> Date: Tue, 11 Dec 2007 21:36:38 -0600 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Martin Steigerwald CC: linux-xfs@oss.sgi.com X-ASG-Orig-Subj: Re: write barrier over device mapper supported or not? Subject: Re: write barrier over device mapper supported or not? References: <200712112342.24094.Martin@lichtvoll.de> In-Reply-To: <200712112342.24094.Martin@lichtvoll.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1197430605 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36376 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5094/Tue Dec 11 18:55:35 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13914 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Martin Steigerwald wrote: > Hello! > > Are write barriers over device mapper supported or not? Nope. see dm_request(): /* * There is no use in forwarding any barrier request since we can't * guarantee it is (or can be) handled by the targets correctly. */ if (unlikely(bio_barrier(bio))) { bio_endio(bio, -EOPNOTSUPP); return 0; } > On LVM2 xfs tells me: > > Dec 11 23:00:09 shambala kernel: Filesystem "dm-0": Disabling barriers, > not supported by the underlying device > Dec 11 23:00:09 shambala kernel: XFS mounting filesystem dm-0 > Dec 11 23:00:09 shambala kernel: Ending clean XFS mount for filesystem: > dm-0 > > But when I mount ext3 on LVM2 I get: > > Dec 11 23:05:34 shambala kernel: kjournald starting. Commit interval 5 > seconds > Dec 11 23:05:34 shambala kernel: EXT3 FS on dm-1, internal journal > Dec 11 23:05:34 shambala kernel: EXT3-fs: mounted filesystem with ordered > data mode. > > even when I explicetely specify "-o barrier=1" which should enable > barriers on ext3. > > As far as I understood from the changelogs as I wrote my Linux-Magazin I > thought there should be device mapper support in the kernel, but I can > not reproduce that finding anymore at the moment. > > But back then I also looked at the ext3 / jbd sources and found that jbd > issues a warning when barrier support is not available. However I do not > find that one either. in journal_write_commit_record() there is such a warning, but not in the mount path: printk(KERN_WARNING "JBD: barrier-based sync failed on %s - " "disabling barriers\n", bdevname(journal->j_dev, b)); and if I set barrier=1 on an lvm-root test box, I do get: JBD: barrier-based sync failed on dm-0 - disabling barriers -Eric From owner-xfs@oss.sgi.com Tue Dec 11 20:03:25 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 11 Dec 2007 20:03:27 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_42 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id lBC43LaN007217 for ; Tue, 11 Dec 2007 20:03:24 -0800 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA23564; Wed, 12 Dec 2007 15:03:23 +1100 Message-ID: <475F5DC3.6070203@sgi.com> Date: Wed, 12 Dec 2007 15:04:19 +1100 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.9 (X11/20071031) MIME-Version: 1.0 To: Bhagi rathi CC: sgi.bugs.xfs@engr.sgi.com, xfs@oss.sgi.com Subject: Re: TAKE 964002 - Don't wait for pending I/Os when purging blocks beyond eof. References: <20071210055955.0F96358C4C34@chook.melbourne.sgi.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/5094/Tue Dec 11 18:55:35 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13915 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs Bhagi rathi wrote: > On Dec 10, 2007 11:29 AM, Lachlan McIlroy wrote: > >> Don't wait for pending I/Os when purging blocks beyond eof. >> >> On last close of a file we purge blocks beyond eof. The same >> code is used when we truncate the file size down. In this case >> we need to wait for any pending I/Os for dirty pages beyond the >> new eof. For the last close case we are not changing the file >> size and therefore do not need to wait for any I/Os to complete. >> This fixes a performance bottleneck where writes into the page >> cache and cache flushes can become mutually exclusive. > > > Lachlan, > > How the following is addressed if we don't wait for I/O to complete during > close of the file and > issue truncate: > > - We didn't waited for the I/O to complete > - Truncated blocks beyond EOF. > - These blocks are re-used for another transaction as meta-data. > - Meta-data flush was induced. However the flush of meta-data > reached first before the data I/O > because of some issues with under-lying driver. Later the file I/O > over-written the meta-data I/O. > We have corruption of data. This case will not happen. For a truncate down we may have dirty pages beyond eof that are in the process of being written to disk while we are trying to shrink the file - we need to wait for those. In the case of truncating blocks beyond eof on last close we are not changing the file size and so there cannot be pages beyond eof. Any I/O that may be in progress will be within the file size and not to any of the blocks we are trying to free. > > It seems the corruption could be in various ways. Isn't this the reason why > truncate has to wait > for the I/O to complete? Corruption could certainly occur if we don't wait for I/O. I think the reason this code was added was to synchronize with direct I/O unwritten extent conversions which could occur after the direct writer thread has released the iolock and so we can't use the iolock alone as an I/O barrier. > I believe fundamental problem is once the blocks > are free'ed, the re-association should > not expect some I/O in concurrent to those same block addresses. > > -Cheers, > Bhagi. > > >> >> Date: Mon Dec 10 16:59:09 AEDT 2007 >> Workarea: redback.melbourne.sgi.com:/home/lachlan/isms/2.6.x-vniowait >> Inspected by: pleckie >> Author: lachlan >> >> The following file(s) were checked into: >> longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb >> >> >> Modid: xfs-linux-melb:xfs-kern:30220a >> fs/xfs/xfs_inode.c - 1.489 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/>> xfs_inode.c.diff?r1=text&tr1=1.489&r2=text&tr2=1.488&f=h > http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/> xfs_inode.c.diff?r1=text&tr1=1.489&r2=text&tr2=1.488&f=h >> http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode.c.diff?r1=text&tr1=1.489&r2=text&tr2=1.488&f=h >> - Don't wait for pending I/Os when purging blocks beyond eof. >> >> >> >> >> > > > [[HTML alternate version deleted]] > > > From owner-xfs@oss.sgi.com Tue Dec 11 21:14:00 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 11 Dec 2007 21:14:21 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_66 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBC5DuYQ019860 for ; Tue, 11 Dec 2007 21:14:00 -0800 X-ASG-Debug-ID: 1197436434-6070004e0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from pentafluge.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 2E8D0470260; Tue, 11 Dec 2007 21:13:54 -0800 (PST) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by cuda.sgi.com with ESMTP id cgmDbOPWSgCwMcYR; Tue, 11 Dec 2007 21:13:54 -0800 (PST) Received: from hch by pentafluge.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1J2Juq-0001uz-2h; Wed, 12 Dec 2007 05:13:52 +0000 Date: Wed, 12 Dec 2007 05:13:51 +0000 From: Christoph Hellwig To: David Chinner Cc: Christoph Hellwig , Lachlan McIlroy , sgi.bugs.xfs@engr.sgi.com, xfs@oss.sgi.com X-ASG-Orig-Subj: Re: TAKE 964002 - Don't wait for pending I/Os when purging blocks beyond eof. Subject: Re: TAKE 964002 - Don't wait for pending I/Os when purging blocks beyond eof. Message-ID: <20071212051351.GA7291@infradead.org> References: <20071210055955.0F96358C4C34@chook.melbourne.sgi.com> <20071211081117.GB19213@infradead.org> <20071211232517.GE4612@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071211232517.GE4612@sgi.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: pentafluge.infradead.org[213.146.154.40] X-Barracuda-Start-Time: 1197436448 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0003 1.0000 -2.0188 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36381 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5095/Tue Dec 11 19:50:12 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13916 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs On Wed, Dec 12, 2007 at 10:25:17AM +1100, David Chinner wrote: > > which is wrong given that we don't wait for all pending direct I/O > > requests.. (and vn_iowait doesn't wait for direct I/O anyway) > > vn_iowait() does wait for direct I/O. That was it's entire purpose - to be > able to prevent truncate vs direct I/O write races by tracking direct I/Os. > We increment ip->i_iocount in xfs_alloc_ioend() which is called from both the > buffered write and direct I/O write path, so vn_iowait() does wait for both > buffered and direct writes to complete. Sorry, forgot a little important word above - it should read 'and vn_iowait doesn't wait _just_ for direct I/O anyway), because it waits for completion of regular I/O aswell. Not that it should actually matter in that caller.forgot a little important word above - it should read 'and vn_iowait doesn't wait _just_ for direct I/O anyway), because it waits for completion of regular I/O aswell. Not that it should actually matter in that caller. From owner-xfs@oss.sgi.com Tue Dec 11 23:01:41 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 11 Dec 2007 23:02:03 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, T_STOX_BOUND_090909_B autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id lBC71X9t029332 for ; Tue, 11 Dec 2007 23:01:39 -0800 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA27583; Wed, 12 Dec 2007 18:01:41 +1100 Message-ID: <475F878D.6090407@sgi.com> Date: Wed, 12 Dec 2007 18:02:37 +1100 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.9 (X11/20071031) MIME-Version: 1.0 To: xfs-dev , xfs-oss Subject: [PATCH] make inode reclaim synchronise with xfs_iflush_done() Content-Type: multipart/mixed; boundary="------------090009090006020202070505" X-Virus-Scanned: ClamAV 0.91.2/5095/Tue Dec 11 19:50:12 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13917 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs This is a multi-part message in MIME format. --------------090009090006020202070505 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On a forced shutdown, xfs_finish_reclaim() will skip flushing the inode. If the inode flush lock is not already held and there is an outstanding xfs_iflush_done() then we might free the inode prematurely. By acquiring and releasing the flush lock we will synchronise with xfs_iflush_done(). Alternatively we could take a hold on the inode when when issuing I/Os with xfs_iflush_done() and release it in xfs_iflush_done(). Would this be a better approach? Lachlan --------------090009090006020202070505 Content-Type: text/x-patch; name="xfs_finish_reclaim.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="xfs_finish_reclaim.diff" --- fs/xfs/xfs_vnodeops.c_1.726 2007-12-12 17:14:59.000000000 +1100 +++ fs/xfs/xfs_vnodeops.c 2007-12-12 17:15:42.000000000 +1100 @@ -3762,20 +3762,29 @@ xfs_finish_reclaim( goto reclaim; } xfs_iflock(ip); /* synchronize with xfs_iflush_done */ + xfs_ifunlock(ip); } ASSERT(ip->i_update_core == 0); ASSERT(ip->i_itemp == NULL || ip->i_itemp->ili_format.ilf_fields == 0); xfs_iunlock(ip, XFS_ILOCK_EXCL); - } else if (locked) { + } else { /* * We are not interested in doing an iflush if we're * in the process of shutting down the filesystem forcibly. * So, just reclaim the inode. - */ - xfs_ifunlock(ip); - xfs_iunlock(ip, XFS_ILOCK_EXCL); + * + * If the flush lock is not already held then temporarily + * acquire it to synchronize with xfs_iflush_done. + */ + if (locked) { + xfs_ifunlock(ip); + xfs_iunlock(ip, XFS_ILOCK_EXCL); + } else { + xfs_iflock(ip); + xfs_ifunlock(ip); + } } reclaim: --------------090009090006020202070505-- From owner-xfs@oss.sgi.com Tue Dec 11 23:06:54 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 11 Dec 2007 23:07:14 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_62, T_STOX_BOUND_090909_B autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id lBC76io0029881 for ; Tue, 11 Dec 2007 23:06:50 -0800 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA27648; Wed, 12 Dec 2007 18:06:50 +1100 Message-ID: <475F88C3.709@sgi.com> Date: Wed, 12 Dec 2007 18:07:47 +1100 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.9 (X11/20071031) MIME-Version: 1.0 To: xfs-dev , xfs-oss Subject: [PATCH] prevent panic during log recovery due to bogus operation header length Content-Type: multipart/mixed; boundary="------------070900080804020003090805" X-Virus-Scanned: ClamAV 0.91.2/5098/Tue Dec 11 21:46:37 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13918 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs This is a multi-part message in MIME format. --------------070900080804020003090805 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit A problem was reported where a system panicked in log recovery due to a corrupt log record. The cause of the corruption is not known but this change will at least prevent a crash for this specific scenario. Log recovery definitely needs some more work in this area. Lachlan --------------070900080804020003090805 Content-Type: text/x-patch; name="xfs_log_recover.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="xfs_log_recover.diff" --- fs/xfs/xfs_log_recover.c_1.332 2007-12-12 17:14:57.000000000 +1100 +++ fs/xfs/xfs_log_recover.c 2007-12-12 17:15:42.000000000 +1100 @@ -2912,7 +2912,12 @@ xlog_recover_process_data( xlog_recover_new_tid(&rhash[hash], tid, be64_to_cpu(rhead->h_lsn)); } else { - ASSERT(dp + be32_to_cpu(ohead->oh_len) <= lp); + if (dp + be32_to_cpu(ohead->oh_len) > lp) { + xlog_warn( + "XFS: xlog_recover_process_data: bad length"); + ASSERT(0); + return (XFS_ERROR(EIO)); + } flags = ohead->oh_flags & ~XLOG_END_TRANS; if (flags & XLOG_WAS_CONT_TRANS) flags &= ~XLOG_CONTINUE_TRANS; --------------070900080804020003090805-- From owner-xfs@oss.sgi.com Tue Dec 11 23:19:37 2007 Received: with ECARTIS (v1.0.0; list xfs); Tue, 11 Dec 2007 23:19:47 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, T_STOX_BOUND_090909_B autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id lBC7JV6S031342 for ; Tue, 11 Dec 2007 23:19:36 -0800 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA27919; Wed, 12 Dec 2007 18:19:38 +1100 Message-ID: <475F8BC3.8020804@sgi.com> Date: Wed, 12 Dec 2007 18:20:35 +1100 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.9 (X11/20071031) MIME-Version: 1.0 To: xfs-dev , xfs-oss Subject: [PATCH] make xfs_idestroy() wait for log I/O to complete Content-Type: multipart/mixed; boundary="------------030001020001050703050701" X-Virus-Scanned: ClamAV 0.91.2/5098/Tue Dec 11 21:46:37 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13919 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs This is a multi-part message in MIME format. --------------030001020001050703050701 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit An xfs inode can be destroyed before log I/O involving that inode is complete. We need to wait for the inode to be unpinned before tearing it down. The patch looks big but the only real change is adding a call to xfs_iunpin_wait() to the start of xfs_idestroy(). The rest of the patch is moving xfs_idestroy() after the pinning routines. Lachlan --------------030001020001050703050701 Content-Type: text/x-patch; name="xfs_idestroy.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="xfs_idestroy.diff" --- fs/xfs/xfs_inode.c_1.489 2007-12-12 17:14:54.000000000 +1100 +++ fs/xfs/xfs_inode.c 2007-12-12 17:15:42.000000000 +1100 @@ -2733,71 +2733,6 @@ xfs_idestroy_fork( } /* - * This is called free all the memory associated with an inode. - * It must free the inode itself and any buffers allocated for - * if_extents/if_data and if_broot. It must also free the lock - * associated with the inode. - */ -void -xfs_idestroy( - xfs_inode_t *ip) -{ - switch (ip->i_d.di_mode & S_IFMT) { - case S_IFREG: - case S_IFDIR: - case S_IFLNK: - xfs_idestroy_fork(ip, XFS_DATA_FORK); - break; - } - if (ip->i_afp) - xfs_idestroy_fork(ip, XFS_ATTR_FORK); - mrfree(&ip->i_lock); - mrfree(&ip->i_iolock); - freesema(&ip->i_flock); - -#ifdef XFS_INODE_TRACE - ktrace_free(ip->i_trace); -#endif -#ifdef XFS_BMAP_TRACE - ktrace_free(ip->i_xtrace); -#endif -#ifdef XFS_BMBT_TRACE - ktrace_free(ip->i_btrace); -#endif -#ifdef XFS_RW_TRACE - ktrace_free(ip->i_rwtrace); -#endif -#ifdef XFS_ILOCK_TRACE - ktrace_free(ip->i_lock_trace); -#endif -#ifdef XFS_DIR2_TRACE - ktrace_free(ip->i_dir_trace); -#endif - if (ip->i_itemp) { - /* - * Only if we are shutting down the fs will we see an - * inode still in the AIL. If it is there, we should remove - * it to prevent a use-after-free from occurring. - */ - xfs_mount_t *mp = ip->i_mount; - xfs_log_item_t *lip = &ip->i_itemp->ili_item; - - ASSERT(((lip->li_flags & XFS_LI_IN_AIL) == 0) || - XFS_FORCED_SHUTDOWN(ip->i_mount)); - if (lip->li_flags & XFS_LI_IN_AIL) { - spin_lock(&mp->m_ail_lock); - if (lip->li_flags & XFS_LI_IN_AIL) - xfs_trans_delete_ail(mp, lip); - else - spin_unlock(&mp->m_ail_lock); - } - xfs_inode_item_destroy(ip); - } - kmem_zone_free(xfs_inode_zone, ip); -} - - -/* * Increment the pin count of the given buffer. * This value is protected by ipinlock spinlock in the mount structure. */ @@ -2860,6 +2795,74 @@ xfs_iunpin_wait( wait_event(ip->i_ipin_wait, (atomic_read(&ip->i_pincount) == 0)); } +/* + * This is called free all the memory associated with an inode. + * It must free the inode itself and any buffers allocated for + * if_extents/if_data and if_broot. It must also free the lock + * associated with the inode. + */ +void +xfs_idestroy( + xfs_inode_t *ip) +{ + /* + * Wait for any log writes referencing this inode to complete. + */ + xfs_iunpin_wait(ip); + + switch (ip->i_d.di_mode & S_IFMT) { + case S_IFREG: + case S_IFDIR: + case S_IFLNK: + xfs_idestroy_fork(ip, XFS_DATA_FORK); + break; + } + if (ip->i_afp) + xfs_idestroy_fork(ip, XFS_ATTR_FORK); + mrfree(&ip->i_lock); + mrfree(&ip->i_iolock); + freesema(&ip->i_flock); + +#ifdef XFS_INODE_TRACE + ktrace_free(ip->i_trace); +#endif +#ifdef XFS_BMAP_TRACE + ktrace_free(ip->i_xtrace); +#endif +#ifdef XFS_BMBT_TRACE + ktrace_free(ip->i_btrace); +#endif +#ifdef XFS_RW_TRACE + ktrace_free(ip->i_rwtrace); +#endif +#ifdef XFS_ILOCK_TRACE + ktrace_free(ip->i_lock_trace); +#endif +#ifdef XFS_DIR2_TRACE + ktrace_free(ip->i_dir_trace); +#endif + if (ip->i_itemp) { + /* + * Only if we are shutting down the fs will we see an + * inode still in the AIL. If it is there, we should remove + * it to prevent a use-after-free from occurring. + */ + xfs_mount_t *mp = ip->i_mount; + xfs_log_item_t *lip = &ip->i_itemp->ili_item; + + ASSERT(((lip->li_flags & XFS_LI_IN_AIL) == 0) || + XFS_FORCED_SHUTDOWN(ip->i_mount)); + if (lip->li_flags & XFS_LI_IN_AIL) { + spin_lock(&mp->m_ail_lock); + if (lip->li_flags & XFS_LI_IN_AIL) + xfs_trans_delete_ail(mp, lip); + else + spin_unlock(&mp->m_ail_lock); + } + xfs_inode_item_destroy(ip); + } + kmem_zone_free(xfs_inode_zone, ip); +} /* * xfs_iextents_copy() --------------030001020001050703050701-- From owner-xfs@oss.sgi.com Wed Dec 12 00:26:53 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 12 Dec 2007 00:27:50 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBC8Qo8K010994 for ; Wed, 12 Dec 2007 00:26:52 -0800 X-ASG-Debug-ID: 1197448017-0380004a0000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.lichtvoll.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 6F57AB3A547 for ; Wed, 12 Dec 2007 00:26:57 -0800 (PST) Received: from mail.lichtvoll.de (mondschein.lichtvoll.de [194.150.191.11]) by cuda.sgi.com with ESMTP id Icn909HDWTib4r6v for ; Wed, 12 Dec 2007 00:26:57 -0800 (PST) Received: from shambala.of.teamix.net (blackhole.teamix.net [194.150.191.251]) by mail.lichtvoll.de (Postfix) with ESMTP id 501585ADDC for ; Wed, 12 Dec 2007 09:25:09 +0100 (CET) From: Martin Steigerwald To: linux-xfs@oss.sgi.com X-ASG-Orig-Subj: Re: write barrier over device mapper supported or not? Subject: Re: write barrier over device mapper supported or not? Date: Wed, 12 Dec 2007 09:26:52 +0100 User-Agent: KMail/1.9.7 References: <200712112342.24094.Martin@lichtvoll.de> <475F5746.8080405@sandeen.net> (sfid-20071212_092001_588630_42C71ACD) In-Reply-To: <475F5746.8080405@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200712120926.53348.Martin@lichtvoll.de> X-Barracuda-Connect: mondschein.lichtvoll.de[194.150.191.11] X-Barracuda-Start-Time: 1197448021 X-Barracuda-Bayes: INNOCENT GLOBAL 0.3501 1.0000 -0.1525 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -0.15 X-Barracuda-Spam-Status: No, SCORE=-0.15 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36394 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5098/Tue Dec 11 21:46:37 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13920 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Martin@lichtvoll.de Precedence: bulk X-list: xfs Am Mittwoch 12 Dezember 2007 schrieb Eric Sandeen: > Martin Steigerwald wrote: > > Hello! > > > > Are write barriers over device mapper supported or not? > > Nope. > > see dm_request(): > > /* > * There is no use in forwarding any barrier request since we > can't * guarantee it is (or can be) handled by the targets correctly. > */ > if (unlikely(bio_barrier(bio))) { > bio_endio(bio, -EOPNOTSUPP); > return 0; > } Thanks for your definitive answer. What does that mean? What is the target in that case? If it is the libata PATA internal notebook drive it actually should support barriers and then I actually would like device mapper to support them too. Or is LVM2 the target and device mapper can't tell that LVM2 supports it? I ask myself the question why write barrier if half the kernel does not handle it correctly and I am limited to plain partitions if I want to use it? Well I think I will just file a bug report at kernel.bugzilla.org about it. Ciao, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 From owner-xfs@oss.sgi.com Wed Dec 12 01:19:39 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 12 Dec 2007 01:21:04 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBC9JXjI015357 for ; Wed, 12 Dec 2007 01:19:35 -0800 X-ASG-Debug-ID: 1197451183-794500cd0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from astra.telenet-ops.be (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id E1907470D7A for ; Wed, 12 Dec 2007 01:19:44 -0800 (PST) Received: from astra.telenet-ops.be (astra.telenet-ops.be [195.130.132.58]) by cuda.sgi.com with ESMTP id ysjyJYdtdqZrBFAL for ; Wed, 12 Dec 2007 01:19:44 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by astra.telenet-ops.be (Postfix) with SMTP id 222F83810F for ; Wed, 12 Dec 2007 10:19:42 +0100 (CET) Received: from [84.195.46.72] (d54C32E48.access.telenet.be [84.195.46.72]) by astra.telenet-ops.be (Postfix) with ESMTP id 0E2AC3810B for ; Wed, 12 Dec 2007 10:19:41 +0100 (CET) Message-ID: <475FA7B1.6070706@pandora.be> Date: Wed, 12 Dec 2007 10:19:45 +0100 From: Denis Wegge User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS unable to mount, recover data Subject: Re: XFS unable to mount, recover data References: <475696D3.60007@pandora.be> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: astra.telenet-ops.be[195.130.132.58] X-Barracuda-Start-Time: 1197451184 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0012 1.0000 -2.0132 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.01 X-Barracuda-Spam-Status: No, SCORE=-2.01 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36398 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5099/Tue Dec 11 23:17:10 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13921 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: denis_wegge@pandora.be Precedence: bulk X-list: xfs I tried putting it in the freezer, but that didn't help. Tests on another computer also show that the hard drive cannot be accessed. It seems like the data on the disk is definitely lost. The disk, however, has a 3 year warranty, so I'm going to return it. Thanks for your help. Denis Justin Piszcz wrote: > > > On Wed, 5 Dec 2007, Denis Wegge wrote: > >> Hello >> >> I am having trouble with the XFS filesystem on a 320GB Western Digital >> SATA harddisk. For no obvious reason the partition can no longer be >> mounted. The following error occurs: >> >> knoppix@Knoppix:~$ sudo mount /dev/sda1 /mnt/sda1 >> mount: /dev/sda1: can't read superblock > > Looks like your disk is dying or dead from your logs. You can try > putting it > in a plastic airtight bag then put it in the freezer and try again but > otherwise if that does not work, its time for the trash bin (after you try) > a dd and overwrite the disk but with that many bad sectors it looks like > it has really gone south. > > Insert new disk, restore from backup. > > Justin. > > > From owner-xfs@oss.sgi.com Wed Dec 12 03:07:36 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 12 Dec 2007 03:08:03 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id lBCB7W08023873 for ; Wed, 12 Dec 2007 03:07:34 -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 WAA02609; Wed, 12 Dec 2007 22:07:39 +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 lBCB7bIN5770421; Wed, 12 Dec 2007 22:07:38 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id lBCB7ZVG5770781; Wed, 12 Dec 2007 22:07:35 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Wed, 12 Dec 2007 22:07:35 +1100 From: David Chinner To: Matthew Hodgson Cc: xfs@oss.sgi.com Subject: Re: Zero-copy Block IO with XFS Message-ID: <20071212110735.GH4612@sgi.com> References: <475E76AB.705@mxtelecom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <475E76AB.705@mxtelecom.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/5099/Tue Dec 11 23:17:10 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13922 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Tue, Dec 11, 2007 at 11:38:19AM +0000, Matthew Hodgson wrote: > Hi all, > > I'm experimenting with using XFS with a network block device (DST), and > have come up against the problem that when writing data to the network, > it uses kernel_sendpage to hand the page presented at the BIO layer to > the network stack. It then completes the block IO request. > > The problem arises when XFS proceeds to then reuse that page before the > NIC actually sends it. Where does XFS overwrite a page while I/O is still in progress? Stack trace please. > Particularly if TX checksumming or TCP > segmentation is being offloaded to the NIC, it seems that the NIC will > try to access to page after the BIO request has returned, and so operate > on stale data. That sounds like you are completing the bio before the I/O has really been completed. Basically, the bio can't be completed until the data has been sent and that will prevent any use after free or overwrite of the data while it is being sent... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Wed Dec 12 03:12:10 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 12 Dec 2007 03:12:44 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id lBCBC2fS024393 for ; Wed, 12 Dec 2007 03:12:07 -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 WAA02676; Wed, 12 Dec 2007 22:12:05 +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 lBCBC4IN5770904; Wed, 12 Dec 2007 22:12:04 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id lBCBC2aA5770590; Wed, 12 Dec 2007 22:12:02 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Wed, 12 Dec 2007 22:12:02 +1100 From: David Chinner To: David Greaves Cc: David Chinner , xfs@oss.sgi.com Subject: Re: XFS internal error xfs_btree_check_sblock Message-ID: <20071212111202.GI4612@sgi.com> References: <475ED66F.40800@dgreaves.com> <20071211222546.GD4612@sgi.com> <475F2008.5030702@dgreaves.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <475F2008.5030702@dgreaves.com> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/5099/Tue Dec 11 23:17:10 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13923 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Tue, Dec 11, 2007 at 11:40:56PM +0000, David Greaves wrote: > David Chinner wrote: > > On Tue, Dec 11, 2007 at 06:26:55PM +0000, David Greaves wrote: > >> Once every 2 or 3 cold boots I get this in dmesg as the user logs in and > > So there's a corrupted freespace btree block. > OK, ta > > >> I ssh in as root, umount, mount, umount and run xfs_repair. > > repair doesn't check the freespace btrees - it just rebuilds them from > > scratch. use xfs_check to tell you what is wrong with the filesystem, then > > use xfs_repair to fix it.... > > OK, having repaired it: > haze:~# xfs_check /dev/video_vg/video_lv > haze:~# Of course there's no errors - you just repaired them ;) Run xfs_check before you run xfs-repair when a corruption occurs. > So why do I have to do this on a regular basis (ie run xfs_repair)? Don't know yet. > I am shutting the machine down cleanly (init 0) That doesn't mean everything shuts down cleanly.... > >> It is possible this fs suffered in the 2.6.17 timeframe > >> It is also possible something got broken whilst I was having lots of issues with > >> hibernate (which is still unreliable). > > > > Suspend does not quiesce filesystems safely, so you risk filesystem > > corruption every time you suspend and resume no matter what filesystem > > you use. > > Well, FWIW, I've not hibernated this machine for a *long* time. Ok, so ignore that. > Also my hibernate script used to run xfs_freeze before hibernating (to be on the > safe side). This would regularly hang with an xfs_io process (or some such IIRC) > in an unkillable state. Well, 2.6.23 completely broke this, along with freezing XFS filesystems. > I was about to edit my init scripts to do a mount, umount, xfs_repair, mount > cycle. But then I thought "this is wrong - I'll report it". > So is there anything else I should do? Check the filesystem before repairing it. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Wed Dec 12 03:18:53 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 12 Dec 2007 03:19:38 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBCBInT1025470 for ; Wed, 12 Dec 2007 03:18:52 -0800 X-ASG-Debug-ID: 1197458340-049b021e0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from puma.mxtelecom.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 0777BB3CA01; Wed, 12 Dec 2007 03:19:00 -0800 (PST) Received: from puma.mxtelecom.com (mx1.mxtelecom.com [87.86.212.101]) by cuda.sgi.com with ESMTP id O6UzT9mDAMDwuZsL; Wed, 12 Dec 2007 03:19:00 -0800 (PST) Received: from wings.mxtelecom.com ([192.168.2.111] helo=[127.0.0.1]) by puma.mxtelecom.com with esmtp (Exim 4.66) (envelope-from ) id 1J2PcA-0000xR-Pm; Wed, 12 Dec 2007 11:18:58 +0000 Message-ID: <475FC40C.3030102@mxtelecom.com> Date: Wed, 12 Dec 2007 11:20:44 +0000 From: Matthew Hodgson Organization: MX Telecom Ltd User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: David Chinner CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Zero-copy Block IO with XFS Subject: Re: Zero-copy Block IO with XFS References: <475E76AB.705@mxtelecom.com> <20071212110735.GH4612@sgi.com> In-Reply-To: <20071212110735.GH4612@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: mx1.mxtelecom.com[87.86.212.101] X-Barracuda-Start-Time: 1197458341 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0209 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36406 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5099/Tue Dec 11 23:17:10 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13924 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: matthew@mxtelecom.com Precedence: bulk X-list: xfs Hi Dave, Thanks for the response :) David Chinner wrote: > On Tue, Dec 11, 2007 at 11:38:19AM +0000, Matthew Hodgson wrote: >> I'm experimenting with using XFS with a network block device (DST), and >> have come up against the problem that when writing data to the network, >> it uses kernel_sendpage to hand the page presented at the BIO layer to >> the network stack. It then completes the block IO request. >> >> The problem arises when XFS proceeds to then reuse that page before the >> NIC actually sends it. > > Where does XFS overwrite a page while I/O is still in progress? > Stack trace please. It doesn't. The problem is that after the block device has completed the IO request with bio_endio(), there's a risk that it may still need access to the page in order to retransmit it, perform offloaded checksumming, etc. >> Particularly if TX checksumming or TCP >> segmentation is being offloaded to the NIC, it seems that the NIC will >> try to access to page after the BIO request has returned, and so operate >> on stale data. > > That sounds like you are completing the bio before the I/O has > really been completed. Basically, the bio can't be completed until > the data has been sent and that will prevent any use after free or > overwrite of the data while it is being sent... Agreed. In general that will cause a fairly major performance hit, however (you'd have to at least wait for the ACK from the TCP peer before completing the BIO). Or make a copy of the page. Is there no scope (however theoretical - I guess this is starting to become an academic question) for providing XFS with hints that particular pages are in use elsewhere and should not be overwritten? Could XFS mandate only overwriting pages in its cache with a ->count of 1? In other news, does XFS still provide the block layer with slab-allocated pages for metadata operations? thanks, Matthew. -- Matthew Hodgson Media & Systems Project Manager Tel: +44 (0) 845 666 7778 http://www.mxtelecom.com From owner-xfs@oss.sgi.com Wed Dec 12 03:39:35 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 12 Dec 2007 03:40:06 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBCBdXC5027549 for ; Wed, 12 Dec 2007 03:39:34 -0800 X-ASG-Debug-ID: 1197459579-14b300830000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.ukfsn.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 8ACAC4717C3 for ; Wed, 12 Dec 2007 03:39:40 -0800 (PST) Received: from mail.ukfsn.org (s2.ukfsn.org [217.158.120.143]) by cuda.sgi.com with ESMTP id BIxELAARiZ5ljzKi for ; Wed, 12 Dec 2007 03:39:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.ukfsn.org (Postfix) with ESMTP id 81CB8DECB9; Wed, 12 Dec 2007 11:41:04 +0000 (GMT) Received: from mail.ukfsn.org ([127.0.0.1]) by localhost (smtp-filter.ukfsn.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zW9iqUbsrjM4; Wed, 12 Dec 2007 11:41:04 +0000 (GMT) Received: from elm.dgreaves.com (i-83-67-36-194.freedom2surf.net [83.67.36.194]) by mail.ukfsn.org (Postfix) with ESMTP id 3CB68DECB3; Wed, 12 Dec 2007 11:41:04 +0000 (GMT) Received: from ash.dgreaves.com ([10.0.0.90]) by elm.dgreaves.com with esmtp (Exim 4.62) (envelope-from ) id 1J2Pw9-00040E-BZ; Wed, 12 Dec 2007 11:39:37 +0000 Message-ID: <475FC878.4000709@dgreaves.com> Date: Wed, 12 Dec 2007 11:39:36 +0000 From: David Greaves User-Agent: Mozilla-Thunderbird 2.0.0.6 (X11/20071009) MIME-Version: 1.0 To: David Chinner CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS internal error xfs_btree_check_sblock Subject: Re: XFS internal error xfs_btree_check_sblock References: <475ED66F.40800@dgreaves.com> <20071211222546.GD4612@sgi.com> <475F2008.5030702@dgreaves.com> <20071212111202.GI4612@sgi.com> In-Reply-To: <20071212111202.GI4612@sgi.com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: s2.ukfsn.org[217.158.120.143] X-Barracuda-Start-Time: 1197459584 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36402 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5099/Tue Dec 11 23:17:10 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13925 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: david@dgreaves.com Precedence: bulk X-list: xfs David Chinner wrote: > On Tue, Dec 11, 2007 at 11:40:56PM +0000, David Greaves wrote: >> So is there anything else I should do? > > Check the filesystem before repairing it. yeah, OK :) Well, it happened next boot. So: haze:~# umount /scratch haze:~# xfs_check /dev/video_vg/video_lv ERROR: The filesystem has valuable metadata changes in a log which needs to be replayed. Mount the filesystem to replay the log, and unmount it before re-running xfs_check. If you are unable to mount the filesystem, then use the xfs_repair -L option to destroy the log and attempt a repair. Note that destroying the log may cause corruption -- please attempt a mount of the filesystem before doing this. haze:~# mount /scratch haze:~# umount /scratch haze:~# xfs_check /dev/video_vg/video_lv bad format 2 for inode 1435146910 type 0 ir_freecount/free mismatch, inode chunk 42/25860704, freecount 64 nfree 63 bad format 2 for inode 1435150526 type 0 ir_freecount/free mismatch, inode chunk 42/25864320, freecount 64 nfree 63 bad format 2 for inode 1435173822 type 0 ir_freecount/free mismatch, inode chunk 42/25887616, freecount 64 nfree 63 bad format 2 for inode 1984739518 type 0 ir_freecount/free mismatch, inode chunk 59/5027968, freecount 27 nfree 26 allocated inode 1435146910 has 0 link count allocated inode 1435173822 has 0 link count allocated inode 1435150526 has 0 link count allocated inode 1984739518 has 0 link count haze:~# Filesystem "dm-0": XFS internal error xfs_btree_check_sblock at line 334 of file fs/xfs/xfs_btree.c. Caller 0xc01b7bc1 [] show_trace_log_lvl+0x1a/0x30 [] show_trace+0x12/0x20 [] dump_stack+0x15/0x20 [] xfs_error_report+0x4f/0x60 [] xfs_btree_check_sblock+0x56/0xd0 [] xfs_alloc_lookup+0x181/0x390 [] xfs_alloc_lookup_ge+0x16/0x20 [] xfs_alloc_ag_vextent_size+0x52/0x410 [] xfs_alloc_ag_vextent+0x107/0x110 [] xfs_alloc_fix_freelist+0x1f8/0x450 [] xfs_free_extent+0x8c/0xd0 [] xfs_bmap_finish+0x119/0x170 [] xfs_itruncate_finish+0x23a/0x3a0 [] xfs_free_eofblocks+0x26d/0x2b0 [] xfs_release+0x171/0x270 [] xfs_file_release+0x16/0x20 [] __fput+0x9b/0x190 [] fput+0x18/0x20 [] filp_close+0x47/0x80 [] sys_close+0x87/0x110 [] syscall_call+0x7/0xb ======================= xfs_force_shutdown(dm-0,0x8) called from line 4274 of file fs/xfs/xfs_bmap.c. Return address = 0xc0214dae Filesystem "dm-0": Corruption of in-memory data detected. Shutting down filesystem: dm-0 I've not yet run a repair... David From owner-xfs@oss.sgi.com Wed Dec 12 05:19:36 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 12 Dec 2007 05:20:05 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_43 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBCDJYQj007484 for ; Wed, 12 Dec 2007 05:19:36 -0800 X-ASG-Debug-ID: 1197465585-727501780000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from lucidpixels.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 27B57471BF6 for ; Wed, 12 Dec 2007 05:19:45 -0800 (PST) Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by cuda.sgi.com with ESMTP id IjvV5vP05gumEUe8 for ; Wed, 12 Dec 2007 05:19:45 -0800 (PST) Received: by lucidpixels.com (Postfix, from userid 1001) id 124FE1C001985; Wed, 12 Dec 2007 08:19:14 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id 0DD5E4019355; Wed, 12 Dec 2007 08:19:14 -0500 (EST) Date: Wed, 12 Dec 2007 08:19:14 -0500 (EST) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: Timothy Shimmin cc: David Sparks , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: mkfs.xfs ... lazy-count=1 ... not mountable by older kernels? Subject: Re: mkfs.xfs ... lazy-count=1 ... not mountable by older kernels? In-Reply-To: <475F2D54.3090609@sgi.com> Message-ID: References: <475EE83A.3060607@ca.sophos.com> <20071211221554.GC4612@sgi.com> <475F2D54.3090609@sgi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Barracuda-Connect: lucidpixels.com[75.144.35.66] X-Barracuda-Start-Time: 1197465586 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36415 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5099/Tue Dec 11 23:17:10 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13926 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs On Wed, 12 Dec 2007, Timothy Shimmin wrote: > David Chinner wrote: >> On Tue, Dec 11, 2007 at 11:42:50AM -0800, David Sparks wrote: >>> Hi all, >>> >>> Is it expected that filesystems made with lazy-count=1 are not mountable >>> by >>> older kernels? >> >> That is expected. lazy-count is a mkfs option because it changes the >> on-disk >> format slightly, and older kernels do not understand that format. Hence >> mkfs sets a superblock feature bit to prevent the filesystem from being >> mounted on kernels that don't understand the slightly different disk >> format. >> >> Cheers, >> >> Dave. > > And there will be a message in the logs but it probably isn't > overly obvious what it is talking about. > > Looking at code, I presume it will come from: > if (!XFS_SB_GOOD_VERSION(sbp)) { > xfs_fs_mount_cmn_err(flags, "bad version"); > return XFS_ERROR(EWRONGFS); > } > so there will be a msg about a "bad version". > > --Tim > > Has anyone done any benchmarks with Dave Chinner's recommendations for mkfs.xfs/optmizations? Justin. From owner-xfs@oss.sgi.com Wed Dec 12 05:26:26 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 12 Dec 2007 05:26:45 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBCDQMs9008258 for ; Wed, 12 Dec 2007 05:26:26 -0800 X-ASG-Debug-ID: 1197465993-567e00080000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from lucidpixels.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 442CA10FBA2B for ; Wed, 12 Dec 2007 05:26:33 -0800 (PST) Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by cuda.sgi.com with ESMTP id sPqqG5pa4TsGQPvi for ; Wed, 12 Dec 2007 05:26:33 -0800 (PST) Received: by lucidpixels.com (Postfix, from userid 1001) id 67E751C001985; Wed, 12 Dec 2007 08:26:01 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id 63F754019355; Wed, 12 Dec 2007 08:26:01 -0500 (EST) Date: Wed, 12 Dec 2007 08:26:01 -0500 (EST) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: Denis Wegge cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS unable to mount, recover data Subject: Re: XFS unable to mount, recover data In-Reply-To: <475FA7B1.6070706@pandora.be> Message-ID: References: <475696D3.60007@pandora.be> <475FA7B1.6070706@pandora.be> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Barracuda-Connect: lucidpixels.com[75.144.35.66] X-Barracuda-Start-Time: 1197465994 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36414 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5099/Tue Dec 11 23:17:10 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13927 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs Just curious what brand/make/model was it that failed? On Wed, 12 Dec 2007, Denis Wegge wrote: > I tried putting it in the freezer, but that didn't help. Tests on > another computer also show that the hard drive cannot be accessed. > > It seems like the data on the disk is definitely lost. The disk, > however, has a 3 year warranty, so I'm going to return it. > > Thanks for your help. > > Denis > > Justin Piszcz wrote: >> >> >> On Wed, 5 Dec 2007, Denis Wegge wrote: >> >>> Hello >>> >>> I am having trouble with the XFS filesystem on a 320GB Western Digital >>> SATA harddisk. For no obvious reason the partition can no longer be >>> mounted. The following error occurs: >>> >>> knoppix@Knoppix:~$ sudo mount /dev/sda1 /mnt/sda1 >>> mount: /dev/sda1: can't read superblock >> >> Looks like your disk is dying or dead from your logs. You can try putting >> it >> in a plastic airtight bag then put it in the freezer and try again but >> otherwise if that does not work, its time for the trash bin (after you try) >> a dd and overwrite the disk but with that many bad sectors it looks like >> it has really gone south. >> >> Insert new disk, restore from backup. >> >> Justin. >> >> >> > > From owner-xfs@oss.sgi.com Wed Dec 12 12:06:24 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 12 Dec 2007 12:09:34 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBCK6JQx014720 for ; Wed, 12 Dec 2007 12:06:23 -0800 X-ASG-Debug-ID: 1197489979-79d4000a0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from astra.telenet-ops.be (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id D2465B60151 for ; Wed, 12 Dec 2007 12:06:19 -0800 (PST) Received: from astra.telenet-ops.be (astra.telenet-ops.be [195.130.132.58]) by cuda.sgi.com with ESMTP id N8TAutOvpcOPuTWk for ; Wed, 12 Dec 2007 12:06:19 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by astra.telenet-ops.be (Postfix) with SMTP id F0E1938154; Wed, 12 Dec 2007 21:05:44 +0100 (CET) Received: from [84.195.42.103] (d54C32A67.access.telenet.be [84.195.42.103]) by astra.telenet-ops.be (Postfix) with ESMTP id B8CFC38141; Wed, 12 Dec 2007 21:05:44 +0100 (CET) Message-ID: <47603F1E.1090901@pandora.be> Date: Wed, 12 Dec 2007 21:05:50 +0100 From: Denis Wegge User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Justin Piszcz Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS unable to mount, recover data Subject: Re: XFS unable to mount, recover data References: <475696D3.60007@pandora.be> <475FA7B1.6070706@pandora.be> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: astra.telenet-ops.be[195.130.132.58] X-Barracuda-Start-Time: 1197489990 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36442 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5105/Wed Dec 12 10:28:14 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13928 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: denis_wegge@pandora.be Precedence: bulk X-list: xfs It was a Western Digital 320GB SATAII 16MB, WD3200KS-00PFB0 (don't remember the name of the model). Justin Piszcz wrote: > Just curious what brand/make/model was it that failed? > > On Wed, 12 Dec 2007, Denis Wegge wrote: > >> I tried putting it in the freezer, but that didn't help. Tests on >> another computer also show that the hard drive cannot be accessed. >> >> It seems like the data on the disk is definitely lost. The disk, >> however, has a 3 year warranty, so I'm going to return it. >> >> Thanks for your help. >> >> Denis >> >> Justin Piszcz wrote: >>> >>> >>> On Wed, 5 Dec 2007, Denis Wegge wrote: >>> >>>> Hello >>>> >>>> I am having trouble with the XFS filesystem on a 320GB Western Digital >>>> SATA harddisk. For no obvious reason the partition can no longer be >>>> mounted. The following error occurs: >>>> >>>> knoppix@Knoppix:~$ sudo mount /dev/sda1 /mnt/sda1 >>>> mount: /dev/sda1: can't read superblock >>> >>> Looks like your disk is dying or dead from your logs. You can try >>> putting it >>> in a plastic airtight bag then put it in the freezer and try again but >>> otherwise if that does not work, its time for the trash bin (after >>> you try) >>> a dd and overwrite the disk but with that many bad sectors it looks like >>> it has really gone south. >>> >>> Insert new disk, restore from backup. >>> >>> Justin. >>> >>> >>> >> >> > > From owner-xfs@oss.sgi.com Wed Dec 12 12:27:17 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 12 Dec 2007 12:28:13 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_50,URIBL_GREY autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBCKRDl5020864 for ; Wed, 12 Dec 2007 12:27:16 -0800 X-ASG-Debug-ID: 1197491243-31ce003a0000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from umail.ru (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id B4EF6475526 for ; Wed, 12 Dec 2007 12:27:24 -0800 (PST) Received: from umail.ru (fe01-umail.mtu.ru [62.5.255.15]) by cuda.sgi.com with ESMTP id lUONC8J4eKF7leQf for ; Wed, 12 Dec 2007 12:27:24 -0800 (PST) X-ASG-Orig-Subj: Undeliverable mail: Delivery reports about your e-mail Subject: Undeliverable mail: Delivery reports about your e-mail From: To: Date: Wed, 12 Dec 2007 23:11:50 +0300 Message-ID: X-MAPI-Message-Class: REPORT.IPM.Note.NDR MIME-Version: 1.0 Content-Type: multipart/report; report-type="delivery-status"; boundary="_===304745768====fe01-umail.umail.ru===_" X-Barracuda-Connect: fe01-umail.mtu.ru[62.5.255.15] X-Barracuda-Start-Time: 1197491244 X-Barracuda-Bayes: INNOCENT GLOBAL 0.6314 1.0000 0.9100 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 1.46 X-Barracuda-Spam-Status: No, SCORE=1.46 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests=NO_REAL_NAME X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36443 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.55 NO_REAL_NAME From: does not include a real name X-Virus-Scanned: ClamAV 0.91.2/5105/Wed Dec 12 10:28:14 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13929 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: MAILER-DAEMON@umail.ru Precedence: bulk X-list: xfs --_===304745768====fe01-umail.umail.ru===_ Content-Type: text/plain; charset="utf-8" Failed to deliver to 'olgaefimova@mtu-net.ru' LOCAL module(account olgaefimova@mtu-net.ru) reports: account is full (quota exceeded) --_===304745768====fe01-umail.umail.ru===_ Content-Type: message/delivery-status Reporting-MTA: dns; fe01-umail.umail.ru Original-Recipient: rfc822; Final-Recipient: LOCAL; Action: failed Status: 4.0.0 --_===304745768====fe01-umail.umail.ru===_ Content-Type: text/rfc822-headers Received: from [195.34.34.242] (HELO so01.mtu.ru) by fe01-umail.umail.ru (CommuniGate Pro SMTP 5.1.10) with ESMTP id 304745757 for olgaefimova@mtu-net.ru; Wed, 12 Dec 2007 23:11:49 +0300 Received: from so01.mtu.ru (localhost.mtu.ru [127.0.0.1]) by so01.mtu.ru (Postfix) with ESMTP id 072DCBA8620 for ; Wed, 12 Dec 2007 23:11:48 +0300 (MSK) Received: from localhost (localhost.mtu.ru [127.0.0.1]) by so01.mtu.ru (Postfix) with ESMTP id E0471BA8604 for ; Wed, 12 Dec 2007 23:11:47 +0300 (MSK) X-Spam-Flag: YES X-Spam-Yversion: Spamooborona 1.7.0-isp Received: from smtp04.mtu.ru (alt-proxy-1.mtu.ru [62.5.255.74]) by so01.mtu.ru (Postfix) with ESMTP id DC3C8BABBF5 for ; Wed, 12 Dec 2007 22:59:08 +0300 (MSK) Received: from smtp04.mtu.ru (localhost [127.0.0.1]) by smtp04.mtu.ru (Postfix) with ESMTP id A5F13819944 for ; Wed, 12 Dec 2007 22:46:06 +0300 (MSK) Received: from oss.sgi.com (ppp128-96.dialup.mtu-net.ru [62.118.128.96]) by smtp04.mtu.ru (Postfix) with ESMTP id A43F2820AC7 for ; Wed, 12 Dec 2007 22:21:00 +0300 (MSK) From: linux-xfs@oss.sgi.com To: olgaefimova@mtu-net.ru Subject: Delivery reports about your e-mail Date: Thu, 7 Sep 2006 12:46:40 +0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0003_54D0AF69.C774F603" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-Id: <20071212192102.A43F2820AC7@smtp04.mtu.ru> X-DCC-STREAM-Metrics: so01.mtu.ru 10002; Body=1 Fuz1=1 --_===304745768====fe01-umail.umail.ru===_-- From owner-xfs@oss.sgi.com Wed Dec 12 19:44:49 2007 Received: with ECARTIS (v1.0.0; list xfs); Wed, 12 Dec 2007 19:45:07 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id lBD3ihGq027747 for ; Wed, 12 Dec 2007 19:44:46 -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 OAA29657; Thu, 13 Dec 2007 14:44:45 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 16346) id 2DEBC58C4C35; Thu, 13 Dec 2007 14:44:45 +1100 (EST) To: sgi.bugs.xfs@engr.sgi.com Cc: xfs@oss.sgi.com Subject: TAKE 973746 - Put the correct offset in dirent d_off Message-Id: <20071213034445.2DEBC58C4C35@chook.melbourne.sgi.com> Date: Thu, 13 Dec 2007 14:44:45 +1100 (EST) From: dgc@sgi.com (David Chinner) X-Virus-Scanned: ClamAV 0.91.2/5106/Wed Dec 12 11:34:15 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13935 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Put the correct offset in dirent d_off The recent filldir regression fix was not putting the correct d_off in each dirent. This was resulting in incorrect cookies being passed to dmapi ioctls and the wrong offset appearing in the dirents. readdir was unaffected as the filp->f_pos was being updated with the correct offset and this was being written into the last dirent in each buffer. Fix the XFS code to do the right thing. Date: Thu Dec 13 14:44:12 AEDT 2007 Workarea: chook.melbourne.sgi.com:/build/dgc/isms/2.6.x-xfs Inspected by: hch@lst.de The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:30240a fs/xfs/xfs_dir2_block.c - 1.58 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir2_block.c.diff?r1=text&tr1=1.58&r2=text&tr2=1.57&f=h - pass the current offset to the filldir method rather than the offset of the next object. filldir expects the current offset, not the next one. fs/xfs/xfs_dir2_sf.c - 1.50 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir2_sf.c.diff?r1=text&tr1=1.50&r2=text&tr2=1.49&f=h - pass the current offset to the filldir method rather than the offset of the next object. filldir expects the current offset, not the next one. fs/xfs/xfs_dir2_leaf.c - 1.60 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir2_leaf.c.diff?r1=text&tr1=1.60&r2=text&tr2=1.59&f=h - pass the current offset to the filldir method rather than the offset of the next object. filldir expects the current offset, not the next one. fs/xfs/linux-2.6/xfs_file.c - 1.160 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_file.c.diff?r1=text&tr1=1.160&r2=text&tr2=1.159&f=h - Update filp->f_pos correctly now that we pass the current offset with each dirent to filldir. fs/xfs/dmapi/xfs_dm.c - 1.61 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/dmapi/xfs_dm.c.diff?r1=text&tr1=1.61&r2=text&tr2=1.60&f=h - Remove special handling of dirent offsets for the cookie betwen ioctl calls. From owner-xfs@oss.sgi.com Thu Dec 13 02:42:29 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 13 Dec 2007 02:43:08 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBDAgRPx003652 for ; Thu, 13 Dec 2007 02:42:29 -0800 X-ASG-Debug-ID: 1197542556-59ad005c0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.ukfsn.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 7DF00112B893 for ; Thu, 13 Dec 2007 02:42:36 -0800 (PST) Received: from mail.ukfsn.org (mx1.ukfsn.org [77.75.108.10]) by cuda.sgi.com with ESMTP id aXthujiwyWDAMO8p for ; Thu, 13 Dec 2007 02:42:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.ukfsn.org (Postfix) with ESMTP id CA551DECFF; Thu, 13 Dec 2007 10:44:07 +0000 (GMT) Received: from mail.ukfsn.org ([127.0.0.1]) by localhost (smtp-filter.ukfsn.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29J-dWkaBx70; Thu, 13 Dec 2007 10:44:07 +0000 (GMT) Received: from elm.dgreaves.com (i-83-67-36-194.freedom2surf.net [83.67.36.194]) by mail.ukfsn.org (Postfix) with ESMTP id 96E15DF316; Thu, 13 Dec 2007 10:44:07 +0000 (GMT) Received: from [10.0.0.90] by elm.dgreaves.com with esmtp (Exim 4.62) (envelope-from ) id 1J2lWU-0008QE-Rm; Thu, 13 Dec 2007 10:42:34 +0000 Message-ID: <47610C9A.3070406@dgreaves.com> Date: Thu, 13 Dec 2007 10:42:34 +0000 From: David Greaves User-Agent: Mozilla-Thunderbird 2.0.0.6 (X11/20071009) MIME-Version: 1.0 To: David Chinner CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS internal error xfs_btree_check_sblock Subject: Re: XFS internal error xfs_btree_check_sblock References: <475ED66F.40800@dgreaves.com> <20071211222546.GD4612@sgi.com> <475F2008.5030702@dgreaves.com> <20071212111202.GI4612@sgi.com> <475FC878.4000709@dgreaves.com> <20071212220032.GJ4612@sgi.com> In-Reply-To: <20071212220032.GJ4612@sgi.com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Barracuda-Connect: mx1.ukfsn.org[77.75.108.10] X-Barracuda-Start-Time: 1197542559 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36498 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5106/Wed Dec 12 11:34:15 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13936 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: david@dgreaves.com Precedence: bulk X-list: xfs David Chinner wrote: > Can you hol doff for a while longer? I'm afraid SWMBO came home and "did the usual fix" whilst I was making coffee.. (she's almost as well trained as I am!) I'll wait for a recurrence and do as you suggested... David From owner-xfs@oss.sgi.com Thu Dec 13 07:52:36 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 13 Dec 2007 07:52:54 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: **** X-Spam-Status: No, score=4.0 required=5.0 tests=AWL,BAYES_50,HTML_MESSAGE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBDFqXUI031052 for ; Thu, 13 Dec 2007 07:52:35 -0800 X-ASG-Debug-ID: 1197561163-6c37021b0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from wa-out-1112.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 943D2111EE1C for ; Thu, 13 Dec 2007 07:52:43 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.176]) by cuda.sgi.com with ESMTP id tk2hrlB9z1rreV3J for ; Thu, 13 Dec 2007 07:52:43 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id k22so1243306waf.18 for ; Thu, 13 Dec 2007 07:52:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=scQhA7U359Zb7w5pm/uovKgNtfGrk6E7J3HBgfKeaAY=; b=gSeQM5pInlmbGrnE8ALbyE+bVuMSCEcMevku+2QN9ufEOtE7pe/91U8AE9n1/uP1nN5fc9EWVHDjqeZ2Dr0qqtSYyVsNNReYfAUEvOqwWOSpmep8IswoWJhrCoOEl1QAHMNDbRKWiVF/8HS2KHzZBA7TSOp4bLLh196oQTlkVro= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=M6TsuLC2gkXLZWqCAnj69oiYVMGyFADhF6qcveTsz5pSdsC6OphXoFsXc0qcpIfZwbGDJyR2PGIwSo12E28N5lOIwbG4uTmafMov+QF59uTvje51liEYJifANfwLC+6xKQIHVgHAMn+A4ofeWhcCRhiGA2sLjnRsnQ6Ga9p03xI= Received: by 10.114.94.1 with SMTP id r1mr2420032wab.32.1197560778970; Thu, 13 Dec 2007 07:46:18 -0800 (PST) Received: by 10.115.74.17 with HTTP; Thu, 13 Dec 2007 07:46:18 -0800 (PST) Message-ID: Date: Thu, 13 Dec 2007 16:46:18 +0100 From: "KE Liew" To: xfs@oss.sgi.com X-ASG-Orig-Subj: mount: Function not implemented Subject: mount: Function not implemented MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_35143_13710901.1197560778960" X-Barracuda-Connect: wa-out-1112.google.com[209.85.146.176] X-Barracuda-Start-Time: 1197561164 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.08 X-Barracuda-Spam-Status: No, SCORE=-1.08 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests=HTML_10_20, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36518 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message 0.94 HTML_10_20 BODY: Message is 10% to 20% HTML X-Virus-Scanned: ClamAV 0.91.2/5112/Thu Dec 13 03:09:13 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13937 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: ke.liew@gmail.com Precedence: bulk X-list: xfs ------=_Part_35143_13710901.1197560778960 Content-Type: multipart/alternative; boundary="----=_Part_35144_16749570.1197560778960" ------=_Part_35144_16749570.1197560778960 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi all, I was in #xfs with sandeen in discussing on the above issue. In the nutshell, I can't mount /dev/hdb due to the above error: mount -t xfs /dev/hdb /path/to It all started after I did a sequence of things to the new hdd I purchased. First, I created an msdos disklabel on a new xfs partition /dev/hdb1. It uses the full capacity of the hdd. Then I transferred files from one hdd to another using mv -v /stuff-to-transfer /hdb-mount-point Upon completion, I umount both devices and rebooted. On boot, I was not able to mount neither /dev/hdb1 nor /dev/hdb. /dev/hdb1 returns mount: special device /dev/hdb1 does not exist and /dev/hdb returns the above error message, no relevant messages are present in dmesg | tail The hexdump: =================== # dd if=/dev/hdb bs=512 count=1 | hexdump -C 1+0 records in 1+0 records out 00000000 58 46 53 42 00 01 00 00 00 00 00 00 00 3a 38 b0 |XFSB.........:8.| 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000020 82 fd 56 0c 80 92 4f 4a 87 8b 5e 5d 5e 55 89 aa |..V...OJ..^]^U..| 00000030 00 00 00 00 00 20 00 05 00 00 00 00 00 00 09 00 |..... ..........| 00000040 00 00 00 00 00 00 09 01 00 00 00 00 00 00 09 02 |................| 00000050 00 00 00 01 00 03 a3 8b 00 00 00 10 00 00 00 00 |................| 00000060 00 00 07 47 3c 04 80 00 01 00 01 00 00 00 00 00 |...G<...........| 00000070 00 00 00 00 00 00 00 00 10 0f 08 08 12 00 00 19 |................| 00000080 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 fd |................| 00000090 00 00 00 00 00 3a 31 18 00 00 00 00 00 00 00 00 |.....:1.........| 000000a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 000000c0 00 0f 80 00 00 01 00 00 00 00 00 00 00 00 00 00 |................| 000000d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000200 512 bytes (512 B) copied, 0.00695137 seconds, 73.7 kB/s =================== The xfs_db: =================== # xfs_db -r -c "sb 0" -c p /dev/hdb cache_node_purge: refcount was 1, not zero (node=0x80ca410) xfs_db: cannot read root inode (22) cache_node_purge: refcount was 1, not zero (node=0x80da608) xfs_db: cannot read realtime bitmap inode (22) Segmentation fault =================== Distro: Debian etch uname -a : 2.6.18-5-686 xfsprogs version 2.9.4-2 (from Sid) You will find the chatlog attached. I just hope that it's recoverable even though I have backups that aren't exactly up to date. Thanks! Best regards, KwangErn ------=_Part_35144_16749570.1197560778960 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi all,

I was in #xfs with sandeen in discussing on the above issue. In the nutshell, I can't mount /dev/hdb due to the above error: mount -t xfs /dev/hdb /path/to

It all started after I did a sequence of things to the new hdd I purchased. First, I created an msdos disklabel on a new xfs partition /dev/hdb1. It uses the full capacity of the hdd. Then I transferred files from one hdd to another using mv -v /stuff-to-transfer /hdb-mount-point Upon completion, I umount both devices and rebooted. On boot, I was not able to mount neither /dev/hdb1 nor /dev/hdb. /dev/hdb1 returns mount: special device /dev/hdb1 does not exist and /dev/hdb returns the above error message, no relevant messages are present in dmesg | tail

The hexdump:
===================
# dd if=/dev/hdb bs=512 count=1 | hexdump -C
1+0 records in
1+0 records out
00000000  58 46 53 42 00 01 00 00  00 00 00 00 00 3a 38 b0  |XFSB.........:8.|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000020  82 fd 56 0c 80 92 4f 4a  87 8b 5e 5d 5e 55 89 aa  |..V...OJ..^]^U..|
00000030  00 00 00 00 00 20 00 05  00 00 00 00 00 00 09 00  |..... ..........|
00000040  00 00 00 00 00 00 09 01  00 00 00 00 00 00 09 02  |................|
00000050  00 00 00 01 00 03 a3 8b  00 00 00 10 00 00 00 00  |................|
00000060  00 00 07 47 3c 04 80 00  01 00 01 00 00 00 00 00  |...G<...........|
00000070  00 00 00 00 00 00 00 00  10 0f 08 08 12 00 00 19  |................|
00000080  00 00 00 00 00 00 01 00  00 00 00 00 00 00 00 fd  |................|
00000090  00 00 00 00 00 3a 31 18  00 00 00 00 00 00 00 00  |.....:1.........|
000000a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000000c0  00 0f 80 00 00 01 00 00  00 00 00 00 00 00 00 00  |................|
000000d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000200
512 bytes (512 B) copied, 0.00695137 seconds, 73.7 kB/s
===================

The xfs_db:
===================
# xfs_db -r -c "sb 0" -c p /dev/hdb
cache_node_purge: refcount was 1, not zero (node=0x80ca410)
xfs_db: cannot read root inode (22)
cache_node_purge: refcount was 1, not zero (node=0x80da608)
xfs_db: cannot read realtime bitmap inode (22)
Segmentation fault
===================

Distro: Debian etch
uname -a : 2.6.18-5-686
xfsprogs version 2.9.4-2 (from Sid)

You will find the chatlog attached. I just hope that it's recoverable even though I have backups that aren't exactly up to date.

Thanks!


Best regards,

KwangErn
------=_Part_35144_16749570.1197560778960-- ------=_Part_35143_13710901.1197560778960 Content-Type: text/plain; name=XFS-SGI.txt Content-Transfer-Encoding: base64 X-Attachment-Id: f_fa5gpacd0 Content-Disposition: attachment; filename=XFS-SGI.txt PGt0d2lsaWdodD4gaSd2ZSBnb3QgYW4gWEZTIHBhcnRpdGlvbiwgaXQgZG9l c24ndCBtb3VudCAnY3V6IHRoZSBzdXBlcmJsb2NrIGNhbid0IGJlIGZvdW5k LCB3aGljaCB3YXMgd2VpcmQuIGkgdHJpZWQgeGZzX3JlcGFpciBidXQgaXQg ZGlkbid0IGdpdmUgbWUgYW55IGdvb2QgcmVzdWx0cy4gaSB0cmllZCB3aXRo IHhmc19yZXBhaXIgLW8gYXNzdW1lX3hmcyAvZGV2L3NkYSBhbmQgaXQgc3Rp bGwgZG9lc24ndCBzZWVtIHRvIHdvcmsuIHNvIGhvdyBjYW4gaSBtb3VudCB0 aGlzIHBhcnRpdGlvbiB3aGVuIGl0IGNhbid0IGZpbmQgdGhlIHN1cGVyYmxv Y2s/IGkga25vdyB0aGVyZSBhcmUgY29udGVudHMgJ2N1eiBpIHRyYW5zZmVy ZWQgZmlsZXMgdG8gaXQgYW5kIHVtb3VudCBpdCBiZWZvcmUgcmVib290aW5n Lgo8c2FuZGVlbj4gd2hhdCBoYXBwZW5lZCBiZXR3ZWVuIHdvcmtpbmcgYW5k IG5vdCB3b3JraW5nPwo8a3R3aWxpZ2h0PiBzYW5kZWVuLCBpIHRyYW5zZmVy ZWQgZmlsZXMgdG8gaXQsIHVtb3VudCBpdCwgdGhlbiByZWJvb3QKPHNhbmRl ZW4+IGt0d2lsaWdodCwgaG93IGJpZyBpcyB0aGUgcGFydGl0aW9uCjxzYW5k ZWVuPiBrdHdpbGlnaHQsIHdoYXQga2VybmVsLCB3aGljaCBwYXJ0aXRpb24s IHdoYXQgdHlwZSBvZiBibG9jayBkZXZpY2UsIGV0Ywo8a3R3aWxpZ2h0PiAy LjYuMTgtNSwgaXQncyB0aGUgZW50aXJlIGhkZCwgL2Rldi9oZGIKPGt0d2ls aWdodD4gd2hhdCBkbyB5b3UgbWVhbiBieSBibG9jayBkZXZpY2U/CjxzYW5k ZWVuPiB0aGF0J3MgZW5vdWdoCjxzYW5kZWVuPiB3aGF0IGRvZXMgZmlsZSAt cyAvZGV2L3NkYiBzYXkKPHNhbmRlZW4+IGVyCjxzYW5kZWVuPiBoZGIgOikK PGt0d2lsaWdodD4gL2Rldi9oZGI6IFNHSSBYRlMgZmlsZXN5c3RlbSBkYXRh IChibGtzeiA2NTUzNiwgaW5vc3ogMjU2LCB2MiBkaXJzKQo8a3R3aWxpZ2h0 PiBpdCBzaG91bGQgaGF2ZSBhIC9kZXYvaGRiMQo8c2FuZGVlbj4gaHVoLCBv aywgSSB0aG91Z2h0IG1heWJlIHNvbWV0aGluZyBvdmVyd3JvdGUgaXQKPGt0 d2lsaWdodD4gaXQncyB1bW91bnQsIGFuZCBpIHRyeSBteSBiZXN0IG5vdCB0 byBkbyBhbnl0aGluZyB0byBkbyA6KQo8c2FuZGVlbj4gbm90aGluZyB3cm9u ZyB3aXRoIHVzaW5nIHRoZSB3aG9sZSBiZGV2CjxrdHdpbGlnaHQ+IGhtLCBi dXQgaSBjYW4ndCBtb3VudCBlaXRoZXIgaGRiIG9yIGhkYjEKPHNhbmRlZW4+ IHdoaWNoIG9uZSAqc2hvdWxkKiBpdCBiZQo8c2FuZGVlbj4gd2hhdCB1c2Vk IHRvIG1vdW50IDopCjxzYW5kZWVuPiBpLmUgLndoYXQncyBpbiBmc3RhYgo8 a3R3aWxpZ2h0PiBub3RoaW5nIGluIGZzdGFiCjxrdHdpbGlnaHQ+IGJ1dCBp IHVzZWQgaGRiMSB0byBtb3VudCBwcmV2aW91c2x5CjxzYW5kZWVuPiB3aGF0 IGRvZXMgZmlsZSAtcyAvZGV2L2hkYjEgc2F5IHRoZW4/CjxzYW5kZWVuPiBv ciBmZGlzayAtbCAvZGV2L3NkYj8KPGt0d2lsaWdodD4gL2Rldi9oZGIxOiBF UlJPUjogY2Fubm90IG9wZW4gYC9kZXYvaGRiMScgKE5vIHN1Y2ggZmlsZSBv ciBkaXJlY3RvcnkpCjxrdHdpbGlnaHQ+IERpc2sgL2Rldi9oZGI6IDI1MC4w IEdCLCAyNTAwNTkzNTAwMTYgYnl0ZXMKPGt0d2lsaWdodD4gMjU1IGhlYWRz LCA2MyBzZWN0b3JzL3RyYWNrLCAzMDQwMSBjeWxpbmRlcnMKPGt0d2lsaWdo dD4gVW5pdHMgPSBjeWxpbmRlcnMgb2YgMTYwNjUgKiA1MTIgPSA4MjI1Mjgw IGJ5dGVzCjxrdHdpbGlnaHQ+IERpc2sgL2Rldi9oZGIgZG9lc24ndCBjb250 YWluIGEgdmFsaWQgcGFydGl0aW9uIHRhYmxlCjxrdHdpbGlnaHQ+IHRoZSBs YXN0IHNlbnRlbmNlIGlzIHF1aXRlLi4uIDovCjxzYW5kZWVuPiBlciwgc28s IHlvdSBubyBsb25nZXIgaGF2ZSBhIHBhcnRpdGlvbiB0YWJsZSwgYnV0IHJh dGhlciBpdCBpcyBhbiB4ZnMgZmlsZXN5c3RlbSBvbiB0aGUgd2hvbGUgL2Rl di9oZGIuLi4gd2hpY2ggaXMgZmluZSwgYnV0IG9uIHRoZSBsYXN0IGJvb3Qg eW91IG1vdW50ZWQgaGRiMT8KPHNhbmRlZW4+IEknbSBoYXZpbmcgYSBoYXJk IHRpbWUgYmVsaWV2aW5nIHRoYXQgbm90aGluZyBoYXBwZW5lZCBleGNlcHQg ZmlsZSBjb3BpZXMgYW5kIGEgcmVib290IDopCjxzYW5kZWVuPiBsb29rcyB0 byBtZSBsaWtlIHlvdSBta2ZzJ2QgL2Rldi9oZGIKPHNhbmRlZW4+IGNhbiB5 b3UgbW91bnQgL2Rldi9oZGI/CjxrdHdpbGlnaHQ+IGNhbid0IGJlLi4uCjxr dHdpbGlnaHQ+IG5vcGUsIGkgY2FuJ3QgbW91bnQgaXQKPHNhbmRlZW4+IHdo YXQgZG9lcyBkbWVzZyBzYXkgd2hlbiB5b3UgdHJ5Pwo8eG9yQXhBeD4ga3R3 aWxpZ2h0OiBoZXhkdW1wIC1DIHRoZSBmaXJzdCA1MTIgYnl0ZXMgZm9yIHVz Cjx4b3JBeEF4PiBhbmQgdXNlIHBhc3RlLnBvY29vLm9yZwo8c2FuZGVlbj4g YSkgeW91IGhhdmUgbm8gcGFydGl0aW9uIHRhYmxlLCB0aHVzIG5vIC9kZXYv aGRiMSwgYW5kIGIpICJmaWxlIiBmaW5kcyBhbiBYRlMgc3VwZXJibG9jayBk aXJlY3RseSBvbiBoZGIsIHNvLi4uCjxrdHdpbGlnaHQ+IGRtZXNnIGRvZXNu J3Qgc2F5IGFueXRoaW5nLCBidXQgbW91bnRpbmcgZ2l2ZXMgbWUgIm1vdW50 OiBGdW5jdGlvbiBub3QgaW1wbGVtZW50ZWQiCiogc2FuZGVlbiB0aGlua3Mg eGZzIHNob3VsZCBzdG9yZSBta2ZzIHRpbWUgZm9yIGNhc2VzIGxpa2UgdGhp cyA6KQo8eG9yQXhBeD4gc2FuZGVlbjogaGVoZQo8c2FuZGVlbj4gbHNtb2Qg fCBncmVwIHhmcyA/IDopCjxrdHdpbGlnaHQ+IHVtLCBzbyBoZXhkdW1wIC1D IC9kZXYvaGRiPwo8eG9yQXhBeD4ga3R3aWxpZ2h0OiBkZCAuLi4gY291bnQ9 MQo8c2FuZGVlbj4gZGQgaWY9L2Rldi9oZGIgYnM9NTEyIGNvdW50PTEgfCBo ZXhkdW1wIC1DCjxrdHdpbGlnaHQ+IHhmcyBpcyBsb2FkZWQsIGkgYXZlIG90 aGVyIHhmcyBwYXJ0aXRpb25zIG1vdW50ZWQKPGt0d2lsaWdodD4gaHR0cDov L3JhZmIubmV0L3AvV0x4SnpkOTAuaHRtbAo8c2FuZGVlbj4gSSBoYXZlIGEg aGFyZCB0aW1lIGJlbGlldmluZyB0aGF0IG1vdW50IC9kZXYvaGRiIC9zb21l L3doZXJlIGZhaWxzIGJ1dCBnZW5lcmF0ZXMgbm8ga2VybmVsIG1lc3NhZ2Vz CjxzYW5kZWVuPiB0cnkgbW91bnQgLXQgeGZzPwo8a3R3aWxpZ2h0PiBodHRw Oi8vcmFmYi5uZXQvcC9naEtDZ0kzNi5odG1sCjxzYW5kZWVuPiB4ZnNfZGIg LXIgLWMgInNiIDAiIC1jIHAgL2Rldi9zZGIgCjxzYW5kZWVuPiBhbmQgbW91 bnQgLXQgeGZzIC9kZXYvaGRiIC9zb21lL3doZXJlOyBkbWVzZyB8IHRhaWwg LW4gMTAKPGt0d2lsaWdodD4gaHR0cDovL3JhZmIubmV0L3AvR0w5NWJlNDgu aHRtbAo8c2FuZGVlbj4gc29ycnkgcy9zZGIvaGRiLyA6KQo8a3R3aWxpZ2h0 PiBucCA7KQo8c2FuZGVlbj4gZXcKPGt0d2lsaWdodD4gaHR0cDovL3JhZmIu bmV0L3AvQWNpbEx6MzAuaHRtbAo8a3R3aWxpZ2h0PiBub3QgYSBnb29kIGV3 IGkgZ3Vlc3MKPGt0d2lsaWdodD4gdGhhdCBzZWdmYXVsdCBpc24ndCBuaWNl CjxzYW5kZWVuPiBlcnJyCjxzYW5kZWVuPiBYRlMgbW91bnRpbmcgZmlsZXN5 c3RlbSBzZGIxCjxzYW5kZWVuPiBFbmRpbmcgY2xlYW4gWEZTIG1vdW50IGZv ciBmaWxlc3lzdGVtOiBzZGIxCjxzYW5kZWVuPiBvaCBzZGIKPHNhbmRlZW4+ IGdlZXNoCjxrdHdpbGlnaHQ+IGRpZmZlcmVudCA7KQo8c2FuZGVlbj4geW91 J2QgdGhpbmsgSSdkIGhhdmUgdGhpcyBzdHJhaWdodCBieSBub3cgOikKPHNh bmRlZW4+ICpzaWdoKgo8a3R3aWxpZ2h0PiBpdCdzIGhkYiwgTk9UIHNkYgo8 a3R3aWxpZ2h0PiB0aG91Z2ggaSBoYXZlIGFuIHNkYiBhbmQgaXQncyB3b3Jr aW5nIHBlcmZlY3RseS4KPGt0d2lsaWdodD4gbGV0J3Mgbm90IHRvdWNoIGl0 IDopCjxrdHdpbGlnaHQ+IHNvIGRtZXNnIGRvZXNuJ3Qgc2F5IGFueXRoaW5n IHdoZW4gdHJ5aW5nIHRvIG1vdW50IGhkYgo8c2FuZGVlbj4gd2VpcmQgdGhh dCB4ZnNfZGIgc2VnZmF1bHRzCjxzYW5kZWVuPiBpcyB0aGlzIGxhdGVzdCB4 ZnNwcm9ncz8KPGt0d2lsaWdodD4gMi44LjExLTEgCjxrdHdpbGlnaHQ+IGRl YmlhbiBldGNoLgo8a3R3aWxpZ2h0PiBpdCdzICJzdGFibGUiIDopCjxzYW5k ZWVuPiBtaWdodCB0cnkgdmVyeSBsYXRlc3QgeGZzcHJvZ3MgZm9yIGZ1bgo8 a3R3aWxpZ2h0PiAuLi4KPHNhbmRlZW4+IGp1c3QgdG8gc2VlIGlmIHdlIGNh biBleGFtaW5lIGl0IG1vcmUKPGt0d2lsaWdodD4gc28gaSBzaG91bGQgZ3Jh YiBpdCBvZmYgc2lkPwo8a3R3aWxpZ2h0PiB0ZWxsIG1lIHdoYXQgeW91IGtu b3cgc28gZmFyIG9yIGl0cyBhc3N1bXB0aW9ucwo8c2FuZGVlbj4gb3IgdXNl IHhmc19tZXRhZHVtcCB0byBnZXQgYW4gZnMgaW1hZ2UsIGFuZCBwcm92aWRl IGl0IHRvIHRoZSBzZ2kgZ3V5cwo8c2FuZGVlbj4gYXQgYSBtaW5pbXVtIHhm c19kYiBzaG91bGQgbm90IHNlZ2ZhdWx0CjxrdHdpbGlnaHQ+IGhtCjxzYW5k ZWVuPiB3ZWxsLCBzbyBmYXIsIGJhcmUgaGRiIGhhcyBhdCBsZWFzdCB0aGUg YmVnaW5uaW5nIG9mIGFuIHhmcyBmaWxlc3lzdGVtIHNpZ25hdHVyZSwgWEZT QiBpcyBzdXBlIGJsb2NrIG1hZ2ljCjxzYW5kZWVuPiBhbmQsIHlvdSBoYXZl IG5vIHBhcnRpdGlvbiB0YWJsZSBvbiBoZGIKPGt0d2lsaWdodD4gc28gYmFz aWNhbGx5IGkgaGF2ZSBubyBmaWxlcyBvbiBoZGI/CjxrdHdpbGlnaHQ+IG5v IHdheSBvZiByZWNvdmVyaW5nPwo8c2FuZGVlbj4gbm90IHN1cmUgeWV0Cjxr dHdpbGlnaHQ+IGdyZWF0IDopCjxzYW5kZWVuPiBidXQsIEkgZG9uJ3QgcXVp dGUgYmVsaWV2ZSB0aGF0IHlvdSBoYWQgL2Rldi9oZGIxIG1vdW50ZWQsIGNv cGllZCBmaWxlcywgdW1vdW50ZWQsIGFuZCBzdWRkZW5seSB5b3UgaGFkIG5v IG1vcmUgcGFydGl0aW9uIHRhYmxlCjxzYW5kZWVuPiBzb21ldGhpbmcgZWxz ZSBoYXBwZW5lZCBpbiBiZXR3ZWVuIHdoZXRoZXIgeW91IGRpZCBpdCB5b3Vy c2VsZiBvciBzb21ldGhpbmcgZGlkIGl0IHRvIHlvdSBJIHRoaW5rIDopCjxr dHdpbGlnaHQ+IGkgZG9uJ3QgYmVsaWV2ZSBpdCBlaXRoZXIsIGJ1dCB0aGF0 J3MgdGhlIHRydXRoLgo8a3R3aWxpZ2h0PiB3ZWxsLCByYXRoZXIgdGhhbiBj b3B5LCBpdCB3YXMgYSBtb3ZlLiBkb2VzIHRoYXQgbWFrZSBhbnkgZGlmZmVy ZW5jZT8gOlAKPHNhbmRlZW4+IHdoYXQga2luZCBvZiBwYXJ0aXRpb24gdGFi bGUgZGlkIHlvdSBoYXZlPwo8c2FuZGVlbj4gZG9zIG9yIGdwdD8KPGt0d2ls aWdodD4gZG9zCjxzYW5kZWVuPiB5b3VyIHJvb3QgaW5vZGUgbnIgZnJvbSB0 aGUgaGV4ZHVtcCBpcyBhIGxpdHRsZSBmdW5reQo8a3R3aWxpZ2h0PiBiYWQg ZnVua3k/CjxrdHdpbGlnaHQ+IGssIGZpbmFsbHkgZ2V0dGluJyBzaWQncyB4 ZnNwcm9ncwo8a3R3aWxpZ2h0PiBncmVhdCwgeGZzX2RiIHNlZ2ZhdWx0cyB0 b28gOikKPGt0d2lsaWdodD4geGZzcHJvZ3MgMi45LjQtMgo8c2FuZGVlbj4g aG1tCjxzYW5kZWVuPiBvdGhlciBzYW1lIG1lc3NhZ2VzPwo8c2FuZGVlbj4g Y2FjaGVfbm9kZSBzdHVmZiBvciBubwo8a3R3aWxpZ2h0PiBub3QgcmVhbGx5 CjxrdHdpbGlnaHQ+IGh0dHA6Ly9yYWZiLm5ldC9wL2U0dVlOQzU4Lmh0bWwK PHNhbmRlZW4+IHNhbWUgc3R1ZmYKPGt0d2lsaWdodD4gbyBvayA6fAo8a3R3 aWxpZ2h0PiBub2RlIGlzIGRpZmZlcmVudC4gdGhhdCBoZWxwcz8KPGt0d2ls aWdodD4gaGFoYQo8a3R3aWxpZ2h0PiBzYW5kZWVuLCB3b3VsZCB4ZnNfZnNy IGhlbHA/CjxzYW5kZWVuPiBubwo8c2FuZGVlbj4geW91IGhhdmUgdG8gbW91 bnQgaXQgZmlyc3QgOikKPGt0d2lsaWdodD4gOigKPGt0d2lsaWdodD4gaG93 ICdib3V0IHhmc19jaGVjayBvciB4ZnNfYWRtaW4/CjxzYW5kZWVuPiBub3Qg dGhhdCBpdCdkIGhlbHAgYW55d2F5CjxrdHdpbGlnaHQ+IGhtCjxrdHdpbGln aHQ+IHNvIHdoYXQgYXJlIG15IG9wdGlvbnM/CjxzYW5kZWVuPiBpZiB4ZnNf ZGIgY2FuJ3QgZXZlbiByZWNvZ25pemUgdGhlIGZpbGVzeXN0ZW0gdGhpbmdz IGFyZW4ndCBzbyBnb29kCjxrdHdpbGlnaHQ+IHdvdWxkIGRkIGhlbHA/IGxl dCdzIHNheSBpIHNraXAgdGhlIGZpcnN0IGZldyBieXRlcwo8a3R3aWxpZ2h0 PiB0aGVuIG1vdW50IGl0IGFzIGFuIGlzby4KPGhhbm5lc2Q+IG5vIGJhY2t1 cD8KPGt0d2lsaWdodD4gaGFubmVzZCwgeWVzLCBidXQgbm90IHRoYXQgdXAg dG8gZGF0ZSA6Lwo8a3R3aWxpZ2h0PiBpZiBpIGNhbiByZWNvdmVyLCBpdCdk IGJlIGJldHRlci4KPHNhbmRlZW4+IGp1c3QgZm9yIGZ1biwgZG9lcyBkZCBp Zj0vZGV2L2hkYiBicz01MTIgY291bnQ9MzIgfCBoZXhkdW1wIC1DIHwgZ3Jl cCBYRlNCIHR1cm4gdXAgbW9yZSB0aGFuIDEgWEZTQj8KKiBzYW5kZWVuIGd1 ZXNzZXMgYXQgdGhlIGNvdW50PTMyLCBidXQgaGRiMSBwcm9iYWJseSBzdGFy dGVkIGJlZm9yZSAxNmsKPGt0d2lsaWdodD4gaHR0cDovL3JhZmIubmV0L3Av dEhxV3liODguaHRtbAo8a3R3aWxpZ2h0PiBpIG9ubHkgc2VlIG9uZS4KPHNh bmRlZW4+IG5vcGUKPGt0d2lsaWdodD4gaG0sIHNvIGl0J3Mgbm90IGdvb2Qu CjxrdHdpbGlnaHQ+IHNvIHNob3VsZCBpIGp1c3QgZm9yZ2V0IGFib3V0IGl0 PyBvciBpcyB0aGVyZSBhIGdsaW1wc2Ugb2YgaG9wZSBzb21ld2hlcmU/IDop CjxzYW5kZWVuPiB3YXMgZ29ubmEgbG9vayBvdmVyIHRoZSBmaXJzdCBoZXhk dW1wIGEgYml0CjxrdHdpbGlnaHQ+IG9rCjxzYW5kZWVuPiAwMCAwMCAwMCAw MCAwMCAwMCAwOSAwMCBzaG91bGQgYmUgeW91ciByb290IGlub2RlLCB3aGlj aCBpcyBub3QgMjIsIHNvIGEgbGl0dGxlIGNvbmZ1c2VkIGFib3V0IHdoeSBp dCBpcyBzc2F5aW5nIHJvb3Rpbm8gMjIgd2hlbiB5b3UgdHJ5IHhmc19kYgo8 c2FuZGVlbj4gdW5sZXNzIHRoYXQncyBFSU5WQUwgdGhhdCBnb3QgbG9zdAo8 c2FuZGVlbj4gY2FuIHlvdSB1c2UgeGZzX21ldGFkdW1wIHRvIG1ha2UgYW4g ZnMgaW1hZ2U/ICAgbWF5YmUgdGhlIHNnaSBndXlzIGNhbiBoZWxwIGZ1cnRo ZXIKPGt0d2lsaWdodD4gc29tZSBtb25zdGVyIGF0ZSBpdCBpIHNlZS4KPGt0 d2lsaWdodD4gaG93IGJpZyB3b3VsZCB0aGUgZnMgaW1hZ2UgYmU/IGFzIGJp ZyBhcyB0aGUgcGFydGl0aW9uPwo8c2FuZGVlbj4gYXQgbGVhc3QgYm5hdWpv ayB3b3VsZCBwcm9iYWJseSBsaWtlIHRvIHNlZSB3aGF0J3MgZ29pbmcgb24g d2l0aCB4ZnNfZGIKPHNhbmRlZW4+IG5vIGl0IG9ubHkgZHVtcHMgbWV0YWRh dGEgbm8gZGF0YQo8c2FuZGVlbj4gc28gaXQgc2hvdWxkIGJlIHNpZ25pZmlj YW50bHkgc21hbGxlcgo8a3R3aWxpZ2h0PiBobQo8c2FuZGVlbj4gYnV0IGlm IGRiIGNhbid0IHJlYWQgaXQsIG1ldGFkdW1wIG1pZ2h0IG5vdCBlaXRoZXIK PGt0d2lsaWdodD4geWEgZ290dGEgc2VlIHRoaXMKPGt0d2lsaWdodD4gaHR0 cDovL3JhZmIubmV0L3Avb2pWQU55NzMuaHRtbAo8c2FuZGVlbj4geWVhaCwg bGlieGZzIHByb2JsZW0sIEkgd2FzIHNvcnRhIGFmcmFpZCBvZiB0aGF0Cjxz YW5kZWVuPiB3ZWxsLiAgdW5kZXJseWluZyBwcm9ibGVtIGlzIHdoYXQncyBv biB5b3VyIGRpc2ssIGJ1dCB0aGVuIGxpYnhmcyBpc24ndCBjb3Bpbmcgd2Vs bCBlaXRoZXIKPHNhbmRlZW4+IG1heWJlIHRoZSBmaXJzdCBmZXcgSyBvZiB0 aGUgZnMgd291bGQgYmUgZW5vdWdoIGZvciB0aGVtIHRvIGRpZyBpbiBmdXJ0 aGVyCjxrdHdpbGlnaHQ+IGhtCjxzYW5kZWVuPiBJIHNob3VsZCBiZSB3b3Jr aW5nIG9uIGFub3RoZXIgZnMgcmlnaHQgbm93IDstKQo8a3R3aWxpZ2h0PiA6 KQo8a3R3aWxpZ2h0PiBrLCBzbyBpIHdpbGwgc2VuZCB4ZnNfbWV0YWR1bXAs IGFuZCB4ZnNfZGIgdG8gc2dpPwo8a3R3aWxpZ2h0PiB3aGF0IGVsc2Ugc2hv dWxkIGkgaW5jbHVkZSBpbiB0aGUgZW1haWw/CjxoYW5uZXNkPiB0aGUgY2hh dCBsb2cgbWF5YmUgOikKPGt0d2lsaWdodD4gOikKPGt0d2lsaWdodD4gYSBo ZWNrIGxvYWQgb2Ygc3R1ZmYgdGhlbgo8a3R3aWxpZ2h0PiBlbWFpbD8gc3Vw cG9ydEBzZ2kuY29tPwo8c2FuZGVlbj4geGZzQHNnaS5jb20KPHNhbmRlZW4+ IG9wZW4gc291cmNlIHhmcyBsaXN0CjxzYW5kZWVuPiBoZXhkdW1wIG9mIGhk YiB3b3VsZCBiZSBhIHBsYWNlIHRvIHN0YXJ0LCBhbG9uZyB3LyB4ZnNfZGIg cmVzdWx0cwo8a3R3aWxpZ2h0PiBubSwgZm91bmQuIHhmc0Bvc3Muc2dpLmNv bQo8c2FuZGVlbj4gYW5kIGEgc3dvcm4gc3RhdGVtZW50IHRoYXQgb2ggcmVh bGx5IHRoaXMgdXNlZCB0byBiZSBoZGIxIGJ1dCBpdCBtYWdpY2FsbHkgbW92 ZWQgOikK ------=_Part_35143_13710901.1197560778960-- From owner-xfs@oss.sgi.com Thu Dec 13 14:24:13 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 13 Dec 2007 14:24:23 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_50 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBDMOAMG030556 for ; Thu, 13 Dec 2007 14:24:13 -0800 X-ASG-Debug-ID: 1197584656-79bf015b0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from pro14.sgizmo.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id E8A04113767A for ; Thu, 13 Dec 2007 14:24:16 -0800 (PST) Received: from pro14.sgizmo.com (pro14.sgizmo.com [66.135.42.16]) by cuda.sgi.com with ESMTP id PAXYsGTUJ5yYQBRp for ; Thu, 13 Dec 2007 14:24:16 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by pro14.sgizmo.com (8.13.1/8.13.1) with ESMTP id lBDMOGjU026898 for ; Thu, 13 Dec 2007 16:24:16 -0600 Date: Thu, 13 Dec 2007 16:24:16 -0600 Message-Id: <200712132224.lBDMOGjU026898@pro14.sgizmo.com> content-type: text/plain; charset=UTF-8 From: "Dr. Ed Halteman" To: "David Chinner " X-ASG-Orig-Subj: Request for Help with National Study on RFID and Wireless Technology Subject: Request for Help with National Study on RFID and Wireless Technology X-Barracuda-Connect: pro14.sgizmo.com[66.135.42.16] X-Barracuda-Start-Time: 1197584660 X-Barracuda-Bayes: INNOCENT GLOBAL 0.4992 1.0000 0.0000 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36542 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5115/Thu Dec 13 09:46:23 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13938 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: ed@survey-design-and-analysis.com Precedence: bulk X-list: xfs Dear David, As an engineering, technology, or business professional, we need your input. Survey Design and Analysis is conducting a study on the market requirements for future applications of RFID technology, particularly as it is used in conjunction with other wireless technologies to track asset movement / usage, improve sales productivity, enhance the customer experience, and manage inventory. The results of this study will be used to guide the development of new products and services. The first 300 qualified respondents that complete the survey will be entered in a drawing for Amazon gift certificates each worth $100. One out of every 10 respondents will win. Please take approximately 15 minutes now to provide your input at the following link. http://s-3d4cr-25491.sgizmo.com/i/9jkvg/2508/516511/ If you have any questions, please do not hesitate to contact me. I know your time is valuable and I appreciate your assistance. Thank you. Ed Halteman Edward Halteman, PhD Wireless Technology Study Manager Survey Design and Analysis 1331 Cedar Ave Boulder, CO 80304 ed@survey-design-and-analysis.com 303-818-3679 SurveyDNA.com ------------------- This invitation was sent by Survey Design and Analysis - 1331 Cedar Ave Boulder, CO 80304 United States. Phone: 303-818-3679 From owner-xfs@oss.sgi.com Thu Dec 13 14:47:50 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 13 Dec 2007 14:48:18 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id lBDMlkAj032091 for ; Thu, 13 Dec 2007 14:47: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 JAA01507; Fri, 14 Dec 2007 09:47:53 +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 lBDMlqIN7830007; Fri, 14 Dec 2007 09:47:52 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id lBDMln3D7832602; Fri, 14 Dec 2007 09:47:49 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Fri, 14 Dec 2007 09:47:49 +1100 From: David Chinner To: KE Liew Cc: xfs@oss.sgi.com Subject: Re: mount: Function not implemented Message-ID: <20071213224749.GJ4396912@sgi.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/5115/Thu Dec 13 09:46:23 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13939 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Thu, Dec 13, 2007 at 04:46:18PM +0100, KE Liew wrote: > Hi all, > > I was in #xfs with sandeen in discussing on the above issue. In the > nutshell, I can't mount /dev/hdb due to the above error: mount -t xfs > /dev/hdb /path/to #define ENOSYS 38 /* Function not implemented */ Exactly what is mount being told there is not system call support? What kernel are you running? Can you strace the mount process and find out where the error is coming from? > It all started after I did a sequence of things to the new hdd I purchased. > First, I created an msdos disklabel on a new xfs partition /dev/hdb1. It > uses the full capacity of the hdd. Did you then write out the partition table? Did the kernel warn you that it couldn't reread the partition table and so you should reboot before doing anything else? Did you make the xfs filesystem on /dev/hdb or hdb1? > Then I transferred files from one hdd to > another using mv -v /stuff-to-transfer /hdb-mount-point Upon completion, I > umount both devices and rebooted. On boot, I was not able to mount neither > /dev/hdb1 nor /dev/hdb. /dev/hdb1 returns mount: special device /dev/hdb1 > does not exist and /dev/hdb returns the above error message, no relevant > messages are present in dmesg | tail > > The hexdump: > =================== > # dd if=/dev/hdb bs=512 count=1 | hexdump -C > 1+0 records in > 1+0 records out > 00000000 58 46 53 42 00 01 00 00 00 00 00 00 00 3a 38 b0 > |XFSB.........:8.| This kind of indicates that you did a 'mkfs.xfs /dev/hdb' not the partition you created. If that is the case, then rebooting may have written who-knows-what to disk. > The xfs_db: > =================== > # xfs_db -r -c "sb 0" -c p /dev/hdb > cache_node_purge: refcount was 1, not zero (node=0x80ca410) > xfs_db: cannot read root inode (22) EINVAL. > cache_node_purge: refcount was 1, not zero (node=0x80da608) > xfs_db: cannot read realtime bitmap inode (22) > Segmentation fault > =================== That tends to indicate that the filesystem superblock is ok but the contents are not. Without knowing exactly what you did and what errors came up, it's going to be hard reconstructing what went wrong. Perhaps a metadump of the filesysetm woul dbe useful in working out how it is broken.... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Thu Dec 13 20:07:00 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 13 Dec 2007 20:07:04 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBE46vOS024185 for ; Thu, 13 Dec 2007 20:07:00 -0800 X-ASG-Debug-ID: 1197605226-5dd8001f0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id B4D8347F655 for ; Thu, 13 Dec 2007 20:07:06 -0800 (PST) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id fRq24CegEShWHJ1Y for ; Thu, 13 Dec 2007 20:07:06 -0800 (PST) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id E50D3182DD13F; Thu, 13 Dec 2007 22:06:33 -0600 (CST) Message-ID: <47620148.2060401@sandeen.net> Date: Thu, 13 Dec 2007 22:06:32 -0600 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: David Chinner CC: KE Liew , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: mount: Function not implemented Subject: Re: mount: Function not implemented References: <20071213224749.GJ4396912@sgi.com> In-Reply-To: <20071213224749.GJ4396912@sgi.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1197605228 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36555 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5115/Thu Dec 13 09:46:23 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13940 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs David Chinner wrote: > On Thu, Dec 13, 2007 at 04:46:18PM +0100, KE Liew wrote: >> The hexdump: >> =================== >> # dd if=/dev/hdb bs=512 count=1 | hexdump -C >> 1+0 records in >> 1+0 records out >> 00000000 58 46 53 42 00 01 00 00 00 00 00 00 00 3a 38 b0 >> |XFSB.........:8.| > > This kind of indicates that you did a 'mkfs.xfs /dev/hdb' not > the partition you created. If that is the case, then rebooting > may have written who-knows-what to disk. although if it was a) new and b) he made a whole-disk partition, it was probably not a busy disk and I wouldn't expect a reboot was necessary. >> The xfs_db: >> =================== >> # xfs_db -r -c "sb 0" -c p /dev/hdb >> cache_node_purge: refcount was 1, not zero (node=0x80ca410) >> xfs_db: cannot read root inode (22) > > EINVAL. Hm, that should probably use perror or something, silly me read that as the inode *number* and then thought "hmm I bet something stuck EINVAL into the inode number, oops!" :) >> cache_node_purge: refcount was 1, not zero (node=0x80da608) >> xfs_db: cannot read realtime bitmap inode (22) >> Segmentation fault >> =================== > > That tends to indicate that the filesystem superblock is ok but > the contents are not. > > Without knowing exactly what you did and what errors came up, it's > going to be hard reconstructing what went wrong. Perhaps a metadump > of the filesysetm woul dbe useful in working out how it is broken.... Metadump failed with the same errors as xfs_db -Eric From owner-xfs@oss.sgi.com Thu Dec 13 21:28:38 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 13 Dec 2007 21:28:42 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id lBE5SU4r032593 for ; Thu, 13 Dec 2007 21:28:37 -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 QAA12779; Fri, 14 Dec 2007 16:28:39 +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 lBE5SbIN7979050; Fri, 14 Dec 2007 16:28:37 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id lBE5SXqc7971999; Fri, 14 Dec 2007 16:28:33 +1100 (AEDT) X-Authentication-Warning: snort.melbourne.sgi.com: dgc set sender to dgc@sgi.com using -f Date: Fri, 14 Dec 2007 16:28:33 +1100 From: David Chinner To: Eric Sandeen Cc: David Chinner , KE Liew , xfs@oss.sgi.com Subject: Re: mount: Function not implemented Message-ID: <20071214052833.GM4396912@sgi.com> References: <20071213224749.GJ4396912@sgi.com> <47620148.2060401@sandeen.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47620148.2060401@sandeen.net> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.91.2/5115/Thu Dec 13 09:46:23 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13941 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs On Thu, Dec 13, 2007 at 10:06:32PM -0600, Eric Sandeen wrote: > David Chinner wrote: > > On Thu, Dec 13, 2007 at 04:46:18PM +0100, KE Liew wrote: > > >> The hexdump: > >> =================== > >> # dd if=/dev/hdb bs=512 count=1 | hexdump -C > >> 1+0 records in > >> 1+0 records out > >> 00000000 58 46 53 42 00 01 00 00 00 00 00 00 00 3a 38 b0 > >> |XFSB.........:8.| > > > > This kind of indicates that you did a 'mkfs.xfs /dev/hdb' not > > the partition you created. If that is the case, then rebooting > > may have written who-knows-what to disk. > > although if it was a) new and b) he made a whole-disk partition, it was > probably not a busy disk and I wouldn't expect a reboot was necessary. Agreed. But something went wrong so best to ask.... > >> The xfs_db: > >> =================== > >> # xfs_db -r -c "sb 0" -c p /dev/hdb > >> cache_node_purge: refcount was 1, not zero (node=0x80ca410) > >> xfs_db: cannot read root inode (22) > > > > EINVAL. > > Hm, that should probably use perror or something, silly me read that as > the inode *number* and then thought "hmm I bet something stuck EINVAL > into the inode number, oops!" :) Yeah, it probably should perror then tell you the root inode number it failed to read.... Looking at it a bit deeper, libxfs_iget() returned EINVAL and that is most likely from: ip->i_ino = ino; ip->i_mount = mp; if ((error = xfs_itobp(mp, tp, ip, &dip, &bp, bno))) return error; if (INT_GET(dip->di_core.di_magic, ARCH_CONVERT) != XFS_DINODE_MAGIC) { xfs_trans_brelse(tp, bp); >>>>>> return EINVAL; } The inode number being toast. Looking back at superblock dump, the root inode number is 0x900, which is extremely strange. Normal root inode number is 0x80 which indicates a block number of 0x40 (512 byte blocks), whereas 0x900 indicates a block number of 0x480 (1152) which is a long way away from where it should be. 00000000 58 46 53 42 00 01 00 00 00 00 00 00 00 3a 38 b0 |XFSB.........:8.| Hmmmm. Filesystem block size = 0x10000 = 64k and data blocks = 0x3a38b0 which gives a filesystem size of 232GB. Disk /dev/hdb: 250.0 GB, 250059350016 bytes Still the root inode is in the wrong place. They should be at 0x800 for 64k block size. (yes, I just checked this out by making a 64k block size filesystem). So, key questions: 1. What platform is this? 2. What page size is being used? 3. what kernel is being run? 4. What was the mkfs command used to make the filesystem? 5. how did you mount this filesystem in the first place? > > Without knowing exactly what you did and what errors came up, it's > > going to be hard reconstructing what went wrong. Perhaps a metadump > > of the filesysetm woul dbe useful in working out how it is broken.... > > Metadump failed with the same errors as xfs_db Oh, I didn't notice that. But seeing as the above error is in libxfs it's not surprising that they both fail there.... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Thu Dec 13 21:43:43 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 13 Dec 2007 21:43:45 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: ** X-Spam-Status: No, score=2.3 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, J_CHICKENPOX_43 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBE5hcOe001237 for ; Thu, 13 Dec 2007 21:43:43 -0800 X-ASG-Debug-ID: 1197611029-439500170000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from wa-out-1112.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 8529A11422CF for ; Thu, 13 Dec 2007 21:43:49 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.183]) by cuda.sgi.com with ESMTP id Xc9uu0DJANtjG1B7 for ; Thu, 13 Dec 2007 21:43:49 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id k22so1654630waf.18 for ; Thu, 13 Dec 2007 21:43:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=DOQAEKDf2A35z/7jhTMlSfD0YpOe2DCztZyLkpEu3Oo=; b=epTVMkqZhAZk53kOyCzioNdugSUDqlzWBg7+iqZ/xK44CSiE+Ok9i/t+bEs/t3hEY3ZZICOe0P4ZU2heSL7l8Eg8Fjzce8VS9VcDWmKiqR1nA/+Robt4+cLX+g9+H883DSKbwoRn+ig7JyDGcWD5nuIvShQDsv5scn3hZEwoI3o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=h8SYhQYLEgoY9evokuiVDmrxZ9P9V/39VU4d5E3uWeXF0yN7dh0ix5DEFepdyn8m+zk183ifXsP8NYtp7j1CyTPn7eopgff0qu8aUaCheVSSy0kcLM0JHHda06sVDk3ioxz+1lS29tG5P24UjcFxZUZuLUysvqGJlMQRV07rWXA= Received: by 10.114.53.1 with SMTP id b1mr3253745waa.134.1197610644042; Thu, 13 Dec 2007 21:37:24 -0800 (PST) Received: by 10.115.74.17 with HTTP; Thu, 13 Dec 2007 21:37:23 -0800 (PST) Message-ID: Date: Fri, 14 Dec 2007 06:37:23 +0100 From: "KE Liew" To: "David Chinner" X-ASG-Orig-Subj: Re: mount: Function not implemented Subject: Re: mount: Function not implemented Cc: "Eric Sandeen" , xfs@oss.sgi.com In-Reply-To: <20071214052833.GM4396912@sgi.com> MIME-Version: 1.0 References: <20071213224749.GJ4396912@sgi.com> <47620148.2060401@sandeen.net> <20071214052833.GM4396912@sgi.com> X-Barracuda-Connect: wa-out-1112.google.com[209.85.146.183] X-Barracuda-Start-Time: 1197611030 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36562 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message X-Virus-Scanned: ClamAV 0.91.2/5115/Thu Dec 13 09:46:23 2007 on oss.sgi.com X-Virus-Status: Clean Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-length: 677 X-archive-position: 13942 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: ke.liew@gmail.com Precedence: bulk X-list: xfs On Dec 14, 2007 6:28 AM, David Chinner wrote: > So, key questions: > > 1. What platform is this? Debian Etch. > > 2. What page size is being used? Pardon my lack of knowledge, but what do you mean by page size? > > 3. what kernel is being run? Stock kernel 2.6.18-5-686 > > 4. What was the mkfs command used to make the filesystem? from .bash_history - mkfs.xfs -f /dev/hdb1 > > 5. how did you mount this filesystem in the first place? As mentioned, the usual mount -t xfs /dev/hdb1 /path/to Tried both /dev/hdb and /dev/hdb1, where hdb1 was the first I tried. KwangErn [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Thu Dec 13 22:26:08 2007 Received: with ECARTIS (v1.0.0; list xfs); Thu, 13 Dec 2007 22:26:10 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: ** X-Spam-Status: No, score=2.6 required=5.0 tests=AWL,BAYES_20,HTML_MESSAGE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBE6Q1ZI003375 for ; Thu, 13 Dec 2007 22:26:08 -0800 X-ASG-Debug-ID: 1197613573-29db021a0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from wa-out-1112.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 4941D1142820 for ; Thu, 13 Dec 2007 22:26:13 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.183]) by cuda.sgi.com with ESMTP id m6P67k5DtPHCAkhQ for ; Thu, 13 Dec 2007 22:26:13 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id k22so1679582waf.18 for ; Thu, 13 Dec 2007 22:26:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; bh=q9EsHIaE3eTioLbhWVwV/QqKmZgpmixIfvvBPZL+zzc=; b=LM6jmOQa1rxblqvwRjmYOQkK0wqCuciPVGQ/EbTfH0YWpnJJUbQZ2ingICY+hNzCePf18EvAnk76u23KHD/NAa+qVSd2tiEszPS2MhvkPcWIWm7FzMrP/r5LW1NZVEaXlLamxxLxlcN19HbMCzoy+oGWC9HYNwP1PjvZvj++Ajg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=PkDU977/Pnu+MXCtbXqNXOwAbHmtjpVfJvSgBoHz6sZ4V8nIsbBoKWNd5lohxWJ8f+SgjbwY8va9HeyRzarindOZUStoHC0g5BiOUEEKUKdPptbvFlAdcDvlMFAtlMvYP8KVEgx96Q46TpSKUgPx7nfYlYyeCDLBouLXBHhvOpM= Received: by 10.114.59.1 with SMTP id h1mr1788694waa.39.1197613198966; Thu, 13 Dec 2007 22:19:58 -0800 (PST) Received: by 10.115.74.17 with HTTP; Thu, 13 Dec 2007 22:19:58 -0800 (PST) Message-ID: Date: Fri, 14 Dec 2007 07:19:58 +0100 From: "KE Liew" To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: mount: Function not implemented Subject: Re: mount: Function not implemented In-Reply-To: MIME-Version: 1.0 References: <20071213224749.GJ4396912@sgi.com> <47620148.2060401@sandeen.net> <20071214052833.GM4396912@sgi.com> X-Barracuda-Connect: wa-out-1112.google.com[209.85.146.183] X-Barracuda-Start-Time: 1197613573 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.08 X-Barracuda-Spam-Status: No, SCORE=-1.08 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests=HTML_10_20, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36564 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message 0.94 HTML_10_20 BODY: Message is 10% to 20% HTML X-Virus-Scanned: ClamAV 0.91.2/5115/Thu Dec 13 09:46:23 2007 on oss.sgi.com X-Virus-Status: Clean Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-length: 922 X-archive-position: 13943 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: ke.liew@gmail.com Precedence: bulk X-list: xfs Just for document purposes... sandeen mentioned to do, dd if=/dev/hdb bs=512 count=128 | hexdump -C | grep XFSB 00000000 58 46 53 42 00 01 00 00 00 00 00 00 00 3a 38 b0 |XFSB.........:8.| 00007e00 58 46 53 42 00 00 10 00 00 00 00 00 03 a3 88 a0 |XFSB............| 128+0 records in 128+0 records out 65536 bytes (66 kB) copied, 0.0283236 seconds, 2.3 MB/s So recreating the partition should work. First we backup the sectors. dd if=/dev/hdb bs=512 count=256 of=backup_sectors Then the partition is recreated using fdisk /dev/hdb, option n -> p (primary -> 1 for partition 1 -> default first cylinder 1 -> default last cylinder 30401 -> (w)rite table to disk and exit. :) Running xfs_check /dev/hdb1 returns no errors, which was hoped. Mounting the partition shows ALL files present! So everything is working back to normal. Thanks to XFS team and sandeen! :) KwangErn [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Fri Dec 14 03:54:50 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 14 Dec 2007 03:55:18 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=BAYES_20 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBEBskmh025737 for ; Fri, 14 Dec 2007 03:54:50 -0800 X-ASG-Debug-ID: 1197633296-58cc03900000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from iate.obninsk.ru (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id C3F1A1144D5C for ; Fri, 14 Dec 2007 03:54:57 -0800 (PST) Received: from iate.obninsk.ru (iate.obninsk.ru [195.112.102.46]) by cuda.sgi.com with ESMTP id 2BG8d4KfnGEDUD4H for ; Fri, 14 Dec 2007 03:54:57 -0800 (PST) X-ASG-Orig-Subj: Undeliverable mail: Subject: Undeliverable mail: From: To: Date: Fri, 14 Dec 2007 14:54:56 +0300 Message-ID: X-MAPI-Message-Class: REPORT.IPM.Note.NDR MIME-Version: 1.0 Content-Type: multipart/report; report-type="delivery-status"; boundary="_===4480892====iate.obninsk.ru===_" X-Barracuda-Connect: iate.obninsk.ru[195.112.102.46] X-Barracuda-Start-Time: 1197633297 X-Barracuda-Bayes: INNOCENT GLOBAL 0.2852 1.0000 -0.4126 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.14 X-Barracuda-Spam-Status: No, SCORE=0.14 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests=NO_REAL_NAME X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36586 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.55 NO_REAL_NAME From: does not include a real name X-Virus-Scanned: ClamAV 0.91.2/5116/Thu Dec 13 23:14:39 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13944 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: MAILER-DAEMON@iate.obninsk.ru Precedence: bulk X-list: xfs --_===4480892====iate.obninsk.ru===_ Content-Type: text/plain; charset="utf-8" Failed to deliver to '' WARNING! Your message was infected by VIRUSES: Worm.Mytob.Crypt.Gen, Suspicious File: text.pif It was rejected for delivery. Antiviral program output: ================================================== infected: Worm.Mytob.Crypt.Gen text.pif Suspicious File: text.pif ================================================== --_===4480892====iate.obninsk.ru===_ Content-Type: message/delivery-status Reporting-MTA: dns; iate.obninsk.ru Original-Recipient: rfc822; Final-Recipient: system; Action: failed Status: 5.0.0 --_===4480892====iate.obninsk.ru===_ Content-Type: text/rfc822-headers Received: from [213.148.186.44] (HELO oss.sgi.com) by iate.obninsk.ru (CommuniGate Pro SMTP 5.1.5) with ESMTP id 4480897 for korovin@iate.obninsk.ru; Fri, 14 Dec 2007 14:54:56 +0300 Received-SPF: none receiver=iate.obninsk.ru; client-ip=213.148.186.44; envelope-from=xfs@oss.sgi.com From: xfs@oss.sgi.com To: korovin@iate.obninsk.ru Subject: Date: Fri, 14 Dec 2007 14:57:01 +0300 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0002_16DB97CC.C435AE51" X-Priority: 3 X-MSMail-Priority: Normal Message-ID: --_===4480892====iate.obninsk.ru===_-- From owner-xfs@oss.sgi.com Fri Dec 14 09:38:38 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 14 Dec 2007 09:38:41 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBEHcahJ018815 for ; Fri, 14 Dec 2007 09:38:38 -0800 X-ASG-Debug-ID: 1197653928-7f3200260000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from out3.smtp.messagingengine.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id BE204114901F for ; Fri, 14 Dec 2007 09:38:48 -0800 (PST) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by cuda.sgi.com with ESMTP id 3w5m4Q66SRc2u0ow for ; Fri, 14 Dec 2007 09:38:48 -0800 (PST) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 4694D7B6F2 for ; Fri, 14 Dec 2007 12:38:47 -0500 (EST) Received: from web8.messagingengine.com ([10.202.2.217]) by compute1.internal (MEProxy); Fri, 14 Dec 2007 12:38:47 -0500 Received: by web8.messagingengine.com (Postfix, from userid 99) id 28033552FC; Fri, 14 Dec 2007 12:38:47 -0500 (EST) Message-Id: <1197653927.3841.1226620089@webmail.messagingengine.com> X-Sasl-Enc: sDK6qeod+JpoSKpNnKDr40O/NAuFXR/64HmDCaRvtHxe 1197653927 From: "Alex Madarasz" To: xfs@oss.sgi.com Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="ISO-8859-1" MIME-Version: 1.0 X-Mailer: MessagingEngine.com Webmail Interface X-ASG-Orig-Subj: Fedora 8.0.1 XFS Tune on HW RAID for Max Write Throughput? Subject: Fedora 8.0.1 XFS Tune on HW RAID for Max Write Throughput? Date: Fri, 14 Dec 2007 12:38:47 -0500 X-Barracuda-Connect: out3.smtp.messagingengine.com[66.111.4.27] X-Barracuda-Start-Time: 1197653928 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36610 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5120/Fri Dec 14 08:10:00 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13945 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: List.XFS@madalexlists.nospammail.net Precedence: bulk X-list: xfs We're building a new Fedora 8.0.1 Linux system to stream data from a 250Msps ADC to disk, and want to start tuning the system configuration for maximum XFS write performance. To date, without any significant effort at tuning our Fedora 7 dev system, we're seeing 250MBps write with 8-bit samples and ~ 300MBps write with 16-bit samples. We want to push the tuning as far as we can go with this architecture before we start looking at other hardware options. Looking at various other tuning pages on the Web finds few that are interested in maxing out sequential writes to very large arrays while using SAS HW RAID with big fast SAS drives too. HW: HP ML350 G5 - 2 x Dual-Core Intel 5160 Xeon (3GHz, 1333 FSB) CPUs - 8GB dual-interleaved memory - HP Smart Array E200i (cciss) embedded PCI-E RAID ctrlr - 128MB cache - 2 x WD RE2 500GB 7200RPM SATA drives - HW RAID 1 - ext3 root LVM and Linux system partitions - HP Smart Array P400 (cciss) PCI-E x8 RAID ctrlr - 512MB cache - 8 x HP/Seagate 300GB 15000RPM SAS drives - HW RAID 0 logical disk - Dedicated xfs data partition - 250Msps ADC on 64-bit/100MHz PCI-X XFS Tuning Options? - HW RAID0: - Array/logical disk HW RAID stripe size? - Cache enabled (some reports that cache s/b turned off?)? - xfs mkfs / mount options? - External Log? - How big a partition on the E200i? - mkfs / mount options? ...? Thanks for any tips, -- Alex From owner-xfs@oss.sgi.com Fri Dec 14 12:25:10 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 14 Dec 2007 12:25:18 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_65, J_CHICKENPOX_66 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBEKP8QA032214 for ; Fri, 14 Dec 2007 12:25:10 -0800 X-ASG-Debug-ID: 1197663917-09e600af0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from verein.lst.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 8DB62113A87A for ; Fri, 14 Dec 2007 12:25:18 -0800 (PST) Received: from verein.lst.de (verein.lst.de [213.95.11.210]) by cuda.sgi.com with ESMTP id g1lqOmXOd5brmBak for ; Fri, 14 Dec 2007 12:25:18 -0800 (PST) Received: from verein.lst.de (localhost [127.0.0.1]) by verein.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id lBEKPBF3023508 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 14 Dec 2007 21:25:11 +0100 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id lBEKPBPT023504 for xfs@oss.sgi.com; Fri, 14 Dec 2007 21:25:11 +0100 Date: Fri, 14 Dec 2007 21:25:11 +0100 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 1/2] cleanup fix handling Subject: [PATCH 1/2] cleanup fix handling Message-ID: <20071214202511.GA23248@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-Barracuda-Connect: verein.lst.de[213.95.11.210] X-Barracuda-Start-Time: 1197663919 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36620 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5122/Fri Dec 14 10:51:12 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13946 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs Cleanup various fid related bits: - merge xfs_fid2 into it's only caller xfs_dm_inode_to_fh. - remove xfs_vget and opencode it in the two callers, simplifying both of them by avoiding the awkward calling convetion. - assign directly to the dm_fid_t members in various places in the dmapi code instead of casting them to xfs_fid_t first (which is identical to dm_fid_t) Signed-off-by: Christoph Hellwig Index: linux-2.6-xfs/fs/xfs/dmapi/xfs_dm.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/dmapi/xfs_dm.c 2007-12-13 19:14:47.000000000 +0100 +++ linux-2.6-xfs/fs/xfs/dmapi/xfs_dm.c 2007-12-13 20:10:04.000000000 +0100 @@ -586,14 +586,12 @@ dm_dip_to_handle( dm_handle_t *handlep) { dm_fid_t fid; - struct xfs_fid *xfid; int hsize; - xfid = (struct xfs_fid *)&fid; - xfid->fid_len = sizeof(struct xfs_fid) - sizeof(xfid->fid_len); - xfid->fid_pad = 0; - xfid->fid_ino = ino; - xfid->fid_gen = be32_to_cpu(dip->di_core.di_gen); + fid.dm_fid_len = sizeof(struct dm_fid) - sizeof(fid.dm_fid_len); + fid.dm_fid_pad = 0; + fid.dm_fid_ino = ino; + fid.dm_fid_gen = be32_to_cpu(dip->di_core.di_gen); memcpy(&handlep->ha_fsid, fsid, sizeof(*fsid)); memcpy(&handlep->ha_fid, &fid, fid.dm_fid_len + sizeof(fid.dm_fid_len)); @@ -3273,27 +3271,49 @@ xfs_dm_get_invis_ops( STATIC int xfs_dm_fh_to_inode( struct super_block *sb, - struct inode **ip, + struct inode **inode, dm_fid_t *dmfid) { - bhv_vnode_t *vp = NULL; - xfs_mount_t *mp = XFS_M(sb); - int error; - struct xfs_fid xfid; + xfs_mount_t *mp = XFS_M(sb); + xfs_inode_t *ip; + xfs_ino_t ino; + unsigned int igen; + int error; - /* Returns negative errors to DMAPI */ + *inode = NULL; - *ip = NULL; - memcpy(&xfid, dmfid, sizeof(*dmfid)); - if (xfid.fid_len) { /* file object handle */ - error = xfs_vget(mp, &vp, &xfid); + if (!dmfid->dm_fid_len) { + /* filesystem handle */ + *inode = igrab(mp->m_rootip->i_vnode); + if (!*inode) + return -ENOENT; + return 0; } - else { /* filesystem handle */ - error = xfs_root(mp, &vp); + + if (dmfid->dm_fid_len != sizeof(*dmfid) - sizeof(dmfid->dm_fid_len)) + return -EINVAL; + + ino = dmfid->dm_fid_ino; + igen = dmfid->dm_fid_gen; + + /* fail requests for ino 0 gracefully. */ + if (ino == 0) + return -ESTALE; + + error = xfs_iget(mp, NULL, ino, 0, XFS_ILOCK_SHARED, &ip, 0); + if (error) + return -error; + if (!ip) + return -EIO; + + if (!ip->i_d.di_mode || ip->i_d.di_gen != igen) { + xfs_iput_new(ip, XFS_ILOCK_SHARED); + return -ENOENT; } - if (vp && (error == 0)) - *ip = vn_to_inode(vp); - return -error; /* Return negative error to DMAPI */ + + *inode = ip->i_vnode; + xfs_iunlock(ip, XFS_ILOCK_SHARED); + return 0; } STATIC int @@ -3303,18 +3323,21 @@ xfs_dm_inode_to_fh( dm_fsid_t *dmfsid) { xfs_inode_t *ip = XFS_I(inode); - int error; - struct xfs_fid xfid; /* Returns negative errors to DMAPI */ if (ip->i_mount->m_fixedfsid == NULL) return -EINVAL; - error = xfs_fid2(ip, &xfid); - if (error) - return -error; /* Return negative error to DMAPI */ - memcpy(dmfid, &xfid, sizeof(*dmfid)); + dmfid->dm_fid_len = sizeof(dm_fid_t) - sizeof(dmfid->dm_fid_len); + dmfid->dm_fid_pad = 0; + /* + * use memcpy because the inode is a long long and there's no + * assurance that dmfid->dm_fid_ino is properly aligned. + */ + memcpy(&dmfid->dm_fid_ino, &ip->i_ino, sizeof(dmfid->dm_fid_ino)); + dmfid->dm_fid_gen = ip->i_d.di_gen; + memcpy(dmfsid, ip->i_mount->m_fixedfsid, sizeof(*dmfsid)); return 0; } Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_export.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_export.c 2007-12-13 19:14:47.000000000 +0100 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_export.c 2007-12-13 19:18:49.000000000 +0100 @@ -118,20 +118,29 @@ xfs_nfs_get_inode( u64 ino, u32 generation) { - xfs_fid_t xfid; - bhv_vnode_t *vp; + xfs_mount_t *mp = XFS_M(sb); + xfs_inode_t *ip; int error; - xfid.fid_len = sizeof(xfs_fid_t) - sizeof(xfid.fid_len); - xfid.fid_pad = 0; - xfid.fid_ino = ino; - xfid.fid_gen = generation; + /* + * NFS can sometimes send requests for ino 0. Fail them gracefully. + */ + if (ino == 0) + return ERR_PTR(-ESTALE); - error = xfs_vget(XFS_M(sb), &vp, &xfid); + error = xfs_iget(mp, NULL, ino, 0, XFS_ILOCK_SHARED, &ip, 0); if (error) return ERR_PTR(-error); + if (!ip) + return ERR_PTR(-EIO); - return vp ? vn_to_inode(vp) : NULL; + if (!ip->i_d.di_mode || ip->i_d.di_gen != generation) { + xfs_iput_new(ip, XFS_ILOCK_SHARED); + return ERR_PTR(-ENOENT); + } + + xfs_iunlock(ip, XFS_ILOCK_SHARED); + return ip->i_vnode; } STATIC struct dentry * Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ksyms.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_ksyms.c 2007-12-13 19:19:52.000000000 +0100 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ksyms.c 2007-12-13 19:22:10.000000000 +0100 @@ -267,7 +267,6 @@ EXPORT_SYMBOL(xfs_read_buf); EXPORT_SYMBOL(xfs_rwlock); EXPORT_SYMBOL(xfs_rwunlock); EXPORT_SYMBOL(xfs_setattr); -EXPORT_SYMBOL(xfs_fid2); EXPORT_SYMBOL(xfs_attr_get); EXPORT_SYMBOL(xfs_attr_set); EXPORT_SYMBOL(xfs_fsync); @@ -310,5 +309,4 @@ EXPORT_SYMBOL(xfs_ichgtime_fast); EXPORT_SYMBOL(xfs_free_eofblocks); EXPORT_SYMBOL(xfs_do_force_shutdown); -EXPORT_SYMBOL(xfs_vget); EXPORT_SYMBOL(xfs_root); Index: linux-2.6-xfs/fs/xfs/xfs_vfsops.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_vfsops.c 2007-12-13 19:14:47.000000000 +0100 +++ linux-2.6-xfs/fs/xfs/xfs_vfsops.c 2007-12-13 19:19:37.000000000 +0100 @@ -1408,56 +1408,3 @@ xfs_syncsub( return XFS_ERROR(last_error); } - -/* - * xfs_vget - called by DMAPI and NFSD to get vnode from file handle - */ -int -xfs_vget( - xfs_mount_t *mp, - bhv_vnode_t **vpp, - xfs_fid_t *xfid) -{ - xfs_inode_t *ip; - int error; - xfs_ino_t ino; - unsigned int igen; - - /* - * Invalid. Since handles can be created in user space and passed in - * via gethandle(), this is not cause for a panic. - */ - if (xfid->fid_len != sizeof(*xfid) - sizeof(xfid->fid_len)) - return XFS_ERROR(EINVAL); - - ino = xfid->fid_ino; - igen = xfid->fid_gen; - - /* - * NFS can sometimes send requests for ino 0. Fail them gracefully. - */ - if (ino == 0) - return XFS_ERROR(ESTALE); - - error = xfs_iget(mp, NULL, ino, 0, XFS_ILOCK_SHARED, &ip, 0); - if (error) { - *vpp = NULL; - return error; - } - - if (ip == NULL) { - *vpp = NULL; - return XFS_ERROR(EIO); - } - - if (ip->i_d.di_mode == 0 || ip->i_d.di_gen != igen) { - xfs_iput_new(ip, XFS_ILOCK_SHARED); - *vpp = NULL; - return XFS_ERROR(ENOENT); - } - - *vpp = XFS_ITOV(ip); - xfs_iunlock(ip, XFS_ILOCK_SHARED); - return 0; -} - Index: linux-2.6-xfs/fs/xfs/xfs_vfsops.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_vfsops.h 2007-12-13 19:19:40.000000000 +0100 +++ linux-2.6-xfs/fs/xfs/xfs_vfsops.h 2007-12-13 19:19:45.000000000 +0100 @@ -15,7 +15,6 @@ int xfs_mntupdate(struct xfs_mount *mp, struct xfs_mount_args *args); int xfs_root(struct xfs_mount *mp, bhv_vnode_t **vpp); int xfs_sync(struct xfs_mount *mp, int flags); -int xfs_vget(struct xfs_mount *mp, bhv_vnode_t **vpp, struct xfs_fid *xfid); void xfs_do_force_shutdown(struct xfs_mount *mp, int flags, char *fname, int lnnum); void xfs_attr_quiesce(struct xfs_mount *mp); Index: linux-2.6-xfs/fs/xfs/xfs_vnodeops.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_vnodeops.c 2007-12-13 19:20:41.000000000 +0100 +++ linux-2.6-xfs/fs/xfs/xfs_vnodeops.c 2007-12-13 19:20:53.000000000 +0100 @@ -3457,27 +3457,6 @@ std_return: goto std_return; } - -int -xfs_fid2( - xfs_inode_t *ip, - xfs_fid_t *xfid) -{ - xfs_itrace_entry(ip); - - xfid->fid_len = sizeof(xfs_fid_t) - sizeof(xfid->fid_len); - xfid->fid_pad = 0; - /* - * use memcpy because the inode is a long long and there's no - * assurance that xfid->fid_ino is properly aligned. - */ - memcpy(&xfid->fid_ino, &ip->i_ino, sizeof(xfid->fid_ino)); - xfid->fid_gen = ip->i_d.di_gen; - - return 0; -} - - int xfs_rwlock( xfs_inode_t *ip, Index: linux-2.6-xfs/fs/xfs/xfs_vnodeops.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_vnodeops.h 2007-12-13 19:20:04.000000000 +0100 +++ linux-2.6-xfs/fs/xfs/xfs_vnodeops.h 2007-12-13 19:22:04.000000000 +0100 @@ -39,7 +39,6 @@ int xfs_readdir(struct xfs_inode *dp, vo int xfs_symlink(struct xfs_inode *dp, bhv_vname_t *dentry, char *target_path, mode_t mode, bhv_vnode_t **vpp, struct cred *credp); -int xfs_fid2(struct xfs_inode *ip, struct xfs_fid *xfid); int xfs_rwlock(struct xfs_inode *ip, bhv_vrwlock_t locktype); void xfs_rwunlock(struct xfs_inode *ip, bhv_vrwlock_t locktype); int xfs_inode_flush(struct xfs_inode *ip, int flags); From owner-xfs@oss.sgi.com Fri Dec 14 12:29:06 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 14 Dec 2007 12:29:13 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBEKT34H000317 for ; Fri, 14 Dec 2007 12:29:06 -0800 X-ASG-Debug-ID: 1197664153-61f900990000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from verein.lst.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id EAF3A484C23 for ; Fri, 14 Dec 2007 12:29:14 -0800 (PST) Received: from verein.lst.de (verein.lst.de [213.95.11.210]) by cuda.sgi.com with ESMTP id GubRwYi5tNia3NA2 for ; Fri, 14 Dec 2007 12:29:14 -0800 (PST) Received: from verein.lst.de (localhost [127.0.0.1]) by verein.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id lBEKQWF3023598 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 14 Dec 2007 21:26:32 +0100 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id lBEKQWTw023596 for xfs@oss.sgi.com; Fri, 14 Dec 2007 21:26:32 +0100 Date: Fri, 14 Dec 2007 21:26:31 +0100 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 2/2] kill xfs_root Subject: [PATCH 2/2] kill xfs_root Message-ID: <20071214202631.GB23248@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-Barracuda-Connect: verein.lst.de[213.95.11.210] X-Barracuda-Start-Time: 1197664154 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36621 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5122/Fri Dec 14 10:51:12 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13947 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs The only caller (xfs_fs_fill_super) can simplify call igrab on the root inode. Signed-off-by: Christoph Hellwig Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ksyms.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_ksyms.c 2007-12-13 20:12:18.000000000 +0100 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ksyms.c 2007-12-13 20:12:23.000000000 +0100 @@ -309,4 +309,3 @@ EXPORT_SYMBOL(xfs_ichgtime_fast); EXPORT_SYMBOL(xfs_free_eofblocks); EXPORT_SYMBOL(xfs_do_force_shutdown); -EXPORT_SYMBOL(xfs_root); Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_super.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_super.c 2007-12-13 20:11:13.000000000 +0100 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_super.c 2007-12-13 20:11:56.000000000 +0100 @@ -1287,9 +1287,11 @@ xfs_fs_fill_super( sb->s_time_gran = 1; set_posix_acl_flag(sb); - error = xfs_root(mp, &rootvp); - if (error) + rootvp = igrab(mp->m_rootip->i_vnode); + if (!rootvp) { + error = ENOENT; goto fail_unmount; + } sb->s_root = d_alloc_root(vn_to_inode(rootvp)); if (!sb->s_root) { Index: linux-2.6-xfs/fs/xfs/xfs_vfsops.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_vfsops.c 2007-12-13 20:11:13.000000000 +0100 +++ linux-2.6-xfs/fs/xfs/xfs_vfsops.c 2007-12-13 20:12:03.000000000 +0100 @@ -808,26 +808,6 @@ fscorrupt_out2: } /* - * xfs_root extracts the root vnode from a vfs. - * - * vfsp -- the vfs struct for the desired file system - * vpp -- address of the caller's vnode pointer which should be - * set to the desired fs root vnode - */ -int -xfs_root( - xfs_mount_t *mp, - bhv_vnode_t **vpp) -{ - bhv_vnode_t *vp; - - vp = XFS_ITOV(mp->m_rootip); - VN_HOLD(vp); - *vpp = vp; - return 0; -} - -/* * xfs_sync flushes any pending I/O to file system vfsp. * * This routine is called by vfs_sync() to make sure that things make it Index: linux-2.6-xfs/fs/xfs/xfs_vfsops.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_vfsops.h 2007-12-13 20:12:05.000000000 +0100 +++ linux-2.6-xfs/fs/xfs/xfs_vfsops.h 2007-12-13 20:12:07.000000000 +0100 @@ -13,7 +13,6 @@ int xfs_mount(struct xfs_mount *mp, stru int xfs_unmount(struct xfs_mount *mp, int flags, struct cred *credp); int xfs_mntupdate(struct xfs_mount *mp, int *flags, struct xfs_mount_args *args); -int xfs_root(struct xfs_mount *mp, bhv_vnode_t **vpp); int xfs_sync(struct xfs_mount *mp, int flags); void xfs_do_force_shutdown(struct xfs_mount *mp, int flags, char *fname, int lnnum); From owner-xfs@oss.sgi.com Fri Dec 14 12:30:13 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 14 Dec 2007 12:30:22 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBEKU9x4000576 for ; Fri, 14 Dec 2007 12:30:13 -0800 X-ASG-Debug-ID: 1197664215-7f3402480000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from pentafluge.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 55074113AC4E for ; Fri, 14 Dec 2007 12:30:15 -0800 (PST) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by cuda.sgi.com with ESMTP id P44zOBFrCWvo8EUq for ; Fri, 14 Dec 2007 12:30:15 -0800 (PST) Received: from hch by pentafluge.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1J3HAC-0006BU-EH; Fri, 14 Dec 2007 20:29:40 +0000 Date: Fri, 14 Dec 2007 20:29:40 +0000 From: Christoph Hellwig To: Lachlan McIlroy Cc: xfs-dev , xfs-oss X-ASG-Orig-Subj: Re: [PATCH] make inode reclaim synchronise with xfs_iflush_done() Subject: Re: [PATCH] make inode reclaim synchronise with xfs_iflush_done() Message-ID: <20071214202940.GA23564@infradead.org> References: <475F878D.6090407@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <475F878D.6090407@sgi.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: pentafluge.infradead.org[213.146.154.40] X-Barracuda-Start-Time: 1197664221 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36620 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5122/Fri Dec 14 10:51:12 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13948 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs On Wed, Dec 12, 2007 at 06:02:37PM +1100, Lachlan McIlroy wrote: > On a forced shutdown, xfs_finish_reclaim() will skip flushing the inode. > If the inode flush lock is not already held and there is an outstanding > xfs_iflush_done() then we might free the inode prematurely. By acquiring > and releasing the flush lock we will synchronise with xfs_iflush_done(). Sound fine, but I think it would be nicer if we could keep the else if formatting, ala: /* * We are not interested in doing an iflush if we're * in the process of shutting down the filesystem forcibly. * So, just reclaim the inode. */ } else if (locked) { xfs_ifunlock(ip); xfs_iunlock(ip, XFS_ILOCK_EXCL); } else { /* * If the flush lock is not already held then temporarily * acquire it to synchronize with xfs_iflush_done. */ xfs_iflock(ip); xfs_ifunlock(ip); } From owner-xfs@oss.sgi.com Fri Dec 14 12:31:05 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 14 Dec 2007 12:31:11 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_62 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBEKV2nU000873 for ; Fri, 14 Dec 2007 12:31:05 -0800 X-ASG-Debug-ID: 1197664273-61f9009e0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from pentafluge.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id A3CD3484C49 for ; Fri, 14 Dec 2007 12:31:14 -0800 (PST) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by cuda.sgi.com with ESMTP id ihk6y9VIWmsR6qXv for ; Fri, 14 Dec 2007 12:31:14 -0800 (PST) Received: from hch by pentafluge.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1J3HBB-0006CP-Nr; Fri, 14 Dec 2007 20:30:41 +0000 Date: Fri, 14 Dec 2007 20:30:41 +0000 From: Christoph Hellwig To: Lachlan McIlroy Cc: xfs-dev , xfs-oss X-ASG-Orig-Subj: Re: [PATCH] prevent panic during log recovery due to bogus operation header length Subject: Re: [PATCH] prevent panic during log recovery due to bogus operation header length Message-ID: <20071214203041.GB23564@infradead.org> References: <475F88C3.709@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <475F88C3.709@sgi.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: pentafluge.infradead.org[213.146.154.40] X-Barracuda-Start-Time: 1197664274 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36621 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5122/Fri Dec 14 10:51:12 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13949 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs On Wed, Dec 12, 2007 at 06:07:47PM +1100, Lachlan McIlroy wrote: > A problem was reported where a system panicked in log recovery due > to a corrupt log record. The cause of the corruption is not known > but this change will at least prevent a crash for this specific > scenario. Log recovery definitely needs some more work in this area. > > Lachlan > --- fs/xfs/xfs_log_recover.c_1.332 2007-12-12 17:14:57.000000000 +1100 > +++ fs/xfs/xfs_log_recover.c 2007-12-12 17:15:42.000000000 +1100 > @@ -2912,7 +2912,12 @@ xlog_recover_process_data( > xlog_recover_new_tid(&rhash[hash], tid, > be64_to_cpu(rhead->h_lsn)); > } else { > - ASSERT(dp + be32_to_cpu(ohead->oh_len) <= lp); > + if (dp + be32_to_cpu(ohead->oh_len) > lp) { > + xlog_warn( > + "XFS: xlog_recover_process_data: bad length"); > + ASSERT(0); > + return (XFS_ERROR(EIO)); > + } this still gives a panic for debug builds.. Maybe this should become a WARN_ON(1) instead? From owner-xfs@oss.sgi.com Fri Dec 14 12:33:17 2007 Received: with ECARTIS (v1.0.0; list xfs); Fri, 14 Dec 2007 12:33:19 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBEKXFOQ001591 for ; Fri, 14 Dec 2007 12:33:17 -0800 X-ASG-Debug-ID: 1197664405-4eab01b90000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from pentafluge.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 3AE90484C7D; Fri, 14 Dec 2007 12:33:25 -0800 (PST) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by cuda.sgi.com with ESMTP id 2jrOM6a6CsaDvRg7; Fri, 14 Dec 2007 12:33:25 -0800 (PST) Received: from hch by pentafluge.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1J3HDn-0006E8-GB; Fri, 14 Dec 2007 20:33:23 +0000 Date: Fri, 14 Dec 2007 20:33:23 +0000 From: Christoph Hellwig To: Lachlan McIlroy Cc: xfs-dev , xfs-oss X-ASG-Orig-Subj: Re: [PATCH] make xfs_idestroy() wait for log I/O to complete Subject: Re: [PATCH] make xfs_idestroy() wait for log I/O to complete Message-ID: <20071214203323.GC23564@infradead.org> References: <475F8BC3.8020804@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <475F8BC3.8020804@sgi.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: pentafluge.infradead.org[213.146.154.40] X-Barracuda-Start-Time: 1197664407 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36621 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5122/Fri Dec 14 10:51:12 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13950 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs On Wed, Dec 12, 2007 at 06:20:35PM +1100, Lachlan McIlroy wrote: > An xfs inode can be destroyed before log I/O involving that inode > is complete. We need to wait for the inode to be unpinned before > tearing it down. The patch looks big but the only real change is > adding a call to xfs_iunpin_wait() to the start of xfs_idestroy(). > The rest of the patch is moving xfs_idestroy() after the pinning > routines. Making sure the inode is unpinned before it's destroyed definitvely sounds useful. I can't think of any harm this might cause either. I'd prefer to have to commits, one to move the function around and one to add the call to xfs_iunpin_wait, though. From owner-xfs@oss.sgi.com Sat Dec 15 20:35:51 2007 Received: with ECARTIS (v1.0.0; list xfs); Sat, 15 Dec 2007 20:35:55 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_43 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBG4ZmBF018656 for ; Sat, 15 Dec 2007 20:35:51 -0800 X-ASG-Debug-ID: 1197779757-34a600eb0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 5865A115D7F2 for ; Sat, 15 Dec 2007 20:35:58 -0800 (PST) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id m3WCXpqWdN0sm5Kj for ; Sat, 15 Dec 2007 20:35:58 -0800 (PST) Received: from Liberator.local (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id A516B182DD1D9; Sat, 15 Dec 2007 22:35:20 -0600 (CST) Message-ID: <4764AB08.7040608@sandeen.net> Date: Sat, 15 Dec 2007 22:35:20 -0600 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Alex Madarasz CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Fedora 8.0.1 XFS Tune on HW RAID for Max Write Throughput? Subject: Re: Fedora 8.0.1 XFS Tune on HW RAID for Max Write Throughput? References: <1197653927.3841.1226620089@webmail.messagingengine.com> In-Reply-To: <1197653927.3841.1226620089@webmail.messagingengine.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1197779760 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36749 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5140/Sat Dec 15 13:09:37 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13951 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Alex Madarasz wrote: > We're building a new Fedora 8.0.1 Linux system to stream data from a > 250Msps ADC to disk, and want to start tuning the system configuration > for maximum XFS write performance. To date, without any significant > effort at tuning our Fedora 7 dev system, we're seeing 250MBps write > with 8-bit samples and ~ 300MBps write with 16-bit samples. We want to > push the tuning as far as we can go with this architecture before we > start looking at other hardware options. Looking at various other > tuning pages on the Web finds few that are interested in maxing out > sequential writes to very large arrays while using SAS HW RAID with big > fast SAS drives too. ... > XFS Tuning Options? > > - HW RAID0: > - Array/logical disk HW RAID stripe size? At any rate you'll want to match xfs's geometry with the raid geometry. > - Cache enabled (some reports that cache s/b turned off?)? If it's battery-backed cache, leave it on, and disable barriers in xfs (it's a mount option) > - xfs mkfs / mount options? David mentioned these before as a generic place to start: # mkfs.xfs -f -l lazy-count=1,version=2,size=128m -i attr=2 -d agcount=4 # mount -o logbsize=256k and that those would be upcoming new defaults for mkfs. 4 ags may not be what you want for a ~2T filesystem. > - External Log? > - How big a partition on the E200i? > - mkfs / mount options? not sure if an external log would be beneficial or not. I'm sure others will have more concrete suggestions. It might be interesting to post any performance you're getting which does not meet your expectations... -Eric > > ...? > > Thanks for any tips, > From owner-xfs@oss.sgi.com Sun Dec 16 01:07:27 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 16 Dec 2007 01:07:30 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_43 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBG97Ppe012341 for ; Sun, 16 Dec 2007 01:07:27 -0800 X-ASG-Debug-ID: 1197796054-700500240000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from lucidpixels.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 8AA6C48A24E for ; Sun, 16 Dec 2007 01:07:35 -0800 (PST) Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by cuda.sgi.com with ESMTP id ZvV3khJOGUkupChM for ; Sun, 16 Dec 2007 01:07:35 -0800 (PST) Received: by lucidpixels.com (Postfix, from userid 1001) id 722FC1C000267; Sun, 16 Dec 2007 04:07:03 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id 700E340195BB; Sun, 16 Dec 2007 04:07:03 -0500 (EST) Date: Sun, 16 Dec 2007 04:07:03 -0500 (EST) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: Eric Sandeen cc: Alex Madarasz , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Fedora 8.0.1 XFS Tune on HW RAID for Max Write Throughput? Subject: Re: Fedora 8.0.1 XFS Tune on HW RAID for Max Write Throughput? In-Reply-To: <4764AB08.7040608@sandeen.net> Message-ID: References: <1197653927.3841.1226620089@webmail.messagingengine.com> <4764AB08.7040608@sandeen.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Barracuda-Connect: lucidpixels.com[75.144.35.66] X-Barracuda-Start-Time: 1197796057 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36766 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5140/Sat Dec 15 13:09:37 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13952 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs On Sat, 15 Dec 2007, Eric Sandeen wrote: > Alex Madarasz wrote: >> We're building a new Fedora 8.0.1 Linux system to stream data from a >> 250Msps ADC to disk, and want to start tuning the system configuration >> for maximum XFS write performance. To date, without any significant >> effort at tuning our Fedora 7 dev system, we're seeing 250MBps write >> with 8-bit samples and ~ 300MBps write with 16-bit samples. We want to >> push the tuning as far as we can go with this architecture before we >> start looking at other hardware options. Looking at various other >> tuning pages on the Web finds few that are interested in maxing out >> sequential writes to very large arrays while using SAS HW RAID with big >> fast SAS drives too. > > ... > >> XFS Tuning Options? >> >> - HW RAID0: >> - Array/logical disk HW RAID stripe size? > > At any rate you'll want to match xfs's geometry with the raid geometry. > >> - Cache enabled (some reports that cache s/b turned off?)? > > If it's battery-backed cache, leave it on, and disable barriers in xfs > (it's a mount option) > >> - xfs mkfs / mount options? > > David mentioned these before as a generic place to start: > > # mkfs.xfs -f -l lazy-count=1,version=2,size=128m -i attr=2 -d agcount=4 > > # mount -o logbsize=256k > > and that those would be upcoming new defaults for mkfs. > > 4 ags may not be what you want for a ~2T filesystem. > >> - External Log? >> - How big a partition on the E200i? >> - mkfs / mount options? > > not sure if an external log would be beneficial or not. > > I'm sure others will have more concrete suggestions. It might be > interesting to post any performance you're getting which does not meet > your expectations... > > -Eric > >> >> ...? >> >> Thanks for any tips, >> > > I have a question, if he exported all of the HDD as JBOD and then made a software raid, took those software raid creation parameters and then re-made the HW raid, would they still apply to the HW raid? Justin. From owner-xfs@oss.sgi.com Sun Dec 16 08:33:48 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 16 Dec 2007 08:34:01 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBGGXli1025633 for ; Sun, 16 Dec 2007 08:33:48 -0800 X-ASG-Debug-ID: 1197822836-6318026c0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from verein.lst.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 16D56116635C for ; Sun, 16 Dec 2007 08:33:56 -0800 (PST) Received: from verein.lst.de (verein.lst.de [213.95.11.210]) by cuda.sgi.com with ESMTP id G5hPHLoEZL1m4sf1 for ; Sun, 16 Dec 2007 08:33:56 -0800 (PST) Received: from verein.lst.de (localhost [127.0.0.1]) by verein.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id lBGGXnF3002356 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sun, 16 Dec 2007 17:33:49 +0100 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id lBGGXndK002354 for xfs@oss.sgi.com; Sun, 16 Dec 2007 17:33:49 +0100 Date: Sun, 16 Dec 2007 17:33:49 +0100 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 2/2] keep i_nlink updated and use proper accessors Subject: [PATCH 2/2] keep i_nlink updated and use proper accessors Message-ID: <20071216163349.GA2107@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-Barracuda-Connect: verein.lst.de[213.95.11.210] X-Barracuda-Start-Time: 1197822840 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36795 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5145/Sun Dec 16 03:23:51 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13953 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs To get the read-only bind mounts in -mm to work correctly with XFS we need to call the drop_nlink and inc_nlink helpers to monitor the link count. Add calls to these to xfs_bumplink and xfs_droplink and stop copying over di_nlink to i_nlink in xfs_validate_fields and vn_revalidate. Signed-off-by: Christoph Hellwig Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_iops.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_iops.c 2007-09-30 20:09:32.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_iops.c 2007-09-30 20:16:43.000000000 +0200 @@ -184,7 +184,6 @@ xfs_validate_fields( struct xfs_inode *ip = XFS_I(inode); loff_t size; - inode->i_nlink = ip->i_d.di_nlink; /* we're under i_sem so i_size can't change under us */ size = XFS_ISIZE(ip); if (i_size_read(inode) != size) Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_vnode.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_vnode.c 2007-09-30 20:09:32.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_vnode.c 2007-09-30 20:16:31.000000000 +0200 @@ -117,7 +117,6 @@ vn_revalidate( xfs_ilock(ip, XFS_ILOCK_SHARED); inode->i_mode = ip->i_d.di_mode; - inode->i_nlink = ip->i_d.di_nlink; inode->i_uid = ip->i_d.di_uid; inode->i_gid = ip->i_d.di_gid; inode->i_mtime.tv_sec = ip->i_d.di_mtime.t_sec; Index: linux-2.6-xfs/fs/xfs/xfs_utils.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_utils.c 2007-09-30 20:09:32.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_utils.c 2007-09-30 20:16:06.000000000 +0200 @@ -302,6 +302,7 @@ xfs_droplink( ASSERT (ip->i_d.di_nlink > 0); ip->i_d.di_nlink--; + drop_nlink(ip->i_vnode); xfs_trans_log_inode(tp, ip, XFS_ILOG_CORE); error = 0; @@ -365,6 +366,7 @@ xfs_bumplink( ASSERT(ip->i_d.di_nlink > 0); ip->i_d.di_nlink++; + inc_nlink(ip->i_vnode); if ((ip->i_d.di_version == XFS_DINODE_VERSION_1) && (ip->i_d.di_nlink > XFS_MAXLINK_1)) { /* From owner-xfs@oss.sgi.com Sun Dec 16 08:33:51 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 16 Dec 2007 08:34:02 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id lBGGXpoE025647 for ; Sun, 16 Dec 2007 08:33:51 -0800 X-ASG-Debug-ID: 1197822838-4ff601c70000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from verein.lst.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id E829848B6D2 for ; Sun, 16 Dec 2007 08:33:59 -0800 (PST) Received: from verein.lst.de (verein.lst.de [213.95.11.210]) by cuda.sgi.com with ESMTP id ZbqSSKWGrjgHMAbc for ; Sun, 16 Dec 2007 08:33:59 -0800 (PST) Received: from verein.lst.de (localhost [127.0.0.1]) by verein.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id lBGGXrF3002372 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sun, 16 Dec 2007 17:33:53 +0100 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id lBGGXq1b002370 for xfs@oss.sgi.com; Sun, 16 Dec 2007 17:33:52 +0100 Date: Sun, 16 Dec 2007 17:33:52 +0100 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 1/2] stop updating inode->i_blocks Subject: [PATCH 1/2] stop updating inode->i_blocks Message-ID: <20071216163352.GB2107@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-Barracuda-Connect: verein.lst.de[213.95.11.210] X-Barracuda-Start-Time: 1197822842 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.0 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.36796 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/5145/Sun Dec 16 03:23:51 2007 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 13954 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs The VFS doesn't use i_blocks, it's only used by generic_fillattr and the generic quota code which XFS doesn't use. In XFS there is one use to check whether we have an inline or out of line sumlink, but we can replace that with a check of the XFS_IFINLINE inode flag. Signed-off-by: Christoph Hellwig Index: linux-2.6-xfs/fs/xfs/dmapi/xfs_dm.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/dmapi/xfs_dm.c 2007-11-30 10:14:10.000000000 +0100 +++ linux-2.6-xfs/fs/xfs/dmapi/xfs_dm.c 2007-11-30 10:18:38.000000000 +0100 @@ -2503,11 +2503,6 @@ xfs_dm_punch_hole( */ if (!error && (len == 0)) { error = xfs_free_eofblocks(mp, ip, XFS_FREE_EOF_NOLOCK); - if (!error) { - /* Update linux inode block count after free above */ - inode->i_blocks = XFS_FSB_TO_BB(mp, - ip->i_d.di_nblocks + ip->i_delayed_blks); - } } /* Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_iops.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_iops.c 2007-11-30 10:15:48.000000000 +0100 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_iops.c 2007-11-30 10:18:38.000000000 +0100 @@ -202,9 +202,6 @@ xfs_validate_fields( loff_t size; inode->i_nlink = ip->i_d.di_nlink; - inode->i_blocks = - XFS_FSB_TO_BB(ip->i_mount, ip->i_d.di_nblocks + - ip->i_delayed_blks); /* we're under i_sem so i_size can't change under us */ size = XFS_ISIZE(ip); if (i_size_read(inode) != size) Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_super.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_super.c 2007-11-30 10:15:48.000000000 +0100 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_super.c 2007-11-30 10:18:38.000000000 +0100 @@ -568,7 +568,7 @@ xfs_set_inodeops( break; case S_IFLNK: inode->i_op = &xfs_symlink_inode_operations; - if (inode->i_blocks) + if (!(XFS_I(inode)->i_df.if_flags & XFS_IFINLINE)) inode->i_mapping->a_ops = &xfs_address_space_operations; break; default: @@ -605,8 +605,6 @@ xfs_revalidate_inode( inode->i_generation = ip->i_d.di_gen; i_size_write(inode, ip->i_d.di_size); - inode->i_blocks = - XFS_FSB_TO_BB(mp, ip->i_d.di_nblocks + ip->i_delayed_blks); inode->i_atime.tv_sec = ip->i_d.di_atime.t_sec; inode->i_atime.tv_nsec = ip->i_d.di_atime.t_nsec; inode->i_mtime.tv_sec = ip->i_d.di_mtime.t_sec; Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_vnode.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_vnode.c 2007-11-30 10:14:10.000000000 +0100 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_vnode.c 2007-11-30 10:18:38.000000000 +0100 @@ -106,8 +106,6 @@ vn_revalidate( inode->i_nlink = ip->i_d.di_nlink; inode->i_uid = ip->i_d.di_uid; inode->i_gid = ip->i_d.di_gid; - inode->i_blocks = - XFS_FSB_TO_BB(mp, ip->i_d.di_nblocks + ip->i_delayed_blks); inode->i_mtime.tv_sec = ip->i_d.di_mtime.t_sec; inode->i_mtime.tv_nsec = ip->i_d.di_mtime.t_nsec; inode->i_ctime.tv_sec = ip->i_d.di_ctime.t_sec; Index: linux-2.6-xfs/fs/xfs/xfs_vnodeops.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_vnodeops.c 2007-11-30 10:14:10.000000000 +0100 +++ linux-2.6-xfs/fs/xfs/xfs_vnodeops.c 2007-11-30 10:18:38.000000000 +0100 @@ -1557,9 +1557,6 @@ xfs_release( error = xfs_free_eofblocks(mp, ip, XFS_FREE_EOF_LOCK); if (error) return error; - /* Update linux inode block count after free above */ - vn_to_inode(vp)->i_blocks = XFS_FSB_TO_BB(mp, - ip->i_d.di_nblocks + ip->i_delayed_blks); } } @@ -1633,9 +1630,6 @@ xfs_inactive( error = xfs_free_eofblocks(mp, ip, XFS_FREE_EOF_LOCK); if (error) return VN_INACTIVE_CACHE; - /* Update linux inode block count after free above */ - vn_to_inode(vp)->i_blocks = XFS_FSB_TO_BB(mp, - ip->i_d.di_nblocks + ip->i_delayed_blks); } goto out; } From owner-xfs@oss.sgi.com Sun Dec 16 13:41:50 2007 Received: with ECARTIS (v1.0.0; list xfs); Sun, 16 Dec 200