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: